O playbook de sucesso de sistemas de engenharia do GitHub

• Para o sucesso em engenharia, é importante que haja equilíbrio entre três áreas: qualidade (Quality), velocidade (Velocity) e satisfação dos desenvolvedores (Happiness)
• O ESSP (Engineering System Success Playbook) fornece um framework de 3 etapas para melhorar esses aspectos de forma integrada e maximizar os resultados de negócio
• Com base em vários frameworks como SPACE, DevEx, DX Core 4 e DORA, ele permite entender a situação atual da organização por meio de 12 métricas principais, definir prioridades de acordo com os objetivos de melhoria e implementar e ajustar mudanças de forma gradual
  • Essas 12 métricas são estruturadas para acompanhar cada área de forma quantitativa e podem ser customizadas conforme o contexto de cada organização
• Todas as melhorias se baseiam na sustentabilidade no nível da equipe e no pensamento sistêmico, enfatizando uma abordagem equilibrada que considera indicadores antecedentes e indicadores defasados
• Busca-se uma transformação sustentável de longo prazo, em vez de melhorias rápidas
• É possível começar com o ESSP mesmo sem ferramentas próprias de medição, e diagnósticos iniciais por métodos qualitativos, como pesquisas, também são úteis
• O GitHub destaca, com base em seus próprios casos, que melhorias centradas em qualidade acabam tendo impacto positivo também na velocidade e na satisfação dos desenvolvedores

Métricas de sucesso em engenharia do GitHub

• Quality
  • Change failure rate: taxa de falha de mudanças
    → proporção de mudanças que causaram incidentes ou problemas
    • Cálculo: (número de deploys com falha / número total de deploys) × 100
    • Dica: a equipe deve alinhar claramente o que será considerado falha (ex.: necessidade de rollback, alerta de monitoramento etc.)
  • Failed deployment recovery time: tempo de recuperação de deploy com falha
    → tempo necessário para reverter um deploy com falha ou restaurar o sistema ao estado normal
    • Cálculo: mediana de momento de conclusão da recuperação − momento em que a falha ocorreu para cada deploy com falha
    • Dica: recomenda-se extrair isso automaticamente de sistemas de alerta ou logs. Prefira usar a mediana em vez da média para evitar o efeito de valores extremos
  • Code security and maintainability: segurança e manutenibilidade do código
    • Cálculo: avaliação abrangente de número de vulnerabilidades, complexidade, cobertura etc. por meio de ferramentas de análise estática, GitHub Advanced Security, CodeQL e afins
    • Dica: configure varreduras automáticas periódicas. Isso pode ser usado para medir o efeito de refatorações ou mudanças em políticas de segurança
• Velocity
  • Lead time: lead time
    → tempo até que uma mudança no código chegue à produção
    • Cálculo: tempo desde a criação do PR até o deploy após o merge
    • Dica: usar a mediana, e não a média, reduz distorções. Se o lead time estiver alto, meça separadamente o tempo de espera do PR ou o atraso nas revisões
  • Deployment frequency: frequência de deploy
    → com que frequência os deploys em produção acontecem
    • Cálculo: número de deploys em um determinado período (por dia/semana)
    • Dica: é preciso definir claramente se deploys automatizados também entram na conta; para equipes pequenas, uma base semanal pode ser mais adequada
  • PRs merged per developer: número de PRs com merge por desenvolvedor
    • Cálculo: número total de PRs com merge / número de desenvolvedores que contribuíram
    • Dica: use isso não como ferramenta de comparação, mas para medir a eficiência do fluxo de trabalho da equipe. É preciso interpretar junto com o tamanho ou a complexidade dos PRs
• Developer Happiness
  • Flow state experience: experiência de estado de fluxo
    • Cálculo: avaliação, por pesquisa com desenvolvedores, da “frequência/duração recente de experiências de fluxo”
    • Dica: recomenda-se uma pesquisa regular ao menos uma vez por mês. Incluir respostas dissertativas pode gerar insights qualitativos
  • Engineering tooling satisfaction: satisfação com as ferramentas de engenharia
    • Cálculo: coleta, por pesquisa com desenvolvedores, do nível de satisfação com o uso das ferramentas e dos pontos de melhoria desejados
    • Dica: separe por categorias detalhadas de ferramentas (IDE, CI, issue tracking etc.) para identificar pontos de melhoria mais práticos
  • Copilot satisfaction: satisfação com o uso do Copilot
    • Cálculo: pesquisa de satisfação com usuários que possuem licença do Copilot (NPS ou pontuação)
    • Dica: recomenda-se comparar diferentes momentos, como logo após a adoção e três meses depois. O feedback pode ajudar a melhorar treinamentos e casos de uso
• Business Outcomes
  • AI leverage: nível de uso de IA
    • Cálculo: participação do Copilot nos commits, taxa de adoção de sugestões de código por IA, tempo de uso etc.
    • Dica: é possível usar a Copilot Telemetry API do GitHub ou instrumentação interna. A análise fica mais eficaz quando combinada com feedback qualitativo
  • Engineering expenses to revenue: proporção entre custos de engenharia e receita
    • Cálculo: gastos relacionados à engenharia / receita total
    • Dica: é necessário organizar os critérios contábeis internos. Recomenda-se analisar tendências mensais ou trimestrais para comparação
  • Feature engineering expenses to total engineering expenses: proporção dos custos de desenvolvimento de funcionalidades no total de custos de engenharia
    • Cálculo: (gastos relacionados ao desenvolvimento de funcionalidades / gastos totais de engenharia)
    • Dica: para uma medição precisa, é preciso definir com antecedência critérios claros de classificação dos custos não relacionados a funcionalidades, como manutenção, infraestrutura e testes

[3 etapas para o sucesso em engenharia]

Step 1: Identify the current barriers to success

• Identificar os problemas no processo de desenvolvimento atual e os obstáculos que impedem o sucesso da engenharia é o ponto central
• Isso serve como linha de base (baseline) para definir a direção e as prioridades das melhorias futuras
• Abordagem
  • Analisar todo o fluxo do SDLC (Software Development Life Cycle) para identificar gargalos
  • No GitHub, a análise é feita com base em 12 métricas padrão, mas é possível usar apenas parte delas de acordo com as características da organização
• Participação da equipe
  • Em vez de um único líder, toda a equipe deve definir junto o processo de melhoria
  • Também é suficiente iniciar conversas significativas com apenas algumas métricas
• Metodologia

  • 1. Entender o fluxo básico

    • O fluxo geral de engenharia é dividido e analisado da seguinte forma:
      • Planejar (Plan) → Desenvolver (Develop) → Revisar (Review) → Build (Build) → Testar (Test) → Lançar (Release) → Operar (Operate)

  • 2. Coletar sinais quantitativos

    • São analisados dados quantitativos como os seguintes:
      • Frequência de deploy: com que frequência os deploys acontecem
      • Lead time: tempo entre a escrita do código e o deploy
      • Taxa de falha de mudanças: proporção de erros que ocorrem após o deploy
      • MTTR (tempo médio de recuperação): tempo necessário para recuperar após a ocorrência de um problema

  • 3. Coletar sinais qualitativos

    • Coletar feedback baseado na experiência de desenvolvedores e equipes:
      • Em que momento os membros da equipe sentem ineficiência
      • Quais ferramentas ou procedimentos causam problemas repetidamente
      • Quais atividades geram a maior carga psicológica
    • Métodos:
      • usar pesquisas, retrospectivas, entrevistas 1:1 etc.
      • também é possível usar uma lista pré-definida de perguntas do ESSP

  • 4. Definir os problemas centrais

    • Definir as barreiras (Barrier) com base nos dados coletados
    • Exemplos:
      • "O lead time é longo, o que atrasa o desenvolvimento de novos recursos"
      • "As falhas de build são frequentes, reduzindo a confiabilidade do deploy"
      • "Os desenvolvedores sofrem frequentemente com troca de contexto (context switching)"
    • O problema deve ser descrito de forma específica e observável

  • 5. Definir a prioridade das métricas

    • Em vez de melhorar todas as métricas de uma vez, focar em uma ou duas métricas com maior impacto
    • Essa prioridade servirá como critério para tentativas de melhoria e medição de resultados nas futuras Etapas 2 e 3
• Dicas para executar a Etapa 1 com sucesso
  • 1. Foque na causa raiz, não na aparência do problema
    • Não julgue apenas pelos sintomas superficiais; é preciso investigar profundamente a raiz do problema
      • Ex.: pode parecer que a lentidão é causada por “testes manuais”, mas a causa real pode ser falta de confiança nos testes automatizados
    • Para isso, é útil consultar antipadrões (antipatterns) comuns em engenharia de software
  • 2. Consulte antipadrões
    • Antipadrões são soluções usadas com frequência, mas que não resolvem de fato o problema e podem até gerar efeitos colaterais
    • O GitHub fornece, como recurso separado, exemplos de antipadrões que podem existir nas equipes, então isso pode ser usado como ferramenta de autoavaliação
  • 3. Envolva as pessoas certas
    • Na Task 1 da Etapa 1, é importante receber contribuições de pessoas com papéis diversos
      • Ex.: desenvolvedores, testers, operações, segurança, product managers etc.
    • Isso permite entender o workflow de forma mais completa e evita deixar passar perspectivas específicas
  • 4. Use dados quantitativos e qualitativos de forma equilibrada
    • Só as métricas não bastam para entender todo o contexto
    • Além da análise quantitativa, também é preciso coletar feedback qualitativo sobre questões psicológicas, culturais e de colaboração da equipe
    • Ex.: queda de moral da equipe, falhas de comunicação e reclamações em retrospectivas não aparecem nos números
  • 5. Não selecione barreiras demais
    • Em vez de tentar resolver tudo de uma vez, foque nas barreiras mais impactantes e urgentes
    • Se houver tarefas de melhoria demais logo no início, há risco de perder capacidade de execução e momentum
  • 6. Garanta segurança psicológica
    • É preciso criar um ambiente em que os membros da equipe possam falar com sinceridade sem medo de prejuízo ou retaliação
    • Isso é uma condição essencial para revelar os problemas reais e aumenta a confiabilidade e a eficácia das ações de melhoria
  • 7. Comparação serve para aprendizado, não para avaliação
    • Comparações de métricas entre equipes ou diferenças de workflow devem ser usadas para gerar insights, não para avaliar desempenho quantitativo
    • Como cada equipe tem contexto, objetivos, stack tecnológica e restrições diferentes, comparações simples podem gerar mal-entendidos
    • Em vez disso, deve-se incentivar uma cultura de aprendizado para compartilhar o que funciona bem e extrair lições

Etapa 2: Avalie o que precisa ser feito para alcançar sua meta-alvo

• Objetivo
  • Etapa de analisar quais mudanças precisam ser implementadas para resolver a questão central (Barrier) definida na Etapa 1
  • Vai além da simples adoção de funcionalidades ou troca de ferramentas, buscando identificar as causas-raiz e soluções em níveis organizacional, técnico e cultural

• 1. Análise das causas-raiz do estado atual

  • Em vez de ficar apenas no resultado de que “a velocidade é lenta” ou “a satisfação é baixa”, é preciso distinguir:
    • por que está lento,
    • quais razões estruturais e organizacionais existem,
    • e o que pode ou não ser mudado
  • Ferramentas que podem ser usadas:
    • técnica dos 5 Whys
    • diagrama espinha de peixe (causa e efeito)
    • análise de feedback qualitativo em retrospectivas de equipe

• 2. Levantamento de soluções possíveis

  • Fazer brainstorming de soluções técnicas, culturais e de processo para o problema
  • Exemplos:
    • técnico: melhorar a velocidade dos testes, aperfeiçoar o pipeline de CI/CD
    • cultural: ajustar práticas de code review, melhorar o onboarding
    • processo: limitar o tamanho de PRs, mudar critérios de merge
  • Técnica recomendada pelo GitHub:
    • combinar soluções baseadas em observação com melhorias centradas nas pessoas

• 3. Avaliação de impacto e riscos

  • Para cada solução, avaliar os seguintes elementos:
    • impacto esperado: em quais métricas de melhoria ela pode influenciar
    • viabilidade: recursos da equipe e capacidade realista de execução
    • aceitação organizacional: nível de resistência à mudança
    • distinção entre efeito de curto e longo prazo: se gera resultados rápidos ou mudanças sustentáveis
  • Para isso, recomenda-se um Pilot (operação piloto)
    • testar com uma equipe pequena, coletar feedback e depois decidir se vale expandir

• 4. Definição de prioridades e comunicação

  • Entre várias soluções, priorize com base nos seguintes critérios:
    • o que pode gerar o maior impacto
    • o que é mais executável
    • o que resolve o ponto de dor mais urgente
  • Essa decisão deve ser compartilhada com a equipe e construída com consenso, e
    • é recomendável registrá-la claramente na forma de OKRs ou metas de melhoria
• Dicas para executar a Etapa 2 com sucesso
  • 1. Considere obrigatoriamente a sustentabilidade de longo prazo
    • Focar apenas em ganhos de curto prazo pode acabar causando problemas no longo prazo
      • Ex.: introduzir uma nova ferramenta pode melhorar a velocidade imediatamente, mas, sem treinamento, suporte e gestão da mudança, pode acabar gerando erros e confusão
    • Portanto, qualquer tentativa de melhoria deve ser uma estratégia que também considere manutenção e possibilidade de expansão
  • 2. Considere os trade-offs entre as diferentes áreas (zones)
    • Tome cuidado para que uma mudança que melhore uma área (ex.: velocidade) não sacrifique outra (ex.: satisfação dos desenvolvedores, qualidade)
      • Ex.: relaxar os critérios de review pode aumentar a velocidade, mas piorar a qualidade do código ou a fadiga dos desenvolvedores
    • É sempre necessário um enfoque equilibrado, considerando que o impacto pode abranger várias áreas ao mesmo tempo
  • 3. Envolva a equipe desde o início
    • Quanto mais a equipe participa diretamente e ajuda a construir a mudança, maior a chance de sucesso
    • Reúna a opinião dos membros para que a mudança possa acontecer de forma bottom-up
    • Mudanças impostas unilateralmente de forma top-down podem gerar resistência e desinteresse
  • 4. Defina claramente os indicadores de sucesso
    • Antes de implementar a mudança, é preciso alinhar o que será considerado sucesso
    • Ex.: se a meta for “reduzir o tempo de deploy”,
      • indicador defasado: redução real no tempo de deploy
      • indicador antecedente: redução no tempo de espera de PRs, aumento nas respostas da pesquisa de desenvolvedores sobre “percepção de melhora na velocidade dos PRs”
    • O ideal é definir juntos Leading Indicators e Lagging Indicators
  • 5. Prefira experimentos rápidos em vez de planos perfeitos
    • Uma abordagem iterativa, em que mesmo pequenas mudanças são testadas rapidamente e melhoradas com feedback, é eficaz
      • No início, mesmo tentativas incompletas podem ser testadas em pequena escala e, se a eficácia for comprovada, ampliadas
    • Isso ajuda a reduzir a chance de fracasso e fortalece a agilidade e capacidade de adaptação da equipe diante da mudança
  • 6. Comece por mudanças que gerem grande efeito com pouco esforço
    • Quando há muitos itens de mudança e eles são complexos, escolha primeiro melhorias de “alto impacto e baixo custo”
    • Ex.: adotar um guia simples de review, remover notificações desnecessárias etc. pode ser aplicado rapidamente e ainda assim ter grande impacto na satisfação
    • Experiências iniciais de sucesso dão confiança à equipe e fornecem o impulso para avançar para problemas mais difíceis

Etapa 3: Implemente suas mudanças, monitore os resultados e ajuste

• Executar a tentativa de melhoria (Intervention) identificada na Etapa 2 dentro da organização,
  medir seus resultados e, se necessário, ajustar ou iterar a melhoria para buscar sucesso contínuo em engenharia

• 1. Execução (Implement the change)

  • Antes da execução, é preciso deixar claro o seguinte:
    • Que mudança será feita?
    • Quem será responsável?
    • Com base em quais métricas será feita a avaliação?
    • De quando até quando será feita a medição?
  • Pontos a considerar na execução:
    • Definição do responsável: deixar a ownership clara
    • Onboarding e treinamento da equipe: todos no time precisam entender por que a mudança é necessária e o que vai mudar
    • Documentação da mudança: registrar o processo para que possa servir de referência em retrospectivas e futuras iterações
  • Exemplos de adoção:
    • Alterar a estratégia de build cache para melhorar a velocidade de CI/CD
    • Alterar a política de code review (ex.: introduzir uma regra de resposta em até 1 dia)

• 2. Monitoramento (Monitor the change)

  • Após executar a melhoria, acompanhar os efeitos com as métricas definidas previamente
    • Se houve redução do lead time
    • Se houve redução da taxa de falhas
    • Se houve melhora na satisfação dos desenvolvedores, etc.
  • Ferramentas:
    • GitHub Insights, Copilot Telemetry, sistemas internos de BI
    • Dashboards de relatórios semanais/mensais
    • Pesquisas com desenvolvedores ou feedback de retrospectivas
  • Pontos importantes:
    • Deve ser possível comparar com a linha de base (baseline)
    • É importante observar tendências, e não apenas um valor isolado

• 3. Coleta de feedback (Collect feedback)

  • Além das métricas quantitativas, também é necessário coletar feedback sobre se a mudança realmente ajudou do ponto de vista dos desenvolvedores
    • Utilizar retrospectivas, pesquisas anônimas, reuniões 1:1 etc.
    • Verificar se a melhoria tem alta "percepção de valor" ou se, ao contrário, está causando fadiga
  • Mudanças executadas às pressas sem consenso organizacional podem provocar resistência e reação negativa

• 4. Ajustar ou iterar (Adjust as needed)

  • Se o resultado da tentativa de melhoria ficar abaixo do esperado ou gerar efeitos colaterais, responder das seguintes formas:
    • Reverter ou complementar a mudança
    • Manter apenas alguns elementos e reduzir o escopo
    • Expandir a aplicação para um escopo maior
  • Independentemente do sucesso ou fracasso da mudança, é sempre preciso aprender o seguinte:
    • Que elementos foram eficazes?
    • O que atuou como fator de bloqueio?
    • O que deve ser mudado na próxima vez?
• Dicas para executar a Etapa 3 com sucesso
  • 1.Não espere perfeição imediata
    • Nem toda mudança gera uma melhoria visível de imediato
      • Os efeitos podem levar tempo para aparecer
      • Como o time também precisa passar por um processo de adaptação à mudança, paciência e observação contínua são importantes
    • No início, é válido usar ferramentas de feedback qualitativo, como pesquisas, para entender a percepção sobre a mudança
  • 2.Continue iterando e melhorando a mudança
    • Mesmo depois de um sucesso, não se trata de manter tudo como está; a mudança também precisa evoluir e ser ajustada continuamente
    • Conforme surgirem novos problemas ou mudanças no ambiente externo, pode ser necessário revisitar as melhorias existentes
    • É preciso incentivar o time a encarar isso como uma atividade regular e manter o ciclo de melhoria
  • 3.Fique atento a efeitos colaterais não intencionais
    • Algumas mudanças podem causar atritos inesperados em outras áreas
      • Ex.: aumentar a velocidade de deploy é uma boa mudança, mas se a validação de qualidade for fraca, isso pode levar ao aumento de bugs
    • Além das métricas, também é preciso observar as mudanças no fluxo geral do workflow e agir imediatamente se surgirem sinais anormais
  • 4.Continue verificando o nível de segurança psicológica
    • Mesmo após a mudança, é preciso manter um ambiente em que o time possa levantar problemas livremente
    • Para evitar o acúmulo de "problemas não ditos", é necessário criar uma atmosfera em que os membros do time possam dar feedback honesto
    • Insatisfação com o processo alterado, aumento excessivo de trabalho, estresse inesperado etc.
  • 5.Avalie continuamente os efeitos de longo prazo
    • O ponto central não é o resultado de curto prazo, mas sim desempenho sustentável e melhora no moral da equipe
    • Ao longo do tempo:
      • Se a mudança foi incorporada de fato
      • Se não surgiram novos efeitos colaterais ou problemas
      • Se há manutenção ou queda de desempenho, tudo isso deve ser monitorado continuamente
  • 6.Use o feedback como oportunidade de aprendizado
    • Mesmo mudanças que fracassam são ativos valiosos de aprendizado
    • É preciso analisar com base em dados e feedback o que deu errado e refletir isso na próxima tentativa
    • Também é importante cultivar uma cultura que incentive o time a enxergar o fracasso como oportunidade de aprendizado

Além das etapas: faça o playbook funcionar para você

• Adaptação

  • Escolher as métricas e os métodos de medição (telemetria vs. pesquisas) de acordo com as características da organização
  • A medição não deve virar um fim em si mesma; ela deve ser usada como ferramenta para melhorias reais

• Gestão da mudança

  • É importante usar frameworks de gestão da mudança, como ADKAR e o modelo de Kotter, para ajudar a organização a se adaptar bem às mudanças

• Mentalidade de crescimento

  • Ver cada tentativa como oportunidade de aprendizado, e uma postura de aceitação do fracasso é essencial para a melhoria contínua

• Gamificação

  • Projetos de recompensa baseados em motivação podem gerar efeitos positivos, mas, se forem mal planejados, podem acabar causando queda de qualidade ou desequilíbrios

Alternativas ao GitHub Engineering System Success Playbook

• Dependendo da situação, em vez do ESSP, também é possível usar análises mais simples focadas no uso de features ou estratégias de melhoria baseadas em ferramentas individuais
• O importante é uma abordagem realista adequada ao time e à organização, além de um esforço contínuo de melhoria