Uma análise prática de uma ferramenta que a maioria das pessoas usa errado
Vou falar sobre 4 razões porque tudo vai bem. Parece um conceito autoajuda, mas na verdade é um framework de gestão de risco que eu finalmente entendi funcionar depois de ver projetos inteiros desmoronarem por ignorá-lo. A primeira vez que ouvi falar disso foi num post obscuvo de um blogue alemão de engenharia de processos, e a segunda vez foi quando precisei aplicar isso a sério, numa auditoria interna que já estava a correr mal há seis meses.
As 4 razões porque tudo vai bem na prática
O framework é simples: identifica quatro categorias de fator de estabilidade e verifica se cada uma está realmente ativa ou apenas presumida. A maioria das equipas para na primeira. Eu vi pelo menos onze casos em que o problema era exatamente esse — a suposição de que algo estava a funcionar sem evidência concreta. A primeira razão é clareza de responsabilidade. Isto parece óbvio até perceberes que ninguém sabia quem era o verdadeiro responsável por algo crítico. Num projeto de migração de base de dados que auditei em 2023, o backup tinha um "owner" list na documentação, mas essa pessoa tinha saído da empresa três meses antes e ninguém atualizou. O sistema de alertas configurava-se automaticamente para o email dela, que estava morto. Quando o servidor principal falhou, ninguém soube quem devia chamar. A workaround? Implementar um check semanal de ownership em todos os sistemas críticos, com fallback obrigatório para pelo menos duas pessoas. Custa cerca de 15 minutos por semana e evita situações assim.
A segunda razão é rede de alerta precoce. Isto não é sobre ferramentas de monitorização caras. É sobre pessoas. Tenho uma lista pessoal de contactos que envio um email quando algo muda significativamente no meu setor, mesmo que não seja problema meu diretamente. Recebo três a cinco desses emails por semana e metade é ruído. Mas nos dois anos anteriores, esses avisos preventivos ajudaram-me a evitar pelo menos quatro problemas maiores que tinham começado a ser discutidos noutros círculos antes de chegarem ao meu terreno. A terceira razão é capacidade de resposta documentada. Ter um plano de contingência não é o mesmo que ter um plano documentado, testado e acessível. Encontrei empresas com planos de disaster recovery de 200 páginas que estavam guardados num PDF em drive que só dois elementos da equipa sabiam que existia. E nenhum deles tinha lido o ficheiro completo. O que funciona na prática são checklists de uma página, impressas e visíveis, com decisões binárias do tipo "se isto acontece, faz isto". Isso reduz o tempo de decisão de minutos para segundos quando o stress está alto.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A quarta razão é margem de manobra real. Não a que está no spreadsheet, a que existe de facto. A maioria das estimativas de prazo e orçamento que eu vi incluem uma "margem de segurança" que na realidade é ilusão. Se queres saber se tens margem real, pergunta: quantos dias de folga tens entre o prazo estimado e a data em que seria tecnicamente impossível entregar qualquer coisa? Se a resposta for menos de três semanas num projeto de médio porte, não tens margem, tens esperança.
Quando este framework falha
Vou ser direto sobre as limitações porque muitas pessoas omitem isto. O framework 4 razões porque tudo vai bem funciona bem para riscos operacionais em contextos estáveis. Não funciona bem em cenários de mudança disruptiva onde as premissas básicas do negócio se alteram rapidamente. Num projeto de digitalização que gerimos em 2024, todas as quatro razões estavam bem estruturadas e mesmo assim o projeto falhou porque a regulamentação mudou três vezes em seis meses, tornando o objetivo original irrelev antes do primeiro milestone. O framework não prevê isso, e nenhum framework consegue, honestamente. Outro ponto: o framework pode criar uma falsa sensação de segurança. Passar a caixa de seleção e sentir que estás protegido é perigoso. Eu vi equipas passarem por todas as quatro razões com orgulho, e depois, três meses depois, um erro simples de configuração num serviço cloud que ninguém tinha considerado porque estava fora dos quatro eixos. O framework é um filtro necessário, não uma garantia.
Como aplicar sem transformar isto num exercício burocrático
A abordagem que uso é bem específica. Dedico uma sessão de duas horas mensais, com no máximo cinco pessoas, para rever cada um dos quatro eixos. Não é uma reunião formal. É sentados com um documentário partilhado, a marcar o estado de cada fator com cores: verde, amarelo, vermelho. O tempo médio de revisão de cada eixo é de doze minutos. Se um eixo está a vermelho há mais de um mês, isso obriga a uma ação concreta, não a mais discussão. O erro mais comum que vejo é aplicar o framework como um exercício anual ou trimestral. A informação demasiado depressa nesse intervalo. Algo que era verde em Janeiro pode estar vermelho em março e ninguém percebeu. A revisão mensal é o mínimo que faz sentido. Para ambientes mais voláteis, quinzenal é melhor.
Se quiseres acesso ao template que uso para estas sessões, está disponível gratuitamente no meu GitHub. O link é simples e não requer registo: github.com/example/4razoestudo. O template inclui as quatro secções com exemplos preenchidos de cenários reais, para não ficar em vazio. Também recomendo, se for a primeira vez que aplicas isto, começar pequeno. Escolhe um único sistema ou processo, aplica as quatro razões num domingo de manhã, e vê o que aparece. Vai te surpreender quantos itens verdes se tornam amarelos ou vermelhos quando os confrontas com evidência ao invés de suposições. Eu fiz isso pela primeira vez num projeto meu e encontrei três problemas sérios que ninguém na equipa sabia que existiam. Três meses depois, dois desses problemas teriam sido catastróficos se tivessem acontecido sem aviso. Agora tenho hábito de fazer isso uma vez por trimestre, em cada projeto ativo. Leva cerca de três horas e muda a forma como encaras cada novo risco que surge.
