madurez-producción

Madurez de Producción (MVP → Producción)

Objetivo: comunicar al propietario, con evidencia, si un producto está listo para usuarios reales, qué bloquea el lanzamiento, y el conjunto mínimo de trabajo para cerrar las brechas. Adaptado al producto — nunca una lista genérica de 200 elementos.

Reglas estrictas

1. Evidencia o es Desconocido. Cada elemento es PASS / GAP / N/A / UNKNOWN, y PASS necesita una prueba (ruta de archivo, configuración, ejecución de CI, dashboard, enlace a documentación). Nunca marques PASS basado en una afirmación del README.
2. Adaptar por nivel. No exijas DR multi-región para una beta de 50 usuarios. Etiqueta cada brecha con el nivel en el que se requiere.
3. Verificar reglas de plataforma en vivo. Las reglas de tiendas de aplicaciones, OAuth, pagos y remitentes de correo electrónico cambian anualmente. Antes de citar un requisito de una tienda/proveedor, consulta la documentación oficial del proveedor (búsqueda web) y cita el enlace + la fecha de verificación.
4. Reutilizar, no duplicar. Si pm-ai-shipping:ship-check, security-audit-static, performance-audit-static, o derive-tests están disponibles, ejecútalos para obtener evidencia a nivel de código e integra los resultados. Esta habilidad posee todo lo que rodea al código.
5. Salida clara. El propietario lee un scorecard de una página; los detalles van en el apéndice y el backlog.
6. Gobernanza dentro del flujo de trabajo, no al final. Prefiere verificaciones que se ejecuten donde ocurre el trabajo (CI, plantillas de PR, pre-commit, barreras de protección en el producto) en lugar de reuniones de revisión añadidas antes del lanzamiento. Una puerta de entrada que solo se ejecuta al final se convierte en el cuello de botella.
7. Enviado ≠ adoptado. La mayoría de los productos se estancan después del lanzamiento porque las personas y los procesos no cambiaron, no porque el código fallara. La preparación incluye el plan de adopción (dominio 13), no solo el sistema.

Niveles de preparación

Nivel	Significado	Barrera típica
T1 Beta pública	Usuarios reales, baja escala, puede tolerar algo de inactividad	Sin fugas de secretos, autenticación sólida, copias de seguridad que se restauran, errores rastreados, páginas legales, reversión funciona
T2 GA	Usuarios de pago, expectativas de SLA	+ SLOs/alertas/guardia, pruebas de carga, runbooks, ruta de soporte, respaldos de integración
T3 Empresarial / regulado	Contratos B2B, PHI/PCI/menores, auditorías	+ SSO/SCIM, registros de auditoría, DPA/BAAs, prueba de penetración, controles SOC 2 / HIPAA, simulacros de DR

Flujo de trabajo

Paso 0 — Perfil del producto (preguntar una vez, agrupar las preguntas)

Capturar: nivel objetivo y fecha de lanzamiento; la métrica de éxito única y su objetivo (qué hace que este lanzamiento sea un éxito, cómo se mide, para cuándo); propietario designado y partes interesadas para la aprobación (producto, ingeniería, seguridad, legal/privacidad, soporte, marketing — señalar legal/privacidad desde el día uno si hay datos personales, salida de IA o usuarios regulados involucrados); superficies (web, iOS, Android, escritorio, API pública, CLI, extensión de navegador, herramienta/plugin/biblioteca para desarrolladores distribuida a otros desarrolladores); alojamiento/stack; tipos de datos (PII, PHI, pago, datos de menores); usuarios (B2C/B2B), regiones (EE.UU./UE/otras); funciones de IA/LLM; pagos; cada integración externa (APIs consumidas, webhooks recibidos, mercados/tiendas de aplicaciones donde se publica, SSO/IdPs). Escanea primero el repositorio (manifiestos de paquetes, plantillas de entorno, importaciones de SDK) para rellenar previamente la lista de integraciones, luego pregunta al propietario solo para confirmar/completar las brechas.

El perfil selecciona qué módulos se aplican. Regístralo al principio del informe.

Paso 1 — Recopilar evidencia

Repositorio (código, configuración de CI, IaC, plantillas de entorno, migraciones), paneles de alojamiento/conectores si están disponibles (Vercel, Railway, Supabase, Render, etc.), rastreador de problemas, documentación existente. Ejecutar las habilidades de auditoría disponibles. Anotar lo que no se pudo inspeccionar → UNKNOWN.

Paso 2 — Evaluar dominios principales (siempre) + módulos aplicables

Puntuar cada elemento. Gravedad: BLOQUEANTE (no se puede lanzar en el nivel objetivo) / ALTA (corregir dentro de las primeras 2 semanas) / POSTERIOR.

Paso 3 — Entregar

1. Scorecard (1 página): Aprobado / Aprobado-con-condiciones / No-aprobado; conteo de bloqueantes; tabla RAG por dominio; 5 riesgos principales en lenguaje sencillo.
2. Backlog de brechas: un ticket por brecha — título, por qué es importante, criterio de aceptación, evidencia necesaria para cerrar, nivel, gravedad, tamaño aproximado (S/M/L). Si Linear/Jira/GitHub Issues está conectado, ofrecer crearlos como un proyecto/hito; si no, una tabla.
3. Kit de endurecimiento (bajo petición): generar puerta de calidad de CI específica del repositorio, archivo de reglas de agente (CLAUDE.md/.cursorrules), .env.example, stubs de runbook — construidos a partir de lo que el repositorio realmente usa, no de una plantilla genérica.
4. Modo de re-ejecución: en ejecuciones posteriores, diferenciar del último informe y mostrar solo lo que ha cambiado.

Dominios principales (siempre evaluados)

1. Secretos y configuración — sin secretos en código o historial de git (gitleaks/trufflehog sobre todo el historial); .env ignorado, .env.example presente; secretos de producción en el almacén de secretos de la plataforma; claves separadas para dev/staging/prod; plan de rotación y quién puede rotar; pasos de respuesta ante fugas de claves.

2. Identidad y acceso — proveedor de autenticación probado o biblioteca bien revisada (sin criptografía hecha a mano); autorización del lado del servidor en cada ruta de datos (verificar IDOR / filtros de tenant faltantes / RLS permisivo); tiempos de vida de sesión/token y revocación; límites de velocidad en inicio de sesión, registro, restablecimiento, OTP; MFA para administradores; cuentas de servicio con mínimos privilegios; acciones de administrador registradas.

3. Seguridad perimetral y de aplicaciones — HTTPS + HSTS; encabezados de seguridad (CSP, frame-ancestors, etc.); CORS estricto; validación de entrada en los límites; límites/verificaciones de tipo en carga de archivos; protecciones SSRF en buscadores de URL; WAF/protección contra bots en T2+; escaneo de dependencias + lockfiles; SAST en CI; SBOM y verificación de licencias en T3.

4. Datos — copias de seguridad automatizadas y una restauración probada (registrar el tiempo de restauración real); recuperación a un punto en el tiempo donde la base de datos lo soporte; migraciones compatibles hacia atrás (expandir → migrar → contraer); staging sin PII de producción sin procesar; retención + ruta de eliminación (la eliminación de cuenta de usuario realmente elimina en DB, almacenamiento, registros, proveedores); cifrado en reposo/en tránsito por defecto confirmado.

5. Confiabilidad — tiempos de espera en cada llamada saliente; reintentos con retroceso + jitter solo en operaciones idempotentes; claves de idempotencia para pagos/webhooks/trabajos; trabajo en segundo plano en una cola duradera; degradación elegante cuando una dependencia está caída; SLOs definidos (disponibilidad, latencia) en T2+; prueba de capacidad/carga al pico esperado ×3 en T2+.

6. Observabilidad — seguimiento de errores con etiquetado de versión (ej., Sentry); registros estructurados con IDs de solicitud/seguimiento y redacción de PII; métricas clave (tasa, errores, duración) por endpoint; verificaciones de tiempo de actividad desde fuera; alertas basadas en síntomas enrutadas a un humano que realmente las verá; paneles para el día del lanzamiento.

7. CI/CD y lanzamiento — verificaciones requeridas en main (lint, typecheck, pruebas, escaneo de secretos, auditoría de dependencias); entorno de vista previa/staging; reversión con un clic probada una vez; feature flags para funciones riesgosas; migraciones ejecutadas de forma segura en el despliegue; notas de versión/changelog; protección de ramas.

8. Pruebas — pruebas en rutas críticas (autenticación, pagos, escrituras de datos, permisos) por encima de un % de cobertura; pruebas de integración contra una base de datos real; pruebas de hum humo E2E en los recorridos principales del usuario ejecutadas post-despliegue; pruebas de contrato o fixtures grabados para APIs externas.

9. Rendimiento y coste — Core Web Vitals / presupuestos de inicio de la aplicación; verificación de N+1 e índices faltantes; caché/CDN; alertas de gasto por proveedor y límites estrictos (nube, LLM, SMS, correo electrónico); coste estimado por usuario activo; escenarios de abuso que pueden aumentar la factura (spam de registro, bucles de prompts de LLM, bombeo de SMS).

10. Operaciones y soporte — propietario/guardia designado incluso si es una sola persona; proceso de incidentes (gravedad, comunicaciones, postmortem); runbooks para los 5 modos de fallo principales; página de estado en T2+; canal de soporte y SLA; herramientas de administración para tareas de soporte comunes (para que las correcciones no necesiten SQL en bruto).

11. Legal y confianza — Términos, Política de Privacidad que coincida con los flujos de datos reales; consentimiento de cookies donde sea necesario (UE/Reino Unido); DPAs con proveedores que procesan datos personales; lista de subprocesadores en T3; objetivo de accesibilidad (WCAG 2.2 AA) y una auditoría básica; cumplimiento de licencias de código abierto; autorización de marca/nombre para el nombre del producto.

12. Preparación del producto — análisis sobre el embudo de activación (con consentimiento); incorporación y estados vacíos; correos electrónicos transaccionales entregables (ver módulo Web); documentos de ayuda/FAQ; precios/facturación en vivo si es de pago; bucle de retroalimentación; interruptor de apagado para funciones problemáticas.

13. Adopción y modelo operativo — métrica de éxito y criterios de salida del piloto escritos antes del lanzamiento (qué lo mueve de 'piloto' a 'escalar' o 'matar'); flujo de trabajo de lanzamiento documentado con aprobadores designados por nivel de riesgo (cambios de bajo riesgo = un revisor, alto riesgo = más) y un tiempo de respuesta acordado para que la aprobación no se estanque; comunicación de lanzamiento (qué cambia, qué no, límites conocidos); grupo de primeros usuarios/campeones y una forma de escucharlos; ayuda en el producto, plantillas o ejemplos para que los usuarios aprendan dentro de la herramienta; bucle de retroalimentación (comentarios de usuarios + métricas de uso) con una cadencia de revisión (ej., 30/60/90 días, luego trimestralmente); propietario para el soporte continuo a medida que crece el uso.

Módulos condicionales

M1. Integraciones que consumes (una hoja por proveedor) — cuenta/producción/claves (no sandbox) y quién posee la cuenta; límites de velocidad y cuotas vs pico esperado; techo de precios y alertas; tipo de autenticación y renovación de tokens; verificación de firma de webhook, protección contra repetición, manejadores idempotentes, reintento/retroceso y cola de mensajes fallidos; versión de API fijada + vigilancia de obsolescencia (suscribirse al changelog); tiempo de espera + interruptor de circuito + respaldo visible para el usuario; página de estado del proveedor suscrita; Términos permiten tu uso (reventa, entrenamiento de IA, scraping); plan de salida — posees tus datos/prompts/config y puedes exportarlos, el contrato no tiene bloqueo de varios años sin cláusulas de rescisión; residencia de datos/DPA; requisitos de verificación/revisión de aplicaciones OAuth (ej., ámbitos sensibles/restringidos de Google, verificación de publicador de Microsoft, revisión de aplicaciones de Slack/Zoom) — verificar las reglas actuales en vivo.

M2. API pública que expones — OpenAPI/especificación publicada; versión y política de obsolescencia; API keys/OAuth con ámbitos, rotación, revocación; límites de velocidad y cuotas por clave; paginación, claves de idempotencia en POST; formato de error consistente; entorno sandbox; webhooks que envías están firmados, reintentados y reproducibles; documentación para desarrolladores + changelog; medición de uso si se factura.

M3. Móvil y tiendas de aplicaciones — Verificar cada una contra la documentación oficial actual antes de citar:

• Apple: Guías de Revisión de la App Store; etiquetas de privacidad nutricional coinciden con la recopilación real; manifiesto de privacidad incluyendo SDKs de terceros; eliminación de cuenta en la aplicación si se pueden crear cuentas; regla de 'Iniciar sesión con Apple' al ofrecer inicio de sesión de terceros; reglas de IAP para bienes digitales; pruebas externas de TestFlight; cumplimiento de exportación.
• Google Play: fecha límite del nivel de API objetivo actual; formulario de seguridad de datos; requisito de pruebas cerradas para nuevas cuentas de desarrollador personales; Play App Signing y custodia de la clave de carga; enlace web de eliminación de cuenta.
• Ambos: informes de fallos; mecanismo de actualización forzada/suave para cambios de API que rompen la compatibilidad; enlaces profundos/universales; credenciales de push propiedad de la cuenta de la empresa; activos de la ficha de la tienda, clasificación por edad, URL de soporte, URL de privacidad; margen de tiempo para rechazos de revisión en el plan de lanzamiento (planificar días, no horas).

M4. Web y correo electrónico — dominio personalizado, DNS propiedad de la cuenta de la empresa, bloqueo del registrador + renovación automática; fundamentos de SEO (títulos, sitemap, robots, etiquetas OG) si la descubribilidad importa; páginas 404/500; autenticación de remitente de correo electrónico SPF, DKIM, DMARC y cancelación de suscripción con un clic para correo masivo (verificar las reglas actuales de remitentes de Gmail/Yahoo); manejo de rebotes/quejas; flujos separados de correo transaccional vs marketing.

M5. Funciones de IA / LLM — abstracción de proveedor o puerta de enlace con modelo de respaldo; tiempos de espera y reintentos en 429/5xx; salida estructurada validada por esquema (Zod/Pydantic); conjunto de evaluación de casos reales ejecutado en CI antes de cambios de prompt/modelo; defensas contra inyección de prompts donde el modelo lee contenido no confiable o puede llamar a herramientas (herramientas con mínimos privilegios, confirmación humana para acciones destructivas); límites de coste por usuario y globales; manejo de PII y configuraciones de retención de datos del proveedor; fechas de obsolescencia de modelos rastreadas; divulgación de IA a los usuarios cuando sea necesario; barreras de calidad/marca en la salida generada (términos prohibidos, verificaciones de tono, revisión humana escalada por riesgo); la interfaz informa a los usuarios de los límites ('verifica los hechos', fuentes mostradas para afirmaciones); cambios de prompt/modelo probados primero en un sandbox con datos históricos o de muestra, luego implementados en una pequeña parte del tráfico antes de todos; revisión programada (ej., semestral) de modelo/proveedor.

M6. Pagos — pago alojado para minimizar el alcance de PCI; estado impulsado por webhook (nunca confiar en la redirección del cliente); cumplimiento idempotente; reembolsos, disputas, dunning; recaudación de impuestos por región; reloj de prueba/sandbox cubierto; conciliación de ingresos.

M7. Datos regulados — PHI → HIPAA: BAA con cada proveedor que toque PHI, registro de acceso, mínimo necesario. PCI más allá del pago alojado → alcance de SAQ. Menores → COPPA/barrera de edad. Usuarios de UE/Reino Unido → base legal del GDPR, proceso de DSAR, transferencias. California → CCPA/CPRA. Señalar para revisión legal; no dar conclusiones legales.

M8. B2B / empresarial — aislamiento de tenant probado (prueba de acceso entre tenants); SSO (SAML/OIDC) y SCIM en T3; exportación de registros de auditoría; modelo de roles/permisos; exportación de datos; paquete de cuestionario de seguridad (arquitectura, subprocesadores, prueba de penetración, políticas); SLA de tiempo de actividad y créditos.

M9. Mercados donde publicas — Chrome Web Store, directorios de aplicaciones de Slack/Teams/Zoom, Shopify, registros de MCP/plugins, etc.: requisitos de listado, plazos de revisión, justificación de permisos, divulgaciones de privacidad — verificar en vivo.

M10. Herramientas para desarrolladores, bibliotecas, plugins y código abierto — licencia elegida deliberadamente (copyleft como AGPL puede bloquear la adopción empresarial; permisiva como MIT/Apache se difunde más rápido) y NOTICE/licencias de terceros correctas; SECURITY.md con un canal de divulgación privado; versionado semántico, CHANGELOG y una ruta de actualización/migración probada para cualquier dato almacenado o formato de configuración; matriz de plataformas compatibles realmente probada en CI (SO × versiones de runtime × cada cliente/IDE que afirma soportar); instalación verificada desde una máquina limpia para cada ruta documentada; nombres de paquetes reservados en cada registro (PyPI, npm, mercados de plugins); lanzamientos firmados / proveniencia de compilación; telemetría desactivada u opt-in y documentada; CONTRIBUTING, código de conducta, plantillas de issue/PR; una sección 'qué no es esto' para que los usuarios no lo utilicen incorrectamente.

Plantilla de scorecard

PRODUCTO: <nombre>   OBJETIVO: T1/T2/T3   LANZAMIENTO: <fecha>   VEREDICTO: APROBADO | APROBADO-CON-CONDICIONES | NO-APROBADO
Bloqueantes: N   Altas: N   Desconocidas: N

...

[truncado para traducción]