Imagine um projeto em que o que se deve entregar é um bebê. Uma vez que a mulher engravida, o tempo de entrega é extremamente previsível, certo? 9 meses, em média, com alguma variação, claro, no fim das contas todos os projetos contam com algum nível de mitigação de riscos.
Substituir membros de uma equipe
Conheça Juliana: ela está grávida de 6 meses, pronta para ter Lucas e entregá-lo para o mundo em 2 meses.
Conheça Amanda: ela não está grávida.
Então, Juliana recebe um telefonema:
"Olá, Juliana. Sabemos que você esteve no Projeto Lucas por 7 meses, mas precisamos de você em outro projeto. Amanda vai substituir você no Projeto Lucas. Sabemos que ela não está grávida, mas não se preocupe, vamos focar na qualidade da transferência para que Amanda ainda consiga ter Lucas pronto a tempo."
Fica muito claro que Amanda não tem como ter um bebê em 2 meses, ela nem está grávida. Mesmo que ela engravide imediatamente, não é possível ter Lucas no tempo estimado. Como resultado, o Projeto Lucas vai atrasar.
Transferência de bebê/conhecimento
Supôs-se que a gravidez de 7 meses podia ser transferida rapidamente de Juliana para Amanda. Quando falamos em bebês fica bem visível que é impossível transferir Lucas de uma mãe para a outra e ainda tê-lo na mesma data determinada. Se você, como uma amiga minha que está grávida, achou que falar em transferência de bebês é "errado, de mau gosto e ridículo", confesso que essa é exatamente a reação que estou procurando. Há algo de muito errado em tratar pessoas como unidades substituíveis e é isso que estou tentando expressar aqui. O ridículo da transferência de um bebê foi o mais próximo que cheguei de passar a mensagem de não tratar pessoas como pessoas.
Essa comparação com uma gravidez é uma "simplificação exagerada", assim como a famosa Lei de Brook: "Nove mulheres não conseguem fazer um bebê em um mês" cunhada por Fred Brooks eu seu livro O Mítico Homem-Mês.
Geralmente, quando um membro da equipe é substituído em um projeto de software, por exemplo, temos uma espécie de transferência de conhecimento, que deve ser planejada com cuidado.
Wikipedia: "Transferência de conhecimento é algo complexo porque o conhecimento reside nos membros da organização (...)"
Habilidades e conhecimentos levam tempo para se desenvolver. Muito mais do que bebês, na verdade. Alguns levam anos para adquirir e aperfeiçoar. No caso de Juliana (grávida), substituída por Amanda (não grávida), há um tempo de transferência a ser levado em conta que é perigoso subestimar. A suposição de que uma pode substituir a outra sem muito impacto não é realista. O impacto de um membro em uma equipe pode ser tão significativo e subestimado quanto o bater das asas de uma borboleta.
Ao substituir um membro de uma equipe, é extremamente importante levar em conta qual é a contribuição desse membro para a equipe à qual ele pertence, em vez de vê-lo como uma unidade substituível: um recurso.
O membro da equipe como um floco de neve
Tratar os membros de uma equipe como unidades substituíveis ou recursos é problemático porque dá a entender que se tivermos um Desenvolvedor de Java Sênior, por exemplo, ele pode ser substituído por qualquer outro Desenvolvedor de Java Sênior e isso não terá nenhum impacto na equipe.
Para parafrasear Frederick P. Brooks, Jr., eu diria:
"Nossas técnicas de gerenciamento de equipes erroneamente confundem papéis dentro da equipe com contribuição à equipe, supondo que pessoas com os mesmos papéis e níveis de senioridade são intercambiáveis."
Na minha experiência, aquele Desenvolvedor de Java Sênior tem muitas habilidades únicas que não conseguimos enquadrar em um papel único, como Analista, Desenvolvedor Java, etc.
Pegando emprestada a metáfora usada pela área de DevOps sobre evitar servidores floco de neve, quando o assunto é alocar pessoas em equipes, realmente precisamos vê-las como flocos de neve. Cada membro da equipe tem um conjunto de habilidades único que os ajuda a atingir objetivos em comum.
Essas habilidades ultrapassam seus papéis e podem ser:
- Relacionamento com os outros membros da equipe
- Conhecimento de domínio
- Frameworks internos específicos relevantes para apenas algumas equipes
- Quaisquer outros benefícios intangíveis
O que eu faço, então?
É quase impossível e está longe do ideal manter todo mundo na mesma equipe para sempre.
Geralmente me perguntam:
"O que eu faço, então, se precisar transferir as pessoas de equipe?"
A coisa mais importante é não tratar as pessoas como unidades substituíveis representadas completamente pelos nomes dos papéis e podem ser realocadas como cadeiras, mesas ou outros recursos físicos. Aqui estão algumas coisas que eu faço e geralmente ajudam:
- Pergunte aos outros membros da equipe quais são as habilidades específicas àquele membro da equipe
- Ao mudar a formação de uma equipe, sempre há algum impacto que deve ser levado em conta
- Aproxime-se dos membros da equipe que estiver gerenciando, para conhecê-los melhor e saber de suas habilidades e aspirações
- Veja cada membro da equipe como um floco de neve, uma pessoa única cujo conjunto de habilidades não é apenas a descrição do seu papel, mas a experiência de uma vida
- Refira-se às pessoas pelos nomes e habilidades:
- Dizer: "Nosso desenvolvedor Paulo vai mudar de equipe e precisamos achar alguém com habilidades equivalentes" é muito melhor do que:
- "Perdemos um recurso que precisa ser substituído" - isso faz parecer que uma de suas mesas quebrou.
Leituras adicionais
- The Magic and Science of Teams (A ciência mágica dos times, em tradução livre), de Mark Levison
- Management 3.0 (Gerenciamento 3.0, em tradução livre), de Jurgen Appelo
- O Mítico Homem-Mês, de Frederick P. Brooks Jr.
- Snowflake Server (O servidor floco de neve, em tradução livre), de Martin Fowler
- Peopleware, de Tom DeMarco
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.