Quando uma equipa entrega devagar, a causa quase nunca são os engenheiros. São normalmente quatro ou cinco atritos concretos que ninguém mediu.
«A equipa é lenta» é um sintoma, e os fundadores costumam diagnosticá-lo mal como um problema de pessoas. Pela nossa experiência é quase sempre um problema de sistema: o trabalho espera em filas, as alterações são grandes e arriscadas, fazer deploy mete medo, e ninguém tem números com que argumentar.
Comece por quatro medições
Estas quatro estão bem estabelecidas e, mais importante, são diagnósticas: cada resultado mau aponta para uma classe específica de problema.
| Métrica | O que expõe quando está má |
|---|---|
| Frequência de deploy | Tamanho de lote demasiado grande, deploys tratados como eventos |
| Tempo de entrega de alterações | Tempo em fila — normalmente revisão de código ou QA à espera, não a programar |
| Taxa de falha de alterações | Testes fracos ou falta de paridade com produção |
| Tempo de reposição | Sem rollback ensaiado, observabilidade fraca |
As constatações habituais
A revisão de código é um estrangulamento, não uma barreira de qualidade
- Os pull requests são grandes demais para serem revistos a sério, logo a revisão torna-se teatro de aprovação
- Não há expectativa quanto ao tempo de resposta da revisão, logo as alterações ficam dias paradas
- Um único engenheiro sénior é o único aprovador — uma fila com um só guichê
O deploy é um evento
- Passos manuais que só uma pessoa conhece
- Nenhum rollback em que se confie, logo as releases são agrupadas, o que as torna mais arriscadas, o que as torna mais raras
- Deploys agendados para horas calmas — sinal forte de que a equipa não confia no processo
O trabalho não está realmente definido
- Tarefas que exigem uma conversa antes de alguém poder começar
- Sem definição partilhada de concluído, logo o trabalho salta entre desenvolvimento e QA
- Demasiado trabalho em curso — toda a gente ocupada, nada a terminar
O que mudar primeiro
- Torne os deploys aborrecidos — automatize, acrescente rollback, pratique-o. Tudo o resto melhora quando lançar é seguro.
- Reduza o tamanho de lote — alterações mais pequenas são mais fáceis de rever, mais seguras de lançar, mais rápidas de diagnosticar.
- Defina um SLA de revisão — horas, não dias, com um segundo aprovador para que uma pessoa nunca seja o estrangulamento.
- Limite o trabalho em curso — terminar vale mais do que começar.
- Instrumente o que os clientes sentem, para que os incidentes sejam encontrados internamente em vez de reportados.
Velocidade e segurança não são um compromisso na entrega de software. As equipas que fazem deploy com mais frequência têm também as taxas de falha mais baixas — porque alterações pequenas, frequentes e reversíveis são simultaneamente mais rápidas e mais seguras.
Analisar trabalho sem classificar pessoas por métricas
Tarefas comparáveis revelam limitações do sistema. Explique esperas e retrabalho sem confundir atividade com produtividade.
- Selecionar alterações concluídas, incluindo uma correção urgente.
- Medir filas, revisões, passagens e dificuldades de publicação.
- Testar uma melhoria com referência inicial e data de revisão.
Perguntas frequentes
Quanto tempo demora uma auditoria de processos de engenharia?
Tipicamente uma a duas semanas: recolher dados de entrega, entrevistar a equipa, observar uma release real e rever as ferramentas. O resultado deve ser um pequeno número de mudanças priorizadas com impacto esperado, não uma pontuação de modelo de maturidade.
Vão dizer-nos para adotar Scrum?
Não. A metodologia raramente é a restrição — são-no o tempo em fila, o tamanho do lote e o risco de deploy. Houve equipas a entregar bem sob todos os frameworks e mal sob todos eles; mudar a cerimónia sem mudar essas três coisas não produz nada.
A nossa equipa diz que precisa de mais engenheiros. É verdade?
Por vezes, mas contratar para dentro de um estrangulamento de processo piora antes de melhorar — mais pessoas a produzir mais trabalho em curso contra as mesmas filas de revisão e deploy. Meça primeiro para onde vai realmente o tempo; se a maior parte for tempo em fila, contratar não é a solução.
Podemos comparar equipas por números brutos?
Apenas com contexto sobre produto, tarefas e condições operacionais. Tendências ajudam ao diagnóstico; contagens isoladas não demonstram eficácia.
A equipa entrega mais devagar do que devia?
Medimos para onde vai realmente o tempo e corrigimos as principais restrições — normalmente em semanas, não em trimestres.
Leitura complementar
Boas práticas de postmortem: escrever um que as pessoas leiam
A maioria dos postmortems é arqueologia: um registo exato de algo que ninguém vai mudar. Um útil produz um pequeno número de coisas que realmente são feitas.
Auditoria técnica de MVP: o que verificamos nas primeiras 48 horas
A maioria das auditorias de MVP produz um documento. Uma útil produz decisões: o que está a arder, o que pode esperar e quanto custa corrigir.