Muito tenho falado dos principais efeitos sistemicos mas sem utilizar muito exemplos praticos. Isso acontece pois normalmente quando temos uma evidencia deste tipo de ocorrencia, nao seria etico divulgar. Entretanto nesta semana ocorreram, quase simultaneamente, dois exemplos que penso nao ser anti-etico divulgar.The Butterfly EffectEste efeito, assim como o proximo, esta diretamente ligado a teoria das redes. Se nao houvesse uma relacao de interdependencia entre todos os elementos do sistema, nada do que vou descrever aqui seria possivel.Ha mais ou menos duas semanas criamos uma politica em um dos nossos projetos que so era permitido comecar a desenvolver com cenarios e casos de teste escrito. Com esta politica, identificamos rapidamente a formacao de um gargalo. A principio este gargalo era considerado como falta de braco em QA, mas fazendo uma analise mais profunda, observamos que poderiamos otimizar o processo de trabalho, eliminando alguns desperdicios.A consultoria de transicao nao atua ainda diretamente com a area de QA. O que fazer entao? 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 pressao foi bem simples. Com apoios importantes, mantivemos firme a decisao de que nada passa da coluna de desenvolvimento sem casos de teste.Esta decisao gerou naturalmente uma pressao no sistema e justamente onde desejavamos. Diversas reunioes foram realizadas, solucoes ponderadas e a otimizacao foi realizada. Neste ponto percebemos que, com estas medidas, o que fizemos foi aumentar o senso de urgencia para uma solucao que otimizaria diretamente o trabalho. Entao esta decisao foi tomada. Precisou/Teve/Necessitava/"coloque aqui o seu termo preferido que indique senso de urgencia" ser tomada.Criando Senso de UrgenciaNo topico anterior percebemos como pressionar um ponto distante para usarmos o efeito sistemico do efeito borboleta a nosso favor. Agora vamos examinar como fizemos, certa vez, para aumentar diretamente o senso de urgencia.Com muitos bugs pipocando no quadro, fomos investigar a causa raiz e procurar uma forma de reduzir o numero de problemas nos codigos 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 nao eram bugs o que estava sendo gerado. Infelizmente, como eu disse anteriormente, nao estamos ainda lidando diretamente com a area de QA. Mas, mais uma vez, podemos dancar com o sistema. Nao poderiamos sugerir diretamente o treinamento dos analistas de teste, mas poderiamos, sutilmente, conduzir o sistema para esta solucao.Como?E relativamente simples: dizendo, por exemplo, que e estranho analista de teste com pouco conhecimento do negocio. Dizendo que os analistas de teste precisam ter, inclusive, mais conhecimento do negocio que os desenvolvedores.Isso, certamente, fechou algumas cognicoes nos cerebros de quem decide e decidiram, no mesmo dia, estruturar um treinamento profundo para as pessoas envolvidas.***E necessario deixarmos claro que, em nenhum momento, colocamos a culpa nas pessoas. Em grandes transicoes, em absolutamente todos os casos, a culpa e do sistema e nao das pessoas. Podemos chegar a algumas causas raizes que, diretamente, nos levarao a culpar as pessoas.