Perguntas de entrevista Project Manager

Qual é a diferença entre Scrum e Kanban? Quando você usa cada um?

Scrum trabalha em sprints fixas com escopo comprometido, papéis definidos, e cerimônias — serve bem para trabalho de produto onde uma cadência de planejamento e revisão agrega valor. Kanban é fluxo contínuo com limites de trabalho em progresso e sem sprints, o que serve bem para suporte, manutenção, e qualquer coisa onde as prioridades mudam diariamente. A pergunta decisiva é se você consegue manter o escopo estável por duas semanas; se não conseguir, as cerimônias do Scrum viram teatro.

Como você estima? O que são story points e planning poker?

Story points expressam tamanho e complexidade relativos em vez de horas, o que evita a falsa precisão das estimativas de tempo e leva em conta que pessoas diferentes trabalham em velocidades diferentes. Planning poker faz todo mundo estimar simultaneamente para que ninguém se ancore na voz mais alta, e a discussão depois de um desacordo é onde está o valor real. Os points só se tornam capazes de previsão depois que várias sprints estabelecem uma velocity.

O que você faz quando um projeto vai perder seu prazo?

Levante isso assim que souber, não quando ficar inegável — o custo de uma surpresa é muito maior do que o custo de uma má notícia. Venha com opções em vez de só o problema: escopo reduzido, entrega em fases, capacidade adicionada com seu custo de ramp-up, ou uma data movida, cada uma com as consequências explicitadas. Depois deixe quem é dono do trade-off decidir.

Como você gerencia risco? Dê um exemplo.

Riscos são identificados com o time, registrados com probabilidade e impacto, recebem um dono, e recebem uma mitigação e um gatilho que diz quando agir. Um exemplo concreto é uma dependência em uma API de terceiros: a mitigação é construir contra um mock atrás de uma interface, e o gatilho é não ter acesso ao sandbox até uma data fixada. Um registro de riscos que ninguém revisa semanalmente é documentação, não gestão.

O que são velocity e um burndown chart? Como você os usa?

Velocity são os points que um time completa por sprint, útil como uma faixa de previsão ao longo de várias sprints em vez de um único número. Um burndown chart mostra o trabalho restante contra o tempo e principalmente revela forma: uma linha plana no início seguida de um precipício significa que o trabalho não está sendo integrado até o fim. Ambas são ferramentas de diagnóstico para o time — usar velocity como meta de desempenho corrompe as estimativas de forma confiável.

Como você resolve conflitos dentro de um time?

Lide com isso cedo e em particular primeiro, separando a posição que cada pessoa defende da necessidade subjacente. A maior parte do conflito técnico na verdade é sobre prioridades não declaradas — uma pessoa otimizando pela data de entrega, outra pela manutenibilidade — e nomear esse trade-off transforma isso em uma decisão em vez de um choque de personalidades. Se não resolver, escale para quem é dono do trade-off em vez de deixar apodrecer.

O que você faz quando um cliente muda constantemente os requisitos?

Não lute contra as mudanças — torne o custo delas visível. Um processo de controle de mudanças onde cada pedido recebe uma estimativa de impacto em escopo, cronograma, e orçamento transforma uma discussão em uma escolha informada, e clientes geralmente se autolimitam assim que os trade-offs ficam explícitos. Mudança frequente também muitas vezes sinaliza que o discovery foi insuficiente, então ciclos de feedback mais curtos e demos podem tratar a causa em vez do sintoma.

Como você comunica más notícias a um cliente?

Cedo, diretamente, com o impacto quantificado e opções anexadas. Lidere com a situação e o que ela significa para eles em vez de um acúmulo de contexto, assuma responsabilidade sem se desculpar demais, e seja específico sobre o que você vai fazer e até quando. O dano ao relacionamento vem quase inteiramente da divulgação tardia, não do problema em si.