10 enablement · Delivery
Project ManagerGerente de ProjetoGerente de Proyecto
Risk, status, stakeholders.Risco, status, stakeholders.Riesgo, estado, stakeholders.
The Project Manager is the persona accountable for predictable delivery across teams and for honest stakeholder communication. In an AI-native SDLC, the Project Manager operates a risk and status loop, not a status-meeting calendar.
Executive summary
The Project Manager converts a portfolio of commitments into a single, honest picture of progress, risk, and stakeholder expectations. In an AI-native SDLC, the Project Manager works inside the Delivery phase with a fixed set of primitives: one risk-scout agent, four slash prompts, scoped instructions, schema-validated hooks, and a curated list of validated MCPs. The primary outputs are status reports, a live risk register in Azure DevOps, stakeholder maps, and RAID logs that drive decisions instead of decorating meetings.
Role and responsibilities
Think of the Project Manager like the air-traffic controller at a busy airport. Planes take off and land under their own power, but every takeoff and landing is sequenced, spaced, and reported to the tower. The Project Manager is that tower. In an AI-native SDLC the code and architecture are owned by other personas; the Project Manager owns the sequencing, the slot, and the radio discipline.
Primary responsibilities:
- Maintain the risk register in Azure DevOps with every risk scored, owned, and dated
- Produce weekly status reports that reconcile GitHub Projects, Azure Boards, and incident data
- Run the stakeholder communication cadence through Microsoft Teams and the M365 Agents SDK
- Keep the RAID log current (Risks, Assumptions, Issues, Dependencies) and link every item to a work item
- Facilitate cross-team dependency management with explicit hand-off criteria
- Escalate material risk to the Engineering Manager and Program leadership with proposed mitigations, never with surprises
- Operate the Risk Scout agent and the
/status,/risk-log,/raid,/stakeholder-mapprompts
Jobs to be done
- As a Project Manager, I want a weekly status report auto-synthesized from GitHub Projects and Azure Boards, so that I spend time on mitigation, not formatting.
- As a Project Manager, I want every risk in the register with a probability, impact, owner, and review date, so that risk conversations are concrete.
- As a Project Manager, I want stakeholders to know what changed and what it means for them, so that trust compounds across quarters.
- As a Project Manager, I want dependencies tracked across teams with explicit acceptance criteria, so that hand-offs do not slip silently.
- As a Project Manager, I want the RAID log to be the single source of truth, so that nobody re-litigates decisions in hallway conversations.
- As a Project Manager, I want an audit trail of every stakeholder commitment, so that scope changes are negotiated with facts.
Pain points before AI-native
- Status theatre. Leadership asks for a one-page update; the Project Manager spends half a day reformatting the same data from three tools.
- Risk registers that are inventories, not instruments. Every risk is logged; none have owners, review dates, or mitigations. The register is audited, not used.
- Stakeholder silence. Bad news is delayed because there is no safe cadence for delivering it. When it finally lands, it lands with surprise and blame.
- Dependency slippage discovered too late. A downstream team learns on Friday that the upstream team slipped two weeks ago.
- RAID logs scattered across documents. Risks in one place, assumptions in another, dependencies in a third spreadsheet. The same item gets three different IDs.
AI-native daily workflow
The Project Manager operates a daily and weekly loop. The loop uses GitHub Copilot primitives inside Visual Studio Code, Claude Code at the terminal for long-form synthesis, and Microsoft Teams via the M365 Agents SDK for stakeholder cadence.
Morning setup
- Open Visual Studio Code on the
program-opsrepository. GitHub Copilot Chat loads the scoped.github/instructions/pm.instructions.md. - Invoke
/risk-log. The Risk Scout agent reviews the register, flags risks overdue for review, and drafts updates where new evidence is available. - Scan the Teams overnight digest from the M365 Agents SDK for any stakeholder message that requires a same-day reply.
Midday execution
- Run
/statusfor the active project. The agent pulls GitHub Projects status, Azure Boards iteration burn-up, Application Insights incident count via the Azure MCP, and composes a draft status report. - Reconcile cross-team dependencies by running
/raid. The agent updates the RAID log with new items detected from PR labels and work-item state transitions. - Hold dependency sync meetings where needed. Each agreement is written back to the RAID log immediately, with an owner and a target date.
Afternoon review
- Publish the status report. The M365 Agents SDK posts it into the appropriate Teams channels, with links back to the repository.
- Invoke
/stakeholder-mapweekly. The agent refreshes the stakeholder inventory, flags stakeholders who have not received an update in over two weeks, and proposes outreach drafts. - Close the day by committing the RAID log and the risk register updates to the
program-opsrepository. GitHub Actions publishes them to the Azure Static Web App that hosts the program dashboard.
Recommended primitives
Agent
| Agent | File | Purpose |
|---|---|---|
risk-scout | .github/agents/risk-scout.agent.md | Maintain the risk register, draft status reports, update the RAID log, refresh the stakeholder map |
The Risk Scout agent uses claude-sonnet-4-6 by default, with tools read, search, grep, bash. It pulls context from GitHub, Azure DevOps, Azure, and Microsoft 365 Agents SDK MCPs. Extended thinking is enabled for dependency analyses that cross multiple teams.
Slash prompts
| Command | File | Purpose |
|---|---|---|
/status | .github/prompts/status.prompt.md | Compose the weekly status report from reconciled sources |
/risk-log | .github/prompts/risk-log.prompt.md | Review and refresh the risk register, flag aging risks |
/raid | .github/prompts/raid.prompt.md | Update the RAID log from recent work-item and PR activity |
/stakeholder-map | .github/prompts/stakeholder-map.prompt.md | Refresh the stakeholder inventory and propose outreach |
Instructions scoped
Scoped applyTo keeps program artifacts distinct from team-level content.
Scope (applyTo) | File | Purpose |
|---|---|---|
program-ops/status/** | .github/instructions/status.instructions.md | Status report tone, one-page ceiling, citation discipline |
program-ops/risks/** | .github/instructions/risks.instructions.md | Risk scoring rubric, owner discipline, mitigation phrasing |
program-ops/stakeholders/** | .github/instructions/stakeholders.instructions.md | Stakeholder map format, outreach cadence, escalation rules |
Hooks
Hooks are zero-token governance for program artifacts.
pre-commit: reject a risk without a scored probability, impact, owner, and review datepost-commit: regenerate the program dashboard JSON on any RAID changepre-push: validate that every status report cites specific work items and Application Insights incidents
Validated MCPs
Every MCP below is registered in the MCP catalog. Do not reference any MCP that is not in the catalog.
| MCP | Status | Use in this persona |
|---|---|---|
| Azure DevOps MCP Server | Official (Microsoft) | Read and update Azure Boards work items, risk register entries, and iteration data |
| GitHub MCP Server | Official | Read GitHub Projects state, PR status, and Actions runs for status composition |
| Azure MCP Server | Official (Microsoft) | Query Azure Monitor and Application Insights for incident evidence behind risks |
| Microsoft Learn Docs MCP | Official | Ground program guidance in Microsoft Learn and GitHub Docs |
| Microsoft 365 Agents SDK MCP | Official (Microsoft) | Post status reports and stakeholder outreach drafts into Microsoft Teams |
Real examples
Example 1: weekly status report for a regulated program
Input: A payments program with three squads, one active production incident, and an auditor review next month.
Invocation: /status.
Expected output:
- A one-page status report in
program-ops/status/2026-W17.mdwith sections: commitments, progress, risks in motion, decisions needed, upcoming milestones. - Every claim cites a work item ID from Azure Boards or a PR from GitHub Projects.
- The active incident is linked to its Application Insights timeline.
- A Teams post via the M365 Agents SDK to the executive sponsor channel with the one-page summary.
Example 2: cross-team dependency at risk
Input: The checkout squad depends on the identity squad delivering a new token endpoint by week 18. Evidence shows the identity squad is behind.
Invocation: /raid.
Expected output:
- A new RAID entry
program-ops/raid/identity-token-endpoint.mdwith type Dependency, owner set to the identity squad lead, impact described in checkout-squad terms, mitigation proposals (temporary stub, feature flag). - An Azure Boards dependency work item created and linked to both squad boards.
- A Teams message to both squad leads with the facts, not a meeting invite.
- A follow-up on the stakeholder map: the checkout squad product owner is flagged for a targeted update.
Anti-patterns
- Status reports that rephrase the plan. Paraphrasing the plan is not progress. Mitigation: the
status.instructions.mdrequires evidence citations for every claim. - Risks without owners. A risk without an owner is a wish. Mitigation: the pre-commit hook rejects unowned risks.
- Stakeholder maps that only list names. A map without cadence and interests is a phonebook. Mitigation:
/stakeholder-maprequires cadence, interests, and preferred channel for each stakeholder. - RAID logs duplicated across tools. Multiple sources of truth create disputes. Mitigation: the RAID log lives in the
program-opsrepository; everything else is a view. - Escalation by surprise. Bad news that lands without proposed mitigations loses trust. Mitigation: the Risk Scout agent always accompanies an escalation with at least two mitigation options.
KPIs and impact metrics
| Metric | Baseline (manual) | Target (agentic) | Measurement |
|---|---|---|---|
| Status report preparation time | 8 hours per week | Under 90 minutes | Time-to-publish log |
| Risk median review age | 21 days | Under 7 days | Risk register audit |
| Dependency slippage lead time | 3 days warning | Over 10 days warning | RAID detection history |
| Stakeholder satisfaction (NPS) | Plus 10 | Plus 40 | Quarterly program survey |
| Escalation-with-mitigation rate | 35 percent | Over 90 percent | Escalation audit |
| Token efficiency | N/A | Under 200k tokens per week | Copilot usage report |
Maturity in four levels
| Level | Name | Markers |
|---|---|---|
| L1 | Manual | Status reports assembled by hand, risks in a spreadsheet, RAID scattered |
| L2 | Assisted | GitHub Copilot Chat for drafting, no agent, some Azure DevOps dashboards |
| L3 | Augmented | Risk Scout agent, four slash prompts, scoped instructions, RAID log in program-ops |
| L4 | Agentic | Full primitives kit, hooks enforced, stakeholder cadence automated in Teams via M365 Agents SDK, risks always scored, maturity scorecard above 80 percent |
Integration with other personas
- With Engineering Manager: shared delivery-health view, risk-to-capacity translation
- With Scrum Master: sprint flow informs program pacing
- With Product Owner: scope negotiation backed by RAID evidence
- With Technical Lead: architectural risks land in the program register with owners
- With Release Manager: release-window coordination across squads
- With InfoSec Officer and Compliance Auditor: program-level controls, audit evidence, regulated-industry cadence
- With SRE: incident-derived risks recorded and tracked
Glossary
- RAID log: the consolidated register of Risks, Assumptions, Issues, Dependencies used as the program’s single source of truth.
- Risk register: the risk subset of the RAID log, kept in Azure DevOps with probability, impact, owner, and review date.
- Stakeholder map: a living inventory of stakeholders, their interests, their cadence, and their preferred channel.
- Status report: a weekly, one-page artifact that reconciles commitments, progress, risks in motion, decisions needed, and upcoming milestones.
- Escalation with mitigation: the discipline of never delivering bad news without at least two proposed options.
- Dependency hand-off: the documented hand-off between two teams, with explicit acceptance criteria.
References
- Azure Boards documentation — authoritative guidance for risk registers and work-item tracking
- GitHub Projects documentation — program-level views across multiple repositories
- Microsoft 365 Agents SDK — post status reports and stakeholder outreach into Teams
- Azure Monitor documentation — incident evidence for risk scoring
- GitHub Actions documentation — schedule program dashboards and reconciliation jobs
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.mdescopado. - 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
/statuspara 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-mapsemanalmente. 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 pontuadospost-commit: regenera o JSON do dashboard de programa em qualquer mudança do RAIDpre-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.mdcom 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.mdcom 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.mdexige 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-mapexige 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
El Project Manager es la persona responsable de la entrega predecible entre equipos y de la comunicación honesta con stakeholders. En un SDLC AI-native, el Project Manager opera un ciclo de riesgo y estado, no un calendario de reuniones de status.
Resumen ejecutivo
El Project Manager convierte un portafolio de compromisos en una única imagen honesta de progreso, riesgo y expectativas de stakeholders. En un SDLC AI-native, el Project Manager trabaja dentro de la fase de Delivery con un conjunto fijo de primitivas: un agente risk-scout, cuatro slash prompts, instrucciones con alcance, hooks validados por esquema y una lista curada de MCPs validados. Las salidas principales son reportes de status, un registro de riesgos vivo en Azure DevOps, mapas de stakeholders y bitácoras RAID que impulsan decisiones en lugar de decorar reuniones.
Rol y responsabilidades
Piense en el Project Manager como el controlador de tráfico aéreo en un aeropuerto concurrido. Los aviones despegan y aterrizan por su propia potencia, pero cada despegue y aterrizaje se secuencia, espacia y reporta a la torre. El Project Manager es esa torre. En un SDLC AI-native, el código y la arquitectura son propiedad de otras personas; el Project Manager es dueño de la secuenciación, del slot y de la disciplina de radio.
Responsabilidades principales:
- Mantener el registro de riesgos en Azure DevOps con cada riesgo puntuado, con dueño y con fecha
- Producir reportes semanales de status que reconcilien GitHub Projects, Azure Boards y datos de incidentes
- Conducir la cadencia de comunicación con stakeholders a través de Microsoft Teams y el M365 Agents SDK
- Mantener la bitácora RAID al día (Risks, Assumptions, Issues, Dependencies) y vincular cada ítem a un work item
- Facilitar la gestión de dependencias entre equipos con criterios explícitos de hand-off
- Escalar riesgos materiales al Engineering Manager y al liderazgo de Programa con mitigaciones propuestas, nunca con sorpresas
- Operar el agente Risk Scout y los prompts
/status,/risk-log,/raid,/stakeholder-map
Jobs to be done
- Como Project Manager, quiero un reporte semanal de status auto-sintetizado desde GitHub Projects y Azure Boards, para que mi tiempo se invierta en mitigación, no en formato.
- Como Project Manager, quiero que cada riesgo del registro tenga probabilidad, impacto, dueño y fecha de revisión, para que las conversaciones de riesgo sean concretas.
- Como Project Manager, quiero que los stakeholders sepan qué cambió y qué significa para ellos, para que la confianza se acumule a través de los trimestres.
- Como Project Manager, quiero dependencias rastreadas entre equipos con criterios de aceptación explícitos, para que los hand-offs no se deslicen silenciosamente.
- Como Project Manager, quiero que la bitácora RAID sea la única fuente de verdad, para que nadie re-litigue decisiones en conversaciones de pasillo.
- Como Project Manager, quiero un trail de auditoría de cada compromiso con stakeholders, para que los cambios de alcance se negocien con hechos.
Puntos de dolor antes de la era AI-native
- Teatro de status. El liderazgo pide una actualización de una página; el Project Manager pasa medio día reformateando los mismos datos desde tres herramientas.
- Registros de riesgos que son inventarios, no instrumentos. Cada riesgo está registrado; ninguno tiene dueño, fecha de revisión o mitigación. El registro se audita, no se usa.
- Silencio de stakeholders. Las malas noticias se demoran porque no hay una cadencia segura para entregarlas. Cuando finalmente llegan, llegan con sorpresa y culpa.
- Deslizamiento de dependencias detectado tarde. Un equipo aguas abajo se entera el viernes de que el equipo aguas arriba se atrasó hace dos semanas.
- Bitácoras RAID dispersas en documentos. Los riesgos en un lugar, los supuestos en otro, las dependencias en una tercera hoja de cálculo. El mismo ítem recibe tres IDs diferentes.
Flujo diario AI-native
El Project Manager opera un ciclo diario y semanal. El ciclo usa primitivas de GitHub Copilot dentro de Visual Studio Code, Claude Code en la terminal para síntesis larga y Microsoft Teams vía el M365 Agents SDK para la cadencia de stakeholders.
Setup de la mañana
- Abrir Visual Studio Code en el repositorio
program-ops. GitHub Copilot Chat carga el.github/instructions/pm.instructions.mdcon alcance. - Invocar
/risk-log. El agente Risk Scout revisa el registro, marca riesgos con revisión vencida y redacta actualizaciones donde hay nueva evidencia disponible. - Escanear el digest nocturno de Teams desde el M365 Agents SDK por cualquier mensaje de stakeholder que requiera respuesta el mismo día.
Ejecución al mediodía
- Ejecutar
/statuspara el proyecto activo. El agente extrae el estado de GitHub Projects, el burn-up de iteración de Azure Boards, el conteo de incidentes de Application Insights vía el Azure MCP y compone un borrador de reporte de status. - Reconciliar dependencias entre equipos ejecutando
/raid. El agente actualiza la bitácora RAID con nuevos ítems detectados desde labels de PR y transiciones de estado de work items. - Sostener reuniones de sincronización de dependencias donde sea necesario. Cada acuerdo se escribe inmediatamente de vuelta en la bitácora RAID, con un dueño y una fecha objetivo.
Revisión al final de la tarde
- Publicar el reporte de status. El M365 Agents SDK lo publica en los canales de Teams apropiados, con enlaces de regreso al repositorio.
- Invocar
/stakeholder-mapsemanalmente. El agente refresca el inventario de stakeholders, marca a quienes no han recibido actualización en más de dos semanas y propone borradores de outreach. - Cerrar el día haciendo commit de la bitácora RAID y de las actualizaciones del registro de riesgos al repositorio
program-ops. GitHub Actions las publica en la Azure Static Web App que aloja el dashboard del programa.
Primitivas recomendadas
Agente
| Agente | Archivo | Propósito |
|---|---|---|
risk-scout | .github/agents/risk-scout.agent.md | Mantener el registro de riesgos, redactar reportes de status, actualizar la bitácora RAID y refrescar el mapa de stakeholders |
El agente Risk Scout usa claude-sonnet-4-6 por defecto, con herramientas read, search, grep, bash. Toma contexto de los MCPs de GitHub, Azure DevOps, Azure y Microsoft 365 Agents SDK. El extended thinking está habilitado para análisis de dependencias que cruzan múltiples equipos.
Slash prompts
| Comando | Archivo | Propósito |
|---|---|---|
/status | .github/prompts/status.prompt.md | Componer el reporte semanal de status desde fuentes reconciliadas |
/risk-log | .github/prompts/risk-log.prompt.md | Revisar y refrescar el registro de riesgos, marcar riesgos envejecidos |
/raid | .github/prompts/raid.prompt.md | Actualizar la bitácora RAID desde la actividad reciente de work items y PRs |
/stakeholder-map | .github/prompts/stakeholder-map.prompt.md | Refrescar el inventario de stakeholders y proponer outreach |
Instructions con alcance
El applyTo con alcance mantiene los artefactos de programa distintos del contenido a nivel de equipo.
Alcance (applyTo) | Archivo | Propósito |
|---|---|---|
program-ops/status/** | .github/instructions/status.instructions.md | Tono del reporte de status, tope de una página, disciplina de citas |
program-ops/risks/** | .github/instructions/risks.instructions.md | Rúbrica de scoring de riesgos, disciplina de dueños, fraseo de mitigaciones |
program-ops/stakeholders/** | .github/instructions/stakeholders.instructions.md | Formato del mapa de stakeholders, cadencia de outreach, reglas de escalamiento |
Hooks
Los hooks son gobernanza de cero tokens para artefactos de programa.
pre-commit: rechaza un riesgo sin probabilidad puntuada, impacto, dueño y fecha de revisiónpost-commit: regenera el JSON del dashboard del programa ante cualquier cambio en RAIDpre-push: valida que cada reporte de status cite work items específicos e incidentes de Application Insights
MCPs validados
Cada MCP a continuación está registrado en el catálogo de MCPs. No referencie ningún MCP que no esté en el catálogo.
| MCP | Estado | Uso en esta persona |
|---|---|---|
| Azure DevOps MCP Server | Oficial (Microsoft) | Leer y actualizar work items de Azure Boards, entradas del registro de riesgos y datos de iteración |
| GitHub MCP Server | Oficial | Leer estado de GitHub Projects, status de PRs y ejecuciones de Actions para componer status |
| Azure MCP Server | Oficial (Microsoft) | Consultar Azure Monitor y Application Insights por evidencia de incidentes detrás de los riesgos |
| Microsoft Learn Docs MCP | Oficial | Fundamentar la guía de programa en Microsoft Learn y GitHub Docs |
| Microsoft 365 Agents SDK MCP | Oficial (Microsoft) | Publicar reportes de status y borradores de outreach a stakeholders en Microsoft Teams |
Ejemplos reales
Ejemplo 1: reporte semanal de status para un programa regulado
Entrada: Un programa de pagos con tres squads, un incidente activo en producción y una revisión de auditor el próximo mes.
Invocación: /status.
Salida esperada:
- Un reporte de status de una página en
program-ops/status/2026-W17.mdcon secciones: compromisos, progreso, riesgos en movimiento, decisiones requeridas, próximos hitos. - Cada afirmación cita un ID de work item de Azure Boards o un PR de GitHub Projects.
- El incidente activo está vinculado a su línea de tiempo de Application Insights.
- Una publicación en Teams vía el M365 Agents SDK al canal del executive sponsor con el resumen de una página.
Ejemplo 2: dependencia entre equipos en riesgo
Entrada: El squad de checkout depende de que el squad de identidad entregue un nuevo endpoint de token para la semana 18. La evidencia muestra que el squad de identidad va atrasado.
Invocación: /raid.
Salida esperada:
- Una nueva entrada RAID
program-ops/raid/identity-token-endpoint.mdcon tipo Dependency, dueño asignado al líder del squad de identidad, impacto descrito en términos del squad de checkout, propuestas de mitigación (stub temporal, feature flag). - Un work item de dependencia en Azure Boards creado y vinculado a ambos tableros de squad.
- Un mensaje de Teams a ambos líderes de squad con los hechos, no una invitación a reunión.
- Un seguimiento en el mapa de stakeholders: el product owner del squad de checkout queda marcado para una actualización dirigida.
Anti-patrones
- Reportes de status que reformulan el plan. Parafrasear el plan no es progreso. Mitigación: el
status.instructions.mdrequiere citas de evidencia para cada afirmación. - Riesgos sin dueño. Un riesgo sin dueño es un deseo. Mitigación: el hook pre-commit rechaza riesgos sin dueño.
- Mapas de stakeholders que solo listan nombres. Un mapa sin cadencia ni intereses es una agenda telefónica. Mitigación:
/stakeholder-maprequiere cadencia, intereses y canal preferido por cada stakeholder. - Bitácoras RAID duplicadas entre herramientas. Múltiples fuentes de verdad crean disputas. Mitigación: la bitácora RAID vive en el repositorio
program-ops; todo lo demás es una vista. - Escalamiento por sorpresa. Las malas noticias que llegan sin mitigaciones propuestas pierden confianza. Mitigación: el agente Risk Scout siempre acompaña un escalamiento con al menos dos opciones de mitigación.
KPIs y métricas de impacto
| Métrica | Línea base (manual) | Meta (agéntico) | Medición |
|---|---|---|---|
| Tiempo de preparación del reporte de status | 8 horas por semana | Menos de 90 minutos | Log de tiempo-a-publicación |
| Edad mediana de revisión de riesgos | 21 días | Menos de 7 días | Auditoría del registro de riesgos |
| Tiempo de aviso de deslizamiento de dependencias | 3 días de aviso | Más de 10 días de aviso | Historial de detección RAID |
| Satisfacción de stakeholders (NPS) | Más 10 | Más 40 | Encuesta trimestral del programa |
| Tasa de escalamiento-con-mitigación | 35 por ciento | Más del 90 por ciento | Auditoría de escalamientos |
| Eficiencia de tokens | N/A | Menos de 200k tokens por semana | Reporte de uso de Copilot |
Madurez en cuatro niveles
| Nivel | Nombre | Marcadores |
|---|---|---|
| L1 | Manual | Reportes de status armados a mano, riesgos en una hoja de cálculo, RAID disperso |
| L2 | Asistido | GitHub Copilot Chat para redactar, sin agente, algunos dashboards de Azure DevOps |
| L3 | Aumentado | Agente Risk Scout, cuatro slash prompts, instrucciones con alcance, bitácora RAID en program-ops |
| L4 | Autónomo | Kit completo de primitivas, hooks aplicados, cadencia de stakeholders automatizada en Teams vía M365 Agents SDK, riesgos siempre puntuados, scorecard de madurez por encima del 80 por ciento |
Integración con otras personas
- Con Engineering Manager: vista compartida de salud de entrega, traducción de riesgo a capacidad
- Con Scrum Master: el flujo del sprint informa el ritmo del programa
- Con Product Owner: negociación de alcance respaldada por evidencia RAID
- Con Technical Lead: los riesgos arquitectónicos aterrizan en el registro del programa con dueños
- Con Release Manager: coordinación de ventanas de release entre squads
- Con InfoSec Officer y Compliance Auditor: controles a nivel de programa, evidencia de auditoría, cadencia de industria regulada
- Con SRE: riesgos derivados de incidentes registrados y rastreados
Glosario
- Bitácora RAID: el registro consolidado de Risks, Assumptions, Issues, Dependencies usado como única fuente de verdad del programa.
- Registro de riesgos: el subconjunto de riesgos de la bitácora RAID, mantenido en Azure DevOps con probabilidad, impacto, dueño y fecha de revisión.
- Mapa de stakeholders: un inventario vivo de stakeholders, sus intereses, su cadencia y su canal preferido.
- Reporte de status: un artefacto semanal de una página que reconcilia compromisos, progreso, riesgos en movimiento, decisiones requeridas y próximos hitos.
- Escalamiento con mitigación: la disciplina de nunca entregar malas noticias sin al menos dos opciones propuestas.
- Hand-off de dependencia: el hand-off documentado entre dos equipos, con criterios de aceptación explícitos.
Referencias
- Documentación de Azure Boards — guía autoritativa para registros de riesgos y seguimiento de work items
- Documentación de GitHub Projects — vistas a nivel de programa entre múltiples repositorios
- Microsoft 365 Agents SDK — publicar reportes de status y outreach a stakeholders en Teams
- Documentación de Azure Monitor — evidencia de incidentes para scoring de riesgos
- Documentación de GitHub Actions — programar dashboards y trabajos de reconciliación del programa