Gestão das Pessoas

Os projetos são feitos por pessoas, e a maior parte dos problemas que se atribuem ao prazo, ao custo ou à tecnologia nasce na comunicação, na confiança e na clareza de papéis. Gerir pessoas num projeto é criar as condições para que uma equipa, muitas vezes reunida só para esse projeto, consiga decidir bem e trabalhar em conjunto.

Mapa do tema

Pergunta	Onde aprofundar
Quem afeta ou é afetado pelo projeto?	Stakeholders
Como organizar as equipas e reduzir dependências?	Team Topologies
Como criar um ambiente onde se pode errar e levantar problemas?	Psychological Safety
Como avaliar o contributo individual em projetos?	Avaliação de Colaboradores
Como evolui um grupo ao longo do tempo?	Estados de um Grupo
Como lidar com sobrecarga e excesso de tarefas em paralelo?	Efeitos do Excesso de Tempo
Como ajudar as pessoas a adotar o que o projeto entrega?	Gestão da Mudança

Construção da equipa

Uma equipa de projeto passa por fases até render. O modelo de Tuckman (formação, conflito, normalização, desempenho) é um bom ponto de partida, e está desenvolvido em Estados de um Grupo. Cabe ao gestor acompanhar a fase em que o grupo está e adaptar o estilo: mais clareza no início, mais mediação no conflito, mais autonomia quando o grupo já funciona.

Confiança e honestidade

Ser aberto e honesto, tanto quanto possível, é a base de tudo o resto. Se o gestor quer estimativas e informação o mais corretas possíveis, tem de dar informação igualmente correta, incluindo as más notícias. A confiança constrói-se com atos pequenos e repetidos: cumprir o que se diz, admitir erros e partilhar o contexto das decisões.

Segurança psicológica

Segurança psicológica é a crença partilhada de que se pode fazer perguntas, admitir erros e discordar sem ser penalizado. A investigadora Amy Edmondson mostrou, em 1999, que as equipas com mais segurança falam mais dos erros e, por isso, aprendem mais com eles. Num projeto, significa saber de um problema na semana 3 e não na semana 12. Ver Psychological Safety.

Feedback

O feedback deve ser específico, oportuno e sobre comportamentos observáveis, não sobre a pessoa. Um formato simples é descrever a situação, o comportamento e o impacto que teve. Algumas regras práticas:

• Feedback individual: preferencialmente em privado, para proteger a dignidade da pessoa e facilitar a conversa. O reconhecimento positivo, ao contrário, pode ser público.
• Problemas da equipa: colocados ao grupo, que os assume como responsabilidade coletiva e os resolve em conjunto, em vez de procurar culpados.
• Frequência: regular e perto do facto, e não apenas na avaliação anual. Ver Avaliação de Colaboradores.

Responsabilização e transparência com o cliente

Proteger a equipa não significa esconder problemas ao cliente. As tensões internas devem ser tratadas internamente primeiro, e o cliente deve ser informado com transparência sobre o que afeta o projeto (riscos, atrasos, decisões), com uma posição coerente da equipa. A lealdade ao grupo e a honestidade para com o cliente não se contrariam: o que desgasta a confiança é ocultar o que o cliente precisa de saber.

Delegar

Delegar é atribuir uma responsabilidade com a autoridade necessária para a cumprir, não atribuir tarefas e desaparecer. Uma boa delegação:

• facilita a compreensão da tarefa e do resultado esperado;
• define objetivos alcançáveis e critérios de sucesso;
• dá o apoio e os recursos necessários;
• deixa espaço para a pessoa decidir como faz, com pontos de verificação combinados.

Papéis e responsabilidades

Muitos conflitos e atrasos nascem de dois erros simples: duas pessoas a achar que são responsáveis pela mesma coisa, ou ninguém a achar que é. Uma matriz de responsabilidades clarifica isto para cada entregável ou decisão. A mais conhecida é a RACI:

R — Responsible (executa)

Quem faz o trabalho. Pode haver mais do que uma pessoa.

A — Accountable (responde)

Quem responde pelo resultado e aprova. Deve haver apenas uma pessoa por entregável.

C — Consulted (consultado)

Quem dá opinião antes de a decisão ser tomada.

I — Informed (informado)

Quem é informado depois de a decisão ser tomada.

Entregável	Gestor de projeto	Equipa técnica	Patrocinador	Cliente
Plano do projeto	A / R	C	I	C
Entrega da funcionalidade X	A	R	I	C
Alteração de âmbito	R	C	A	C

Os valores são ilustrativos. Cada linha deve ter um único A, e uma linha sem R é um sinal de alerta. Ver também o controlo de alterações, onde a decisão de aprovar tem de ter dono.

Motivação

Num projeto, a motivação não se resolve só com remuneração. A investigação sugere alguns fatores que o gestor pode influenciar:

• Autonomia: decidir como fazer o trabalho, dentro de objetivos claros.
• Competência: ter as capacidades e a formação para fazer bem o que se pede, com desafios adequados.
• Relação: sentir-se parte da equipa e respeitado por ela.
• Sentido: perceber para que serve o trabalho e como contribui para o resultado.
• Progresso visível: ver avanços, mesmo pequenos, é um dos maiores motores do bom desempenho no dia a dia.

Em sentido inverso, alguns fatores desmotivam mesmo quando tudo o resto está bem: objetivos contraditórios, sobrecarga contínua, falta de reconhecimento e mudanças de prioridades sem explicação. Herzberg chamou-lhes fatores de higiene: a sua ausência não motiva, mas a sua presença desmotiva.

Negociação

Um projeto negoceia continuamente: prazos, recursos, âmbito, prioridades. A negociação funciona melhor quando as partes procuram os interesses por trás das posições, em vez de defender cada uma a sua posição (a ideia central de Fisher e Ury em Getting to Yes). Cinco passos ajudam a estruturar a conversa:

Compreensão

Perceber a proposta em discussão e as opções disponíveis; o que cada grupo e cada pessoa pretende ganhar; o que se traz para a mesa e quais as cedências possíveis.

Empatia

Perceber as emoções das pessoas envolvidas permite comunicar para além da lógica e antecipar resistências.

Confiança

As negociações bem-sucedidas assentam na confiança. O gestor de projeto deve tomar a iniciativa de a estabelecer entre as partes.

Contribuição

Todas as partes devem contribuir para chegar a uma solução. Quem fica de fora pode sentir-se excluído e deixar de apoiar o resultado.

Consenso

Todas as partes assinalam a aceitação dos compromissos assumidos, e estes ficam registados.

Estas conversas são também o centro da relação com os stakeholders. Quando o resultado altera o âmbito, o prazo ou o custo, deve passar pelo controlo de alterações e refletir-se no equilíbrio entre as restrições.

Conflito

O conflito é normal em projetos: há prioridades diferentes, recursos escassos e pressão de prazo. O objetivo não é eliminá-lo, mas evitar que passe do assunto para as pessoas.

• Sobre a tarefa: desacordo sobre âmbito ou solução. Pode ser útil, se for tratado com dados.
• Sobre o processo: quem faz o quê e como. Resolve-se com papéis e regras claros.
• Sobre a relação: tensões pessoais. É o mais corrosivo e deve ser tratado cedo, em privado e com mediação se for preciso.

Uma sequência simples: ouvir cada parte, separar factos de interpretações, procurar o interesse comum, acordar uma ação e escalar apenas o que a equipa não consegue resolver.

Liderança

Em projetos, a liderança raramente se apoia em autoridade hierárquica. Apoia-se em dar contexto (porquê e para quê), clareza (quem decide o quê) e apoio (remover obstáculos). A forma como se alinham objetivos entre equipas está em OKRs, e a organização das equipas em Team Topologies.

Checklist

• Os papéis e as responsabilidades estão claros e escritos (por exemplo, numa matriz RACI com um único responsável por entregável)
• As pessoas sabem quem decide o quê
• Existe um espaço regular para levantar problemas sem receio
• O feedback é frequente e específico
• As delegações incluem objetivo, autoridade, apoio e pontos de verificação
• Os compromissos de cada negociação ficam registados
• Os conflitos são tratados cedo e a nível adequado
• A carga de trabalho de cada pessoa é realista e visível

Erros Frequentes

• Dar feedback só quando há problemas, ou só no fim do projeto.
• Delegar sem autoridade ou sem apoio e depois culpar quem não conseguiu.
• Ocultar riscos ao cliente para «proteger» a equipa.
• Tratar a segurança psicológica como simpatia, e não como condição para o trabalho de qualidade.
• Evitar o conflito até ele se tornar pessoal.
• Sobrecarregar as mesmas pessoas e chamar-lhe «compromisso».

Como Aplicar em 30 Dias

1. Semana 1: clarificar papéis, responsabilidades e quem decide o quê.
2. Semana 2: criar um momento regular (por exemplo, no fim da reunião semanal) para levantar problemas e riscos.
3. Semana 3: começar conversas curtas de feedback com cada pessoa e rever as delegações em curso.
4. Semana 4: rever com a equipa o que funcionou e o que deve mudar na forma de trabalhar.

Referências

• Tuckman, B. W., Developmental sequence in small groups, Psychological Bulletin (1965).
• Edmondson, A., Psychological Safety and Learning Behavior in Work Teams, Administrative Science Quarterly (1999).
• Fisher, R. e Ury, W., Getting to Yes (1981).
• Herzberg, F., Mausner, B. e Snyderman, B., The Motivation to Work (1959).
• Deci, E. L. e Ryan, R. M., The “What” and “Why” of Goal Pursuits, Psychological Inquiry (2000).
• Amabile, T. e Kramer, S., The Progress Principle (2011).
• PMI, PMBOK Guide: planeamento e gestão dos recursos e das responsabilidades.

Atualizado em: 03/10/2026