Vamos começar com uma suposta falha de comunicação entre desenvolvedor e gerencia/liderança.
Cenário: Uma informação, necessária para uma reunião de status report, chegou até a gerencia via cliente enquanto ainda estava havendo a validação se o problema realmente era um problema. Isso aconteceu porque a reunião de status report aconteceria muito em breve.
- Por que essa informação não foi passada pelo time? Porque ainda estava em validação.
- Por que então foi antecipada? Porque era necessária para uma reunião inadiável de status report que aconteceria em breve e o cliente estava sendo cobrado por sua liderança/gerencia.
- Por que uma reunião de status report, ainda mais inadiável? Porque falta confiança.
- Por que falta confiança? Porque já aconteceram muitas releases com problemas.
- Por que já aconteceram muitas releases com problemas? Pela ausencia de um processo mais eficiente de testes, UAT e deploy.
Os exemplos práticos que colocarei aqui são resultados da minha mente psicopata, portanto, não fazem parte do meu dia a dia. O recado é: não pare no primeiro "por que" ele pode te levar a um diagnóstico simplista demais. Medidas para remediar o primeiro "por que" podem não surtir o efeito desejado e, mesmo aplicando a inspeção, podemos estar agindo na causa errada. Errada pois por trás dela existem causas muito maiores que não estão sendo endereçadas. Daí pode estar vindo a sensação de "enxugar gelo" e de que, na verdade, as pessoas não estão se esforçando para realizar as "determinações de melhoria". Um conselho para você que acredita nisso: "Isso não é verdade! Você está tratando as causas erradas."
Nenhum comentário:
Postar um comentário