Existem Times, times, timinhos e igrejinhas, como a Copa recém-encerrada bem mostrou. A formação de equipes, para projetos de qualquer natureza, é uma complexa mistura de ciência, bom senso, tato e intuição.
Ciência porque é preciso conhecer o projeto, as partes interessadas, as habilidades requeridas – tanto sociais quanto técnicas, e o desenho sócio-técnico mais adequado. O bom senso delineia fronteiras, particularmente em relação aos selecionáveis. O tato é exigido tanto na convocação quanto na exclusão de integrantes da equipe. Por fim, a intuição, subjetiva qualidade que permite perceber que aquele improvável jogador pode render bastante em determinado momento do projeto.
Este artigo trata exclusivamente o primeiro componente, a ciência. E, claro, não falará sobre seleções de futebol. Apesar de sua possível utilidade em outros tipos de iniciativas, o alvo aqui são os projetos para desenvolvimento de sistemas.
Até pouco tempo atrás eu me gabava de ter feito apenas uma pequena alteração em um metamodelo sócio-técnico que tinha uns 10 anos de idade. Vendia-o como um modelo para um Dream Team, ignorando alguns padrões emergentes que exigiam outro nível de abstração. A ficha só caiu depois de uns tabefes na cara, particularmente os proferidos por Jim Highsmith em “Agile Project Management – 2nd Edition” (Addison-Wesley, 2010). Roman Pichler, em seu “Agile Product Management with Scrum“ (Addison-Wesley, 2010), deu o bofetão de misericórdia.
O Líder do Projeto
O Movimento Ágil colocou o auto-gerenciamento no topo da agenda de todos que estavam formando times seguindo seus princípios. “Indivíduos e interações são mais importantes que processos e ferramentas”, é o que diz o primeiro verso do Manifesto Ágil. Dele derivaram os conceitos de auto-direção, auto-organização, auto-disciplina, respeito pelos indivíduos, igualitarismo e um bom ambiente de trabalho.
Highsmith diz com todas as letras que “times auto-organizados não se caracterizam pela falta de liderança, mas por um estilo de liderança”. Reforça a mensagem citando Larson e LaFasto (“Teamwork: What Must Go Right, What Can Go Wrong”. Sage Publications, 1989): “bons líderes são o principal ingrediente de projetos e organizações de sucesso”.
Highsmith ataca frontalmente, resguardando os nomes dos santos, as propostas de auto-direção. Estas sim se caracterizariam pela ausência de um líder único. Os integrantes se revezariam nesta função dependendo de determinada situação em um projeto. Parece claro que ele dirige suas críticas para algumas práticas sugeridas em frameworks como o Scrum e a XP (Extreme Programming). Critica as práticas ou algumas interpretações delas, preciso dizer.
Déjà vu? Pois é, já falei um tanto sobre o líder aqui no finito, na seguinte série:
O Time de Produto
Residem aqui todos os que ajudam a definir e priorizar o que precisa ser feito. Sim, é aqui que fica o Product Owner (PO – Dono do Produto) em um projeto guiado pelo Scrum. Uma coisa que precisa ser mais reconhecida e divulgada é que o PO, normalmente um usuário ou especialista no domínio, raramente terá disponibilidade para executar e entregar tudo o que está sob sua responsabilidade. Para muitos não fará sentido, por exemplo, a execução de várias tarefas operacionais para desenvolvimento e manutenção da Pauta (ou Product Backlog, como queiram).
Além do PO ou gerente do produto, o time de produto pode ser formado por: analistas de negócios, especialistas no produto / domínio e parte do pessoal de controle de qualidade (QA). Highsmith reconhece que “a formação deste time, com as pessoas mais adequadas e com tempo suficiente, pode ser um complicado desafio para muitas organizações porque o comprometimento exigido é bem maior do que em projetos tocados de maneira tradicional”.
É por isso que teimo tanto com a Formação de Analistas de Negócios. Por entender que os bons analistas podem compensar a indisponibilidade de usuários e clientes que mal têm tempo para cuidar de seus afazeres cotidianos. Que fique claro: eles compensam, mas não substituem nunca os usuários e especialistas.
O curioso é que até hoje vemos equipes sendo formadas sem um único representante disso que chamo (depois do Highsmith) de Time de Produto¹. Gerentes de projetos e analistas-programadores normalmente se revezam na posse dessas atribuições. O (imenso) problema com este enfoque é um só: gerentes e analistas-programadores não percebem o “levantamento de requisitos” (sic) como sua responsabilidade principal: “a gente não foi contratado pra isso”. Eles querem é gerenciar e programar. “Requisitos”, vejam só, é um tipo de impedimento para que eles executem seu trabalho real. Uma amolação.
O Time de Desenvolvimento
Gerentes de projetos, analistas-programadores (é melhor Desenvolvedores, não?) e afins moram aqui. Se o Time de Produto define o que precisa ser feito, este é o grupo responsável pelo como será feito e pela construção propriamente dita. Apesar de vivermos em tempos de massificação simplista e beócia – formando e contratando “analistas-programadores” como se tudo fosse a mesma coisa – não custa insistir que este time também é multidisciplinar. Que, dependendo do projeto, vários especialistas podem ser requeridos. Um profissional que saiba desenvolver para o Android ou iPhone, por exemplo.
Gosto de ver, de forma macro, uma estrutura com um mínimo de 4 células: interfaces, serviços, dados e infraestrutura. Isso não significa hierarquização nem divisão excessiva do trampo, mas sim a aceitação de que existem conhecimentos específicos. Não é “linha de montagem”, mas o reconhecimento do fator humano e da impossibilidade de contratar gente que saiba tudo sobre tudo. Estão distantes os tempos dos monoblocos cobolísticos.
Juntando Tudo
Se há um projeto então existe um objetivo ou conjunto de objetivos bem definido. Se o Líder, o Time de Produto e o Time de Desenvolvimento trabalham no sentido de alcançar o mesmo objetivo, então eles formam um único time. Este deveria ser o único critério para definir um time de verdade, não as eventuais divisões internas que só existem para organizar o conhecimento e as responsabilidades de cada um.
É muito sadia a divisão entre a turma do “que” e do “como”:
- Falando como um usuário: “Eu realmente participo do projeto, faço parte do time. E quando não posso participar de algum encontro, fico tranquilo porque tenho um representante que defende meu ponto de vista. Isso, mais as entregas regulares que um processo iterativo e incremental garante, torna o projeto um trabalho agradável e estimulante, ao contrário do calvário que caracterizava nossos projetos anteriores.”
- Falando como um desenvolvedor: “Finalmente inventamos uma maneira de ter o usuário bem perto da gente sem aquela sensação de ‘nós contra eles’, de dormir com o inimigo. Somos um time só e o que nos une são os objetivos do projeto.”
Divisão sadia, mas naturalmente conflituosa. Sempre foi, independente da arquitetura social ou processo de desenvolvimento utilizado. E sempre será. Os conflitos podem gerar uma tensão criativa, desejável ou até mesmo fundamental dependendo da natureza do projeto. Uma hora é um time que apresenta sua caixa – suas restrições e condições. Outra hora a outra divisão o faz. E todos trabalham, como diz Scott Berkun², “pensando dentro da caixa, debaixo dela, fora dela, quebrando-a e fazendo uma bela fogueira”. É nesta hora que a presença de um líder pode fazer diferença. Quando o “que” e o “como” demoram para atingir um consenso, transformando a caixa numa solução criativa, nada melhor que um olhar isento mas igualmente comprometido com os mesmos objetivos. E com 3 votos nunca teremos empates, certo?
.:.
Observações:
- Já usei o termo “Time do Dono do Produto”, traduzindo literalmente Roman Pichler no livro já citado. “Time de Produto”, conforme sugerido por Jim Highsmith, é bem melhor. Mas confesso que não sei como ficará de forma definitiva em português. Aliás, nem sei se vingará como conceito!!
- Em “A Arte do Gerenciamento de Projetos” (Bookman, 2008).
- A ilustração utilizada neste artigo, “Chain of People”, foi legalmente surrupiada de HikingArtist.
