paulasilvatech ASP Personas del SDLC Agéntico v1.0.0
EN PT ES
01 product · Planning

Product Owner

Escribe y gobierna el spec.

Actualizado: 2026-04-24 14 secciones Descargar .zip

El Product Owner es la persona que escribe, gobierna y cierra el ciclo de la especificación. En un SDLC AI-native, el Product Owner opera un stack de primitivas validadas que convierten la intención en un contrato legible por máquinas.

Resumen ejecutivo

El Product Owner convierte la intención de negocio ambigua en una especificación aprobada y verificable que el resto del SDLC puede ejecutar sin pérdidas en la traducción. En un SDLC AI-native, el Product Owner opera dentro de la fase de Planning con un conjunto fijo de primitivas: un agente de especificación, cuatro slash prompts, instrucciones con alcance, hooks validados por esquema y una lista curada de MCPs validados. Las salidas principales son documentos SPECIFICATION.md en forma EARS, criterios de aceptación en Given-When-Then, enlaces de trazabilidad desde el requisito hasta la prueba y registros de decisión para cada cambio de alcance.

Rol y responsabilidades

Piensa en el Product Owner como un ingeniero civil que redacta la especificación de un puente. Los constructores, inspectores y reguladores leen el mismo documento y derivan su trabajo a partir de él. El Product Owner no vierte concreto, pero es responsable de que cada vertido, soldadura y cable coincida con una cláusula numerada que alguien pueda verificar bajo carga. En un SDLC AI-native, la especificación es el contrato entre humanos y agentes, y el Product Owner es su editor jefe.

Responsabilidades principales:

  • Redactar y mantener SPECIFICATION.md para cada feature, usando requisitos EARS y criterios de aceptación en Given-When-Then
  • Gobernar el backlog en GitHub Projects o Azure Boards, asegurando que cada ítem enlace a una sección del spec
  • Definir y proteger la hipótesis de resultado del producto, no la lista de salidas
  • Resolver conflictos de alcance entre stakeholders antes de que lleguen al Developer
  • Operar el agente Spec Scribe y los prompts /draft-spec, /earsify, /review-spec, /link-acceptance
  • Cerrar el ciclo confirmando la aceptación en los pull requests fusionados en GitHub
  • Mantener la matriz de trazabilidad desde el requisito hasta la prueba y el artefacto desplegado
  • Publicar las release notes a partir del diff del spec, no del diff del código

Jobs to be done

  1. Como Product Owner, quiero convertir una conversación con stakeholders en un borrador de spec en menos de una hora, para que el equipo nunca espere por mí para iniciar el discovery.
  2. Como Product Owner, quiero cada requisito en forma EARS, para que los agentes puedan parsearlo sin interpretación.
  3. Como Product Owner, quiero cada criterio de aceptación en Given-When-Then, para que el QA Engineer pueda generar pruebas directamente desde el spec.
  4. Como Product Owner, quiero un enlace de trazabilidad en vivo desde cada requisito hasta su prueba y su artefacto desplegado, para que pueda responder preguntas de auditoría en minutos.
  5. Como Product Owner, quiero que el spec rechace el merge cuando falte la aceptación, para que la deriva de alcance se detecte antes de escribir código.
  6. Como Product Owner, quiero que las release notes se generen a partir del diff del spec, para que los stakeholders vean el valor entregado, no los commits enviados.

Puntos de dolor antes de la era AI-native

  1. Tickets ambiguos. Las descripciones libres en un tracker obligan a cada lector a adivinar la intención. Los developers implementan la interpretación más fácil; QA prueba la más defensiva.
  2. Handoffs verbales. El alcance vive en la memoria de la reunión. Cuando termina la reunión, el alcance se bifurca silenciosamente.
  3. Criterios de aceptación inventados al momento del review. Los reviewers negocian la definición de done después de escrito el código, así que el rework es inevitable.
  4. Trazabilidad construida a mano en hojas de cálculo. La matriz queda obsoleta el día que se publica, y los auditores lo saben.
  5. Release notes escritas por el release manager a partir de los logs de commit. Los stakeholders ven ruido técnico, no resultados de producto, y la confianza se erosiona.

Flujo diario AI-native

El Product Owner opera un loop fijo cada día. El loop usa primitivas de GitHub Copilot dentro de Visual Studio Code y Claude Code en la terminal, además de un pequeño catálogo de MCPs validados para contexto externo.

Setup de la mañana

  1. Abrir el repositorio en Visual Studio Code. GitHub Copilot Chat carga AGENTS.md y las instrucciones de spec con alcance.
  2. Hacer pull del último main y abrir el branch activo de la feature para el spec en curso.
  3. Revisar los aportes nocturnos de stakeholders capturados en hilos de Microsoft Teams y Outlook a través del MCP del Microsoft 365 Agents SDK.
  4. Ejecutar /review-spec sobre el borrador del día anterior para detectar violaciones a EARS y aceptaciones faltantes.

Ejecución al mediodía

  1. Toma de aportes de stakeholders. Invocar /draft-spec con la transcripción de la reunión o el hilo de Teams. El agente Spec Scribe produce un primer borrador con requisitos numerados y preguntas abiertas marcadas.
  2. Conversión a EARS. Invocar /earsify sobre cualquier enunciado en forma libre. El agente reescribe cada uno en la forma WHEN ... THE system SHALL ... y se niega a emitir requisitos sin una condición disparadora.
  3. Vinculación de aceptación. Invocar /link-acceptance para adjuntar criterios Given-When-Then a cada requisito. El agente bloquea el spec para que no avance al review hasta que cada requisito tenga al menos un criterio.
  4. Sincronización del backlog. Usar el MCP de GitHub o el MCP de Azure DevOps para crear o actualizar work items que referencien anclas de sección del spec, no resúmenes en prosa.

Revisión al final de la tarde

  1. Invocar /review-spec para correr la barrida final de gobierno. El agente verifica testabilidad, contradicciones, duplicados y requisitos huérfanos.
  2. Abrir un pull request sobre SPECIFICATION.md. GitHub Copilot Code Review comenta sobre problemas estructurales; los stakeholders humanos aprueban el contenido.
  3. Actualizar la matriz de trazabilidad. Un hook post-merge regenera la matriz a partir de las anclas del spec, los IDs de prueba y los registros de despliegue en GitHub Actions.
  4. Publicar el digest diario del spec al canal de Teams a través del Microsoft 365 Agents SDK, resumiendo los requisitos aceptados y las preguntas abiertas.

Primitivas recomendadas

Agente

AgenteArchivoPropósito
spec-scribe.github/agents/spec-scribe.agent.mdRedactar, earsificar, revisar y enlazar la aceptación para SPECIFICATION.md

El Spec Scribe usa claude-sonnet-4-6 por defecto. Herramientas: read, edit, search, grep, glob. Sin acceso a bash, porque la persona Product Owner nunca ejecuta código. El extended thinking se habilita solo para /review-spec, donde la detección de contradicciones se beneficia de un razonamiento profundo.

Slash prompts

ComandoArchivoPropósito
/draft-spec.github/prompts/draft-spec.prompt.mdConvertir una entrada cruda de stakeholders en un borrador numerado de spec
/earsify.github/prompts/earsify.prompt.mdReescribir requisitos en forma libre a sintaxis EARS
/review-spec.github/prompts/review-spec.prompt.mdBarrida de gobierno por testabilidad, contradicciones y huérfanos
/link-acceptance.github/prompts/link-acceptance.prompt.mdAdjuntar criterios Given-When-Then a cada requisito

Instrucciones con alcance

El applyTo con alcance reduce el costo en tokens en aproximadamente 68 por ciento comparado con instrucciones globales.

Alcance (applyTo)ArchivoPropósito
docs/specs/**/*.md.github/instructions/specs.instructions.mdFormato EARS, numeración, anclas y verbos vagos prohibidos
docs/adr/**/*.md.github/instructions/adr.instructions.mdFormato del registro de decisión cuando un spec requiere una elección arquitectónica
docs/releases/**/*.md.github/instructions/release-notes.instructions.mdRelease notes generadas a partir del diff del spec, no del log de commits

Hooks

Los hooks cuestan cero tokens de LLM. Son la capa de gobierno más fuerte para las especificaciones.

  • pre-commit: rechazar cualquier archivo de spec con un requisito que carezca de un disparador EARS o un criterio de aceptación huérfano
  • post-commit: regenerar la matriz de trazabilidad a partir de las anclas del spec y los IDs de prueba
  • pre-merge: bloquear el merge de cualquier cambio de spec que no incluya una entrada en el changelog y un work item enlazado

MCPs validados

MCPPropósitoDueño
GitHub MCP ServerLeer y actualizar GitHub Projects, issues y PRs para el gobierno del backlogGitHub (oficial)
Azure DevOps MCP ServerLeer y actualizar work items de Azure Boards cuando el equipo usa Azure DevOpsMicrosoft (oficial)
Microsoft Learn Docs MCPObtener documentación vigente de productos Microsoft al escribir specs para features de M365 o AzureMicrosoft (oficial)
Microsoft 365 Agents SDK MCPTraer hilos de Teams, decisiones de Outlook y artefactos de SharePoint a la toma de aportes del specMicrosoft (oficial)
Azure MCP ServerConsultar Application Insights y Azure Monitor para anclar specs en el comportamiento de producciónMicrosoft (oficial)

Ejemplos reales

Ejemplo 1: redactar un spec a partir de una conversación de Teams

Entrada: Un hilo de Microsoft Teams de 45 minutos entre ventas y soporte que propone un flujo de renovación de contrato self-service.

Invocación: /draft-spec con el hilo exportado vía el MCP del Microsoft 365 Agents SDK.

Salida esperada:

  1. Un docs/specs/contract-renewal/SPECIFICATION.md con seis requisitos EARS numerados, cada uno seguido por criterios de aceptación Given-When-Then.
  2. Un GitHub issue por requisito creado a través del MCP de GitHub, enlazado al ancla del spec.
  3. Una sección de preguntas abiertas que enumera cuatro puntos que requieren una decisión antes de la aprobación.

Ejemplo 2: barrida de gobierno antes del merge

Entrada: Un spec de 28 requisitos para un upgrade de billing, ya earsificado en una pasada anterior.

Invocación: /review-spec.

Salida esperada:

  1. Un reporte de revisión que marca dos contradicciones entre los requisitos 7 y 14, un duplicado entre 19 y 22, y tres criterios de aceptación huérfanos no adjuntos a ningún requisito.
  2. Un comentario en el pull request con sugerencias enlazadas a anclas.
  3. Un merge bloqueado hasta que el autor resuelva las tres categorías.

Anti-patrones

  1. Escribir specs como prosa. Los párrafos esconden contradicciones y no pueden ser consumidos por agentes. Mitigación: forzar EARS vía el hook pre-commit y el prompt /earsify.
  2. Saltarse los criterios de aceptación. Un requisito sin Given-When-Then no es testable. Mitigación: /link-acceptance se niega a cerrar el ciclo y el hook bloquea el commit.
  3. Ítems del backlog sin anclas al spec. Si el ticket no enlaza a un requisito numerado, el alcance va a derivar. Mitigación: el MCP de GitHub auto-inyecta la URL del ancla al crear el issue.
  4. Release notes generadas desde commits. Los stakeholders ven ruido técnico. Mitigación: las release notes se generan a partir del diff del spec mediante las instrucciones con alcance.
  5. Verbos ambiguos. Palabras como “soportar”, “manejar”, “mejorar” están prohibidas por las instrucciones del spec. Mitigación: el hook pre-commit las rechaza.

KPIs y métricas de impacto

KPILínea baseMetaMedición
Lead time del spec, de toma a aprobado5 días< 1 díaTimestamps del PR de SPECIFICATION.md en GitHub
Requisitos en forma EARS20 por ciento100 por cientoReporte del linter de spec en GitHub Actions
Cobertura de aceptación, requisitos con Given-When-Then40 por ciento100 por cientoMatriz de trazabilidad
Tasa de cambios de alcance post-aprobación35 por ciento< 10 por cientoConteo de PRs de spec reabiertos
Tiempo para responder una consulta de auditoría2 días< 1 horaLog de consultas a la matriz de trazabilidad
Satisfacción de stakeholders con la claridadDesconocida> 4.2 de 5Encuesta trimestral vía Microsoft Forms

Madurez en cuatro niveles

NivelNombreMarcadores
L1ManualTickets en prosa, sin EARS, sin aceptación, alcance negociado en review
L2AsistidoGitHub Copilot usado para pulir el texto del ticket, sin spec legible por máquina
L3AumentadoAgente Spec Scribe, cuatro slash prompts, instrucciones con alcance, uno o dos MCPs, EARS forzado
L4AutónomoKit completo de primitivas, hooks forzados, trazabilidad auto-generada, release notes desde el diff del spec, digest a stakeholders automatizado

Integración con otras personas

  • Hacia Requirements Engineer: SPECIFICATION.md aprobado con requisitos EARS numerados como entrada canónica para la descomposición detallada
  • Hacia Business Manager: hooks de KPI a nivel de requisito para que los resultados puedan amarrarse a la historia de valor
  • Hacia Enterprise Architect: cláusulas del spec que disparan un nuevo ADR o invocan un principio existente
  • Hacia Software Architect: superficie de contrato usada para derivar CODEMAP.md y los contratos de API
  • Hacia QA Engineer: aceptación Given-When-Then como fuente directa de los casos de prueba
  • Hacia Developer: ancla del spec en cada pull request para implementación trazable
  • Hacia Tech Writer: release notes generadas a partir del diff del spec, no del diff de commits

Glosario

  • EARS: Easy Approach to Requirements Syntax. La forma canónica WHEN ... THE system SHALL ... usada en SPECIFICATION.md.
  • Given-When-Then: formato de criterio de aceptación que une una precondición, una acción y un resultado observable.
  • Ancla del spec: ancla markdown estable sobre el ID de un requisito, usada como objetivo canónico de enlace desde issues, PRs y pruebas.
  • Matriz de trazabilidad: tabla generada que mapea cada requisito a sus pruebas, pull requests y artefactos desplegados.
  • Hipótesis de resultado: el resultado de negocio medible que la feature se supone debe producir, distinto de la lista de salidas.
  • Backlog: la lista ordenada de work items en GitHub Projects o Azure Boards, cada uno enlazado a un ancla del spec.

Referencias