M4 · Stakeholder Engagement, Lifecycle & GTM — Resumen de estudio

Curso 4 de 5. Cubre el trabajo "en la sala" con stakeholders: discovery, presentación de tradeoffs, feedback loop, documentación para el handoff, entry point y outcome document.

Ciclo de vida: discovery → design → handoff → monitoring → iteration.

⚠️ Las partes marcadas Partner Track (demo, joint scoping con Applied AI, objeciones, reuse como IP) no entran en el examen de Architect.

1. Discovery: una elicitación estructurada, no una charla

Filtro de 3 pasos:

1. Escuchar el objetivo de negocio.
2. Traducir a requisitos, supuestos y restricciones no resueltas.
3. Escribirlo antes de que la conversación avance.

El movimiento central es la traducción: una preferencia esconde una restricción.

• "Seamless", "fácil", "rápido", "intuitivo" → señal de que falta discovery.
• Pregunta qué lo rompería, qué no debe notar nunca el usuario y qué debe seguir siendo cierto cuando algo falla.
• Ejemplo: "seamless" → p95 objetivo + sin re-captura de datos + excepciones a un humano sin exponer errores técnicos + todo dentro de una sola app.

4 categorías de preguntas:

1. Must do: capacidades como resultados de negocio (Claude / sistema / humano).
2. Must not do: límites, acciones prohibidas, casos que van a un humano. Nadie los ofrece; hay que preguntarlos.
3. Must cost: latencia, costo por interacción, volumen.
4. Must prove: evidencia y obligaciones de prueba (en entornos regulados).

Resultado = translation table: declaración del stakeholder · restricción implícita · decisión de arquitectura requerida · supuesto documentado.

Requirement vs assumption: un requisito se rastrea a algo que el stakeholder dijo. Un supuesto sin fuente es el más peligroso, porque nadie recuerda haberlo decidido.

⚠️ Watch out: "notas clínicas desde dictado = augmented pattern, prototipo la próxima semana". El "quick check" era una autorización clínica obligatoria, había PHI en el contexto y dos estados con reglas de retención distintas. Un boceto plausible detiene las preguntas. Termina las 4 categorías antes de proponer.

Checkpoint: supuesto no documentado = D (retención de transcripciones por 60 días); ninguna declaración del stakeholder lo respalda.

2. Presentar tradeoffs (y GTM)

Tu trabajo no es resolver el tradeoff antes de la reunión, sino hacer posible la decisión.

Marco de decisión:

1. ¿Qué ganamos?
2. ¿Qué cedemos?
3. ¿Cuánto cuesta revertirlo cuando el sistema ya depende de esta decisión? ← lo que casi todos omiten y lo que cambia la reunión.
4. (En entornos regulados) ¿Qué le hace a nuestra postura de compliance?

• Presenta un paquete: opciones, criterios, recomendación y riesgos remanentes. El stakeholder acepta una decisión que tendrá que defender ante su liderazgo.
• Description (competencia 4D) con stakeholders:
  • Empieza por el resultado de negocio.
  • Expón las limitaciones con honestidad.
  • Anticipa la "prueba ante pares": el stakeholder debe salir con su justificación.

Objeciones técnicas (3 tipos):

• Capability: ¿puede hacerlo?
• Governance/compliance: ¿es confiable y demostrable?
• Design-choice: ¿por qué esto y no aquello? Se responde con el tradeoff y el costo de la alternativa.

Partner Track (no entra en el examen):

• Demo por escenario (no de capacidades): flujo reconocible, 1–2 limitaciones nombradas de antemano como límites intencionales, narrativa acordada con ventas, datos con forma realista (anonimizados).
• Joint scoping con Applied AI: llega con requisitos documentados, patrones candidatos con sus tradeoffs y una lista corta de preguntas abiertas.

⚠️ Watch out: "4 centavos por interacción", aprobado. Seis semanas después, una línea de cinco cifras al mes. "Aprobé una dirección, no un número." No se habló del costo de revertir ni del caching. Una presentación precisa puede responder la pregunta equivocada.

Checkpoint: recomendar A (logging incluido). A la opción B le falta C: el costo de revertir (restaurar el logging cuando el diseño ya depende de la ganancia de latencia).

3. Feedback loop y SLA

• Un sistema en vivo deriva sin monitoreo activo. La calidad se erosiona poco a poco.
• El feedback loop es una capa de decisión sobre la observabilidad: Signals → Triage → Decide → Act → Review.
• El SLA nombra 3 cosas: qué se mide, qué cuenta como incumplimiento y qué pasa entonces. Los umbrales salen de algo tangible:
  • Latencia ← expectativa de experiencia de usuario.
  • Disponibilidad ← criticidad para el negocio.
  • Calidad ← evals y criterios de aceptación.
• El costo es lo que más se rompe tras el lanzamiento: producción suele ser 10–100× el piloto. Da un forecast de consumo y una postura de control de gasto (caching, tiering, alertas) antes de la primera factura.
• En entornos regulados, hay revisiones por calendario aunque nada falle (auditoría de outputs, confirmación de residencia). Se definen antes del lanzamiento.

Governance table (existe antes del lanzamiento):

⚠️ Watch out: el eval score bajó desde la semana 4 sin que se disparara ninguna alerta (el error rate estaba plano). La revisión trimestral lo detectó en la semana 12. El monitoreo no es un feedback loop: faltaba la regla que conecta drift lento → trigger → dueño.

Checkpoint (triage):

• Interno: 1 (p99 +40 ms dentro del presupuesto), 8 (tokens por tráfico estacional conocido).
• Architect: 2 (eval cayendo 3 semanas).
• Stakeholder: 3 (confirmación de residencia), 5 (costo cruzó el umbral), 7 (auditoría trimestral).
• Ruido: 4 (request malformado de un cliente conocido), 6 (retry que tuvo éxito), 9 (plantilla nueva con error rate plano).

4. Documentación que sobrevive a tu ausencia (handoff)

Un documento, 3 lectores:

• Handoff recipient: decisiones + alternativas rechazadas + por qué. Sin eso revertirá lo correcto por una razón equivocada.
• Compliance reviewer: obligación → control → dueño → evidencia (el control register vivo).
• Architect que regresa: decisiones fechadas, supuestos etiquetados como supuestos y pendientes con dueño y criterio de cierre.

Prueba de completitud: ¿un Architect competente que no estuvo en la sala puede hacer un cambio seguro después de leerlo?

Checklist: Decision (con fecha) · Rejected alternatives · Tradeoff named (gana, cede, revertir) · Owner · Evidence artifact · Audit-ready status.

⚠️ Watch out: diagrama sin justificación. El sucesor cambió la context strategy por rendimiento y rompió la residencia de datos. "El diagrama muestra el qué y perdió el porqué." Si no se escribe, se va contigo.

Checkpoint (plano):

• Handoff · intention: diagrama, decision log con rationale, assumption register.
• Handoff · evidence: runbook.
• Compliance · evidence: control register con enlaces a evidencia, resumen de resultados de pruebas.

5. Entry point en producción multi-plataforma y outcome document

En multi-plataforma aparecen problemas nuevos:

• Los IDs de modelo difieren entre rutas.
• Las features llegan con retraso en las CSP.
• La región en Bedrock y Vertex debe configurarse explícitamente: usar el endpoint global por defecto rompe la residencia.

Entry-point-responsibility map: qué entry point hace qué tarea y por qué, antes de escribir código de integración. Evita que una ruta absorba tareas que no le tocan.

Outcome document (6 campos):

1. Caso de uso con límite de alcance.
2. Métrica antes.
3. Métrica después (misma definición).
4. Control que lo hace auditable.
5. Dueño de la medición.
6. Potencial de reuso (Partner Track).

⚠️ Watch out: "40k requests al mes, menos de 2 s, menos de 0.5% de errores". El CFO preguntó qué ahorró y no había respuesta. Las métricas fáciles de exportar casi nunca justifican el costo. Sin la métrica "antes" no hay historia; sin el control, el "después" es una afirmación.

Checkpoint: AWS + strict + compliance → Bedrock en región explícita (primario) + Direct API para back-end no regulado (secundario). Campos: Control in place (auditable) + Measurement owner.

Ejercicio acumulativo (red de salud, 2 nubes, el Architect sale)

1. Must-prove: obligación de privacidad de salud con audit trail. Fila: registro auditable de cada nota revisada por un clínico, trazable a la interacción.
2. Tradeoff: recortar logging gana latencia y cede el audit detail. Revertirlo implica rediseñar la capa de interacción, y el periodo sin logs es una exposición de compliance que hay que divulgar.
3. Fila de gobierno: auditoría de outputs trimestral por calendario, sin importar las métricas. Dueño: compliance lead.
4. Fila crítica del decision log: ejecución en región vía Bedrock. Alternativa rechazada: endpoint global.
5. Primario: Bedrock con la región fijada explícitamente en el cliente. Secundario: Direct API para lo no regulado.
6. Outcome: tiempo de dictado → nota autorizada, antes y después. Control: log de autorización clínica con timestamp.
7. Gate de fase: el outcome document. En la semana 4 todavía no se cumple (falta runtime para la métrica "después"). Nombra al dueño, confirma el logging y agenda la entrega.

Para recordar

1. Discovery en 4 categorías; cada preferencia se traduce a una restricción y queda como fila con su supuesto etiquetado.
2. Todo tradeoff en 3 elementos, incluido el costo de revertir.
3. Una governance table antes del lanzamiento: señal → trigger → dueño → acción, incluidos los checkpoints por calendario.
4. Documenta el porqué y lo rechazado; prueba: un extraño puede hacer un cambio seguro.
5. Entry-point-responsibility map con región explícita; outcome document con antes/después de negocio y un control auditable.