Error budget: quando parar de feature e investir em estabilidade

Ligar SLOs a decisões de roadmap: usar orçamento de erro como linguagem comum entre produto e plataforma.

Contexto

Este artigo integra a série Qualidade & entrega no blog da Barre — pensado para CTOs, arquitetos e líderes de produto que precisam de decisões com critério e continuidade operacional, não de modismos.

Pressão de negócio e restrições

Sem definição partilhada de pronto, velocidade mede-se contra um alvo que muda — e o retrabalho esconde-se nos bastidores.

Relacionado com o foco anunciado no título: Ligar SLOs a decisões de roadmap: usar orçamento de erro como linguagem comum entre produto e plataforma.

Padrões que voltam a aparecer

• Velocidade medida sem qualidade percebida pelo utilizador.

• Ambientes de teste irrealistas — erros só na linha final.

• Rollback ou flags sem critério claro de saúde.

Decisão em uma frase, aplicada

Decisão útil: fechar Definition of Done com evidência partilhada — não com promessa verbal.

Quanto mais curto e verificável o compromisso, maior a probabilidade de sobreviver a mudanças de equipa.

Consequências, trade-offs e o que vigilar

Qualidade sem número vira opinião — e perde contra prazo em qualquer discussão.

Trade-offs: mais automação e observabilidade custam agora; pagam em menos incidentes e menos retrabalho.

O que vigilar

• Defeitos em produção por causa raiz e tendência.

• Tempo para recuperar serviço e para reverter release.

• Dívida aceite explicitamente vs escondida.

Próximos passos (se for prioridade agora)

1. Definition of Done conjunta (produto + engenharia) com evidência.

2. Erro budget ou política explícita quando se comprime prazo.

3. Rollback ou flag documentado antes do primeiro utilizador real.

Síntese

Para fechar: tratar Error budget como sistema — medir, limitar e rever — evita que cada projeto reinvente o mesmo debate.

---

Resumo: Ligar SLOs a decisões de roadmap: usar orçamento de erro como linguagem comum entre produto e plataforma.