Kommunizieren Sie die Auswirkungen von GitHub Copilot

Wenn Sie ein Copilot Rollout verwalten, muss ein Bericht für Führungskräfte mehr tun, als zu zeigen, dass die Nutzung wächst. Es muss erklären, was die Beweise für Ihre Engineeringziele bedeuten und eine Entscheidung empfehlen.

In diesem Lernprogramm können Sie Metriken und Entwicklerfeedback in einen kurzen Bericht umwandeln. Das folgende Beispiel zeigt, wie Sie eine begrenzte Erweiterung empfehlen, ohne behaupten zu müssen, dass Copilot jede beobachtete Verbesserung verursacht hat.

Voraussetzungen

Sammeln Sie Ihre Copilot Nutzungsdaten, Ausgabendaten, Technische Ergebnismaßnahmen und Entwicklerfeedback. Arbeiten Sie mit den für Metriken und Abrechnung verantwortlichen Personen zusammen, wenn Sie keinen Zugriff auf diese Quellen haben.

Anweisungen zum Zugreifen auf Nutzungs- und Ausgabendaten, einschließlich der erforderlichen Berechtigungen, finden Sie unter:

• Anzeigen des Dashboards für Copilot-Nutzungsmetriken
• Verwalten der Ausgaben Ihres Unternehmens für GitHub Copilot

Wählen Sie Ergebniskennzahlen aus, die Ihren Rolloutzielen entsprechen, bevor Sie den Bericht vorbereiten. Siehe Erreichen der Engineeringziele deines Unternehmens mit GitHub Copilot.

Schritt 1: Definieren der Entscheidung

Notieren Sie sich die Entscheidung, die der Bericht unterstützen soll, und wer sie treffen wird. Entscheiden Sie beispielsweise, ob Lizenzen verlängert, ein Rollout ausgeweitet oder in Schulungen investiert werden soll.

Wählen Sie Nachweise aus, die die Fragen des Entscheidungsträgers beantworten:

• Für eine Executive Review verbinden Sie die Akzeptanz mit den technischen Zielen, die für die Führung relevant sind. Fassen Sie Fortschritt, Kosten und verbleibende Risiken zusammen.
• Für eine Erneuerung erklären Sie die kontinuierliche Nutzung und den beobachteten Wert neben den Ausgaben. Identifizieren Sie Lücken bei der Einführung und den Plan, sie zu beheben.
• Erläutern Sie für eine Investitionsanfrage, welche Teams oder Workflows als Nächstes unterstützt werden sollen. Geben Sie das vorgeschlagene Budget, die erwarteten Ergebnisse und wie Sie die Investition bewerten werden an.

Verwenden Sie für diese Unterhaltungen dieselben zugrunde liegenden Erkenntnisse, beginnen Sie aber mit den Ergebnissen, die für die Entscheidung wichtig sind.

Schritt 2: Einrichten des Vergleichs

Legen Sie den Umfang Ihres Berichts explizit fest, damit Leser verstehen können, was sich geändert hat.

1. Erfassen Sie die enthaltenen Organisationen, Teams und Repositorys.
2. Geben Sie die Berichtstermine und die Ausgangsbasis an, mit der Sie vergleichen. Verwenden Sie vergleichbare Zeiträume, und erläutern Sie alle Unterschiede in ihrer Länge.
3. Notieren Sie die Population hinter jeder Kennzahl. Unterscheiden Sie beispielsweise zugewiesene Lizenzen, aktive Benutzer und Umfrageteilnehmer.
4. Beachten Sie Änderungen an Personal, Projektkomplexität, Veröffentlichungszeitplänen oder Entwicklungspraktiken, die sich auf die Ergebnisse auswirken könnten.

Wenn Sie keine Baseline vor dem Rollout haben, sagen Sie dies. Verwenden Sie den frühesten zuverlässigen Zeitraum, um trends nachzuverfolgen, ohne sie als Vor- und Nachher-Vergleich der Einführung zu beschreiben.

Gehen Sie nicht davon aus, dass Dashboard- und API-Summen austauschbar sind. Überprüfen Sie deren Berichtsfenster und -populationen, bevor Sie sie kombinieren. Siehe Abstimmung der Copilot-Nutzungsmetriken über Dashboards, APIs und Berichte hinweg.

Schritt 3: Nachweise zusammenstellen

Wählen Sie eine kleine Gruppe von Signalen aus, die Ihre Entscheidungsfrage beantworten können. Zeichnen Sie für jedes Ergebnis die Quelle, den Zeitraum, den Bereich und alle fehlenden Daten auf.

Erstellen Sie Ihren Bericht anhand dieser Nachweistypen:

• Akzeptanz: Verwenden Sie Trends bei aktiven Nutzern, anhaltende Nutzungs- und Adoptionskohorten, um zu erklären, wer Copilot nutzt und wie sich die Nutzung ändert.
• Kosten: Verwenden Sie Ausgabendatensätze, um Lizenzkosten und zusätzliche Nutzungsgebühren zu beschreiben. Weisen Sie AI credits den Verbrauch getrennt von den in Rechnung gestellten Ausgaben separat aus. Schließen Sie Schulungs- oder Verwaltungskosten in Ihre Investitionsbewertung ein und kennzeichnen Sie Schätzungen.
• Code-Generierung: Verwenden Sie Code-Generierung und Trends bei den Codezeilen, um Aktivität zu beschreiben. Behandeln Sie mehr generierten Code nicht als Nachweis höherer Produktivität, besserer Qualität oder gelieferten Werts.
• Lieferung: Vergleichen Sie den Durchsatz von Pull Requests und die Zeit bis zum Zusammenführen mit den von Ihnen ausgewählten Lieferzielen.
• Qualität: Berücksichtigen Sie relevante Testabdeckungen, Mängel, Sicherheitsergebnisse oder Vorfälle, sodass eine schnellere Lieferung nicht isoliert bewertet wird.
• Entwicklerfeedback: Fassen Sie zusammen, wo Entwickler nützliche Unterstützung, zusätzliche Überprüfungsarbeit oder Workflowbarrieren melden. Geben Sie die Anzahl der Befragten ein, und erläutern Sie, wie Sie ihr Feedback gesammelt haben.

Verwenden Sie Abrechnungstools, um Ausgaben festzulegen, anstatt Nutzungstelemetrie als Rechnungssumme darzustellen.

Schritt 4: Trennen Sie Beobachtungen von Schlussfolgerungen

Schreiben Sie für jede Feststellung, was Sie beobachtet haben, bevor Sie erklären, was Sie meinen. Beispielsweise beschreibt „Teams mit stärkerer Nutzung mehr Pull Requests pro Benutzer zusammenführten“ eine Zuordnung. „Copilot diese Teams produktiver gemacht“ behauptet einen ursächlichen Zusammenhang, den der Vergleich allein nicht belegt.

Anleitungen zum Interpretieren von Dashboardvergleichen und Schätzungen finden Sie unter Interpretieren von Nutzungs- und Einführungsmetriken für GitHub Copilot.

Vermeiden Sie die Darstellung von Nutzungswachstumsraten oder Akzeptanzraten als Erfolgsgeschichte für sich genommen. Erläutern Sie, wie sie mit Ihren ausgewählten Ergebnissen zusammenhängen, und fügen Sie Ergebnisse hinzu, die nicht verbessert wurden.

Konvertieren Sie weder generierte Codezeilen noch berichtete Zeiteinsparungen direkt in finanzielle Renditen. Wenn Sie eine Einsparschätzung einschließen, dokumentieren Sie die Annahmen, und überprüfen Sie sie mit Ihrem Finanzteam. Unterscheiden Sie die für andere Arbeiten verfügbare Zeit von einer tatsächlichen Reduzierung der Ausgaben.

Schritt 5: Schreiben der Beschreibung

Halten Sie den Hauptbericht kurz, mit unterstützenden Quellen, die für Leser verfügbar sind, die weitere Details benötigen.

1. Geben Sie die Entscheidung und das Ziel an. Erläutern Sie, was Genehmigt werden soll, und welches technische Problem es betrifft.

2. Fassen Sie die Beweise zusammen. Beschreiben Sie die Nutzung, die Ausgaben und die Ergebnisse, die für dieses Ziel am relevantesten sind.

3. Erläutern Sie die Einschränkungen. Geben Sie an, was unsicher ist, was sonst noch geändert wurde und was die Beweise nicht festlegen können.

4. Empfehlen Sie eine Maßnahme. Erklären Sie, warum die Belege diese Maßnahme unterstützen, anstatt ein breiteres Engagement.

   • Wenn die Einführung ungleichmäßig ist, gehen Sie Setup- oder Schulungshürden an, bevor Sie eine geringe Nutzung als Mangel an Wert interpretieren.
   • Wenn die Einführung nachhaltig ist, aber die Belege für die Ergebnisse begrenzt sind, messen Sie weiter an der Baseline, bevor Sie ein größeres Engagement vornehmen.
   • Wenn Ergebnisse und Feedback die Erweiterung unterstützen, schlagen Sie einen mehrstufigen Rollout mit einem Budget und Überprüfungskriterien vor.
   • Wenn Kosten oder Qualitätsergebnisse inakzeptabel sind, empfehlen Sie, den betroffenen Rollout während der Untersuchung anzupassen oder anzuhalten.

5. Definieren Sie die nächste Überprüfung. Weisen Sie einen Verantwortlichen für die vereinbarte Aktion zu, geben Sie an, wie der Erfolg aussehen wird, und planen Sie die nächste Überprüfung. Halten Sie den Berichtsbereich und die Definitionen konsistent, damit der nächste Bericht anzeigen kann, ob die Aktion geholfen hat.

Ein hypothetischer Rolloutbesitzer könnte beispielsweise Folgendes melden:

Wir empfehlen, das Rollout auf ein zusätzliches Team von 15 Entwicklern mit einem vorgeschlagenen Budget von 2.000 $ für Lizenzen, Nutzung und Schulungen im Oktober zu erweitern. Unser Ziel ist es, die Zeit bis zum Merge eines Pull Requests zu verkürzen, ohne die Qualität zu senken.

Im September verwendeten 40 von 50 lizenzierten Entwicklern Copilot, im Vergleich zu 30 von 50 im August, unserem Basismonat. Die mittlere Pull-Request-Zeit bis zur Zusammenführung fiel von drei Tagen auf zweieinhalb Tage. In einer Teamumfrage gaben 28 von 35 Befragten an, Hilfe beim Schreiben von Tests erhalten zu haben, aber die Testabdeckung war unverändert.

Die Ausgaben blieben im Rolloutbudget. Wir können die Änderung bei der Auslieferung nicht allein Copilot zuordnen, da das Team auch seinen Überprüfungsprozess geändert hat.

Der Rolloutbesitzer wird Ende Oktober Testschreiben-Schulungen hinzufügen und Einführung, Ausgaben, Abdeckung und Entwicklerfeedback überprüfen. Eine weitere Erweiterung hängt davon ab, dass die Median-Zeit bis zum Merge bei oder unter zweieinhalb Tagen bleibt, die Testabdeckung zunimmt und die Ausgaben im Budget bleiben.

Ersetzen Sie die Zahlen und Empfehlung des Beispiels durch Ihre eigenen Nachweise. Wenn der Bericht für eine Verlängerung spricht, geben Sie die Empfehlung zur Verlängerung explizit an. Geben Sie für eine Investitionsanforderung die benötigten Ressourcen an, anstatt zu implizieren, dass beobachtete Trends zukünftige Renditen garantieren.