Gerente de Projeto · Personas do SDLC Agêntico

O Project Manager é a persona responsável pela entrega previsível entre times e pela comunicação honesta com stakeholders. Em um SDLC AI-native, o Project Manager opera um loop de risco e status, não um calendário de reuniões de status.

Resumo executivo

O Project Manager converte um portfólio de compromissos em uma imagem única e honesta de progresso, risco e expectativas de stakeholders. Em um SDLC AI-native, o Project Manager trabalha dentro da fase de Delivery com um conjunto fixo de primitivas: um agente risk-scout, quatro slash prompts, instruções escopadas, hooks validados por schema e uma lista curada de MCPs validados. As saídas primárias são relatórios de status, um risk register vivo no Azure DevOps, mapas de stakeholders e logs RAID que dirigem decisões em vez de enfeitar reuniões.

Papel e responsabilidades

Pense no Project Manager como o controlador de tráfego aéreo em um aeroporto movimentado. Aviões decolam e pousam com a própria potência, mas cada decolagem e pouso é sequenciado, espaçado e reportado para a torre. O Project Manager é essa torre. Em um SDLC AI-native, o código e a arquitetura são propriedade de outras personas; o Project Manager é dono do sequenciamento, do slot e da disciplina de rádio.

Responsabilidades primárias:

Manter o risk register no Azure DevOps com todo risco pontuado, com dono e com data
Produzir relatórios de status semanais que reconciliem GitHub Projects, Azure Boards e dados de incidente
Rodar a cadência de comunicação com stakeholders via Microsoft Teams e o M365 Agents SDK
Manter o log RAID atualizado (Risks, Assumptions, Issues, Dependencies) e linkar cada item a um work item
Facilitar a gestão de dependências entre times com critérios explícitos de hand-off
Escalar risco material ao Engineering Manager e à liderança do programa com mitigações propostas, nunca com surpresas
Operar o agente Risk Scout e os prompts /status, /risk-log, /raid, /stakeholder-map

Jobs to be done

Como Project Manager, eu quero um relatório de status semanal auto-sintetizado a partir do GitHub Projects e Azure Boards, para que eu gaste tempo em mitigação, não em formatação.
Como Project Manager, eu quero todo risco no register com probabilidade, impacto, dono e data de revisão, para que conversas sobre risco sejam concretas.
Como Project Manager, eu quero que stakeholders saibam o que mudou e o que isso significa para eles, para que a confiança se componha ao longo dos trimestres.
Como Project Manager, eu quero dependências rastreadas entre times com critérios explícitos de aceitação, para que hand-offs não deslizem silenciosamente.
Como Project Manager, eu quero que o log RAID seja a única fonte da verdade, para que ninguém releve decisões em conversas de corredor.
Como Project Manager, eu quero um audit trail de todo compromisso com stakeholder, para que mudanças de escopo sejam negociadas com fatos.

Dores antes da era AI-native

Status de fachada. A liderança pede um update de uma página; o Project Manager gasta meio dia reformatando os mesmos dados de três ferramentas.
Risk registers que são inventários, não instrumentos. Todo risco é registrado; nenhum tem dono, data de revisão ou mitigação. O register é auditado, não usado.
Silêncio de stakeholder. Más notícias são adiadas porque não há uma cadência segura para entregá-las. Quando finalmente chegam, chegam com surpresa e culpa.
Desvio de dependência descoberto tarde demais. Um time a jusante descobre na sexta que o time a montante derrapou duas semanas atrás.
Logs RAID espalhados em documentos. Riscos em um lugar, premissas em outro, dependências em uma terceira planilha. O mesmo item ganha três IDs diferentes.

Fluxo diário AI-native

O Project Manager opera um loop diário e semanal. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code, Claude Code no terminal para síntese longa e Microsoft Teams via M365 Agents SDK para cadência com stakeholders.

Setup da manhã

Abra o Visual Studio Code no repositório program-ops. GitHub Copilot Chat carrega o .github/instructions/pm.instructions.md escopado.
Invoque /risk-log. O agente Risk Scout revisa o register, sinaliza riscos atrasados para revisão e rascunha atualizações onde há nova evidência disponível.
Passe pelo digest da madrugada do Teams do M365 Agents SDK em busca de qualquer mensagem de stakeholder que exija resposta no mesmo dia.

Execução no meio do dia

Rode /status para o projeto ativo. O agente puxa o status do GitHub Projects, o burn-up de iteração do Azure Boards, contagem de incidentes do Application Insights via Azure MCP e compõe um rascunho de relatório de status.
Reconcilie dependências cross-team rodando /raid. O agente atualiza o log RAID com novos itens detectados a partir de labels de PR e transições de estado de work item.
Conduza as reuniões de sync de dependência quando necessário. Cada acordo é escrito de volta no log RAID imediatamente, com dono e data-alvo.

Revisão no fim da tarde

Publique o relatório de status. O M365 Agents SDK posta-o nos canais apropriados do Teams, com links de volta para o repositório.
Invoque /stakeholder-map semanalmente. O agente atualiza o inventário de stakeholders, sinaliza stakeholders que não receberam update há mais de duas semanas e propõe rascunhos de outreach.
Encerre o dia commitando o log RAID e as atualizações do risk register ao repositório program-ops. GitHub Actions publica-os no Azure Static Web App que hospeda o dashboard do programa.

Primitivas recomendadas

Agente

Agente	Arquivo	Propósito
`risk-scout`	`.github/agents/risk-scout.agent.md`	Manter o risk register, rascunhar relatórios de status, atualizar o log RAID, atualizar o stakeholder map

O agente Risk Scout usa claude-sonnet-4-6 por padrão, com ferramentas read, search, grep, bash. Ele puxa contexto dos MCPs do GitHub, Azure DevOps, Azure e Microsoft 365 Agents SDK. Extended thinking fica habilitado para análises de dependência que cruzam múltiplos times.

Slash prompts

Comando	Arquivo	Propósito
`/status`	`.github/prompts/status.prompt.md`	Compor o relatório de status semanal a partir de fontes reconciliadas
`/risk-log`	`.github/prompts/risk-log.prompt.md`	Revisar e atualizar o risk register, sinalizar riscos envelhecidos
`/raid`	`.github/prompts/raid.prompt.md`	Atualizar o log RAID a partir de atividade recente de work items e PRs
`/stakeholder-map`	`.github/prompts/stakeholder-map.prompt.md`	Atualizar o inventário de stakeholders e propor outreach

Instruções escopadas

Um applyTo escopado mantém artefatos de programa distintos de conteúdo em nível de time.

Escopo (`applyTo`)	Arquivo	Propósito
`program-ops/status/**`	`.github/instructions/status.instructions.md`	Tom do relatório de status, teto de uma página, disciplina de citação
`program-ops/risks/**`	`.github/instructions/risks.instructions.md`	Rubrica de pontuação de risco, disciplina de dono, fraseado de mitigação
`program-ops/stakeholders/**`	`.github/instructions/stakeholders.instructions.md`	Formato do stakeholder map, cadência de outreach, regras de escalação

Hooks

Hooks são governança de custo zero em tokens para artefatos de programa.

pre-commit: rejeita um risco sem probabilidade, impacto, dono e data de revisão pontuados
post-commit: regenera o JSON do dashboard de programa em qualquer mudança do RAID
pre-push: valida que todo relatório de status cita work items específicos e incidentes do Application Insights

MCPs validados

Todos os MCPs abaixo estão registrados no catálogo de MCPs. Não referencie nenhum MCP que não esteja no catálogo.

MCP	Status	Uso nesta persona
Azure DevOps MCP Server	Oficial (Microsoft)	Ler e atualizar work items, entradas do risk register e dados de iteração no Azure Boards
GitHub MCP Server	Oficial	Ler estado do GitHub Projects, status de PR e runs do Actions para compor status
Azure MCP Server	Oficial (Microsoft)	Consultar Azure Monitor e Application Insights para evidência de incidente por trás de riscos
Microsoft Learn Docs MCP	Oficial	Ancorar o guia do programa em Microsoft Learn e GitHub Docs
Microsoft 365 Agents SDK MCP	Oficial (Microsoft)	Postar relatórios de status e rascunhos de outreach a stakeholders no Microsoft Teams

Exemplos reais

Exemplo 1: relatório de status semanal para um programa regulado

Entrada: Um programa de pagamentos com três squads, um incidente ativo em produção e uma revisão de auditor no próximo mês.

Invocação: /status.

Saída esperada:

Um relatório de status de uma página em program-ops/status/2026-W17.md com seções: compromissos, progresso, riscos em andamento, decisões necessárias, marcos próximos.
Toda afirmação cita um ID de work item do Azure Boards ou um PR do GitHub Projects.
O incidente ativo está linkado à sua timeline no Application Insights.
Um post no Teams via M365 Agents SDK no canal do sponsor executivo com o resumo de uma página.

Exemplo 2: dependência cross-team em risco

Entrada: O squad de checkout depende do squad de identity entregar um novo endpoint de token até a semana 18. Evidência mostra que o squad de identity está atrasado.

Invocação: /raid.

Saída esperada:

Uma nova entrada RAID em program-ops/raid/identity-token-endpoint.md com tipo Dependency, dono definido como o líder do squad de identity, impacto descrito em termos do squad de checkout, propostas de mitigação (stub temporário, feature flag).
Um work item de dependência no Azure Boards criado e linkado a ambos os boards dos squads.
Uma mensagem no Teams para ambos os líderes de squad com os fatos, não um convite de reunião.
Um follow-up no stakeholder map: o product owner do squad de checkout é sinalizado para um update direcionado.

Anti-padrões

Relatórios de status que parafraseiam o plano. Parafrasear o plano não é progresso. Mitigação: o status.instructions.md exige citações de evidência para toda afirmação.
Riscos sem dono. Um risco sem dono é um desejo. Mitigação: o hook pre-commit rejeita riscos sem dono.
Stakeholder maps que só listam nomes. Um mapa sem cadência e interesses é uma agenda telefônica. Mitigação: /stakeholder-map exige cadência, interesses e canal preferido para cada stakeholder.
Logs RAID duplicados entre ferramentas. Múltiplas fontes da verdade criam disputa. Mitigação: o log RAID vive no repositório program-ops; tudo o mais é view.
Escalação por surpresa. Más notícias que chegam sem mitigações propostas perdem confiança. Mitigação: o agente Risk Scout sempre acompanha uma escalação com pelo menos duas opções de mitigação.

KPIs e métricas de impacto

Métrica	Linha base (manual)	Meta (agentic)	Medição
Tempo de preparação do relatório de status	8 horas por semana	Menos de 90 minutos	Log de time-to-publish
Idade mediana de revisão de risco	21 dias	Menos de 7 dias	Auditoria do risk register
Lead time de detecção de desvio de dependência	3 dias de aviso	Acima de 10 dias de aviso	Histórico de detecção do RAID
Satisfação de stakeholder (NPS)	Mais 10	Mais 40	Pesquisa trimestral de programa
Taxa de escalação com mitigação	35 por cento	Acima de 90 por cento	Auditoria de escalação
Eficiência de tokens	N/A	Menos de 200k tokens por semana	Relatório de uso do Copilot

Maturidade em quatro níveis

Nível	Nome	Marcadores
L1	Manual	Relatórios de status montados à mão, riscos em planilha, RAID espalhado
L2	Assistido	GitHub Copilot Chat para rascunho, sem agente, alguns dashboards no Azure DevOps
L3	Aumentado	Agente Risk Scout, quatro slash prompts, instruções escopadas, log RAID em `program-ops`
L4	Autônomo	Kit completo de primitivas, hooks aplicados, cadência de stakeholder automatizada no Teams via M365 Agents SDK, riscos sempre pontuados, scorecard de maturidade acima de 80 por cento

Integração com outras personas

Com Engineering Manager: view de delivery-health compartilhada, tradução de risco para capacidade
Com Scrum Master: fluxo de sprint informa o ritmo do programa
Com Product Owner: negociação de escopo com respaldo de evidência do RAID
Com Technical Lead: riscos arquiteturais caem no register do programa com donos
Com Release Manager: coordenação de janela de release entre squads
Com InfoSec Officer e Compliance Auditor: controles em nível de programa, evidência de auditoria, cadência de indústria regulada
Com SRE: riscos derivados de incidentes registrados e rastreados

Glossário

Log RAID: o register consolidado de Risks, Assumptions, Issues, Dependencies usado como única fonte da verdade do programa.
Risk register: o subconjunto de riscos do log RAID, mantido no Azure DevOps com probabilidade, impacto, dono e data de revisão.
Stakeholder map: um inventário vivo de stakeholders, seus interesses, sua cadência e seu canal preferido.
Relatório de status: um artefato semanal de uma página que reconcilia compromissos, progresso, riscos em andamento, decisões necessárias e marcos próximos.
Escalação com mitigação: a disciplina de nunca entregar más notícias sem pelo menos duas opções propostas.
Hand-off de dependência: o hand-off documentado entre dois times, com critérios explícitos de aceitação.

Referências

Documentação do Azure Boards — guia autoritativo para risk registers e rastreamento de work items
Documentação do GitHub Projects — views em nível de programa entre múltiplos repositórios
Microsoft 365 Agents SDK — postar relatórios de status e outreach a stakeholders no Teams
Documentação do Azure Monitor — evidência de incidente para pontuação de risco
Documentação do GitHub Actions — agendar dashboards de programa e jobs de reconciliação