Unidade 06

Gestão de Pessoas e
Equipes de Projeto

Das competências à composição da equipe: estrutura organizacional, liderança, MIPPE, comunicações e stakeholders. Complemento: equipes de projetos com Scrum.

CHAPerfis profissionaisMIPPELiderançaScrum

Introdução

Nos capítulos anteriores da disciplina, partimos dos fundamentos da gestão de projetos e avançamos pela governança, pela complexidade e pela maturidade organizacional. Em seguida, a gestão do escopo traduziu necessidades em requisitos e entregas, enquanto a gestão do tempo organizou atividades, dependências e recursos em um cronograma. A abordagem com Scrum acrescentou a esse percurso a priorização por valor e o planejamento em ciclos curtos.

Esta unidade conecta essas decisões às pessoas que realizarão o trabalho. A pergunta inicial é quais competências as entregas exigem e como reuni-las em uma equipe capaz de colaborar. A partir daí, definimos perfis profissionais, estrutura organizacional, papéis, responsabilidades e necessidades de mobilização ao longo do tempo.

O dimensionamento da equipe e o cronograma amadurecem em conjunto: mudanças na disponibilidade de competências alteram os prazos viáveis, e mudanças nas atividades alteram a necessidade de pessoas. Liderança, comunicação e integração sustentam esse ajuste, tanto em estruturas matriciais quanto em equipes que trabalham com Scrum.

Esse planejamento prepara a continuidade da disciplina: os perfis e sua alocação apoiam a formação do orçamento; as lacunas de capacidade e as dependências alimentam a análise de riscos; e as responsabilidades e interfaces contribuem para a qualidade e para a integração do projeto. O fio condutor é manter coerência entre escopo, tempo, equipe, custos e valor entregue.

↑ Voltar ao início

Competências e Perfis Profissionais

A literatura de gestão por competências decompõe a competência individual em três dimensões — Conhecimento, o saber teórico e técnico acumulado; Habilidade, a capacidade de aplicar esse saber na prática; e Atitude, a disposição comportamental para agir de determinada forma —, reunidas sob a sigla CHA (DURAND, 2006; FLEURY; FLEURY, 2001), como ilustra a Figura 22. As três dimensões são necessárias e nenhuma substitui as demais.

Figura 22 — Modelo CHA (Conhecimento, Habilidade, Atitude) na composição da competência individual. Clique para ampliar.

A prática profissional aqui relatada consolidou esse raciocínio em um conceito operacional próprio: o perfil. Um perfil é o conjunto de competências técnicas — formação, conhecimentos, certificações e experiência profissional — e competências comportamentais necessário para ocupar uma posição específica na estrutura organizacional do projeto. A distinção entre perfil e pessoa é deliberada: o objeto do planejamento, nas etapas iniciais, é o perfil — uma posição definida por competências —, e apenas posteriormente esse perfil é ocupado por um profissional específico. Planejar por perfis, e não diretamente por pessoas, permite que a estrutura organizacional do projeto seja definida com base no que o trabalho exige, e não com base na disponibilidade imediata de indivíduos específicos.

As competências técnicas de cada perfil são, em geral, mais simples de avaliar: cursos formais, certificações e comprovação em trabalhos anteriores semelhantes oferecem critérios relativamente objetivos. As competências comportamentais apresentam maior dificuldade de avaliação, e exigem profissionais preparados para identificar atributos como capacidade de liderança, resiliência à pressão, autocontrole e responsabilidade — competências que, como discutido na Seção 6.7, variam conforme o papel que cada perfil desempenhará na estrutura do projeto.

A amplitude de competências exigidas por um único projeto multidisciplinar pode ser surpreendente para quem não atuou nesse tipo de empreendimento. Um caso concreto para o projeto de um sistema de elevada complexidade relacionou, entre as competências necessárias à equipe, gerenciamento de projetos, modelagem e melhoria de processos, engenharia de requisitos, engenharias mecânica, eletrônica, de telecomunicações e da computação, doutrina de operações militares, saúde, processos de aquisição no serviço público, direito administrativo, comunicação e marketing, segurança da informação e economia e finanças, ou seja, uma diversidade enorme de competências e, consequentemente, de perfis. Nenhum indivíduo reúne, isoladamente, a totalidade dessas competências; a estrutura organizacional discutida na Seção 6.3 é exatamente o mecanismo que permite distribuí-las entre diferentes perfis e, ao mesmo tempo, integrá-las em um planejamento coerente.

↑ Voltar ao início

Estrutura Organizacional do Projeto

O dimensionamento da equipe tem início não pelas pessoas, mas pela estrutura organizacional necessária para produzir as entregas do projeto. Cada pacote de trabalho, derivado do escopo discutido no Capítulo 3, é agrupado em blocos de competências coerentes, e cada bloco passa a ser de responsabilidade de uma equipe específica. A Figura 23 apresenta essa referência de estruturação de equipe.

Essa estrutura, na prática aqui relatada, assumiu de forma recorrente uma configuração matricial com três componentes. Verticalmente, equipes técnicas organizadas por competências coerentes entre si, cada uma liderada por um líder técnico responsável pela qualidade e pelo andamento de seu bloco de trabalho. Horizontalmente, uma equipe de integração, responsável por assegurar a coerência entre os blocos técnicos, liderada por um líder de integração. No centro da estrutura, um núcleo de gestão, responsável por assessorar diretamente o gerente do projeto nas áreas de conhecimento da gestão de projetos — escopo, tempo, custos, riscos, aquisições, comunicações e demais áreas.

Figura 23 — Estrutura organizacional matricial: equipes técnicas verticais, equipe de integração horizontal e núcleo de gestão no centro. Clique para ampliar.

Essa configuração não é uma matriz funcional tradicional como normalmente apresentada pela literatura introdutória (MINTZBERG, 1979). A diferença está em seus três níveis claramente definidos — competência técnica, integração e gestão — e na forma como a integração entre disciplinas é tratada como responsabilidade organizacional explícita, e não como consequência espontânea da boa vontade entre equipes. É importante destacar que, obviamente, essa estrutura é tanto mais aplicável quanto maior for a diversidade de perfis e competências alocadas para realizar as atividades que compreendem o esforço de trabalho. Embora métodos ágeis privilegiem equipes pequenas e multifuncionais, naturalmente isso não se coaduna com a realidade de projetos complexos, em que a multidisciplinaridade é uma das premissas típicas.

Uma ideia interessante é tornar explícitas as interseções entre as equipes verticais, organizadas por sistema, e blocos transversais de classificação — análogos a uma estrutura horizontal adicional, sobreposta à equipe de integração. Em vez de presumir genericamente que "a integração é importante", identificar e relacionar em uma tabela específica quais classes de elementos do sistema geram interseção forte, antecipando exatamente onde a coordenação entre equipes técnicas demanda maior atenção — e orientando, a partir dessa análise, tanto a quantidade quanto as competências dos técnicos a serem alocados em cada interseção identificada.

↑ Voltar ao início

Dimensionamento da Equipe

Definida a estrutura organizacional e identificados os perfis de cada posição, surge somente então a pergunta sobre quantidade: quantos profissionais de cada perfil serão necessários, e quando. Essa quantidade deriva diretamente do cronograma discutido no Capítulo 4: o cronograma determina quando cada perfil será necessário, durante quanto tempo permanecerá mobilizado e quando poderá ser desmobilizado.

Figura 5.3 — Alocação temporal dos perfis ao longo do cronograma do projeto. Clique para ampliar.

Essa abordagem permite estimar com precisão os custos salariais e os encargos associados a cada perfil — tema desenvolvido no conteúdo de gestão de custos — e antecipa decisões sobre as estratégias de contratação adequadas a cada caso, discutidas na próxima seção. Para projetos intensivos em capital humano, a alocação oportuna de cada perfil ao longo do tempo é um dos fatores que mais influenciam a adequação do custo final do projeto: dimensionar corretamente o perfil, mas mobilizá-lo no momento errado, produz os mesmos efeitos indesejados de um dimensionamento incorreto.

↑ Voltar ao início

Estratégias de Mobilização e Contratação da Equipe

Definido o quantitativo de cada perfil ao longo do cronograma, torna-se necessário decidir a forma de vínculo mais adequada para cada caso — contratação direta por prazo indeterminado, contratação por prazo determinado, prestação de serviços por profissional autônomo ou pessoa jurídica, ou terceirização integral de determinada frente de trabalho. Essa decisão é estratégica, e não meramente jurídica: envolve disponibilidade de competências no mercado, duração prevista das atividades, retenção de conhecimento ao longo do projeto, flexibilidade operacional para ajustes futuros e, evidentemente, custo.

Ao planejar projetos intensivos em mão de obra, é recomendável considerar, desde o início do projeto, a estratégia de mobilização e desmobilização da força de trabalho, observando a legislação trabalhista vigente e seus impactos sobre os custos do projeto. Em diferentes momentos da prática profissional aqui relatada, essa preocupação assumiu formas distintas — em um período, limitar a janela de contratação a prazos que reduzissem custos de desligamento ao final do projeto; em outro, avaliar criteriosamente quais perfis deveriam ser vinculados por prazo indeterminado e quais por prestação de serviços. O ponto que permanece constante, independentemente do arranjo legal vigente em cada época, é a necessidade de planejar a mobilização e a desmobilização da equipe com a mesma disciplina dedicada ao restante do cronograma, evitando que decisões de contratação sejam tomadas de forma improvisada, sob pressão do início da execução.

Em organizações estruturadas em matriz, a mobilização da equipe raramente está sob o controle exclusivo do gerente do projeto: ela depende, em alguma medida, de negociação com a estrutura funcional permanente da organização. Uma metodologia interna real, aplicada de forma consistente em uma organização de consultoria especializada, formaliza esse processo em uma regra simples: o gerente do projeto solicita à gerência de operações a alocação da equipe adequada, com base nas estimativas derivadas da estrutura analítica do projeto; quando os perfis necessários não estão disponíveis entre os colaboradores já existentes, o gerente solicita formalmente sua seleção ao setor de recursos humanos, e essa seleção passa a ser registrada explicitamente como uma dependência interna do projeto, com reflexo direto no cronograma. Tratar a mobilização de pessoal como uma dependência rastreável — e não como uma simples expectativa informal de que "a equipe estará disponível quando necessário" — é o que permite antecipar, e não apenas lamentar, os atrasos que a indisponibilidade de perfis específicos pode produzir.

↑ Voltar ao início

Liderança Técnica e Equipes de Integração

A definição de perfis e quantitativos não encerra o planejamento da equipe. Resta ainda atribuir funções, papéis e autoridade a cada posição alocada ao longo do tempo — utilizando, para isso, conceitos compatíveis com a matriz de responsabilidades RACI, amplamente difundida na literatura de gestão de projetos (PROJECT MANAGEMENT INSTITUTE, 2021). Esse encerramento do planejamento da equipe só se completa quando quatro elementos estão consistentes entre si: a estrutura organizacional, os perfis, os quantitativos e as funções e papéis atribuídos a cada um.

Um ponto de atenção especial recai sobre a escolha dos líderes técnicos. O melhor especialista técnico de uma equipe não é, necessariamente, o melhor líder para ela: liderança técnica e liderança de pessoas são competências distintas, e a escolha de um líder deve considerar ambas, e não apenas a excelência técnica individual.

A equipe de integração, introduzida na Seção 6.3, merece tratamento próprio por ser um tema pouco explorado na literatura introdutória de gestão de projetos, que tende a privilegiar as estruturas funcionais e matriciais convencionais. À medida que a complexidade de um projeto aumenta, cresce também a necessidade de coordenação entre os diversos subsistemas e disciplinas envolvidas — e essa coordenação é, precisamente, a responsabilidade da equipe de integração. Entre suas atribuições destacam-se o acompanhamento da evolução de cada equipe técnica, o monitoramento de interfaces internas e externas, a manutenção de padrões técnicos comuns e a promoção ativa da integração entre disciplinas. O dimensionamento dessa equipe depende diretamente da complexidade do sistema: projetos simples podem dispensar uma estrutura dedicada de integração, ao passo que projetos complexos normalmente exigem uma equipe permanente para essa função — uma observação que dialoga diretamente com a discussão sobre interoperabilidade e sistemas de sistemas apresentada no Capítulo 3.

Figura 5.4 — Equipe de integração conectando engenharia, software, infraestrutura, qualidade, fornecedores e cliente. Clique para ampliar.

Vale notar, ainda, que uma equipe recém-formada não opera, desde o primeiro dia, com a mesma eficácia que alcança após um período de convivência e ajuste mútuo. Tuckman (1965) descreve essa evolução em estágios sucessivos — formação, conflito, normatização e desempenho —, e Hackman (2002) reforça que a eficácia de uma equipe depende não apenas da competência individual de seus membros, mas de condições estruturais que a organização precisa deliberadamente prover, como clareza de objetivos e composição adequada. Essa maturação é um argumento adicional, ao lado dos já discutidos no Capítulo 4, para que o cronograma reserve tempo suficiente à consolidação da equipe, e não apenas à execução das tarefas técnicas propriamente ditas.

↑ Voltar ao início

Competências Comportamentais e atitudes

No modelo CHA, as atitudes representam a dimensão comportamental da competência, relacionada à disposição para agir, colaborar, comunicar, liderar e adaptar-se às circunstâncias. As competências comportamentais, entretanto, não se limitam às atitudes isoladamente: resultam da mobilização integrada de conhecimentos, habilidades e atitudes em situações concretas.

As competências comportamentais relevantes para um projeto não são universais; elas dependem do papel desempenhado por cada perfil. Um especialista responsável por cálculos técnicos especializados pode exigir, sobretudo, rigor, organização e disciplina; um líder de integração, por sua vez, depende mais intensamente de competências como negociação, comunicação, mediação de conflitos e visão sistêmica. Por essa razão, é mais preciso falar em uma matriz de competências — relacionando perfil, função, competências técnicas e competências comportamentais — do que em uma lista única de competências comportamentais desejáveis para toda a equipe.

Algumas competências comportamentais, contudo, são exigidas transversalmente, independentemente do papel específico: comprometimento, colaboração e capacidade de aprender contínuo tendem a ser indispensáveis a qualquer integrante da equipe, ao passo que negociação, resiliência à pressão e visão sistêmica concentram-se mais fortemente em papéis de liderança técnica e de integração.

↑ Voltar ao início

Grau de Liberdade Gerencial na Composição da Equipe

A metodologia descrita neste capítulo foi desenvolvida e aplicada, com sucesso recorrente, em um contexto de elevada autonomia gerencial — a iniciativa privada, na qual o gerente podia compor a estrutura, definir os perfis, contratar os profissionais e montar a equipe de acordo com a necessidade identificada. Em projetos de governo, contudo, essa liberdade não está disponível da mesma forma. A estrutura organizacional e os perfis ainda podem — e devem — ser planejados; a disponibilidade efetiva das pessoas, porém, depende da organização e do patrocinador do projeto, sem garantia de que a quantidade ou a qualificação dos perfis designados corresponda exatamente ao planejado.

Essa diferença pode ser resumida da seguinte forma: na iniciativa privada, o gerente administra predominantemente recursos; na administração pública, ele administra, com frequência, predominantemente restrições. Essa distinção altera profundamente a natureza da liderança exigida em cada contexto. Quanto menor a liberdade para compor a equipe, maior se torna a importância da liderança: na iniciativa privada, parte dos problemas de equipe pode ser resolvida pela contratação de novos profissionais ou pela substituição de perfis inadequados; na administração pública, essa flexibilidade é, em geral, muito mais limitada, e a liderança passa a compensar, por meio de motivação, distribuição adequada de responsabilidades e desenvolvimento das pessoas disponíveis, limitações que em outros contextos seriam resolvidas por uma simples mudança na composição da equipe. Não que a liderança seja menos importante nos projetos privados — é tão importante quanto —, mas porque, nesse contexto, parte de suas exigências pode ser suprida pela própria contratação no mercado, possibilidade que nem sempre está disponível ao gestor público.

↑ Voltar ao início

O MIPPE — Método Iterativo de Planejamento de Perfis e Equipes

As seções anteriores descrevem, em conjunto, uma metodologia própria, amadurecida ao longo de décadas de prática profissional e aplicada com sucesso recorrente: o Método Iterativo de Planejamento de Perfis e Equipes, ou MIPPE. O MIPPE não substitui os referenciais clássicos de gerenciamento de projetos; ao contrário, utiliza seus conceitos como fundamento, propondo uma sistematização prática do planejamento organizacional capaz de transformar escopo, cronograma e competências em uma estrutura de equipe consistente.

O raciocínio que fundamenta o MIPPE resulta de experiências práticas de planejamento de equipes. Preliminarmente esse processo foi rotulado como Dimensionamento da Equipe: um mapa reunindo as competências necessárias ao desenvolvimento dos serviços e a quantidade de profissionais de cada competência planejada para cada etapa do projeto. A justificativa registrada para a importância dessa ferramenta era direta: como não havia, naquele contrato, liberdade significativa para alterar prazo de execução ou recursos financeiros disponíveis, o dimensionamento correto da equipe — e não apenas do cronograma ou do orçamento — tornava-se a principal variável sobre a qual a equipe ainda exercia controle efetivo. Essa observação confirma, com outras palavras e em outro contexto, a relação entre grau de liberdade gerencial e composição da equipe discutida na Seção 6.8: quanto mais restritas as demais variáveis de gestão, maior a importância de dimensionar corretamente aquela que permanece sob controle do gestor. Dessa primeira experiência, surgiu o método, denominado MIPPE — Método Iterativo de Planejamento de Perfis e Equipes, sistematização, construída a partir da experiência profissional em gestão de projetos e compatível com os princípios consagrados de gerenciamento de projetos, em que a estrutura organizacional do projeto é derivada dos pacotes de trabalho, os perfis profissionais são definidos pelas competências requeridas para cada função, e a composição da equipe é obtida iterativamente a partir do cronograma, permitindo o refinamento contínuo do planejamento até sua consolidação.

O método assenta-se em cinco princípios. Primeiro, o planejamento da equipe decorre do escopo do projeto: não existem equipes padronizadas, e cada projeto demanda competências específicas. Segundo, os perfis são definidos antes da seleção das pessoas: o objeto do planejamento é o perfil profissional, somente depois ocupado por um indivíduo específico. Terceiro, cronograma e equipe são interdependentes: alterações no cronograma modificam a necessidade de recursos, e alterações na equipe modificam, por sua vez, o cronograma viável. Quarto, o planejamento é iterativo: escopo, cronograma, estrutura organizacional e equipe evoluem simultaneamente, em sucessivas revisões, até atingir um grau adequado de maturidade. Quinto, o planejamento deve considerar todo o ciclo de vida da equipe — mobilização, permanência e desmobilização —, e não apenas o momento de sua composição inicial.

MIPPE — Método de Planejamento de Perfis e Equipes. Clique para ampliar.

Esses princípios traduzem-se em uma sequência de etapas, que se repetem em ciclos sucessivos, e não em uma progressão estritamente linear: a partir do escopo e dos pacotes de trabalho, define-se a estrutura organizacional — equipes técnicas, equipe de integração e núcleo de gestão; para cada posição da estrutura, define-se o perfil correspondente, em termos de competências técnicas e comportamentais; a partir do cronograma, dimensiona-se a quantidade necessária de cada perfil e sua alocação temporal; definem-se, então, funções, papéis e autoridade; e o conjunto resultante é confrontado novamente com o escopo e o cronograma, retroalimentando o planejamento até que ambos atinjam maturidade suficiente para sustentar a estimativa de custos abordada na gestão do orçamento.

Figura 5.5 — Fluxo do MIPPE, com retroalimentação contínua ao planejamento. Clique para ampliar.
↑ Voltar ao início

Comunicações e Gestão de Stakeholders

A estrutura organizacional, os perfis e o dimensionamento discutidos nas seções anteriores só produzem os resultados esperados quando sustentados por um fluxo de informação disciplinado. A gestão das comunicações é, com frequência, tratada como a dimensão menos técnica da gestão de pessoas — e, por isso mesmo, a mais subestimada. Essa percepção é equivocada. Em projetos de alta complexidade, com múltiplos stakeholders, múltiplos fornecedores e múltiplas jurisdições organizacionais, comunicar exige tanta estrutura e deliberação quanto compor uma equipe ou dimensionar um cronograma. O PMI trata as comunicações e o gerenciamento de stakeholders como áreas específicas de conhecimento (PROJECT MANAGEMENT INSTITUTE, 2021); a experiência aqui relatada sugere, no entanto, que ambas se manifestam concretamente no exercício da liderança discutido na Seção 6.6, e não como atividades autônomas e desconectadas da gestão da equipe.

O modelo clássico de comunicação, proposto por Shannon e Weaver (1949) para problemas de transmissão de sinais, descreve a comunicação como um processo de codificação, transmissão e decodificação de mensagens entre um emissor e um receptor. Em projetos, esse modelo é útil, mas insuficiente: a comunicação gerencial não transmite apenas informação, mas constrói entendimento compartilhado e alinha expectativas entre partes com interesses nem sempre coincidentes. Um relatório de status tecnicamente correto, mas mal interpretado pelo cliente, cumpre a função de transmissão descrita por Shannon e Weaver, mas fracassa como comunicação gerencial.

A lição mais consistente sobre comunicação, observada ao longo de projetos de engenharia de sistemas de naturezas muito distintas, é que a ausência de informação não é neutra: ela é preenchida por suposições, rumores e interpretações individuais que frequentemente divergem da realidade e entre si. Em um ambiente em que o subcontratado não recebe informação regular sobre o andamento do projeto como um todo, ele inevitavelmente desenvolve sua própria narrativa — que pode ser otimista demais, gerando comprometimentos que não serão cumpridos, ou pessimista demais, gerando paralisias desnecessárias. O plano de comunicações existe precisamente para evitar esse vácuo.

O ciclo de comunicações de um projeto começa, formalmente, com a reunião de kick- off. É uma boa prática que a sequência de inicialização do programa seja descrita com precisão: 1) após uma revisão formal de aceitação do contrato, o gerente de programa estabelece o arcabouço do programa; 2) concluídas as atividades de inicialização e planejamento, uma reunião de kick-off seja realizada para permitir que as pessoas-chave tenham um entendimento comum do programa e sejam capazes de iniciar a fase de planejamento detalhado. O kick-off não é, portanto, um evento protocolar de abertura, mas o momento em que o entendimento comum do programa é construído coletivamente, alinhando expectativas, esclarecendo papéis e responsabilidades e antecipando incertezas. Além do kick-off, o ciclo de comunicações inclui revisões periódicas de progresso, cuja frequência deve ser calibrada pela velocidade de mudança do projeto, e não pela conveniência da agenda.

O relatório de status é o artefato mais elementar da gestão de comunicações — e, por isso mesmo, o mais frequentemente malfeito. Um relatório eficaz não é uma lista de atividades concluídas: é uma comunicação sobre o estado do projeto em relação ao seu plano, com destaque para desvios, ações em andamento e decisões pendentes. Por exemplo, em projetos com múltiplos subcontratados, o gerente do contrato principal pode solicitar relatórios periódicos de status a cada fornecedor não apenas para monitorar o andamento individual de cada subcontrato, mas para identificar interdependências que podem estar criando riscos sistêmicos invisíveis a partir da perspectiva de cada fornecedor isoladamente.

O conceito de stakeholder, introduzido no Capítulo 1 a partir de Freeman (1984) como qualquer grupo ou indivíduo capaz de afetar ou ser afetado pelos objetivos do projeto, ganha aqui sua dimensão prática de gestão. Identificar quem tem interesse no projeto, qual é o nível de poder e influência de cada parte, o que cada uma espera e teme, e como cada uma precisa ser comunicada são atividades que devem ser realizadas na abertura do projeto e revisadas periodicamente. Mendelow (1991) sistematizou essa avaliação em uma matriz de poder e interesse amplamente adotada pela prática de gestão de stakeholders, e Bourne (2009) desenvolveu essa lógica em um modelo de maturidade organizacional para o relacionamento com partes interessadas, reforçando que a gestão de stakeholders é uma competência a ser deliberadamente construída, e não apenas exercida intuitivamente pelo gerente.

Em projetos com múltiplas partes interessadas — cliente final, fiscais de contrato, comitês de aprovação, fornecedores, parceiros acadêmicos e órgãos reguladores —, a gestão de stakeholders pode ser tão complexa quanto a gestão técnica do sistema. O gerente que ignora essa dimensão frequentemente descobre, tarde demais, que o projeto foi aprovado em todos os aspectos técnicos mas rejeitado por motivos políticos ou institucionais que estavam visíveis desde o início, para quem estivesse prestando atenção. Essa observação conecta diretamente comunicações e stakeholders à liderança técnica discutida na Seção 6.6: negociação, mediação de conflitos e leitura das relações de poder são, na prática aqui relatada, extensões da mesma competência de liderança, e não disciplinas isoladas a serem geridas por um plano de comunicações à parte.

Artefatos da gestão de comunicações e stakeholders. Clique para ampliar.
↑ Voltar ao início

Síntese

A gestão de pessoas, como discutida neste capítulo, não começa com a pergunta "quantas pessoas preciso", mas com a pergunta "que competências o escopo e o cronograma exigem". O conceito de perfil — competências técnicas e comportamentais associadas a uma posição, e não a uma pessoa específica — organiza esse raciocínio; a estrutura organizacional matricial, com equipes técnicas, equipe de integração e núcleo de gestão, fornece o arranjo no qual os perfis são posicionados; e o dimensionamento, as estratégias de contratação e a atribuição de funções e papéis completam o planejamento.

O grau de liberdade gerencial, já discutido nos capítulos anteriores, manifesta-se na gestão de pessoas de forma particularmente direta: ele determina quanto do MIPPE o gerente pode executar por conta própria, e quanto precisa negociar com instâncias externas ao projeto. Reconhecer essa limitação não é admitir impotência gerencial, mas calibrar corretamente onde concentrar o esforço de liderança — e essa calibração é, talvez, uma das competências mais subestimadas pela literatura introdutória de gestão de pessoas em projetos.

O MIPPE encerra-se exatamente no ponto em que a organização planejada está suficientemente madura para sustentar a estimativa de custos — o tema que será aprofundado na gestão de custos. Tal como ocorreu na transição do escopo para o cronograma, e do cronograma para a equipe, a transição da equipe para o orçamento não é um corte abrupto entre áreas de conhecimento isoladas, mas a continuidade natural de um mesmo processo de amadurecimento progressivo do planejamento.

↑ Voltar ao início

Equipes de projetos com Scrum

Referência: Alexandre Magno, Tire seu projeto do papel com Scrum (2019), Parte II, p. 83–130. Síntese em palavras próprias. As responsabilidades e os eventos apresentados adiante seguem o Guia Scrum de 2020.

Construir um time exige condições de colaboração

Na Parte II, Magno discute o crescimento do projeto como um desafio de organização de pessoas, comunicação e dependências. Um time exige objetivos coletivos e condições coerentes com a colaboração; incentivos centrados apenas no desempenho individual podem contrariar esse propósito.

A definição de sucesso e a entrega de incrementos prontos orientam o levantamento de conhecimentos, habilidades e atitudes. A multidisciplinaridade é coletiva: o conjunto precisa reunir as competências necessárias, sem exigir que cada integrante domine todas as especialidades.

Colaborar com o negócio e com a organização

O diálogo com representantes do negócio alimenta a descoberta, a atualização e a priorização do trabalho. A colaboração com outras áreas exige compreender dependências e negociar condições favoráveis ao fluxo de valor. O Scrum Master ganha relevância diante de barreiras organizacionais que o time não consegue resolver sozinho.

As reuniões precisam de propósito, participantes adequados e facilitação. A disciplina de execução completa essa estrutura: adotar nomes e encontros sem produzir incrementos efetivamente prontos enfraquece os resultados. Essas ideias conectam a Parte II ao CHA, à liderança e às comunicações deste capítulo.

Responsabilidades no Scrum Team

O Guia de 2020 descreve um time autogerenciável e multifuncional, tipicamente com dez pessoas ou menos, sem subequipes ou hierarquias internas.

Responsabilidades segundo o Guia Scrum de 2020
ResponsabilidadeContribuição
Product OwnerMaximizar o valor do produto e responder pela gestão eficaz do Product Backlog.
DevelopersPlanejar a Sprint, criar incrementos utilizáveis, assegurar qualidade e adaptar diariamente o plano.
Scrum MasterEstabelecer o Scrum, favorecer a eficácia do time e promover a remoção de impedimentos.

Magno usa “Development Team” e “auto-organização”, conforme o referencial da época. O Guia de 2020 usa “Developers” e “autogerenciamento”. Scrum Master não corresponde automaticamente a gerente de projeto ou líder técnico.

Inspeção e adaptação por meio dos eventos

  • Sprint Planning: definir por que a Sprint tem valor, o que realizar e como.
  • Daily Scrum: Developers inspecionam o progresso rumo à Meta da Sprint e adaptam o plano; duração de 15 minutos.
  • Sprint Review: time e stakeholders inspecionam resultados e discutem adaptações.
  • Sprint Retrospective: planejar melhorias de qualidade e eficácia.

A Sprint contém esses eventos e dura um mês ou menos. A Definição de Pronto estabelece os critérios de qualidade do incremento.

Aplicação em aula: do MIPPE a um time Scrum

Exemplo didático proposto: uma equipe construirá um portal de atendimento. A meta da primeira Sprint será permitir que um usuário registre e acompanhe uma solicitação. Antes de escolher pessoas, os alunos identificam competências de atendimento, experiência do usuário, desenvolvimento, testes e segurança.

  1. Relacionar competências a perfis e identificar lacunas de capacidade.
  2. Definir as responsabilidades Scrum e acordar a disponibilidade das pessoas.
  3. Negociar com a infraestrutura o acesso ao ambiente de testes.
  4. Planejar um incremento pequeno, com critérios explícitos de qualidade.
  5. Inspecionar o resultado com usuários e revisar o plano e a forma de colaboração.

Para discussão: se o ambiente de testes atrasar, quais ajustes de equipe, dependências e planejamento devem ser negociados? A relação com o MIPPE é uma proposta pedagógica desta unidade.

Referências

Gestão de pessoas, equipes e comunicações

BOURNE, Lynda. Stakeholder Relationship Management: A Maturity Model for Organisational Implementation. Farnham: Gower, 2009.

DURAND, Thomas. L'alchimie de la compétence. Revue Française de Gestion, n. 160-161, p. 261-292, 2006.

FLEURY, Afonso; FLEURY, Maria Tereza Leme. Construindo o conceito de competência. Revista de Administração Contemporânea, v. 5, n. spe, p. 183-196, 2001.

HACKMAN, J. Richard. Leading Teams: Setting the Stage for Great Performances. Boston: Harvard Business School Press, 2002.

MENDELOW, Aubrey L. Stakeholder mapping. In: Proceedings of the 2nd International Conference on Information Systems. Cambridge, MA, 1991.

MINTZBERG, Henry. The Structuring of Organizations. Englewood Cliffs: Prentice-Hall, 1979.

TUCKMAN, Bruce W. Developmental sequence in small groups. Psychological Bulletin, v. 63, n. 6, p. 384-399, 1965.

SHANNON, Claude E.; WEAVER, Warren. The Mathematical Theory of Communication. Urbana: University of Illinois Press, 1949.

PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK Guide). 7. ed. Newtown Square: PMI, 2021.

Complemento sobre Scrum

MAGNO, Alexandre. Tire seu projeto do papel com Scrum: atitudes e práticas para realizar seus projetos no trabalho e na vida pessoal. São Paulo: LeYa, 2019. Parte II: E se o projeto precisar crescer?, p. 83–130. ISBN 978-85-7734-698-1. Dados da obra e sumário.

SCHWABER, Ken; SUTHERLAND, Jeff. O Guia do Scrum. Novembro de 2020. Fonte oficial. Acesso em: 28 out. 2026.