Robert Miesen enviou esta história de uma patologia de projeto:
Eu fazia parte de uma equipe que estava escrevendo um sistema de seleção e solicitação de emprego com base na Web (um quiosque de emprego, como o cliente o chamava) e minha equipe e nosso cliente concordaram em implementar esse quiosque de emprego usando Windows, Apache, PHP5 e ZendFramework – todos, exceto um dos membros da equipe, a quem chamarei de “Joe”. Joe continuou defendendo o uso do JavaScript durante toda a fase de deliberação da tecnologia, embora o cliente tenha deixado bem claro que esperava que a grande maioria do quiosque de empregos fosse implementada usando uma tecnologia do lado do servidor e que toda a validação fosse feita usando a tecnologia do lado do servidor.
O fato de o cliente ter concordado com isso, no entanto, não impediu Joe de defender o JavaScript – de forma abrasiva. Toda vez que o nosso projeto encontrava um obstáculo, Joe começava a falar sobre como nossa vida seria mais fácil se escrevêssemos esse quiosque de empregos apenas em JavaScript. Joe reclamava constantemente que estávamos fazendo tudo errado porque não estávamos escrevendo em JavaScript, nem mesmo se dava ao trabalho de aprender as tecnologias que estávamos usando e, sempre que os colegas de equipe tentavam trazê-lo de volta ao grupo (geralmente por e-mail), Joe simplesmente o xingava. No auge do fanatismo pró-JavaScript de Joe, ele fazia regularmente comentários do tipo: “Bem, se tivéssemos feito isso em JavaScript”, a tal ponto que a equipe teria ficado melhor se ele tivesse simplesmente se demitido (ou sido transferido ou demitido).
Depois de ler essa história, tive de resistir ao impulso de me inclinar para a frente, com a mão colocada pensativamente sob o queixo, sobrancelhas franzidas, e perguntar… o senhor já experimentou o JavaScript?
Robert achava que essa história era um conto de advertência sobre a dependência da tecnologia, mas vejo outra coisa: um membro da equipe problemático, uma maçã podre clássica.
Tenho certeza de que o “Joe” tinha a melhor das intenções, mas a ponto de o senhor estar ativamente fazendo campanha contra o projeto e trabalhando contra seus colegas de equipe… o senhor é um risco para o projeto.
O custo de pessoal problemático em um projeto é grave, conforme observado no Capítulo 12 do livro de McConnell Rapid Development: Taming Wild Software Schedules.
Se o senhor tolerar até mesmo um desenvolvedor que os outros desenvolvedores considerem problemático, prejudicará o moral dos bons desenvolvedores. O senhor está insinuando que não só espera que os membros da sua equipe deem tudo de si, como também espera que eles façam isso quando os colegas de trabalho estão trabalhando contra eles.
Em uma análise de 32 equipes de gestão, Larson e LaFasto descobriram que a reclamação mais consistente e intensa dos membros da equipe era que os líderes da equipe não estavam dispostos a confrontar e resolver os problemas associados ao mau desempenho de cada membro da equipe. (Larson e LaFasto 1989). Eles relatam que, “mais do que qualquer outro aspecto da liderança da equipe, os membros são perturbados por líderes que não estão dispostos a lidar direta e eficazmente com membros da equipe que se servem a si mesmos ou que não contribuem”. Eles continuam dizendo que esse é um ponto cego significativo da administração porque os gerentes quase sempre acham que suas equipes estão funcionando melhor do que os membros da equipe.
Como identificamos o pessoal problemático? Não é tão difícil quanto o senhor imagina. Certa vez, um amigo meu descreveu alguém de sua equipe como – e esta é uma citação direta – “um câncer”. No momento em que o senhor, ou qualquer outra pessoa da sua equipe, estiver usando palavras como câncer para descrever um colega de equipe, o senhor tem uma séria patologia de projeto. O senhor não precisa ser amigo de todos da sua equipe, embora isso certamente ajudemas um nível básico de respeito pessoal e profissional é obrigatório para que qualquer equipe funcione normalmente.
Steve descreve alguns sinais de alerta de que o senhor está lidando com uma maçã podre em sua equipe:
- Eles encobrem sua ignorância em vez de tentar aprender com seus colegas de equipe. “Não sei como explicar meu projeto; só sei que ele funciona.” ou “Meu código é muito complicado para ser testado.” (Essas duas citações são reais).
- Eles têm um desejo excessivo de privacidade. “Não preciso que ninguém revise meu código.”
- Eles são territoriais. “Ninguém mais pode corrigir os erros em meu código. Estou muito ocupado para corrigi-los agora, mas vou fazer isso na próxima semana.”
- Eles reclamam das decisões da equipe e continuam a revisitar discussões antigas muito depois de a equipe ter seguido em frente. “Ainda acho que deveríamos voltar e mudar o design sobre o qual estávamos conversando no mês passado. O que escolhemos não vai funcionar.”
- Todos os outros membros da equipe fazem piadas ou reclamam da mesma pessoa regularmente. Os desenvolvedores de software geralmente não reclamam diretamente, então o senhor precisa perguntar se há algum problema quando ouve muitas piadas.
- Eles não participam das atividades da equipe. Em um projeto em que trabalhei, dois dias antes do nosso primeiro grande prazo, um desenvolvedor pediu um dia de folga. O motivo? Ele queria passar o dia em uma liquidação de roupas masculinas em uma cidade próxima – um sinal claro de que não havia se integrado à equipe.
Deixe-me ser bem claro neste ponto: se o líder ou gerente da sua equipe não estiver lidando com as maçãs podres do seu projeto, o senhor pode ter certeza de que não está lidando com elas, ele não está fazendo o trabalho dele.
O senhor nunca deve ter receio de afastar, ou até mesmo demitir, pessoas que não tenham em mente os melhores interesses da equipe. O senhor pode desenvolver habilidades, mas não pode desenvolver uma atitude positiva. Quanto mais tempo essas personalidades perturbadoras permanecerem em um projeto, piores serão seus efeitos. Elas espalharão lentamente veneno por todo o projeto, na forma de código, relacionamentos e contatos.
Remover alguém de uma equipe é doloroso; não é divertido para ninguém. Mas percebendo que o senhor deveria ter removido alguém há seis meses é muito mais doloroso.