Business Manager

El Business Manager es la persona que une la estrategia con la medición. En un SDLC AI-native, el Business Manager opera un stack de primitivas validadas que convierten la intención de negocio en KPIs e hipótesis de resultado legibles por máquinas.

Resumen ejecutivo

El Business Manager traduce la estrategia empresarial y los OKRs en KPIs a nivel de producto, historias de valor y casos de inversión contra los cuales el resto del SDLC puede optimizar. En un SDLC AI-native, el Business Manager opera dentro de la fase de Planning con un conjunto fijo de primitivas: un agente de traducción de KPIs, cuatro slash prompts, instrucciones con alcance, hooks validados por esquema y una lista curada de MCPs validados. Las salidas principales son árboles de OKR, especificaciones de KPI, casos de negocio y historias de valor enlazadas a anclas del spec.

Rol y responsabilidades

Piensa en el Business Manager como el director de una orquesta que lee la partitura escrita por el compositor. El director no toca ningún instrumento, pero es responsable de que cada sección toque a tiempo y en tono, y de que lo que el público escuche coincida con la intención del compositor. En un SDLC AI-native, el árbol de OKR es la partitura, las specs de KPI son las marcas de tempo, y el Business Manager es responsable de la ejecución a través de producto, arquitectura y construcción.

Responsabilidades principales:

• Redactar y mantener el árbol de OKR en docs/okrs/ con resultados clave medibles y acotados en el tiempo
• Traducir cada objetivo estratégico en un KPI a nivel de producto con línea base, meta y método de medición
• Publicar la historia de valor para cada iniciativa, enlazada al SPECIFICATION.md que pertenece al Product Owner
• Mantener el caso de negocio con costo, beneficio y riesgo para cada feature por encima de un umbral definido
• Operar el agente KPI Translator y los prompts /okrs, /kpi-map, /biz-case, /value-story
• Gobernar la revisión del portafolio en GitHub Projects o Azure Boards
• Cerrar el ciclo con telemetría de Application Insights y Azure Monitor para verificar el logro de KPIs

Jobs to be done

1. Como Business Manager, quiero convertir un objetivo estratégico en un árbol de OKR en un día, para que el portafolio esté alineado al inicio de cada trimestre.
2. Como Business Manager, quiero que cada KPI tenga línea base, meta y método de medición, para que los resultados sean auditables, no anecdóticos.
3. Como Business Manager, quiero que la historia de valor esté enlazada al spec, para que las decisiones de ingeniería se rastreen hasta la intención de negocio.
4. Como Business Manager, quiero casos de negocio generados a partir de entradas con plantilla, para que el ciclo de idea a financiamiento se mida en días, no en semanas.
5. Como Business Manager, quiero telemetría en vivo del logro de KPIs desde Application Insights, para que pueda intervenir antes de que termine el trimestre.
6. Como Business Manager, quiero un reporte mensual de salud del portafolio generado automáticamente, para que las decisiones de liderazgo se basen en datos actuales.

Puntos de dolor antes de la era AI-native

1. OKRs escritos como diapositivas, no como datos. Los mazos de diapositivas no se pueden consultar. La deriva a mitad de trimestre es invisible hasta la reunión de revisión.
2. KPIs sin líneas base. Una meta sin línea base es un deseo. Los equipos optimizan lo fácil de medir, no lo importante.
3. Historias de valor desconectadas de los specs. El liderazgo escucha una narrativa, ingeniería entrega otra, y la brecha solo aflora en el lanzamiento.
4. Casos de negocio escritos en hojas de cálculo. El costo, beneficio y riesgo viven en archivos estáticos sin enlace a artefactos de ejecución.
5. Telemetría ignorada después del lanzamiento. El éxito de la feature se declara en la fecha de envío. El impacto real nunca se mide contra la meta original.

Flujo diario AI-native

El Business Manager 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 del portafolio en Visual Studio Code. GitHub Copilot Chat carga AGENTS.md y las instrucciones de OKR con alcance.
2. Traer la última telemetría de KPIs desde Application Insights vía el Azure MCP Server y refrescar los dashboards de KPIs.
3. Revisar los aportes nocturnos de stakeholders capturados en Teams y Outlook a través del MCP del Microsoft 365 Agents SDK.
4. Ejecutar /kpi-map para confirmar que cada iniciativa activa esté mapeada a al menos un KR.

Ejecución al mediodía

1. Autoría de OKR. Invocar /okrs sobre el tema estratégico del trimestre. El agente KPI Translator produce un árbol de OKR con objetivos numerados y resultados clave medibles, y se niega a emitir un KR sin línea base y meta.
2. Traducción de KPI. Invocar /kpi-map para amarrar cada KR a un KPI a nivel de producto. El agente verifica que el método de medición referencie una fuente de datos concreta, típicamente Application Insights, Azure Monitor o GitHub Projects.
3. Caso de negocio. Invocar /biz-case para cualquier iniciativa por encima del umbral de financiamiento. El agente llena las secciones de costo, beneficio, riesgo y supuestos contra la plantilla.
4. Historia de valor. Invocar /value-story para amarrar el caso de negocio al SPECIFICATION.md que pertenece al Product Owner. El agente produce una narrativa de una página con resultados medibles.

Revisión al final de la tarde

1. Correr una barrida de salud del portafolio sobre todos los OKRs activos. Marcar cualquier KR sin telemetría fresca, cualquier KPI por debajo de la trayectoria y cualquier iniciativa sin un spec enlazado.
2. Abrir un pull request sobre el árbol de OKR. GitHub Copilot Code Review comenta sobre la medibilidad; los reviewers de liderazgo aprueban el contenido.
3. Publicar el digest diario del portafolio al canal ejecutivo de Teams a través del Microsoft 365 Agents SDK, resumiendo progreso, riesgos y decisiones requeridas.
4. Sincronizar el backlog en GitHub Projects o Azure Boards para que cada ítem lleve los tags de OKR y KPI.

Primitivas recomendadas

Agente

Agente	Archivo	Propósito
kpi-translator	.github/agents/kpi-translator.agent.md	Traducir objetivos en KPIs, redactar árboles de OKR, generar casos de negocio e historias de valor

El KPI Translator usa claude-sonnet-4-6 por defecto. Herramientas: read, edit, search, grep, glob. Sin acceso a bash. El extended thinking se habilita solo para /biz-case, donde el modelado de beneficio y riesgo se beneficia de un razonamiento más profundo.

Slash prompts

Comando	Archivo	Propósito
/okrs	.github/prompts/okrs.prompt.md	Redactar o revisar el árbol de OKR para un tema estratégico
/kpi-map	.github/prompts/kpi-map.prompt.md	Amarrar cada KR a un KPI a nivel de producto con línea base, meta y fuente
/biz-case	.github/prompts/biz-case.prompt.md	Generar un caso de negocio estructurado con costo, beneficio y riesgo
/value-story	.github/prompts/value-story.prompt.md	Producir una narrativa de una página que enlaza el caso de negocio al spec

Instrucciones con alcance

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

Alcance (applyTo)	Archivo	Propósito
docs/okrs/**/*.md	.github/instructions/okrs.instructions.md	Formato del árbol de OKR, reglas de medibilidad, verbos vagos prohibidos
docs/kpis/**/*.md	.github/instructions/kpis.instructions.md	Esquema de spec de KPI: línea base, meta, fuente, cadencia
docs/biz/**/*.md	.github/instructions/biz-case.instructions.md	Plantilla de caso de negocio y requisitos de evidencia

Hooks

Los hooks cuestan cero tokens de LLM. Son la capa de gobierno más fuerte para los artefactos de negocio.

• pre-commit: rechazar cualquier OKR sin un KR medible y cualquier KPI sin línea base o fuente
• post-commit: refrescar el dashboard del portafolio a partir de los archivos más recientes de OKR y KPI
• pre-merge: bloquear el merge de cualquier caso de negocio que carezca de un ancla del spec enlazada

MCPs validados

MCP	Propósito	Dueño
Azure MCP Server	Consultar Application Insights y Azure Monitor para telemetría de KPI en vivo	Microsoft (oficial)
GitHub MCP Server	Leer y actualizar GitHub Projects para gobierno del portafolio y backlog etiquetado por OKR	GitHub (oficial)
Azure DevOps MCP Server	Sincronizar OKRs y KPIs con Azure Boards cuando el equipo usa Azure DevOps	Microsoft (oficial)
Microsoft 365 Agents SDK MCP	Publicar digests a Teams e ingerir decisiones desde Outlook	Microsoft (oficial)
Microsoft Learn Docs MCP	Anclar casos de negocio en documentación vigente de precios y capacidades de Microsoft y Azure	Microsoft (oficial)

Ejemplos reales

Ejemplo 1: autoría trimestral de OKR

Entrada: Un tema estratégico del plan anual: “Aumentar la tasa de renovación de contrato self-service de 22 por ciento a 55 por ciento para Q4.”

Invocación: /okrs con el tema y la telemetría del año pasado obtenida desde el Azure MCP.

Salida esperada:

1. Un docs/okrs/2026-q3.md con un objetivo y tres KRs, cada uno con una línea base, una meta y una consulta de Application Insights como fuente de medición.
2. Tres issues en GitHub Projects etiquetados con el OKR y asignados a las squads dueñas.
3. Un digest publicado en el canal de liderazgo de Teams a través del Microsoft 365 Agents SDK.

Ejemplo 2: caso de negocio para una compuerta de financiamiento

Entrada: Una propuesta para una nueva integración de API con partners por encima del umbral de financiamiento.

Invocación: /biz-case seguido de /value-story.

Salida esperada:

1. Un docs/biz/partner-api-2026.md con secciones de costo, beneficio, riesgo y supuestos llenadas contra la plantilla.
2. Una historia de valor de una página en docs/biz/partner-api-2026-value.md que enlaza al ancla del SPECIFICATION.md y nombra el KPI que la iniciativa moverá.
3. Un pull request que dispara la revisión de la compuerta de financiamiento, con Copilot Code Review comentando sobre medibilidad y alcance.

Anti-patrones

1. KRs sin líneas base. Una meta de “aumentar adopción” no es medible. Mitigación: el hook pre-commit rechaza cualquier KR sin línea base y fuente.
2. OKRs en diapositivas primero. Si la copia autoritativa vive en un mazo, no se puede consultar ni diferenciar. Mitigación: el árbol de OKR se redacta en markdown bajo control de versiones.
3. Historias de valor desconectadas de los specs. Cuando la narrativa no enlaza a un ancla del spec, ingeniería optimiza otra cosa. Mitigación: /value-story se niega a cerrar sin un enlace al spec.
4. Telemetría ignorada post-lanzamiento. Declarar éxito en la fecha de envío es un hábito, no una medición. Mitigación: el dashboard del portafolio marca cualquier KR con telemetría obsoleta.
5. Casos de negocio en hojas de cálculo. Los archivos estáticos derivan de la realidad. Mitigación: los casos de negocio viven en markdown con hooks que validan la completitud de la plantilla.

KPIs y métricas de impacto

KPI	Línea base	Meta	Medición
Cobertura de OKR, iniciativas mapeadas a un KR	55 por ciento	100 por ciento	Consulta del dashboard del portafolio
KPIs con línea base y fuente de medición	40 por ciento	100 por ciento	Linter de spec de KPI en GitHub Actions
Tiempo desde la actualización de la estrategia hasta el árbol de OKR	3 semanas	< 3 días	Timestamps de PR de GitHub
Tiempo de ciclo de financiamiento, de propuesta a compuerta	6 semanas	< 2 semanas	Timestamps de PR de caso de negocio
Tasa de KR en trayectoria a mitad de trimestre	Desconocida	> 75 por ciento	Consulta de telemetría del Azure MCP
Resultado post-lanzamiento verificado contra la meta	20 por ciento	100 por ciento	Application Insights vs meta

Madurez en cuatro niveles

Nivel	Nombre	Marcadores
L1	Manual	OKRs en diapositivas, KPIs en hojas de cálculo, historias de valor verbales
L2	Asistido	Copilot usado para pulir prosa de OKR, sin artefactos legibles por máquina
L3	Aumentado	Agente KPI Translator, cuatro slash prompts, instrucciones con alcance, Azure MCP para telemetría, KPIs con líneas base
L4	Autónomo	Kit completo de primitivas, hooks forzados, dashboard del portafolio en vivo, digest a liderazgo automatizado, verificación post-lanzamiento estándar

Integración con otras personas

• Desde Enterprise Architect: escaneo de capacidades y principios de la constitución que restringen el árbol de OKR
• Hacia Product Owner: OKRs y KPIs aprobados a los que el spec debe engancharse vía /link-acceptance
• Hacia Requirements Engineer: resultados ligados a KPI que informan los gap scans y la trazabilidad
• Hacia Engineering Manager: árbol de OKR que dirige la planificación de capacidad y la asignación de squads
• Hacia SRE: SLOs alineados con KPIs cara al cliente para inversión en confiabilidad
• Hacia Release Manager: historia de valor como columna vertebral de la narrativa de release y la comunicación a stakeholders

Glosario

• OKR: Objectives and Key Results. Un marco trimestral de fijación de metas con resultados medibles.
• KPI: Key Performance Indicator. Una métrica a nivel de producto con línea base, meta, fuente y cadencia.
• KR: Key Result. Un componente medible de un objetivo, amarrado a uno o más KPIs.
• Historia de valor: una narrativa de una página que enlaza un caso de negocio a un ancla del spec y un KPI.
• Caso de negocio: documento estructurado con secciones de costo, beneficio, riesgo y supuestos usado en compuertas de financiamiento.
• Dashboard del portafolio: vista generada que agrega todos los OKRs, KPIs y estados de iniciativas.

Referencias

• Azure Monitor documentation — plataforma de telemetría para la medición de KPI
• Application Insights documentation — telemetría de aplicación para la verificación de resultados
• GitHub Projects documentation — seguimiento del portafolio para iniciativas etiquetadas por OKR
• Azure Well-Architected Framework — pilares de costo, confiabilidad y excelencia operativa para casos de negocio
• GitHub Copilot documentation — fuente autoritativa para features de Copilot, agent mode e instructions