Uma pessoa ou uma equipa? Como definir a composição mínima de um projeto com base em competências, dependências e risco

A investigação não suporta uma regra simples como "equipas menores são sempre melhores" ou "equipas maiores produzem sempre mais".

Uma meta-análise de 2023, com 208 efeitos independentes e 21 435 equipas, encontrou uma relação global praticamente nula entre tamanho da equipa e desempenho da tarefa, mas uma grande variação conforme o contexto. Os autores mostram que a importância do tamanho muda, entre outros fatores, com a complexidade da tarefa e as necessidades de coordenação. [4]

Uma experiência com uma tarefa complexa de mapeamento de crises também mostrou benefícios e custos de equipas maiores: a colaboração aumentou com o tamanho, enquanto os padrões de esforço individual mudaram. Nessa experiência específica, as maiores equipas superaram um número equivalente de pessoas a trabalhar de forma independente. Isto não é uma receita universal para qualquer tipo de trabalho. [5]

A conclusão prática é simples: o número de pessoas deve resultar da natureza do trabalho, não de um número mágico.

O Scrum Guide de 2020 descreve a Scrum Team como pequena, multifuncional e autogerida. Também indica que normalmente tem 10 pessoas ou menos. [3]

É uma orientação útil no contexto de Scrum, mas não uma lei universal para todos os projetos, serviços, setores ou modelos de execução.

Um projeto de construção, uma campanha de marketing, uma avaliação de segurança, um sistema financeiro e um pequeno site informativo têm necessidades muito diferentes. Um único número não deve ser transferido diretamente entre estes contextos.

O Service Standard britânico exige que as equipas de serviços digitais sejam multidisciplinares e tenham acesso a um conjunto adequado de competências. Também diz que a composição deve depender do que a equipa precisa de alcançar em cada fase. [1]

Outra orientação da GOV.UK afirma que o tamanho da equipa e as funções necessárias mudam ao longo das fases de criação de um serviço. [2]

Daqui resulta uma regra prática:

primeiro descreva o trabalho e as responsabilidades, depois identifique as competências e só no fim atribua pessoas concretas.

Não é possível dimensionar uma equipa para um âmbito pouco claro.

Registe pelo menos:

• o resultado a produzir,
• o que está dentro do âmbito,
• o que fica de fora,
• os principais requisitos de qualidade,
• as restrições de tempo e orçamento,
• quem aceitará o resultado,
• se a equipa apenas entrega a solução ou também a opera.

Um projeto "criar uma aplicação" e outro "conceber, criar, proteger, implementar e operar uma aplicação durante um ano" exigem coberturas de trabalho completamente diferentes.

Em vez de atribuir cargos de imediato, liste os tipos de trabalho que realmente têm de ser realizados.

Num serviço digital podem incluir:

• compreender as necessidades dos utilizadores,
• conceber a solução,
• construir a parte visível para o utilizador,
• desenvolver lógica e integrações do lado do servidor,
• testar,
• segurança,
• acessibilidade,
• implementação e operação,
• coordenação do âmbito e das decisões.

Outro tipo de projeto terá uma lista diferente.

A GOV.UK indica que uma equipa que cria e opera um serviço digital precisa de um conjunto amplo de competências, incluindo necessidades dos utilizadores, design, construção, testes, segurança, implementação e operação. [2]

Nem todas as competências necessárias exigem uma pessoa a tempo inteiro na equipa.

Classifique cada área:

Permanente - necessária regularmente e com influência direta nas decisões diárias.
Periódica - necessária em fases ou pontos de controlo específicos.
Disponível externamente - pode ser fornecida por outra pessoa ou equipa, desde que o tempo de resposta e a responsabilidade estejam suficientemente claros.

A GOV.UK admite explicitamente que uma equipa tenha acesso a conhecimento especializado sem que o especialista seja necessariamente membro permanente. [1]

Isto evita muitas vezes aumentar artificialmente a equipa sem perder uma competência importante.

Duas pessoas podem reunir todas as competências necessárias e ainda assim formar uma má configuração se todo o trabalho depender de uma cadeia estreita.

Verifique:

• que tarefas podem avançar em paralelo,
• quais têm de esperar por outras,
• quem toma decisões que bloqueiam trabalho posterior,
• de que equipas ou fornecedores externos depende o projeto,
• onde a ausência de uma pessoa pararia várias áreas ao mesmo tempo.

A GOV.UK inclui a gestão de dependências com outras equipas entre as capacidades necessárias para criar serviços digitais. [2]

Quando mais de uma equipa trabalha num serviço, surge também a necessidade adicional de coordenar planos e progresso entre equipas. [8]

Algumas competências necessárias não aparecem numa lista de funcionalidades do produto, mas a sua ausência pode ser dispendiosa.

Consoante o projeto, podem incluir:

• segurança,
• proteção de dados,
• acessibilidade,
• requisitos legais ou setoriais,
• fiabilidade,
• migração de dados,
• integrações com sistemas críticos,
• tecnologia que a equipa ainda não utilizou.

A GOV.UK recomenda acesso a conhecimento especializado quando o projeto necessita e diz que a composição deve também refletir as hipóteses mais arriscadas da fase atual. [1]

Isto não exige automaticamente uma função a tempo inteiro para cada risco. Significa, porém, que uma pessoa competente deve ter responsabilidade explícita e capacidade real de influenciar as decisões.

Uma pessoa pode saber design, desenvolvimento, testes e implementação. Isso não significa que consiga realizar todos esses tipos de trabalho ao mesmo tempo com qualquer prazo.

O material da PMI sobre planeamento de recursos destaca a importância de ajustar competências, disponibilidade, custo e experiência às necessidades do projeto. [7]

Para cada pessoa, verifique:

• quanto tempo consegue realmente dedicar,
• que tarefas disputam a sua atenção,
• se o trabalho necessário tem de avançar em paralelo,
• se o prazo pressupõe mudanças irrealistas entre muitos tipos de trabalho,
• se alguém terá de continuar a operar a solução depois do lançamento.

Cobrir competências sem cobrir tempo disponível não é cobrir todo o projeto.

A composição mínima deve considerar também a continuidade.

Pergunte:

• o que acontece se uma pessoa-chave estiver indisponível,
• se apenas uma pessoa compreende uma parte crítica da solução,
• se decisões e conhecimento estão documentados,
• se outra pessoa pode assumir as tarefas mais importantes,
• se o projeto pode parar de forma segura durante uma ausência.

Nem todos os pequenos projetos precisam de redundância completa. Num projeto curto e de baixo risco, aceitar conscientemente este risco pode ser razoável.

Num projeto crítico, a mesma dependência de uma pessoa pode ser inaceitável.

Um projeto não precisa de uma pessoa diferente para cada nome de função.

Se uma pessoa possui realmente as competências necessárias, tem capacidade suficiente e não cria um risco inaceitável, pode cobrir várias áreas de forma responsável.

Num projeto pequeno, por exemplo, uma pessoa pode combinar design de interface e implementação. Noutro, pode combinar análise de negócio e coordenação do âmbito.

Não junte responsabilidades apenas porque "alguém tem de fazer isto". A combinação só faz sentido se a pessoa puder desempenhar ambas ao nível exigido e tiver tempo suficiente.

Uma pessoa pode ser uma configuração racional quando todas estas condições se verificam:

• o âmbito é pequeno e bem definido,
• as competências necessárias cabem realmente nas suas capacidades,
• as tarefas exigem pouco trabalho paralelo,
• as dependências externas são limitadas,
• o risco é aceitável,
• o prazo corresponde à capacidade real,
• a falta de substituição é conscientemente aceite.

Pode ser o caso de um pequeno material informativo, uma análise simples, uma consulta pontual ou uma implementação limitada num ambiente conhecido.

Ainda assim, depende do âmbito concreto. O rótulo "projeto pequeno" não decide a questão por si só.

Uma equipa torna-se mais justificada quando aparecem várias destas condições:

• as competências necessárias são demasiado amplas para uma pessoa,
• muitas atividades têm de decorrer em paralelo,
• o prazo é menor do que uma execução sequencial realista,
• o projeto tem muitas dependências e interfaces,
• o risco exige conhecimento especializado independente,
• a solução tem de ser construída e operada ao mesmo tempo,
• uma pessoa tornar-se-ia um ponto crítico de todo o projeto,
• a responsabilidade abrange várias disciplinas distintas.

Nestas condições, acrescentar capacidades em falta é mais importante do que simplesmente aumentar o número de pessoas.

Adicionar pessoas aumenta o conhecimento disponível e a capacidade potencial, mas também pode aumentar dependências, transferências de trabalho e a necessidade de alinhar decisões.

Um estudo de projetos de software publicado no Journal of Systems and Software mostrou que as relações entre tamanho da equipa, produtividade, esforço e tempo são complexas e nem sempre coincidem com as expectativas intuitivas. [6]

A meta-análise sobre tamanho das equipas também mostra que os resultados dependem do contexto da tarefa e dos custos dos processos de equipa. [4]

A pergunta, portanto, não é "quantas pessoas podemos acrescentar?", mas "a próxima pessoa elimina uma limitação real do projeto mais do que aumenta o custo de coordenação?"

Nem toda competência importante precisa de estar presente todos os dias.

Presença permanente faz mais sentido quando a pessoa toma decisões regularmente, o seu trabalho tem muitas dependências com outras áreas ou é necessária resposta rápida.

Apoio periódico pode ser suficiente quando a competência é necessária em momentos específicos, como revisão, consulta, avaliação de risco ou validação especializada.

Há uma condição: a disponibilidade tem de ser real. Deve estar claro:

• quem é responsável,
• quando está disponível,
• qual o tempo de resposta esperado,
• que decisões pode tomar,
• o que acontece se identificar um problema.

Ter acesso nominal a um especialista sem responsabilidade definida pode ficar bem num organograma e falhar num projeto real.

Suponha que o objetivo é lançar um sistema de reservas online.

Variante A: protótipo simples para testar a ideia
O âmbito é limitado, não existem pagamentos nem dados especialmente sensíveis e o objetivo é testar o processo com um pequeno grupo de utilizadores. Uma pessoa versátil pode potencialmente cobrir design e implementação, com apoio pontual quando necessário.

Variante B: serviço público com contas, pagamentos e integrações
Surgem mais especialização, testes, risco, dependências e trabalho paralelo. Uma equipa de várias pessoas fica muito mais justificada.

Variante C: serviço em funcionamento contínuo que exige resposta rápida a problemas
À construção juntam-se operação, monitorização, resposta a incidentes e continuidade do conhecimento. A composição necessária para lançar pode não ser suficiente para operar de forma sustentável.

É o mesmo tipo geral de produto, mas âmbito, risco e modelo operacional diferentes criam necessidades de equipa diferentes.

1. Começa por uma lista pronta de cargos em vez do trabalho a realizar.

2. Assume que cada função exige uma pessoa diferente.

3. Olha apenas para competências e ignora o tempo disponível.

4. Adiciona pessoas sem remover dependências e estrangulamentos.

5. Ignora competências motivadas pelo risco porque não criam uma funcionalidade visível.

6. Faz várias áreas críticas dependerem de uma pessoa sem aceitar conscientemente o risco.

7. Trata a composição inicial como fixa até ao fim do projeto.

A GOV.UK afirma explicitamente que o tamanho e as funções da equipa mudam ao longo das fases de desenvolvimento de um serviço. [2]

É uma regra sensata também fora dos serviços públicos:

• no início pode ser necessária mais investigação e definição do problema,
• durante a implementação ganham importância as competências de execução e teste,
• antes do lançamento podem aumentar as necessidades de segurança, qualidade e preparação operacional,
• depois do lançamento muda o equilíbrio entre evolução e operação.

A composição mínima depende da fase e do âmbito, não é um número fixo atribuído ao projeto para sempre.

Para cada área importante, registe cinco elementos:

Área de trabalho - o que tem de ser feito?
Competência - que conhecimento e capacidade são necessários?
Responsabilidade - quem decide e responde pelo resultado?
Disponibilidade - a competência é permanente, periódica ou externa?
Risco de ausência - o que acontece se a competência faltar ou a pessoa estiver indisponível?

Só depois atribua pessoas concretas.

Se uma pessoa cobrir várias linhas, verifique o tempo e as dependências. Se uma linha precisar de várias pessoas, verifique se a razão é capacidade, controlo independente ou trabalho paralelo.

1. Todas as áreas de trabalho obrigatórias têm responsável?
2. Cada responsabilidade crítica tem uma pessoa com a competência adequada?
3. Alguém cobre várias funções e tem realmente tempo suficiente?
4. O projeto exige trabalho paralelo que a composição atual não consegue suportar?
5. Conhecemos as principais dependências de outras pessoas, equipas e fornecedores?
6. Os riscos importantes têm acesso ao conhecimento especializado adequado?
7. A ausência de uma pessoa pode parar todo o projeto?
8. A composição chega não só para construir, mas também para lançar e operar a solução se isso fizer parte do âmbito?
9. Sabemos que competências podem ser periódicas em vez de permanentes?
10. Definimos momentos para reavaliar a composição após mudanças de âmbito ou fase?

A composição da equipa não deve começar pela pergunta:

"quantas pessoas costumam ser necessárias para um projeto destes?"

Uma ordem melhor é:

resultado -> trabalho -> competências -> dependências -> risco -> capacidade -> pessoas.

Se uma pessoa realmente cobrir tudo depois desta análise, uma pessoa pode ser a escolha certa.

Se faltarem competências, tempo, revisão independente, continuidade ou capacidade para trabalho paralelo, precisa de mais pessoas ou de acesso fiável a especialistas.

O objetivo não é a equipa mais pequena. O objetivo é a menor composição capaz de entregar realisticamente o resultado exigido com o nível de risco e qualidade necessário.

[1] GOV.UK Service Standard - Have a multidisciplinary team
Abrir fonte

[2] GOV.UK Service Manual - Set up a service team at each phase
Abrir fonte

[3] The Scrum Guide, 2020 - Scrum Team
Abrir fonte

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
Abrir fonte

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
Abrir fonte

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
Abrir fonte

[7] Project Management Institute - Solving The Resource Puzzle
Abrir fonte

[8] GOV.UK Service Manual - Running more than one service team
Abrir fonte

Nota metodológica: algumas fontes tratam de serviços públicos digitais, outras de equipas Scrum, gestão de projetos ou investigação sobre equipas e desenvolvimento de software. Este guia usa cada fonte apenas no que ela realmente suporta. O método em sete passos é uma síntese editorial destes princípios, não uma norma formal das organizações referidas.