O que o Accelerate acrescenta às métricas de fluxo
Uma demanda pode atravessar o quadro de trabalho com rapidez e ainda passar semanas esperando para chegar a produção.
Esse intervalo importa.
WIP, throughput e lead time ajudam a enxergar como o trabalho se move pelo sistema. Eles continuam sendo uma base importante para falar de foco, cadência e previsibilidade.
Mas equipes que operam software em produção precisam olhar também para o que acontece depois que uma mudança está pronta: quanto tempo ela leva para chegar ao ambiente real, com que frequência isso acontece e o que a organização faz quando algo dá errado.
É esse recorte que as métricas difundidas pelo DORA e pelo livro Accelerate ajudam a iluminar.
Elas não substituem métricas de fluxo. Elas mostram outro trecho do mesmo sistema.
O quadro não termina em produção
Já vi equipes celebrarem um lead time curto porque o desenvolvimento estava concluído em poucos dias. Quando a conversa avançava, apareciam homologação, aprovação, janela de mudança, dependência de infraestrutura e uma publicação que só acontecia semanas depois.
O problema não era a definição escolhida para a métrica. Era tratá-la como se representasse toda a jornada.
Uma equipe pode ter um fluxo de desenvolvimento organizado e uma esteira de publicação frágil. Pode publicar muito, mas não conseguir restaurar um serviço quando uma mudança falha. Pode fazer poucas publicações porque cada uma delas carrega trabalho demais e risco demais.
Olhar apenas para o quadro esconde a operação. Olhar apenas para produção esconde filas, dependências e excesso de trabalho em andamento.
A conversa boa junta os dois lados.
Frequência de implantação não é competição de botões
Frequência de implantação, ou deployment frequency, mostra com que regularidade uma organização coloca mudanças em produção.
Ela não existe para premiar quem publicou mais vezes no mês.
Uma implantação pode conter uma correção pequena, uma configuração, uma mudança invisível para clientes ou um conjunto grande de alterações. O ponto é saber se o sistema consegue mover mudanças úteis com frequência e segurança, sem depender de grandes eventos de publicação.
Lotes menores costumam tornar revisão, teste, diagnóstico e reversão mais simples. Isso não significa que toda equipe precisa publicar várias vezes por dia. Produto, risco, regulação e capacidade operacional mudam o que é adequado.
A pergunta que me interessa é outra: conseguimos colocar uma mudança útil em produção no ritmo que o problema exige, sem concentrar risco em uma aposta grande demais?
Dois lead times, duas conversas
O lead time de uma demanda costuma começar quando a equipe assume o compromisso de resolver uma necessidade e terminar quando algo está disponível para uso. Ele pode incluir descoberta, refinamento, desenvolvimento, testes e aprovações.
O lead time for changes é mais estreito. Ele observa o tempo entre uma mudança registrada no código e essa mudança estar rodando em produção.
Os dois são úteis. Os dois podem ser longos. Mas podem estar longos por razões completamente diferentes.
Se o lead time de demanda cresce, talvez haja entrada demais, escopo mal dimensionado ou dependências que ninguém assumiu. Se a demanda está pronta, mas o lead time for changes é alto, talvez a fila esteja na revisão de código, na esteira, na aprovação manual ou na própria forma de publicar.
Usar um como sinônimo do outro faz a equipe procurar o problema no lugar errado.
Recuperar é uma capacidade do sistema
Quando um serviço degrada ou uma mudança provoca incidente, o tempo de restauração mostra quanto demoramos para recuperar a operação.
Em alguns lugares essa métrica aparece como time to restore service. Em outros, como MTTR. O nome é menos importante que a definição. Quando o relógio começa? O que significa serviço restaurado? Quais eventos entram na conta?
Essa não é uma medida da competência de quem estava de plantão.
Tempo de restauração fala sobre a capacidade coletiva de detectar, entender e recuperar uma falha. Alertas, observabilidade, feature flags, reversão simples, documentação, arquitetura e coordenação entre pessoas interferem nesse tempo.
Uma organização que mede restauração para procurar culpados recebe menos transparência sobre incidentes. As pessoas aprendem a esconder, reclassificar ou discutir a definição antes de discutir o problema.
Uma organização que mede para aprender faz o contrário: torna falhas visíveis e reduz a chance de repeti-las do mesmo jeito.
Falhar não pode virar motivo para esconder mudança
A taxa de falha de mudança relaciona publicações a mudanças que exigiram correção, reversão, hotfix ou que degradaram o serviço.
Ela também exige acordo. Um erro visual corrigido no mesmo dia entra? Uma configuração externa entra? Uma reversão preventiva entra?
Não existe uma resposta universal. Existe uma definição que precisa ser clara e estável o bastante para permitir comparação com o próprio histórico.
O uso ruim dessa métrica cria exatamente o comportamento que ela deveria ajudar a evitar. Se uma equipe é punida por falhar, ela pode publicar menos, esconder problemas ou agrupar mudanças para reduzir o denominador aparente.
O número melhora. O sistema piora.
Eu usaria a medida para abrir outras perguntas: que tipo de mudança falha mais? Onde poderíamos ter descoberto isso antes? Que proteção reduziria o impacto sem transformar a entrega em burocracia?
Velocidade e estabilidade não são inimigas
Existe uma oposição que aparece com frequência: ou entregamos rápido, ou entregamos com segurança.
Ela parece razoável até olharmos para o tamanho do lote.
Mudanças menores, observáveis e reversíveis reduzem o custo de descobrir um problema e voltar atrás. Não porque tornam as pessoas mais heroicas, mas porque tornam o sistema menos dependente de heroísmo.
Isso não transforma toda aceleração em sinal de saúde. A frequência pode subir porque mudanças foram fragmentadas artificialmente. O tempo de restauração pode cair porque incidentes deixaram de ser registrados. A taxa de falha pode melhorar porque o critério mudou.
Por isso, eu confio mais em tendências acompanhadas de contexto do que em metas isoladas. A definição da métrica faz parte da métrica.
Um mapa de perguntas
Uma equipe de produto e engenharia pode olhar para:
- WIP, para entender excesso de compromissos simultâneos;
- throughput, para acompanhar ritmo de conclusão;
- lead time de demanda, para conversar sobre expectativa com produto e negócio;
- frequência de implantação e lead time for changes, para observar a passagem até produção;
- tempo de restauração e taxa de falha de mudança, para observar confiabilidade e recuperação.
Isso não é um placar de produtividade. É um mapa de perguntas.
Se o WIP cresce e o lead time de demanda aumenta, talvez estejamos aceitando trabalho demais. Se a demanda está pronta, mas demora para entrar em produção, talvez a esteira seja o gargalo. Se a frequência de implantação sobe junto com a taxa de falha, talvez o tamanho do lote, os testes ou a observabilidade precisem de atenção. Se o tempo de restauração é alto, talvez o sistema não ofereça condições para operar com segurança.
Cada padrão pede uma investigação diferente.
A conversa não termina na engenharia
Essas métricas ficam mais úteis quando não pertencem apenas à engenharia.
Frequência de implantação pode alterar a velocidade de aprendizado de produto. Tempo de restauração pode afetar confiança, retenção e custo operacional. Taxa de falha de mudança pode chegar ao suporte, à operação e ao cliente. Lead time for changes pode explicar por que uma oportunidade de mercado demora tanto para ser testada.
Essa relação não é automática. Ela precisa ser investigada em cada contexto.
Mas ela permite que produto, engenharia e negócio enxerguem o mesmo sistema por lentes diferentes, sem precisar fingir que uma única métrica dá conta de tudo.
O ganho não está em adicionar quatro números a um painel.
Está em reduzir o intervalo entre uma ideia, uma mudança segura, uma consequência observada e o próximo aprendizado.
Referências
Forsgren, N.; Humble, J.; Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018.
Google Cloud. DORA: Capabilities: Software delivery performance. Referência conceitual para as métricas de entrega e confiabilidade.
O livro é a base. No curso, eu transformo esse repertório em prática guiada.
Conhecer o curso