Gerente de projetos Perguntas de Entrevista & Respostas

Resposta modelo

Assumi um projeto de implementação de CRM que estava 3 meses atrasado e 40% acima do orçamento. O gerente de projeto anterior havia saído e o moral da equipe estava baixo. Na primeira semana, realizei conversas individuais com cada membro da equipe e com os principais stakeholders para entender os problemas reais. Identifiquei três causas raiz: o escopo havia expandido 3 vezes em relação ao plano original sem ajustes no cronograma, o fornecedor estava com desempenho abaixo do esperado nas integrações e dois membros críticos da equipe foram realocados para outros projetos. Apresentei um plano de recuperação: renegociei o escopo com o patrocinador do negócio, cortando 30% das funcionalidades para uma Fase 2 e concentrando a Fase 1 nas capacidades essenciais. Escalei o problema de desempenho do fornecedor para a área de compras, que aplicou penalidades contratuais e nos trouxe um desenvolvedor sênior dedicado. Consegui reforço parcial para os membros realocados. Entregamos a Fase 1 com um mês de atraso (em vez de três), dentro do orçamento ajustado e com 92% de satisfação dos stakeholders. As funcionalidades da Fase 2 foram entregues no trimestre seguinte.

Resposta modelo

Dois engenheiros sênior da minha equipe discordavam fundamentalmente sobre a arquitetura de uma migração de dados: um defendia uma migração completa de uma só vez, o outro preferia uma abordagem em fases. O desentendimento havia se tornado pessoal, prejudicando as reuniões da equipe. Conversei separadamente com cada um para entender suas preocupações. O defensor da migração única estava preocupado com a manutenção de dois sistemas em paralelo. O defensor da abordagem em fases temia a perda de dados durante a transição. Ambas as preocupações eram válidas. Facilitei uma revisão de design estruturada onde cada um apresentou sua abordagem com análise de riscos. Pedi à equipe que avaliasse as duas opções em três critérios: risco de perda de dados, complexidade operacional e prazo. Os dados mostraram que a abordagem em fases era de menor risco, mas exigia mais esforço. Tomei a decisão: abordagem em fases, mas com automação para reduzir a carga do sistema paralelo (atendendo à preocupação do primeiro engenheiro). Reconheci publicamente as preocupações válidas do defensor da migração única e o designei para liderar o trabalho de automação. A migração foi bem-sucedida com zero perda de dados.

Resposta modelo

No meio de uma migração de plataforma de 6 meses, a equipe de compliance identificou novos requisitos regulatórios que acrescentavam 8 semanas de trabalho. O patrocinador do negócio ainda esperava o prazo original. Realizei imediatamente uma análise de impacto: os novos requisitos adicionavam 320 horas de desenvolvimento e 80 horas de testes. Apresentei três opções ao comitê diretivo. Opção A: estender o prazo em 8 semanas para acomodar o escopo completo. Opção B: contratar 3 prestadores de serviço para manter o prazo, com custo adicional de $90K. Opção C: adiar as funcionalidades não relacionadas a compliance para manter o prazo e o orçamento, entregando-as 6 semanas depois. Recomendei a Opção C porque compliance não era negociável, mas várias funcionalidades adiadas não seriam necessárias até o terceiro trimestre de qualquer forma. O comitê diretivo concordou. Atualizei o plano do projeto, comuniquei a mudança a todos os stakeholders com justificativa clara e entregamos a versão focada em compliance no prazo. As funcionalidades adiadas foram entregues 5 semanas depois. O ponto central foi apresentar opções com trade-offs em vez de simplesmente trazer más notícias.

Resposta modelo

Gerenciei um projeto de redesign de site com membros da equipe em Nova York, Londres e Bangalore, três fusos horários com apenas 3 horas de sobreposição. Estabeleci uma estrutura de comunicação que respeitava os fusos horários: comunicação assíncrona via Slack e Confluence para tudo que não precisava de discussão em tempo real, uma reunião diária de 15 minutos na janela de sobreposição apenas para impedimentos e sessões semanais de aprofundamento que alternavam entre horários favoráveis a cada fuso, para que ninguém estivesse sempre em uma ligação tarde da noite. Criei documentação detalhada de sprint para que a equipe de Bangalore pudesse continuar o trabalho deixado pela equipe de Nova York e vice-versa. Também investi fortemente no relacionamento: eventos virtuais mensais da equipe e one-on-ones por vídeo trimestrais com cada membro. O projeto foi entregue no prazo com uma pontuação de satisfação da equipe de 4,5/5. Dois membros da equipe me disseram que foi o projeto distribuído mais bem gerenciado em que haviam trabalhado.

Resposta modelo

Escolho com base em três fatores: estabilidade dos requisitos, flexibilidade dos stakeholders e experiência da equipe. O Waterfall funciona quando os requisitos são bem definidos e têm pouca probabilidade de mudança (projetos de conformidade regulatória, construção, hardware), quando o cliente precisa de preço e prazo fixos desde o início, ou quando o projeto tem dependências rígidas que devem seguir uma sequência. O Agile funciona quando os requisitos evoluirão com base no feedback dos usuários (desenvolvimento de produto, transformação digital), quando entregar valor incremental é mais importante do que esperar por uma solução completa e quando a equipe tem experiência com trabalho iterativo. Na prática, a maioria dos projetos se beneficia de uma abordagem híbrida: execução Agile dentro de um framework de governança Waterfall. Defino o escopo geral e os marcos antecipadamente (para alinhamento de orçamento e stakeholders), mas executo em sprints com flexibilidade para ajustar prioridades dentro do escopo. O antipadrão que evito: usar Agile como desculpa para não planejar, ou usar Waterfall como desculpa para não ter flexibilidade.

Resposta modelo

Uso uma combinação de técnicas dependendo da fase do projeto. Fase inicial (ordem de grandeza): estimativa por analogia, comparando com projetos similares do passado ajustados pela complexidade. Isso gera um intervalo, não uma estimativa pontual. 'Com base no projeto de CRM do ano passado, isso leva de 4 a 6 meses.' Fase de planejamento: estimativa bottom-up, quebrando o trabalho em tarefas, pedindo à equipe que estime cada tarefa (uso o Planning Poker para dimensionamento relativo), adicionando dependências e buffer. Aplico a regra de 1,5x: qualquer que seja a estimativa da equipe, multiplico por 1,5 para contabilizar imprevistos, complexidade de integração e mudanças de contexto. Para tarefas individuais, peço estimativas em três pontos: otimista, mais provável e pessimista. A fórmula PERT (O + 4M + P) / 6 fornece uma média ponderada. Sempre apresento estimativas como intervalos, nunca como números únicos. E reestimo a cada marco importante à medida que aprendemos mais sobre o projeto. A estimativa mais perigosa é aquela que nunca é atualizada.

Resposta modelo

Mantenho um registro de riscos ativo que é revisado semanalmente. Para cada risco, capturo: descrição, probabilidade (1 a 5), impacto (1 a 5), pontuação de risco (probabilidade x impacto), responsável, estratégia de mitigação e indicadores de gatilho. Categorizo os riscos em: técnicos (nova tecnologia, complexidade de integração), de recursos (dependência de pessoas-chave, lacunas de competências), externos (atrasos de fornecedores, mudanças regulatórias) e de cronograma (cadeias de dependência, incerteza nas estimativas). Para os 5 principais riscos por pontuação, desenvolvo planos de mitigação específicos. Alguns exemplos: para dependência de pessoas-chave, garanto compartilhamento de conhecimento e documentação. Para risco de fornecedor, mantenho um relacionamento com um fornecedor de backup. Para risco de cronograma no caminho crítico, adiciono buffers de tempo e identifico tarefas que podem ser paralelizadas. Diferencio entre mitigação de risco (reduzir probabilidade ou impacto antes que ocorra) e planejamento de contingência (o que fazemos se o risco se materializar). Cada responsável reporta o status semanalmente. Riscos que se materializam tornam-se problemas e são acompanhados no registro de problemas com um responsável e prazo de resolução.

Resposta modelo

Monitoro quatro categorias. Cronograma: tendência de velocidade dos sprints (a equipe está acelerando, estável ou desacelerando?), taxa de conclusão de marcos e índice de desempenho de cronograma (valor agregado / valor planejado). Orçamento: gastos reais versus planejados, taxa de consumo e estimativa no término. Qualidade: densidade de defeitos, taxa de aprovação em testes e percentual de retrabalho (quanto trabalho é devolvido). Equipe: satisfação (pesquisas mensais de pulso), horas extras (horas extras sustentadas são um sinal de alerta) e risco de rotatividade. Apresento isso em um painel de página única usando verde/âmbar/vermelho para cada categoria. A métrica mais importante não é nenhum número individual: é a tendência. Uma velocidade estável em 30 pontos de história está bem. Uma velocidade que era 40 no sprint anterior e agora é 30 é um sinal de alerta que precisa de investigação. Acompanho também uma métrica honesta que não pode ser manipulada: datas de entrega reais versus previstas para marcos concluídos. Se consistentemente entregamos com atraso, nosso processo de estimativa precisa ser corrigido.

Resposta modelo

Primeiro, teria uma conversa honesta com o membro que está saindo sobre seu prazo de aviso e disposição para ajudar na transferência de conhecimento. Mesmo 2 semanas de handover estruturado têm valor. Avaliaria imediatamente o impacto: qual trabalho depende do conhecimento único dessa pessoa? Em quais tarefas ela está trabalhando atualmente? Onde estão os pontos únicos de falha? Em seguida, agiria em três frentes. Captura de conhecimento: sessões intensivas de documentação e demonstrações gravadas do trabalho dela. Documentação imperfeita é melhor do que nenhuma. Redistribuição de carga: realocaria as tarefas com base na capacidade e nas habilidades dos outros membros. Seja realista: a equipe vai desacelerar temporariamente. Comunicação: informaria os stakeholders sobre o impacto no prazo e o que estou fazendo a respeito. Prefiro dar más notícias cedo com um plano a surpreendê-los com uma entrega atrasada. Quanto à substituição: iniciaria o processo de contratação imediatamente, mas planejaria para o projeto continuar sem essa pessoa. Nenhum projeto deveria estar refém de uma única pessoa. Se está, esse é um risco que deveria ter sido mitigado antes.

Resposta modelo

Começaria tornando os conflitos visíveis. Muitas vezes, os stakeholders não sabem que estão em conflito porque cada um comunicou suas prioridades ao gerente de projeto separadamente. Organizaria uma sessão de alinhamento de prioridades com todos os stakeholders principais, apresentando: a lista completa de requisitos, os recursos e o prazo disponíveis e o fato de que não podemos entregar tudo de uma vez. Usaria um exercício de classificação forçada: cada stakeholder recebe 100 pontos para distribuir entre as funcionalidades. Isso torna os trade-offs concretos: não é possível dar 100 pontos para tudo. Onde as classificações divergem significativamente, facilitaria uma discussão: qual é o caso de negócio para cada prioridade? Qual é o custo do atraso? Muitas vezes, ouvir o raciocínio dos outros resolve o conflito. Se não resolver, escalaria para o patrocinador do projeto para uma decisão de desempate, munido dos dados do exercício de classificação e da minha recomendação. Após o alinhamento, documentaria as prioridades acordadas e as compartilharia amplamente. Quando as prioridades inevitavelmente mudarem, repetiria o processo em vez de tomar a decisão sozinho.

Resposta modelo

Agiria rapidamente: os estouros de orçamento pioram quanto mais tempo você espera. Primeiro, análise de causa raiz: por que estamos acima do orçamento? Causas comuns: escopo adicional sem ajuste de orçamento, erros de estimativa (tarefas demoraram mais do que o previsto), mudança nos custos de recursos ou fatores externos (aumentos de preço de fornecedor, requisitos regulatórios). Em seguida, apresentaria a situação e as opções ao patrocinador do projeto. Opção A: aumentar o orçamento em 25% e entregar o escopo completo. Justificaria o aumento com detalhes sobre o que mudou. Opção B: reduzir o escopo para caber no orçamento original, especificando quais funcionalidades seriam adiadas e seu impacto no negócio. Opção C: estender o prazo (se o estouro se deve a custos de horas extras, distribuir o trabalho por mais tempo pode ser mais barato). Opção D: otimizar a execução: podemos reduzir custos por meio de automação, renegociação de taxas com fornecedores ou uso de recursos diferentes? Apresentaria minha recomendação com dados que a sustentam. Seja qual for a decisão, implementaria controles de custo mais rígidos: revisões semanais de orçamento em vez de mensais, pontos de aprovação para qualquer novo escopo e estimativas atualizadas para o trabalho restante. O ponto central: nunca deixe uma surpresa orçamentária ser uma surpresa. Comunique cedo.

Resposta modelo

Investigaria antes de prescrever. Primeiro, analisaria os dados: em quais tipos de trabalho estamos falhando? As estimativas são consistentemente baixas, ou as interrupções estão desviando os membros da equipe do trabalho do sprint? Há gargalos de dependência em que uma equipe bloqueia outra? Em seguida, conversaria com a equipe nas retrospectivas: eles consideram as metas do sprint realistas? Há problemas sistêmicos que veem e eu não? Causas raiz comuns que procuraria: comprometimento excessivo (a equipe planeja com 100% de capacidade quando a realidade é 70% por causa de reuniões, suporte e interrupções), estimativas ruins (histórias são consistentemente 2 a 3 vezes maiores do que o estimado), requisitos pouco claros (histórias entram no sprint e passam 2 dias em esclarecimentos) e troca de contexto (membros da equipe puxados para incidentes ou outros projetos). Minhas correções dependem do diagnóstico: incluir um buffer de capacidade de 30%, melhorar o refinamento das histórias para identificar ambiguidades antes do planejamento do sprint, negociar tempo de foco protegido com a gestão ou dividir as histórias em partes menores, mais fáceis de estimar e concluir.