A sigla significa Observe, Oriente-se, Decida, Aja. Original em Inglês para Observe, Orient, Decide, Act . Foi uma técnica/filosia criada pela Força Aérea Americana com o objetivo de criar um processo simples para ser usado durante operações de combate.
O loop significa que depois de observar, se orientar, decidir o que fazer e agir você imediatamente faz isso novamente. Esse ciclo perpétuo continua até que seus objetivos sejam alcançados. No caso dos militares a vitória.
Não demorou muito para a filosofia se espalhar para outros ramos já que nada mais é do que um modo de abordar tomadas de decisão.
Se uma empresa está constantemente observando o mercado (seus clientes e a concorrência), então comparando essa informação com a sua realidade (orientando-se), fazendo planos de como abordar o que precisa ser mudado (decidindo), essa empresa vai conseguir criar um plano de ação e continuar relevante no mercado.
Quero oferecer aqui um outro uso para a técnica OODA Loop: Troubleshooting.
Observe
Esse é o estágio inicial quando você começa a fazer o troubleshooting da sua aplicação ou infra-estrutura. Quais os sintomas? Erros? Mensagens? O que mais você sabe sobre o problema? Quando começou? Qual o escopo? Que outras informações pertinentes você consegue juntar nessa fase inicial?
Aqui quantidade talvez seja mais importante do que qualidade. Quanto mais informações você tiver no começo melhor. Deixe para a fase de decisão o que fazer com essa informação toda.
Oriente-se
Agora que você já sabe qual o estado atual do sistema a próxima fase é descobrir ou determinar qual é o estado normal ou desejado.
Aqui vai fazer diferença se você está fazendo troubleshooting em algo que você está familiarizado ou não. Quando estamos trabalhando em um sistema que conhecemos bem é possível que essa fase seja bem simples, afinal sabemos exatamente como as coisas deveriam ser em um estado de normalidade.
Por outro lado se o troubleshooting é em um sistema que temos pouca ou nenhuma familiaridade precisamos nos engajar em levantar informações. Normalmente os usuário finais do sistema são a melhor fonte de tais informações. Mas outros recursos como documentação também são úteis.
Infelizmente não são raros os casos onde você vai precisar inferir algumas coisas.
Decida
Aqui você vai começar a efetivamente trabalhar no problema. Você vai olhar para as informações que levantou na fase inicial e baseado no que aprendeu quando se orientou formule um plano.
Mantenha em mente que nesse ponto não é um plano de ação com 100 passos que vai com certeza resolver o problema. Não se esqueça de que estamos trabalhando em um loop aqui. Pequenos passos incrementais que vão te avançando pouco a pouco.
Planeje algo bem simples e fácil de implementar, apenas um único passo que vai te ajudar a se mover um pouco mais para frente no processo.
Aja
Agora que você tem uma ideia do que fazer, faça. Não sei, mudar uma configuração? Reiniciar um serviço? Ativar um log mais detalhado na aplicação? Seja o que for que decidiu na fase anterior, simplesmente implemente.
Faça tudo novamente
Se depois de agir e implementar sua ideia o problema ainda não foi resolvido, entre novamente no loop e passe por todas as fases.
Ao observar novamente pergunte-se se alguma coisa mudou. O que tem de diferente nesse momento?
Sua fase de orientação agora é um pouco diferente. Você precisar entender causa e efeito. Como o que você fez da última vez causou as mudanças sendo observadas agora? Isso faz sentido? Você já viu problemas parecidos? Consegue inferir alguma conclusão no momento?
Agora com isso tudo um pouco digerido, decida o que fazer a seguir. Talvez você já saiba o suficiente para tentar implementar uma solução. Talvez ainda precise levantar mais informações. Tome sua decisão do que fazer agora.
Aja novamente e volte para o loop caso necessário.
Que outras técnicas de troubleshoot você usa? Deixe a dica.
No tag for this post.
