Velocidade não é pular etapas. É estar pronto para agir.

Durante a sessão “T01.02 — Qualidade Além dos Testes”, do QA Transform, discutimos duas situações que parecem opostas. Quando um problema em produção afeta clientes ou interrompe uma operação, tudo se torna urgente: pessoas são mobilizadas, decisões são aceleradas e etapas podem ser puladas para restaurar o serviço. Quando o impacto é menor, a equipe segue o fluxo normal: análise, priorização, desenvolvimento, validação, aprovação e deploy, e a resolução pode levar dias.

Isso significa que o time só consegue ser rápido quando abandona o processo?

Essa diferença revela menos sobre a disposição das pessoas e mais sobre como a organização foi preparada para entregar e se recuperar. Se a velocidade depende de improviso, acesso excepcional e alguém disposto a “resolver direto em produção”, ela não é uma capacidade do sistema. É uma reação à crise.

O tempo gasto e o tempo esperando

Para compreender esse cenário, precisamos separar duas medidas apresentadas no encontro.

Lead Time for Changes é o tempo entre uma alteração de código e sua disponibilidade em produção. Ele não representa apenas as horas em que alguém está programando ou testando. Inclui também esperas: uma tarefa parada na fila, uma revisão pendente, a dependência de outra área, uma janela de deploy ou uma aprovação manual.

Por isso, uma mudança simples pode exigir poucas horas de trabalho e levar vários dias até o usuário. O número revela o fluxo completo, não apenas o esforço individual.

MTTR, ou Mean Time to Recover, observa quanto tempo a equipe leva para restaurar um serviço após uma falha em produção. Para que a comparação seja útil, cada organização precisa definir quando a contagem começa; no contexto discutido no encontro, consideramos a partir da identificação da falha.

As duas medidas se relacionam. Se toda recuperação exigir desenvolver uma correção e fazê-la percorrer o mesmo fluxo demorado das mudanças comuns, o Lead Time limitará o MTTR. Mas a recuperação pode ser mais rápida quando existe uma alternativa segura: reverter para uma versão anterior, alterar uma configuração, desativar a funcionalidade afetada ou redirecionar o serviço enquanto a causa é investigada.

O objetivo não é criar um processo descuidado para incidentes. É preparar um caminho de resposta que preserve os controles essenciais sem tratar uma falha ativa como uma demanda comum da fila.

O que a DORA procura revelar

Lead Time e MTTR fazem parte das métricas apresentadas no encontro a partir da DORA, programa de pesquisa que estuda quais práticas favorecem o desempenho da entrega e das operações de software. Essa linha de pesquisa ganhou forma nos relatórios State of DevOps, publicados desde 2014, e ajudou a desafiar a crença de que entregar rápido exige sacrificar estabilidade.

No modelo trabalhado na sessão, quatro sinais são observados em conjunto: frequência de deploy, Lead Time for Changes, taxa de falha das mudanças e MTTR. Eles mostram, respectivamente, com que frequência valor chega à produção, quanto tempo uma mudança leva para chegar, quantos deploys exigem intervenção e quanto tempo o serviço leva para ser recuperado.

Nenhum deles deve virar meta isolada. Um Lead Time menor não representa melhoria se foi obtido eliminando validações necessárias. Um MTTR baixo também pode esconder correções frágeis que apenas adiam a recorrência. Métricas servem para substituir impressões vagas por perguntas específicas: onde o trabalho espera? Qual etapa concentra retrabalho? O que impede uma recuperação segura?

A ilusão de ganhar tempo

Pular etapas produz uma sensação imediata de velocidade. A mudança chega antes porque revisão, teste, registro ou comunicação ficaram para depois. O problema é que esse “depois” frequentemente reaparece como investigação, correção adicional, divergência entre versões e branches ou novo incidente.

O que parecia tempo economizado transforma-se em retrabalho.

Imagine um cenário ilustrativo em que um incidente mobilize duas pessoas de desenvolvimento, uma de QA, uma de operações, uma de produto e uma de atendimento durante três horas. São 18 horas de trabalho desviadas, sem contar clientes afetados, transações perdidas ou entregas adiadas. Se a correção apressada provoca outra falha, a organização paga novamente e interrompe as mesmas áreas que deveriam estar criando valor.

Velocidade sustentável não consiste em remover todos os controles. Consiste em reduzir filas, dependências desnecessárias e operações manuais, enquanto os controles importantes se tornam rápidos, repetíveis e confiáveis.

Feature Flags: separar deploy de liberação

Uma prática que ajuda nessa preparação é o uso de Feature Flags, ou sinalizadores de funcionalidade. Elas permitem alterar o comportamento de uma função sem exigir que um novo pacote seja criado e implantado naquele momento.

Seu benefício central é separar deploy de liberação. O código pode seguir para produção em mudanças menores e menos complexas, permanecendo oculto ou desativado até que exista segurança para disponibilizá-lo. Em vez de acumular muitas alterações em uma grande liberação arriscada, a equipe entrega pacotes menores com mais frequência.

Em uma falha, uma flag operacional pode permitir que a parte afetada seja desligada enquanto o restante do sistema continua disponível. Em uma liberação planejada, pode expor a novidade gradualmente. Também pode viabilizar testes A/B quando dois comportamentos são comparados para grupos diferentes, com uma hipótese e uma medida de resultado.

Um e-commerce pode manter o checkout anterior disponível enquanto introduz uma nova experiência. Um aplicativo de mobilidade pode desativar temporariamente o cálculo dinâmico de tarifas sem interromper as corridas já em andamento. Um sistema hospitalar pode liberar um novo painel de agendamento apenas para algumas unidades e acompanhar falhas antes de expandir o uso para toda a rede.

Feature Flags, porém, não substituem análise de causa raiz, testes ou rollback. Elas também geram complexidade. Flags antigas precisam de responsável, prazo e remoção; caso contrário, diferentes combinações de estados tornam o sistema mais difícil de compreender e validar.

Preparação produz resultado para o negócio

Times maduros não dependem de adivinhação. Criam caminhos para reduzir o impacto, identificar a causa e aplicar a resposta adequada. Isso envolve observabilidade para perceber a falha, responsabilidades claras para decidir, versões recuperáveis, automação de deploy e opções seguras para reverter ou limitar uma mudança.

Produto e negócio ajudam a definir impacto e prioridade. Desenvolvimento constrói mecanismos de entrega e recuperação. QA contribui com cenários de risco e evidências. Operações acompanha o serviço. Liderança remove esperas desnecessárias e protege o tempo destinado à melhoria estrutural.

Quando esses elementos funcionam juntos, velocidade deixa de aparecer apenas durante a emergência. Ela se traduz em menos indisponibilidade, menos retrabalho, menor interrupção das prioridades e recuperação mais previsível para clientes e equipes. Ao observar causas e padrões, a organização deixa de apenas detectar falhas e passa também a trabalhar para preveni-las.

A pergunta relevante não é somente “em quanto tempo resolvemos?”. Precisamos perguntar o que esse tempo revela: houve espera evitável? A correção exigiu improviso? Conseguimos limitar o impacto? O processo ficou mais preparado para a próxima ocorrência?

Correr quando tudo já deu errado é urgência. Velocidade com qualidade é chegar à produção e recuperar o serviço sem transformar cada mudança em uma aposta.