Transição - Os efeitos sistêmicos

Muito tenho falado dos principais efeitos sistêmicos mas sem utilizar muito exemplos práticos. Isso acontece pois normalmente quando temos uma evidencia deste tipo de ocorrência, não seria ético divulgar. Entretanto nesta semana ocorreram, quase simultaneamente, dois exemplos que penso não ser anti-ético divulgar.

The Butterfly Effect

Este efeito, assim como o próximo, está diretamente ligado à teoria das redes. Se não houvesse uma relação de interdependência entre todos os elementos do sistema, nada do que vou descrever aqui seria possível.

Há mais ou menos duas semanas criamos uma política em um dos nossos projetos que só era permitido começar a desenvolver com cenários e casos de teste escrito. Com esta política, identificamos rapidamente a formação de um gargalo. A princípio este gargalo era considerado como falta de braço em QA, mas fazendo uma análise mais profunda, observamos que poderíamos otimizar o processo de trabalho, eliminando alguns desperdícios.

A consultoria de transição não atua ainda diretamente com a área de QA. O que fazer então? Lembrando a teoria das redes sabemos que podemos pressionar um ponto distante para surtir o efeito que desejamos em outro. Neste caso, o ponto de pressão foi bem simples. Com apoios importantes, mantivemos firme a decisão de que nada passa da coluna de desenvolvimento sem casos de teste.

Esta decisão gerou naturalmente uma pressão no sistema e justamente onde desejávamos. Diversas reuniões foram realizadas, soluções ponderadas e a otimização foi realizada. Neste ponto percebemos que, com estas medidas, o que fizemos foi aumentar o senso de urgência para uma solução que otimizaria diretamente o trabalho. Então esta decisão foi tomada. Precisou/Teve/Necessitava/"coloque aqui o seu termo preferido que indique senso de urgência" ser tomada.

Criando Senso de Urgência

No tópico anterior percebemos como pressionar um ponto distante para usarmos o efeito sistêmico do efeito borboleta a nosso favor. Agora vamos examinar como fizemos, certa vez, para aumentar diretamente o senso de urgência.

Com muitos bugs pipocando no quadro, fomos investigar a causa raiz e procurar uma forma de reduzir o número de problemas nos códigos entregues. Durante este processo, descobrimos que a origem de alguns bugs era a falta de conhecimento do negocio por parte de QA. Assim, explicamos os motivos da necessidade para que isso parasse, de que não eram bugs o que estava sendo gerado. Infelizmente, como eu disse anteriormente, não estamos ainda lidando diretamente com a área de QA. Mas, mais uma vez, podemos dançar com o sistema. Não poderíamos sugerir diretamente o treinamento dos analistas de teste, mas poderíamos, sutilmente, conduzir o sistema para esta solução.

Como?

É relativamente simples: dizendo, por exemplo, que é estranho analista de teste com pouco conhecimento do negócio. Dizendo que os analistas de teste precisam ter, inclusive, mais conhecimento do negócio que os desenvolvedores.

Isso, certamente, fechou algumas cognições nos cérebros de quem decide e decidiram, no mesmo dia, estruturar um treinamento profundo para as pessoas envolvidas.

***

É necessário deixarmos claro que, em nenhum momento, colocamos a culpa nas pessoas. Em grandes transições, em absolutamente todos os casos, a culpa é do sistema e não das pessoas. Podemos chegar a algumas causas raízes que, diretamente, nos levarão a culpar as pessoas. Entretanto, se investigarmos um pouco mais, vamos encontrar causas sistêmicas como causas raízes.

É fundamental change agents e gestores de todos os níveis conhecerem e exercitarem a habilidade de usar os efeitos sistêmicos a seu favor. Também é de grande importância aprender a investigar corretamente as causas raízes, para que as soluções trabalhem em benefício na melhoria da organização como um todo. 

Se você atacar causas superficiais, você resolverá apenas problemas superficiais. Se você atacar as causas raízes, você estará resolvendo problemas profundos da organização.