OKR, Hoshin Kanri e Ágil – Visão sem execução é apenas alucinação!

A ciência é o “conhecimento das causas pelas causas. É o conhecimento demonstrativo” já dizia Aristóteles (385 a.C a 323 a.C).

Destaco a afirmativa de “conhecimento demonstrativo”, que corresponde ao empirismo. Não é possível afirmar como ciência algo que não pode ser experimentado, demonstrado, observado e etc. 

Para tanto, criar algo que seja ciência exige muita pesquisa e dedicação. Não se experimenta algo que não esteja planejado e principalmente, se não há cenário para experimentação. Os pais da administração, Taylor e Fayol, tinham o cenário propício para experimentar e demonstrar práticas de gestão que iriam otimizar a produtividade. Práticas estas que mudaram para sempre o modo como a humanidade configura suas linhas de produção.

Taylor e Fayol foram os primeiros a ver a prática de gestão como ciência, afirma Francisco Mello (2018) em seu livro “OKRs, da missão às métricas”. Eles foram os primeiros a medir tempos e movimentos dos trabalhadores das linhas de produção. Através destas métricas, aplicaram diversas ações que otimizaram sua produção. De tempos em tempos, novas ações eram implementadas, gerando um certo ciclo de melhoria contínua.

Mas foi Cecil Alec Mace, em 1935, que decretou a largada para a corrida das metas. Ele realizou experimentos que comprovaram que trabalhadores funcionam melhor quando orientados por métricas. Cecil afirmou que “Uma meta rígida e específica levará a incrementos maiores no desempenho do que uma instrução pouco específica, do tipo ‘faça o seu melhor.’”

Outros estudiosos vieram à seguir, como Peter Drucker, George Odiorne e etc, bem como grandes empresas, como a HP e General Electric, que aplicaram diversos métodos de métricas e otimização por volta da década de 1950, mas detalhar estes estudos e ações não são o foco deste texto. Destaco aqui, que nada é por acaso. As ferramentas que temos hoje não surgiram de devaneios, nasceram de práticas. Décadas de práticas e melhoria contínua. Em respeito à este processo de criação, inseri parte da história. 

Três ferramentas, ou melhor dizendo, conjunto de ferramentas (frameworks) de gestão e processos, que nasceram de toda esta necessidade de otimização, são: OKR, Hoshin Kanri do Lean e Scrum.

E eis o objetivo aqui: Estabelecer um entrelaçamento entre estes três importantes e essenciais métodos. É claro que, o objetivo aqui não é trazer todo o conteúdo possível à respeito, mas um ponto de reflexão. E claro, voltado à equipes de desenvolvimento de Software, ainda que estes métodos podem e devem ser usados em todos os setores de uma empresa. 

OKR

Literalmente OKR significa “Objective and Key Results”. Onde, de fato, são definidos os objetivos e os Key Results para atingi-los. Grosso modo, objetivo é o resultado que o negócio deseja alcançar, mas que será medido por termos qualitativos, em outra palavra, números. Já Key Result possui a seguinte estrutura:

KPI (indicador chave) + valor base (atual) + valor alvo (meta)

Se seu OKR for bem definido e, portanto, confiável, quando os Key Results forem atingidos, seu objetivo também o será. Caso contrário pode haver algum problema com seus Key Results, por exemplo. 

Há várias camadas onde OKR’s podem ser aplicadas. Podem ser resultados relativos à pessoas ou equipes, até o resultado geral da organização. Para ficar mais claro, destaco a figura 1 abaixo, onde exponho um exemplo muito simples de OKR para uma determinada equipe:

Figura 1 - Exemplo prático de OKR

Figura 1 – Exemplo prático de OKR

Observe a figura conceitual abaixo:

Figura 2 - Passos de uma OKR /  Fonte: Site Tecnicon (Link na referência bibliográfica ao final)

Figura 2 – Passos de uma OKR /  Fonte: Site Tecnicon (Link na referência bibliográfica ao final)

Destaco aqui alguns passos e comento pontos de atenção:

Passo 1: OKR’s estratégicos devem ocupar ciclos menores, para que ajustes necessários sejam feitos rapidamente. É o mesmo princípio dos pilares de Inspeção e Adaptação no Scrum. A cada iteração, verifica-se o caminho à seguir, se permanece correto ou deve ser alterado. 

Passo 3: O desenvolvimento de OKR’s para cada time estimula o pilar da Transparência no Scrum, fazendo com que todos saibam onde precisam chegar e o quanto o seu esforço impacta diretamente na OKR principal da organização. 

Passo 4: Retornamos aos pilares da Transparência e Adaptação. Mapear dependências e realizar alinhamentos significa claramente ajustes aplicados. E claro, para haver este mesmo alinhamento, a transparência deve estar em alta e a comunicação devidamente utilizada. 

Passo 5: Monitoramentos semanais vão mais uma vez ao encontro dos pilares de Inspeção e Adaptação. Creio que fundamentalmente a Transparência também. Ciclos curtos de monitoramento vão caminhar juntos com o tempo definido para as iterações (sprints) no Scrum, onde sempre há cerimônia de Review e Retrospectiva no final do ciclo, fazendo referência direta ao Passo 7

As OKR’s incentivam outros pontos que vão diretamente e automaticamente associar-se aos Princípios do Scrum: Auto-organização e Colaboração. OKR’s incentivam o engajamento dos envolvidos à autonomia e responsabilidade.

Hoshin Kanri

Ainda segundo Francisco Mello (2018), saber a literatura sobre Hoshin Kanri é fundamental para qualquer empresa que queira se tornar uma excelente praticante de OKR. Mais uma vez, não é um assunto que será amplamente desdobrado aqui. Incentivo o leitor à pesquisa. 

Hoshin Kanri é uma metodologia que defende a gestão pela qualidade total, por meio de processos e metas. Faço portanto aqui o link entre processo (Scrum) e Metas (OKR). Esta expressão (Hoshin Kanri) significa “gerenciamento de bússola” segundo a Wikipedia. No entanto, há outras traduções como “metal brilhante” que indica a direção a ser seguida, afirma Sidney Rago (2020).  A figura 3 abaixo mostra a metodologia Hoshin Kanri:

Figura 3 - Metodologia Hoshin Kanri / Fonte: Baseado na figura de Sidney Rago (2020)]

Figura 3 – Metodologia Hoshin Kanri / Fonte: Baseado na figura de Sidney Rago (2020)]

O Hoshin Kanri circula por todas os “níveis” da organização. Costuma-se dizer “de P a P (do Porteiro ao Presidente). Isto traz visão estratégica ampla e generalizada. Agora repare os quadrantes três e quatro com atenção. Temos no três a ação de criar indicadores táticos BSC (Balanced Scorecard), que se configura desta forma (figura 4):

Figura 4 - Métricas Hoshin Kanri / Fonte: Baseada na figura de Lorena Brito

Figura 4 – Métricas Hoshin Kanri / Fonte: Baseada na figura de Lorena Brito

É uma forma semelhante ao “pensar” do OKR. Objetivo principal e níveis de indicadores como se fossem os KPI’s. Atingindo os níveis abaixo, consequentemente o nível acima obterá sucesso. Observo que depende também do bom levantamento de indicadores. 

No quadrante quatro, existem os indicadores operacionais, que podem ser apenas um nível dentro dos já estabelecidos indicadores táticos, no entanto, há também a Gestão Diária, a Gestão Visual e o Kaizen. É neste ponto que estabeleço meu raciocínio de mais uma vez, perceber que não há como prosseguir em métricas corretas se não aplicarmos métodos ágeis no processo de desenvolvimento de software. Neste caso, Scrum para Gestão Diária e Kaizen (que em outras palavras, de forma bem resumida, significa melhoria contínua).

Estes preceitos (Gestão Diária e Kaizen) se encaixam perfeitamente nos três pilares do Scrum: Inspeção, Adaptação e Transparência. A Gestão Visual, que também é transparente, pode ser realizada por Kanban, outra metodologia ágil que realiza parceria perfeita com o Scrum. 

Concluo aqui meu raciocínio ao dizer que: Métricas por si só, não trazem avanços. É mais uma vez um sinal de mudança cultural (mindset) juntamente com mudanças de processos ineficazes, para então aplicar uma metrificação correta, sobre um esforço correto. Thomas Edison (dispensa apresentações!), grande empresário e inventor disse: “Visão sem execução é apenas alucinação”.

Referências Bibliográficas

Raphael Siqueira

Mais artigos deste autor »

Profissional de quase uma década na área de Qualidade de Software. Formado em Tecnologia da Informação, Pós-graduado em Engenharia de Software. Certificação CTFL pelo BSTBQ. Certificado LACP - Lean Agile Coach Professional pela Uniagil, dentre outras certificações.


Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!