Entrevista — GP Júnior

Projetos tecnicamente perfeitos falham por causa de pessoas, não de código.

• Expectativas não alinhadas desde o início
• Decisores que não foram incluídos na comunicação
• Usuários finais que resistem à mudança
• Patrocinador que muda de prioridade no meio do projeto

Matriz Poder × Interesse

Na Metadados: gestor do cliente (alto poder/alto interesse) → gerenciar de perto.

"Como você lidaria com um cliente insatisfeito com o projeto?"

Divide o trabalho em partes menores e gerenciáveis.

A sequência mais longa de atividades que determina o prazo total do projeto.

Planejar demais para projeto simples é desperdício. Planejar de menos para projeto complexo é risco.

• Qual o tamanho e duração do projeto?
• Qual o nível de incerteza no escopo?
• Quantos stakeholders com expectativas diferentes?
• Qual o impacto de atraso ou erro?
• A equipe tem experiência nesse tipo de projeto?

"Como você planejaria a implantação de um novo cliente?"

Lógica: Planejar tudo antes de executar.

Quando usar: Escopo bem definido, requisitos estáveis, contratos fechados.

Lógica: Entregar valor em ciclos curtos e iterar.

• Sem sprints fixos — fluxo contínuo
• Limita trabalho em andamento (WIP)
• Bom para suporte e operações

"Qual metodologia você prefere?"

• Cliente consegue usar o sistema no dia a dia
• Processos do cliente melhoraram com o sistema
• Usuários foram treinados e adotaram o sistema
• Cliente opera com autonomia após o go-live

Condição que uma entrega precisa cumprir para ser considerada pronta.

Exemplo prático

Módulo de Folha de Pagamento:

• Cálculo para 3 tipos de contrato testado e aprovado
• Relatório mensal gerado sem erros
• 2 usuários-chave treinados e aprovados no teste prático
• Integração com módulo de RH validada em homologação

Escopo Creep = expansão não controlada do escopo durante o projeto.

1. Escopo documentado e assinado no início
2. Processo formal de avaliação de mudanças (Change Request)
3. Toda mudança: análise de impacto em prazo e custo
4. Aprovação formal antes de executar

"Como você garante a qualidade das entregas?"

"O que você faz quando o cliente pede mudanças no meio do projeto?"

Para Ameaças

Qualquer mudança em um lado impacta os outros dois. O GP é o guardião desse equilíbrio.

Prazo

• SPI > 1 = adiantado | SPI < 1 = atrasado
• % de tarefas concluídas no prazo

Custo

• CPI > 1 = abaixo do orçamento | CPI < 1 = acima

Em projetos ágeis

• Velocidade — pontos entregues por sprint
• Burndown — progresso em direção à meta

1. Onde estamos? — status atual
2. Para onde vamos? — previsão e tendências
3. O que está bloqueando? — riscos ativos
4. O que precisa de decisão? — itens para aprovação

O time precisa sentir que pode:

• Fazer perguntas sem parecer incompetente
• Admitir erros sem medo de punição
• Discordar e apresentar ideias diferentes

"Como você lida com membro que não está entregando?"

"Como você se descreveria como líder?"

"Como você garantiria que os usuários adotam o sistema?"

Pontos fortes — seja específica, não genérica

• Comunicação com clientes: Tenho facilidade em traduzir linguagem técnica para linguagem de negócio e vice-versa, o que facilita o alinhamento de expectativas.
• Organização e documentação: Tenho disciplina para registrar decisões, processos e lições aprendidas — algo que evita retrabalho e mantém o time alinhado.
• Facilitação: Conduzir reuniões de forma objetiva, garantindo que saímos com decisões e próximos passos claros.

Ponto de melhoria — seja honesta e mostre consciência

É o documento que autoriza formalmente o projeto. Sem ele, o projeto não existe oficialmente.

O que contém:

• Objetivo e justificativa do projeto
• Escopo de alto nível (o que está dentro e o que está fora)
• Restrições e premissas
• Cronograma e orçamento macro
• Stakeholders principais
• Nome e autoridade do Gerente de Projetos
• Assinatura do patrocinador

É a sequência mais longa de atividades do projeto — ela determina o prazo mínimo de conclusão.

• Qualquer atraso em atividade do caminho crítico atrasa o projeto inteiro
• Atividades fora do caminho crítico têm folga — podem atrasar sem impactar o prazo final
• O GP deve concentrar atenção extra nas atividades críticas

1. Entender o problema de negócio — não apenas o que o cliente pede, mas por que precisa disso
2. Levantar requisitos — workshops, entrevistas, análise de processos atuais
3. Documentar o que está DENTRO e o que está FORA — o que não é dito como "fora" pode ser cobrado depois
4. Criar a WBS — decompor o trabalho em entregas menores e mensuráveis
5. Validar e assinar — o cliente precisa aprovar formalmente o escopo antes do início

Técnicas de estimativa

Primeiro: diagnosticar antes de agir. Atraso tem causa — resolver o sintoma sem entender a causa não resolve nada.

Análise:

• O atraso está no caminho crítico ou fora dele?
• É pontual ou tendência (vários sprints/fases atrasando)?
• Qual é a causa raiz? (estimativa errada, impedimento, falta de recurso, escopo expandido?)

Ações possíveis (dependem da causa):

Velocity = quantidade média de trabalho (story points) que o time entrega por sprint.

Como usar no planejamento:

1. Após 2–3 sprints, calcule a média de pontos entregues
2. Some todos os pontos do backlog total
3. Divida: backlog total ÷ velocity = número estimado de sprints
4. Multiplique pelos dias de sprint para ter a previsão de data

É o conjunto de critérios acordados pelo time que uma entrega precisa atender para ser considerada concluída.

Exemplo de DoD para uma funcionalidade:

• Código revisado por par (ou configuração validada por colega)
• Testes realizados e aprovados
• Documentação atualizada
• Aprovado pelo PO / cliente
• Sem bugs críticos abertos

É uma forma de descrever um requisito do ponto de vista do usuário, focando no valor que ele recebe.

Formato padrão:

Exemplo prático:

Critérios INVEST para uma boa User Story:

Princípio: comunicar cedo, com contexto e com solução

Antes de agir, entender a motivação. Sabotagem raramente é gratuita — geralmente vem de:

• Medo de perder relevância ou autoridade com o novo sistema
• Experiências ruins com projetos anteriores
• Não ter sido envolvido nas decisões
• Interesses políticos que o projeto ameaça

Abordagem recomendada:

1. Conversa individual — entender a perspectiva sem julgamento
2. Identificar o interesse real por trás da resistência
3. Envolver na solução — transformar crítico em colaborador
4. Documentar todas as decisões e comunicações
5. Se necessário, escalar para o patrocinador com fatos, não opiniões

O plano de comunicação responde: quem precisa saber o quê, quando e como.

Primeiro: diagnosticar a causa da desmotivação. Ela pode vir de:

• Falta de clareza sobre objetivos ou prioridades
• Excesso de retrabalho ou mudanças constantes
• Falta de reconhecimento pelos resultados entregues
• Conflito interpessoal não resolvido
• Sensação de que o projeto não vai dar certo

Ações práticas:

• Clareza: Revisitar o propósito do projeto — por que ele importa?
• Quick wins: Entregar algo visível que mostre progresso real
• Escuta individual: Conversar com cada membro e entender o que está pesando
• Reconhecimento: Nomear contribuições específicas publicamente
• Autonomia: Dar mais controle sobre o como, não apenas o quê

Modelo SBI — Situação, Comportamento, Impacto

Princípios:

• Em privado, nunca na frente da equipe ou do cliente
• Específico e baseado em comportamento observável, não em julgamento de caráter
• Dar espaço para a pessoa responder e se posicionar
• Focar na melhoria, não na punição
• Fazer no momento certo — nem no calor da emoção, nem semanas depois

1. Separar as partes — conversar com cada um individualmente primeiro
2. Ouvir sem julgar — entender a perspectiva e o interesse real de cada lado
3. Identificar o tipo de conflito:
   • De tarefa (quem faz o quê) → resolver com clareza de papéis
   • De processo (como fazer) → resolver com acordo de método
   • Interpessoal (atrito pessoal) → requer facilitação mais cuidadosa
4. Reunião conjunta — mediar a conversa focando em interesses, não em posições
5. Documentar o acordo — o que foi combinado e como será monitorado

KPIs precisam ser relevantes ao objetivo do projeto, não apenas fáceis de medir.

É a técnica para encontrar a causa real de um problema, não apenas o sintoma visível.

Técnica dos 5 Porquês:

Estrutura de lições aprendidas:

1. Registrar formalmente a solicitação (Change Request)
2. Analisar o impacto: quanto tempo vai adicionar? Qual o custo? Existe risco técnico?
3. Apresentar a análise ao cliente com 3 opções:
   • Adicionar agora — com impacto claro em prazo/custo
   • Adicionar em uma fase 2 após o go-live
   • Não adicionar — com justificativa
4. Documentar a decisão — qualquer que seja, com assinatura

1. Quantificar — confirmar o impacto real (3 semanas é estimativa ou certeza?)
2. Avaliar opções de resposta — existe como mitigar? Transferir? Evitar?
3. Comunicar imediatamente ao patrocinador e ao cliente — com o risco E as opções, não só o problema
4. Decidir em conjunto — quem tem autoridade decide a abordagem
5. Atualizar o plano — cronograma, riscos, comunicação

Critérios de priorização de portfólio:

Esse é um conflito de stakeholders clássico em implantações. O GP não toma partido — facilita o alinhamento.

1. Mapear exatamente onde estão as divergências
2. Entender o interesse real de cada lado (não apenas a posição declarada)
3. Verificar o que está no escopo e no contrato — esse é o árbitro técnico
4. Propor reunião conjunta com ambos para alinhar
5. Documentar o consenso alcançado ou a decisão do patrocinador