Gerente de Proyecto

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

1. 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.
2. 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.
3. 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.
4. Como Project Manager, quiero dependencias rastreadas entre equipos con criterios de aceptación explícitos, para que los hand-offs no se deslicen silenciosamente.
5. 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.
6. 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

1. 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.
2. 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.
3. Silencio de stakeholders. Las malas noticias se demoran porque no hay una cadencia segura para entregarlas. Cuando finalmente llegan, llegan con sorpresa y culpa.
4. Deslizamiento de dependencias detectado tarde. Un equipo aguas abajo se entera el viernes de que el equipo aguas arriba se atrasó hace dos semanas.
5. 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

1. Abrir Visual Studio Code en el repositorio program-ops. GitHub Copilot Chat carga el .github/instructions/pm.instructions.md con alcance.
2. Invocar /risk-log. El agente Risk Scout revisa el registro, marca riesgos con revisión vencida y redacta actualizaciones donde hay nueva evidencia disponible.
3. 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

1. Ejecutar /status para 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.
2. 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.
3. 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

1. Publicar el reporte de status. El M365 Agents SDK lo publica en los canales de Teams apropiados, con enlaces de regreso al repositorio.
2. Invocar /stakeholder-map semanalmente. 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.
3. 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ón
• post-commit: regenera el JSON del dashboard del programa ante cualquier cambio en RAID
• pre-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:

1. Un reporte de status de una página en program-ops/status/2026-W17.md con secciones: compromisos, progreso, riesgos en movimiento, decisiones requeridas, próximos hitos.
2. Cada afirmación cita un ID de work item de Azure Boards o un PR de GitHub Projects.
3. El incidente activo está vinculado a su línea de tiempo de Application Insights.
4. 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:

1. Una nueva entrada RAID program-ops/raid/identity-token-endpoint.md con 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).
2. Un work item de dependencia en Azure Boards creado y vinculado a ambos tableros de squad.
3. Un mensaje de Teams a ambos líderes de squad con los hechos, no una invitación a reunión.
4. Un seguimiento en el mapa de stakeholders: el product owner del squad de checkout queda marcado para una actualización dirigida.

Anti-patrones

1. Reportes de status que reformulan el plan. Parafrasear el plan no es progreso. Mitigación: el status.instructions.md requiere citas de evidencia para cada afirmación.
2. Riesgos sin dueño. Un riesgo sin dueño es un deseo. Mitigación: el hook pre-commit rechaza riesgos sin dueño.
3. Mapas de stakeholders que solo listan nombres. Un mapa sin cadencia ni intereses es una agenda telefónica. Mitigación: /stakeholder-map requiere cadencia, intereses y canal preferido por cada stakeholder.
4. 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.
5. 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