Fundamentos de Colaboración con Stakeholders

10 ejemplos para empezar con Producto y Stakeholders - 7 básicos y 3 intermedios.

Estos patrones ayudan a los tech leads de Go integrados a escribir especificaciones, estimaciones y actualizaciones de estado que los propietarios de producto, diseño y ejecutivos puedan utilizar sin necesidad de leer go.mod.

Prerrequisitos

• Toolchain de Go 1.26.x localmente (go version) cuando los ejemplos hagan referencia a módulos o go fix.
• Un espacio de documentación compartido (Notion, Confluence o docs/ en el repositorio) donde los stakeholders puedan comentar.
• Acuerdo sobre quién es el responsable del alcance (producto), las fechas (conjunto) y la viabilidad técnica (ingeniería).

Ejemplos Básicos

1. Resumen de Especificación en un Párrafo

Enmarca una funcionalidad en lenguaje de resultados antes de cualquier detalle de API.

## Exportar informes (T3)
 
**Resultado:** Usuarios de pago descargan informes PDF en menos de 2s p99.
**Alcance:** Clientes de facturación existentes; PDF máximo de 50MB.
**Fuera de alcance:** Entrega programada por correo electrónico (T4).
**Responsable de ingeniería:** @alex (payments-api, Go/chi).

• Empieza con un resultado medible, no con la implementación.
• Nombra el servicio y la pila tecnológica para que los revisores sepan dónde aterrizará el código.
• Lo explícitamente fuera de alcance evita la ampliación del alcance en la planificación de sprints.

Relacionado: De Requisitos a Especificaciones de Servicios Go - flujo completo de especificaciones

2. Historia de Usuario con Criterios de Aceptación Verificables

Reescribe historias vagas en comprobaciones verificables.

**Historia:** Como administrador de facturación, exporto una factura en PDF.
 
**Aceptación:**
- Dado un ID de factura pagada, cuando hago GET /v1/invoices/{id}/pdf, entonces HTTP 200 y `application/pdf`.
- Dada una factura no pagada, cuando exporto, entonces HTTP 403 con código de error estable `invoice_unpaid`.
- Latencia p99 ≤ 2s a 100 RPS en staging.

• Cada criterio se mapea a una prueba automatizada o a un umbral de carga.
• Los códigos de error estables son importantes para los SDKs del cliente y las herramientas de soporte.
• Los criterios de latencia conectan los SLOs de ingeniería con las promesas del producto.

3. Boceto de API en Estilo OpenAPI

Los stakeholders revisan las rutas; los ingenieros implementan basándose en los campos.

paths:
  /v1/invoices/{id}/pdf:
    get:
      summary: Descargar factura PDF
      parameters:
        - name: id
          in: path
          required: true
          schema: { type: string, format: uuid }
      responses:
        "200": { description: Bytes PDF, content: { application/pdf: {} } }
        "403": { description: invoice_unpaid }

• El formato YAML o de tabla es suficiente para la revisión; la generación de código vendrá después.
• El formato UUID evita tipos de ID ambiguos entre servicios.
• Los códigos de respuesta documentados al principio reducen sorpresas en la integración.

4. Estimación por Tallas con Supuestos

Da al producto un rango, no un número único falso.

| Talla | Calendario | Supuestos |
|----------|----------|-------------|
| S | 3-5 días | Reutilizar librería PDF existente; sin tablas nuevas |
| M | 2 semanas | Nuevo trabajo asíncrono + almacenamiento S3 |
| L | 4+ semanas | SDK de terceros desconocido; se requiere spike |

• Los supuestos son el contrato; cambiarlos desencadena una reestimación.
• Señala explícitamente las incógnitas (fila L) en lugar de ocultarlas en el margen.
• El tiempo de calendario incluye revisión y QA, no solo horas de codificación.

5. Línea de Riesgo en Cada Estimación

Adjunta riesgos nombrados que los stakeholders pueden aceptar o mitigar.

**Riesgos:**
1. `github.com/jung-kurt/gofpdf` sin mantenimiento - puede necesitar directiva de reemplazo (2d).
2. Staging carece de carga PDF similar a producción - riesgo de rendimiento hasta prueba de carga (1d).
**Buffer:** +20% en la estimación M hasta que el spike #1 se cierre.

• Los buffers porcentuales vinculados a riesgos nombrados se leen como profesionales, no como especulación.
• El estado de mantenimiento del módulo es un riesgo específico de Go que el producto debería ver.
• Los resultados del spike actualizan la tabla de estimación la semana siguiente.

6. Bloque de Estado Semanal (Enviado / Próximo / Bloqueado)

Una pantalla para audiencias mixtas.

## Payments API - semana del 14/07/2026
 
**Enviado:** Exportación de factura PDF detrás del flag de funcionalidad `export_pdf` (staging).
**Próximo:** Prueba de carga 100 RPS; habilitar canary del 10% en producción el jueves.
**Bloqueado:** Revisión legal sobre retención de PDF almacenado (esperando 3d).
**Riesgo:** Ninguno nuevo; en camino para GA el 21 de julio si legal aprueba el lunes.

• "Enviado" se vincula a algo demostrable o medible.
• "Bloqueado" utiliza el responsable y el tiempo de espera, no la culpa.
• La línea de riesgo expone el impacto en el cronograma en lenguaje claro.

7. Nota de Trade-off de Go Amigable para Stakeholders

Explica una elección técnica sin un tutorial de lenguaje.

**Decisión:** Trabajo asíncrono de PDF en lugar de HTTP síncrono.
 
**Por qué:** Objetivo p99 de 2s; la generación tarda 5-15s para facturas grandes.
**Trade-off:** Los usuarios consultan o reciben webhook; UX ligeramente más complejo.
**Nota Go:** El worker utiliza el binario `cmd/worker` existente; sin nuevo despliegue.

• El formato de trade-off imita las consecuencias de ADR sin la sobrecarga formal de ADR.
• "Sin nuevo despliegue" habla del costo operativo que el producto entiende.
• El impacto en la UX se declara por adelantado para que el diseño pueda planificar la UI de consulta.

Ejemplos Intermedios

8. Tabla de Estimación para Trabajo de Actualización de Módulo

Las tareas de plataforma reciben el mismo rigor que las funcionalidades.

| Elemento de trabajo | Esfuerzo | Dependencia |
|-----------|--------|------------|
| Actualizar `go` a 1.26 en 4 módulos | 3d | Actualización de imagen CI |
| `go fix` + segunda pasada | 2d | desarrolladores con 1.26 localmente |
| Remediación de `govulncheck` | 1-5d | triaje de seguridad |
| Canary 10% + métricas GC | 2d | dashboard SRE |
**Total:** 8-12d de ingeniería + 3d de espera de calendario

• El número de módulos y el acoplamiento de CI son visibles para los gerentes de programa.
• El tiempo de espera es de calendario, no de días de ingeniero; indicar ambos.
• Las métricas GC son importantes para los cambios predeterminados de Go 1.26 Green Tea.

Relacionado: Planificación de Actualizaciones de Versión de Go en un Monorepo - manual de despliegue

9. Esqueleto de Nota de Lanzamiento Interno

Comunica cambios de plataforma que rompen la compatibilidad a los propietarios de servicios.

# Lanzamiento de plataforma: shared/auth/v3
 
**Efectivo:** 01/08/2026
**Acción requerida:** Actualizar dependencia a v3.1.0; ejecutar `go test ./...`
**Ruptura:** `AuthClient.Verify` ahora requiere `context.Context`
**Migración:** `go fix` no está disponible; ver fragmento en el apéndice
**Soporte:** Horario de oficina #go-platform martes 10am

• La fecha de efectividad y los verbos de acción reducen los incidentes de "no lo sabíamos".
• Los cambios de firma que rompen la compatibilidad son hechos específicos de Go que los consumidores necesitan conocer pronto.
• El canal de soporte reduce el miedo en equipos con poca fluidez en módulos.

Relacionado: Notas de Lanzamiento para Cambios Internos de Plataforma Go - plantilla completa

10. Diapositiva de Priorización: Funcionalidad vs Plataforma

Haz visibles los trabajos en competencia en una sola vista.

| Iniciativa | Impacto en el cliente | Riesgo si se pospone | Voto |
|------------|-----------------|------------------|------|
| Exportar PDF (funcionalidad) | Alto - bloqueo de renovación | Medio | Enviar Jul |
| Actualización Go 1.26 (plataforma) | Bajo directo | Alto - ventana de CVE | Enviar semana 1 de Ago |
| Línea base de linting (plataforma) | Ninguno directo | Medio - arrastre de revisión | T4 |
 
**Recomendación:** Pista paralela: 1 ingeniero en plataforma semana 1 de Ago; equipo de funcionalidad sin cambios.

• La columna "Riesgo si se pospone" habla mejor a los ejecutivos que "deuda técnica".
• La recomendación muestra la realidad de la dotación de personal, no un paralelismo falso.
• El impacto en el cliente se mantiene honesto para las filas de plataforma (a menudo indirecto).

Relacionado: Priorización de Funcionalidades vs Trabajo de Plataforma en Go - patrones de negociación

Relacionado

• Los Tech Leads Unen Ingeniería y Negocio - rol y modelo mental
• Mejores Prácticas de Colaboración con Stakeholders - hábitos revisables
• Comunicando Trade-offs de Go a Stakeholders No Técnicos - latencia, despliegues, dotación de personal

Versiones de Stack: Esta página fue escrita para Go 1.26.x (predeterminado GC Green Tea, modernizadores go fix - verificar parche en la compilación), chi (última versión - verificar en la compilación), gin (última versión - verificar en la compilación), echo (última versión - verificar en la compilación), google.golang.org/grpc (última versión - verificar en la compilación), sigs.k8s.io/controller-runtime (última versión - verificar en la compilación), kubebuilder (última versión - verificar en la compilación), tinygo (última versión - verificar objetivos de placa en la compilación), wazero (última versión - verificar en la compilación) y golangci-lint (última versión - verificar conjunto de linters en la compilación).

NzA2MjAyfDU2NG9pZ2N8b2kuc2VkaXVnZWRvYw==