Não é a toa que existe um processo específico do PMBOK sobre a montagem da equipe. Eu acredito que este é um dos pontos principais a serem considerados em um projeto.
Vamos a uma situação que aconteceu comigo e vocês irão entender...
Ontem na reunião de definição dos objetivos do ciclo de desenvolvimento, o meu chefe comentou da necessidade de colocarmos mais uma pessoa na nossa equipe (somos 3 desenvolvedores + 1 gerente) que ficaria responsável pela documentação, um dos pontos chaves do nosso projeto. Recusei a idéia, pelo menos de forma momentânea, pois acredito que estamos "redondinhos" para as tarefas que temos pela frente. Eu confesso que 4 desenvolvedores seria o tamanho ideal para este projeto, mas não vejo a necessidade de termos uma pessoa só para documentação. Além disso, recém saimos de uma mudança de ambiente de trabalho que já causou um impacto ruim na equipe. Acrescentar uma nova pessoa poderia trazer um impacto pior.
Quando iniciamos este projeto, lá em setembro de 2006, a equipe era composta pelas seguintes pessoas:
- Flavio, gerente de projetos (na época bem inexperiente);
- EB, o patrocinador-especialista-cliente do projeto;
- GP, um dos melhores recursos do nosso projeto. Porém, devido à desorganização inicial, teve sua motivação e produtividade afetadas enormemente;
- VT, outro bom recurso, mas que tem sérios problemas com horários;
- PV, inicialmente sub-avaliado como um recurso para suporte;
- VP, bom conhecedor dos assuntos, mas de personalidade forte e controversa;
- LK, bom conhecedor do assunto, mas visivelmente não estava muito interessado;
- PZ, grande amigo do LK e bom recurso, que também visivelmente não estava muito interessado;
- GA, uma espécie de bombeiro do grupo, sendo chamado apenas em casos de necessidade;
- FS, foi o último recurso a se juntar a nós e tem se mostrado muito bom e fácil de lidar.
Começamos com 7 desenvolvedores, 1 patrocinador-cliente-especialista, 1 bombeiro e 1 gerente. Imaginem uma fase de concepção (muita pesquisa) sendo organizada e dividida entre 7 pessoas? É óbvio que o resultado foi terrível. Não entrarei em maiores detalhes para não perder o foco, mas ficou evidente desde a primeira reunião de kick-off que 7 pessoas era um número muito grande para se administrar, ainda mais em um projeto de grande complexidade como o nosso.
Então, o tempo tratou de reduzir a equipe. Sairam, na ordem cronológica:
- PZ, para fazer intercâmbio no exterior, em dezembro 2006.
- LK, para entrar em outra empresa, em janeiro 2007.
- GA, para fazer doutorado em Portugal.
- VP, por ser o principal causador de conflitos do grupo (o único que foi "demitido"). Foi substituído pelo FS.
- GP, para fazer mestrado na Itália.
É impressionante a diferença entre se trabalhar com 3 ou 4 pessoas. A comunicação flui, a motivação e produtividade crescem... enfim, tudo se torna mais "administrável". Podemos dizer também que a possibilidade de definir de fato quem é responsável pelo quê, tornou as coisas mais simples também (VT é responsável pelo software, PV pelo hardware e o FS pelo middleware... ficou mais ou menos assim).
Tamanho e qualidade da equipe não podem ser avaliadas separadamente. Como disse um palestrante uma vez: "1 mulher faz um bebê em 9 meses, mas 9 mulheres não fazem 1 bebê em 1 mês". É preciso avaliar o projeto e escolher bem a sua equipe, seja em quantidade de pessoas, seja em qualidade.
Eu aprendi as seguintes lições:
a) Lealdade, experiência e relacionamento devem ser essenciais. Ninguém quer contratar alguém sabendo que essa pessoa tem um passado de deixar os outros na mão, ou que essa pessoa não tem experiência na área onde está se metendo (ou se for contratar um inexperiente, certificar de que ele terá suporte). E o relacionamento? Uma pessoa que não consegue conviver ou trabalhar em equipe, não pode ser cogitada para um trabalho em que a comunicação e interação é grande.
b) Avaliar MUITO BEM as necessidades de equipe. Sete pessoas para realizar uma pesquisa na internet? Uma ou duas pessoas para desenvolverem uma tecnologia digna de um mestrado? Quantidade não é qualidade, e vice-versa.
c) Ter pelo menos uma ou duas pessoas de extrema confiança no grupo. São elas que geralmente serão seu braço direito (e esquerdo). Opte por pelo menos uma pessoa com um perfil comunicativo e com bons conhecimentos técnicos. E deixe claro o que você pretende com esta pessoa, para garantir a lealdade.
d) Cuidado com a amizade. Amizade e profissionalismo são diferentes. Se você for muito amigo de seus subordinados, o profissionalismo começa a sumir. Mas isso é um assunto para ser discutido posteriormente...
e) Se você puder, interfira na formação da equipe. Lembre-se de que é você quem irá conviver o dia-a-dia com estas pessoas, não o seu chefe.
terça-feira, 2 de outubro de 2007
Montando a sua equipe...
Marcadores:
comentários,
conflitos,
Dia-a-dia,
lições aprendidas,
sugestões
Assinar:
Postar comentários (Atom)
Um comentário:
A Martine Devos (http://www.objectmentor.com/omTeam/devos_m.html) falou uma vez num curso de "Certified Scrum Master" que o único problema em aplicar Agilidade em uma equipe cada vez maior, é que cada vez maior são os desafios para manter uma boa comunicação entre a equipe.
Postar um comentário