Comunicar o impacto do GitHub Copilot

Se você gerenciar uma Copilot implantação, um relatório de liderança precisará fazer mais do que mostrar que o uso está crescendo. Ele precisa explicar o que as evidências significam para suas metas de engenharia e recomendar uma decisão.

Este tutorial ajuda você a transformar métricas e comentários do desenvolvedor em um relatório curto. O exemplo a seguir mostra como recomendar uma expansão limitada sem alegar que Copilot causou cada melhoria observada.

Prerequisites

Reúna seus Copilot dados de uso, registros de gastos, medidas de resultado de engenharia e comentários do desenvolvedor. Trabalhe com as pessoas responsáveis por métricas e cobrança se você não tiver acesso a essas fontes.

Para obter instruções sobre como acessar dados de uso e gastos, incluindo as permissões necessárias, consulte:

Escolha medidas de resultado que correspondam aos seus objetivos da implantação antes de preparar o relatório. Consulte Alcançar as metas de engenharia da sua empresa com o GitHub Copilot.

Etapa 1: Definir a decisão

Anote a decisão que você deseja que o relatório apoie e quem a tomará. Por exemplo, decida se deseja renovar licenças, expandir uma implantação ou investir em treinamento.

Escolha evidências que respondam às perguntas do tomador de decisão:

Para uma revisão executiva, conecte a adoção às metas de engenharia que importam à liderança. Resumir o progresso, os custos e os riscos restantes.
Para uma renovação, explique o uso sustentado e o valor observado junto com os gastos. Identifique as lacunas de adoção e o plano para resolvê-las.
Para uma solicitação de investimento, explique quais equipes ou fluxos de trabalho devem receber suporte em seguida. Declare o orçamento proposto, os resultados esperados e como você avaliará o investimento.

Use as mesmas evidências subjacentes para essas conversas, mas comece pelas conclusões que importam para a decisão.

Etapa 2: estabelecer a comparação

Torne o escopo do relatório explícito para que os leitores possam entender o que mudou.

Registre as organizações, as equipes e os repositórios incluídos.
Informe as datas de relatório e a linha de base com a qual você está comparando. Use períodos comparáveis e explique quaisquer diferenças em sua duração.
Registre a população associada a cada medida. Por exemplo, distingue licenças atribuídas, usuários ativos e respondentes da pesquisa.
Observe alterações na equipe, complexidade do projeto, agendas de lançamento ou práticas de engenharia que podem afetar os resultados.

Se você não tiver uma linha de base de pré-distribuição, diga isso. Use o período confiável mais antigo para iniciar o acompanhamento de tendências, sem descrevê-lo como uma comparação antes e depois da adoção.

Não suponha que os totais de dashboard e de API sejam intercambiáveis. Verifique suas janelas de relatórios e populações antes de combiná-las. Consulte Reconciliando métricas de uso do Copilot entre dashboards, APIs e relatórios.

Etapa 3: Reunir as evidências

Selecione um pequeno conjunto de sinais que ajuda a responder à sua pergunta de decisão. Para cada descoberta, registre sua origem, período, escopo e eventuais dados ausentes.

Crie seu relatório com base nesses tipos de evidência:

Adoção: Use tendências de usuários ativos, uso sustentado e coortes de adoção para explicar quem está usando Copilot e como o uso está mudando.
Custo: Use os registros de gastos para descrever os custos de licença e encargos de uso adicionais. Informe AI credits o consumo separadamente dos gastos cobrados. Inclua os custos de treinamento ou administração em sua avaliação de investimento e identifique as estimativas.
Geração de código: Use tendências de geração de código e linhas de código para descrever a atividade. Não trate mais código gerado como prova de maior produtividade, melhor qualidade ou valor entregue.
Entrega: Compare o throughput de pull requests e o tempo para mesclar com as metas de entrega que você selecionou.
Qualidade: Inclua cobertura de teste relevante, defeitos, descobertas de segurança ou incidentes para que a entrega mais rápida não seja avaliada isoladamente.
Comentários do desenvolvedor: Resumir onde os desenvolvedores relatam assistência útil, trabalho de revisão extra ou barreiras de fluxo de trabalho. Inclua o número de respondentes e explique como você reuniu seu feedback.

Use ferramentas de cobrança para definir os gastos, em vez de apresentar a telemetria de uso como um total de fatura.

Etapa 4: Separar observações de conclusões

Para cada descoberta, escreva o que você observou antes de explicar o que você acha que significa. Por exemplo, "Equipes com maior adoção mesclaram mais pull requests por usuário" descreve uma associação. "Copilot tornou essas equipes mais produtivas" afirma uma causa que a comparação por si só não estabelece.

Para obter diretrizes sobre como interpretar comparações e estimativas do painel, consulte Interpretando métricas de uso e adoção para GitHub Copilot.

Evite apresentar o crescimento do uso ou as taxas de aceitação como uma história de sucesso por conta própria. Explique como eles se relacionam com os resultados escolhidos e inclua resultados que não melhoraram.

Não converta as linhas de código geradas ou a economia de tempo relatada diretamente em retornos financeiros. Se você incluir uma estimativa de poupança, documente as suposições e valide-as com sua equipe de finanças. Distinguir o tempo disponível para outras tarefas de uma redução real dos gastos.

Etapa 5: Escrever a narrativa

Mantenha o relatório principal curto, com fontes de suporte disponíveis para leitores que precisam de mais detalhes.

Declare a decisão e a meta. Explique o que você quer que seja aprovado e qual problema de engenharia ele aborda.
Resuma as evidências. Descreva a adoção, os gastos e os resultados mais relevantes para essa meta.
Explique as limitações. Declare o que é incerto, o que mais mudou, e o que as evidências não podem estabelecer.
Recomende uma ação. Explique por que as evidências apoiam essa ação em vez de um compromisso mais amplo.
- Se a adoção for desigual, resolva as barreiras de instalação ou treinamento antes de interpretar o baixo uso como falta de valor.
- Se a adoção for mantida, mas as evidências de resultado forem limitadas, continue medindo em relação à linha de base antes de assumir um compromisso maior.
- Se os resultados e os comentários apoiarem a expansão, proponha uma implantação em etapas com um orçamento e critérios de revisão.
- Se os custos ou os resultados de qualidade forem inaceitáveis, recomende ajustar ou pausar a implantação afetada enquanto você investiga.
Defina a próxima revisão. Atribua um responsável à ação acordada, defina como será o sucesso e agende a próxima revisão. Mantenha o escopo e as definições de relatório consistentes para que o próximo relatório possa mostrar se a ação ajudou.

Por exemplo, um responsável hipotético pelo rollout pode relatar:

Recomendamos expandir a distribuição para uma equipe adicional de 15 desenvolvedores, com um orçamento proposto de US$ 2.000 para licenças, uso e treinamento durante outubro. Nossa meta é reduzir o tempo de pull request até fazer merge sem reduzir a qualidade.

Em setembro, 40 dos 50 desenvolvedores licenciados usaram Copilot, contra 30 de 50 em agosto, nosso mês de linha de base. O tempo mediano de solicitação de pull para mesclagem caiu de três dias para dois dias e meio. Em uma pesquisa de equipe, 28 dos 35 entrevistados relataram ajuda com a escrita de testes, mas a cobertura do teste não foi alterada.

Os gastos permaneceram dentro do orçamento de implantação. Não é possível atribuir a alteração na entrega apenas a Copilot, porque a equipe também alterou seu processo de revisão.

O responsável pela implementação adicionará treinamento de escrita de testes e revisará a adoção, os gastos, a cobertura e os comentários dos desenvolvedores no final de outubro. A expansão adicional dependerá de o tempo mediano para mesclagem permanecer em ou abaixo de dois dias e meio, do aumento da cobertura de testes e de os gastos permanecerem dentro do orçamento.

Substitua os números e a recomendação do exemplo por suas próprias evidências. Se o relatório der suporte a uma renovação, torne a recomendação de renovação explícita. Para uma solicitação de investimento, especifique os recursos necessários em vez de implicar que as tendências observadas garantem retornos futuros.