Mide antes de que te digan que Platform Engineering es caro
En 2026, justificar la inversión en platform engineering se convirtió en la prioridad número uno de CTOs y VPs of Engineering. Con inversiones que van de 20 a 80 millones de yenes en grandes empresas —y que en organizaciones gigantes superan cientos de millones anuales—, la frecuencia con que la alta dirección pregunta "¿y qué mejoró realmente?" no para de crecer. Las organizaciones que no tienen respuesta han empezado a ser objeto de recortes y reestructuraciones.
El problema es que los resultados de Platform Engineering están incorporados en la "experiencia cotidiana de los desarrolladores", lo que los hace difíciles de capturar con KPIs simples. Si aumenta la frecuencia de despliegues, no siempre queda claro si fue gracias a la plataforma, a otros esfuerzos de refactorización o simplemente a que se relajaron los criterios de release. La clave para resolver esto está en una estrategia de medición que combine varios frameworks de forma inteligente.
DORA: sigue siendo "lo mínimo que hay que medir"
Las cuatro métricas DORA —Deployment Frequency, Lead Time for Changes, Change Failure Rate y Mean Time to Restore— se consolidaron como indicadores estándar de la capacidad de entrega a raíz del libro `Accelerate` (2018) de Nicole Forsgren y sus colegas. En la décima edición del State of DevOps Report de 2026 se mantienen como métricas centrales, y los umbrales para la clase Elite casi no cambiaron: frecuencia de despliegue mayor a una vez por día, lead time menor a un día, CFR menor al 5% y MTTR menor a una hora.
La limitación de DORA está en que no mide la experiencia individual del desarrollador. Por ejemplo, dos organizaciones que alcanzan el nivel Elite pueden ser radicalmente distintas: una lo logra a base de despliegues de emergencia nocturnos repetidos, y la otra, de forma automática y sostenida a través de pipelines. Para llenar este punto ciego, surgieron SPACE y DevEx a partir de 2020.
SPACE: cinco dimensiones para ver la salud del equipo
El framework SPACE (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, 2021) mide la productividad del desarrollador en cinco dimensiones: Satisfaction and Well-being, Performance, Activity, Communication and Collaboration, y Efficiency and Flow. Su característica distintiva es la regla de "siempre combinar múltiples dimensiones", y sirve como advertencia contra el antipatrón de seguir solo la dimensión de Activity (como el conteo de commits).
En la implementación de SPACE, se seleccionan dos o tres indicadores por dimensión y se miden periódicamente. Por ejemplo: Satisfaction con encuestas trimestrales de experiencia del desarrollador y tasa de rotación; Performance con disponibilidad del servicio y tasa de adopción de funcionalidades; Activity con número de pull requests y tasa de commits significativos; Communication con tiempo de revisión de código y tasa de asignación de mentores; y Efficiency and Flow con ratio de tiempo en estado de flujo y frecuencia de interrupciones. Lo fundamental es el compromiso de "no usar estos datos para evaluación individual". Romper esto lleva directamente a caer en la Ley de Goodhart (cuando una métrica se convierte en un objetivo, deja de ser útil como métrica).
DevEx Framework (2023): Feedback Loops, Cognitive Load y Flow State
El DevEx Framework publicado por Nicole Forsgren y otros en 2023 se centra en las tres áreas que Platform Engineering puede mejorar directamente: Feedback Loops, Cognitive Load y Flow State. Si SPACE ofrece una vista panorámica de la salud del equipo, DevEx se diferencia por enfocarse en el territorio al alcance de la plataforma.
Feedback Loops se refiere al tiempo que transcurre desde un cambio en el código hasta conocer su resultado: la cadena de tiempo de build local, tiempo de CI, tiempo de revisión de PR, tiempo de propagación a staging y tiempo hasta la observación en producción. Es el área donde las mejoras de Platform Engineering tienen el impacto más directo. Cognitive Load es la carga de lo que los desarrolladores necesitan tener presente: calidad de la documentación de guardia, facilidad para descubrir APIs internas, nivel de automatización en la configuración de entornos. Flow State es cuánto tiempo de trabajo concentrado se puede encadenar, y es función de la frecuencia de notificaciones, la densidad de reuniones y la cantidad de interrupciones.
La recomendación oficial del DevEx Framework es combinar percepción (subjetiva) con workflow (medición objetiva), ejecutando encuestas trimestrales en paralelo con telemetría diaria.
Developer Experience Index (DXI): integración en un único índice
Lo que se pregunta con más frecuencia en la práctica es: "¿al final, estamos mejorando?" Para responder eso de forma sencilla existe el DXI (Developer Experience Index), propuesto en 2023 por DX (CEO: Abi Noda), y adoptado en 2026 por más de 200 grandes empresas.
El DXI consiste en 14 preguntas de encuesta medidas en escala Likert de 5 puntos, con un puntaje de 0 a 100 calculado como promedio ponderado. Las preguntas cubren ítems sobre los cuales Platform Engineering tiene influencia directa: Deep Work Time, Ease of Deploy, Confidence in Making Changes, Quality of Internal Documentation, entre otros. En el benchmark interno de DX, la mediana es 68, el cuartil superior supera 80 y el inferior está por debajo de 55.
El atractivo del DXI es que permite hablar en términos aproximados de cuántos yenes de mejora de productividad equivale a cada punto ganado. El metaanálisis de DX con Meta indica una correlación de 0,5 horas por desarrollador por semana por cada punto que sube el DXI; traducir eso a costo salarial hace la conversación con la dirección mucho más concreta. Hay riesgo de simplificación excesiva, pero es una herramienta eficaz para el diálogo con la alta gerencia.
Selección de herramientas de medición: Opsera, Faros AI y Jellyfish
Incluso con el framework definido, se necesitan herramientas para recopilar, agregar y visualizar datos. Aquí se resumen las características de los tres productos principales de 2026.
Opsera, conocida como "DevOps Intelligence", tiene fortaleza en la recopilación de datos centrada en pipelines. Calcula las métricas DORA casi sin configuración desde Jenkins, GitHub Actions, Azure DevOps y GitLab CI. Es ideal para organizaciones que priorizan la visibilidad del estado de CI/CD. Cuenta con certificaciones SOC2 Type II y FedRAMP Moderate, lo que facilita su adopción en industrias reguladas.
Faros AI, como "Engineering Operations Platform", ofrece un modelo de datos integral con fortaleza en la integración de Jira, Git, CI, incidentes y calendarios. Permite medir DORA, SPACE y DevEx simultáneamente, y en 2025 incorporó Bottleneck Detection basado en IA. También soporta exportación a data warehouses (Snowflake, BigQuery), lo que lo hace preferido por organizaciones que priorizan la integración con BI interna.
Jellyfish, en la categoría "Engineering Management Platform", tiene como mayor fortaleza la visualización de la distribución de inversión (Features / KTLO / Deuda técnica / Innovación). DORA y SPACE son estándar, y genera automáticamente cifras de "inversión en ingeniería vs. resultados" útiles para el diálogo con Finanzas. Es ideal para organizaciones que priorizan el reporte a la junta directiva.
Como criterio de selección: si la prioridad es optimizar el pipeline, Opsera; si se busca optimización global e insights con IA, Faros AI; si lo que importa es la visualización de inversión vinculada a Finanzas, Jellyfish. En 2026, la presencia en el mercado japonés es de alrededor de 30 empresas para Opsera, 15 para Faros AI y 20 para Jellyfish. La UI en japonés es parcial en todos los casos, con localización completa prevista para la segunda mitad de 2026.
Modelo de madurez organizacional: ajustar las métricas según la etapa
Una trampa frecuente es intentar medir todo desde el principio. Las métricas que no corresponden al nivel de madurez se vacían de significado y terminan siendo contraproducentes. El siguiente modelo escalonado funciona bien en la práctica.
Etapa 1 — Ad-hoc (recién formado el equipo de plataforma): medir solo Deployment Frequency y Lead Time de las cuatro métricas DORA. El objetivo en esta etapa es construir el mecanismo de medición en sí; la precisión es secundaria.
Etapa 2 — Foundational (12-18 meses del equipo de plataforma): las cuatro métricas DORA + encuesta DXI dos veces al año. Agregar tasa de adopción de la plataforma (número de servicios registrados en el catálogo, tasa de uso del Golden Path).
Etapa 3 — Intentional (cuando la plataforma ya opera como producto): DORA continua + DXI trimestral + múltiples dimensiones de SPACE + medición real de Feedback Loops del DevEx Framework. Platform NPS trimestral.
Etapa 4 — Optimized (cuando la plataforma se acerca a un centro de ganancia): todo lo anterior + ROI convertido a valor económico + análisis de distribución de inversión. Reporte trimestral a la junta directiva.
Etapa 5 — Transformative: cuando la plataforma es candidata a producto para terceros o contribuye a benchmarks del sector. Incluye visibilidad externa como presentaciones en Platform Engineering Day o KubeCon y contribuciones a proyectos open source.
Cómo justificar el ROI en términos concretos
En presentaciones a la dirección, los mensajes más simples son los más poderosos: X puntos de mejora en DXI equivalen a Y horas anuales de productividad, o Z millones de yenes. X incidentes P1 menos por mes, Y% de mejora en el índice de fatiga de SRE on-call. X servicios adoptando el Golden Path; tiempo hasta el primer despliegue reducido de X días a X horas. Lo ideal no es mostrar dashboards sino concentrar todo en una sola diapositiva.
En 2026, Platform Engineering ya no puede defender su presupuesto solo con "vamos a mejorar la experiencia del desarrollador". Medir lo que hay que medir y hablar el mismo lenguaje que la dirección: ese es el camino más corto para que Platform Engineering se afiance como infraestructura cultural duradera.