Comunicar el impacto de GitHub Copilot

Si gestiona un Copilot despliegue, un informe de liderazgo debe hacer más que mostrar que el uso está creciendo. Debe explicar qué significa la evidencia para sus objetivos de ingeniería y recomendar una decisión.

Este tutorial le ayuda a convertir las métricas y los comentarios de los desarrolladores en un breve informe. En el ejemplo siguiente se muestra cómo recomendar una expansión limitada sin reclamar que Copilot provocó cada mejora observada.

Prerequisites

Recopile los Copilot datos de uso, los registros de gasto, las medidas de resultados de ingeniería y los comentarios del desarrollador. Trabaje con las personas responsables de las métricas y la facturación si no tiene acceso a esas fuentes.

Para obtener instrucciones sobre el acceso a los datos de uso y gasto, incluidos los permisos necesarios, consulte:

• Visualización del panel de métricas de uso de Copilot
• Administración del gasto de su empresa en GitHub Copilot

Elija medidas de resultados que coincidan con los objetivos de despliegue antes de preparar el informe. Consulte Lograr los objetivos de ingeniería de tu empresa con GitHub Copilot.

Paso 1: Definir la decisión

Anote la decisión que desea que el informe respalde y quién la tomará. Por ejemplo, decida si desea renovar licencias, expandir un lanzamiento o invertir en el entrenamiento.

Elija evidencia que responda a las preguntas del responsable de la toma de decisiones:

• Para una revisión ejecutiva, conecte la adopción a los objetivos de ingeniería que importan a la dirección. Resumir el progreso, los costos y los riesgos restantes.
• Para una renovación, explique el uso sostenido y el valor observado junto con el gasto. Identifique las brechas de adopción y el plan para abordarlas.
• Para una solicitud de inversión, explique qué equipos o flujos de trabajo apoyar a continuación. Indique el presupuesto propuesto, los resultados esperados y cómo evaluará la inversión.

Use la misma evidencia subyacente para estas conversaciones, pero empiece por los hallazgos que importan para la decisión.

Paso 2: Establecer la comparación

Haga que el ámbito del informe sea explícito para que los lectores puedan comprender lo que ha cambiado.

1. Registre las organizaciones, los equipos y los repositorios incluidos.
2. Indique las fechas de informe y la línea base con la que se compara. Use períodos comparables y explique las diferencias que haya en su longitud.
3. Registre la población correspondiente a cada medida. Por ejemplo, distinguir licencias asignadas, usuarios activos y personas encuestadas.
4. Tenga en cuenta los cambios en el personal, la complejidad del proyecto, las programaciones de versión o las prácticas de ingeniería que podrían afectar a los resultados.

Si no tiene una línea de base de lanzamiento previa, dígalo. Utilice el primer período confiable para iniciar el seguimiento de las tendencias, sin describirlo como una comparación del antes y el después de la adopción.

No suponga que los totales de panel y API son intercambiables. Compruebe sus periodos de generación de informes y poblaciones antes de combinarlas. Consulte Conciliación de métricas de uso de Copilot en paneles, API e informes.

Paso 3: Ensamblar la evidencia

Seleccione un pequeño conjunto de señales que ayude a responder a su pregunta de decisión. Para cada hallazgo, registre su origen, período, ámbito y los datos que faltan.

Crea el informe a partir de estos tipos de pruebas:

• Adopción: Utilice tendencias de usuario activo, uso sostenido y cohortes de adopción para explicar quién usa Copilot y cómo cambia el uso.
• Costo: Utilice registros de gasto para describir los costos de licencia y los cargos de uso adicionales. Informe AI credits el consumo por separado de los gastos facturados. Incluya costos de formación o administración en la evaluación de la inversión y etiquete las estimaciones.
• Generación de código: Utilice las tendencias de generación de código y líneas de código para describir la actividad. No considere más código generado como prueba de mayor productividad, mejor calidad o valor entregado.
• Entrega: Compare la cadencia de procesamiento y el tiempo de fusión de las solicitudes de incorporación de cambios con los objetivos de entrega seleccionados.
• Calidad: Incluya la cobertura de pruebas, defectos, hallazgos de seguridad o incidentes pertinentes para que la entrega más rápida no se evalúe de forma aislada.
• Comentarios de los desarrolladores: Resumir dónde los desarrolladores notifican ayuda útil, trabajo de revisión adicional o barreras de flujo de trabajo. Incluya el número de encuestados y explique cómo ha recopilado sus comentarios.

Utilice herramientas de facturación para determinar el gasto, en lugar de presentar la telemetría de uso como un total de factura.

Paso 4: Separar las observaciones de las conclusiones

Para cada hallazgo, escriba lo que observó antes de explicar lo que piensa que significa. Por ejemplo, "Teams con una adopción más profunda fusionaron más solicitudes de incorporación de cambios por usuario" describe una asociación. "Copilot hizo que esos equipos sean más productivos" afirma una causa que la comparación por sí sola no establece.

Para obtener instrucciones sobre cómo interpretar comparaciones y estimaciones del panel, consulte Interpretación del uso y las métricas de adopción para GitHub Copilot.

Evite presentar tasas de crecimiento de uso o aceptación como una historia de éxito por sí misma. Explique cómo se relacionan con los resultados elegidos e incluya resultados que no mejoraron.

No convierta líneas de código generadas ni ahorros de tiempo notificados directamente en rendimientos financieros. Si incluye una estimación del ahorro, documente las suposiciones y valide con el equipo financiero. Distinga el tiempo disponible para otro trabajo de una reducción real del gasto.

Paso 5: Escribir la narración

Mantenga el informe principal corto, con fuentes auxiliares disponibles para los lectores que necesitan más detalles.

1. Indique la decisión y el objetivo. Explique lo que desea que se apruebe y qué problema de ingeniería soluciona.

2. Resuma la evidencia. Describir la adopción, el gasto y los resultados más relevantes para ese objetivo.

3. Explica las limitaciones. Indique lo que no es seguro, lo que ha cambiado y lo que la evidencia no puede establecer.

4. Recomiende una acción. Explique por qué la evidencia apoya esa acción en lugar de un compromiso más amplio.

   • Si la adopción es desigual, solucione las barreras de configuración o entrenamiento antes de interpretar el bajo uso como falta de valor.
   • Si la adopción se mantiene, pero la evidencia de resultados es limitada, continúe midiendo con respecto a la línea base antes de realizar un compromiso mayor.
   • Si los resultados y los comentarios respaldan la expansión, proponga un despliegue por fases con un presupuesto y criterios de revisión.
   • Si los costos o los resultados de calidad son inaceptables, recomiende ajustar o pausar el lanzamiento afectado mientras investiga el problema.

5. Defina la siguiente revisión. Asigne un responsable a la acción acordada, indique cómo será el éxito y programe la siguiente revisión. Mantenga el ámbito y las definiciones de informes coherentes para que el siguiente informe pueda mostrar si la acción ayudó.

Por ejemplo, un responsable hipotético del despliegue podría notificar:

Se recomienda ampliar el lanzamiento a un equipo adicional de 15 desarrolladores, con un presupuesto propuesto de 2000 USD para licencias, uso y entrenamiento durante octubre. Nuestro objetivo es reducir el tiempo de pull request para fusionarse sin reducir la calidad.

En septiembre, 40 de 50 desarrolladores con licencia usaron Copilot, en comparación con 30 de 50 en agosto, nuestro mes de línea base. El tiempo medio de pull request hasta la fusión se redujo de tres días a dos días y medio. En una encuesta de equipo, 28 de 35 encuestados informaron de ayuda con la escritura de pruebas, pero la cobertura de pruebas no cambió.

El gasto se mantuvo dentro del presupuesto de despliegue. No se puede atribuir el cambio de entrega solo a Copilot porque el equipo también cambió su proceso de revisión.

El propietario del lanzamiento agregará entrenamiento de escritura de pruebas y revisará la adopción, el gasto, la cobertura y los comentarios de los desarrolladores a finales de octubre. La expansión adicional dependerá de que el tiempo mediano de integración se mantenga en dos días y medio o menos, de que aumente la cobertura de las pruebas y de que el gasto permanezca dentro del presupuesto.

Reemplace las cifras y la recomendación del ejemplo por sus propias pruebas. Si el informe admite una renovación, haga explícita la recomendación de renovación. Para una solicitud de inversión, especifique los recursos necesarios en lugar de implicar que las tendencias observadas garantizan resultados futuros.