Caça às Bruxas

Tempos atrás me encontrei em uma situação interessante. Por problemas de comunicação, eu estava em um lugar e deveria estar em outro. Quem já não passou por isso?

Mas o que me chamou a atenção foi a primeira pergunta que me foi feita quando notamos o problema. “Quem falou para você vir para cá?”. Por reflexo respondi, mas fiquei com isso na cabeça.

O que eu vi acontecer nos próximos minutos foi uma rápida caça às bruxas. O importante não era descobrir como eu chegaria a tempo no local certo e sim descobrir quem era o culpado por eu estar no lugar errado. Não tem algo de estranho por aqui? O que seria ganho encontrando o culpado?

Isso é um traço cultural de muitas empresas. Essa “cultura do culpado” é muito forte e costuma trazer efeitos desastrosos. O erro passa a ser tratado como a pior coisa que pode acontecer e não como parte do aprendizado. Como o erro é uma ofensa terrível, ele deve ser escondido. Pronto. Acabamos de destruir uma empresa. Esses erros que ficam ocultos vão minando as bases da empresa até o ponto em que ela fica insustentável.

Uma solução a essa “cultura do culpado” é uma “cultura da solução”. O culpado passa a ser um personagem secundário. O realmente importante é encontrar uma solução e voltar o mais rápido possível ao estado normal de trabalho. Essa forma de agir tem algumas vantagens:

  • Seus problemas são solucionados mais rápido
  • O erro passa a ser parte do aprendizado e por isso não faz sentido ter medo e escondê-los
  • Como seus erros estão visíveis, você finalmente tem a chance de fazer melhorias reais para evitar que eles aconteçam novamente

Essa “cultura da solução” é um dos principais pontos dentro de Scrum (e também é uma das mais difíceis de serem implantadas). Toda a parte de Inspecionar e Adaptar só é possível se você tiver (não apenas dentro do time, mas com todos os envolvidos no projeto) segurança para relatar os problemas que tem acontecido.

3 Comentários »

Categorias deste post

Scrum, Técnico

Não perturbe o programador

Recentemente, acompanhando a lista de discussão sobre Scrum “Scrum Development”, vi uma discussão interessante sobre um programador que afirmava precisar de tempo de isolamento para trabalhar.

Isso me fez pensar bastante. Realmente várias vezes eu senti necessidade de me isolar para poder trabalhar (em especial em um momento me que eu precisava implementar algum algoritmo específico ou precisava otimizar determinado código). Isso fez muito sentido na minha cabeça e durante um tempo cheguei a concordar com o programador. Mas será que isso é uma coisa boa?

Vamos analisar a curto prazo. Durante duas horas eu me isolo da equipe (não posso mais chamar de time pois estou trabalhando sozinho) e resolvo o problema. Foi vantajoso porque se eu parasse para discutir ou utilizasse pair-programming demoraria cerca de 8 horas (algoritmos são bem difíceis de explicar para quem ainda não teve contato com ele). Aumentei a velocidade do time e isso foi uma coisa boa, correto?

Não. Essa foi a pior atitude que poderia ser tomada. Pensem na sequinte situação ocorrendo logo após essa.

Novamente a equipe é confrontada com um problema semelhante. Quem é o único que tem experiência resolvendo esse tipo de problema? Eu. Então novamente me isolo da equipe para resolvê-lo. Começaram a notar onde pretendo chegar?

No momento em que me isolei da equipe, eu causei um dano muito sério. Retive conhecimento ao invéz de compartilha-lo. Se apenas eu sei como lidar com o problema, na próxima vez que ele ocorrer ou quando for necessário dar manutenção, eu preciso trabalhar nele. Ou seja, o Truck Factor para aquele trecho de código é 1.

Porque isso é muito ruim? Um programador com tendência de concentrar informação, não vai concentrar apenas um dos pontos. Ele irá agir dessa forma muitas outras vezes. Logo, ele será o único com conhecimento para resolver muitos problemas, causando um sério impedimento. Isso sem contar que a equipe não vai ter a oportunidade de crescer e aprender a resolver esse problema.

Isso é uma atitude de muita irresponsabilidade. O crescimento da equipe deve ser prioridade para todos os programadores da equipe. Apenas agindo dessa forma a equipe poderá passar a ser um time.

10 Comentários »

Categorias deste post

Técnico