12.4
12.4 Autoevaluación de madurez
Cada capítulo de esta guía termina con un “Modelo de madurez” que describe cómo evoluciona típicamente una práctica. Este apéndice consolida el modelo de madurez de cada capítulo en una sola referencia para que puedas evaluar un equipo, un dominio, o una organización entera de un vistazo.
La escala compartida de cinco niveles
Todos los capítulos describen la misma progresión. La redacción exacta varía ligeramente entre capítulos, pero la intención se mapea limpiamente a estos cinco niveles:
- Nivel 1, Iniciar. Improvisado, reactivo, y guiado por personalidades. Las prácticas existen solo donde un individuo las elige, así que los resultados dependen del heroísmo y la suerte.
- Nivel 2, Desarrollar. Existen prácticas básicas, pero son inconsistentes entre equipos, parcialmente manuales, y a menudo evadidas bajo presión.
- Nivel 3, Estandarizar. Las prácticas están documentadas, estandarizadas, y se aplican en toda la organización. Este es el piso de auditoría y cumplimiento: el nivel que la mayoría del trabajo empresarial y gubernamental debe alcanzar para ser confiable y auditable.
- Nivel 4, Gestionar. Las prácticas se miden y controlan con datos y métricas contra líneas base. Sabes cuantitativamente cómo se desempeña cada práctica, y actúas con base en los números.
- Nivel 5, Orquestar. Las prácticas se mejoran continuamente, se integran en toda la organización, y son adaptativas. El camino seguro o correcto es el predeterminado, y la organización aprende y evoluciona deliberadamente.
Cómo usarlo para la autoevaluación
- Para cada capítulo relevante a tu contexto, lee las cinco celdas de abajo y elige el nivel que describa honestamente tu comportamiento típico, no tu mejor equipo en su mejor día, y no tu política escrita, sino lo que realmente sucede.
- Califica cada capítulo del 1 al 5. Redondea hacia abajo cuando tengas duda; una práctica que es inconsistente es Nivel 2, no Nivel 3.
- Promedia las puntuaciones dentro de una parte para ver dónde está parado todo un dominio, luego mira la dispersión: una parte con “3 en promedio” que esconde un capítulo de Nivel 1 todavía carga el riesgo de ese capítulo.
- Reevalúa periódicamente y rastrea la tendencia. El movimiento importa más que cualquier instantánea individual.
La madurez es un medio, no un fin
Mayor madurez no es automáticamente mejor. El objetivo es el ajuste: suficiente rigor para gestionar el riesgo y la escala que realmente enfrentas, y no más. Una herramienta pequeña y de bajo riesgo no necesita ingeniería del caos de Nivel 5. Buscar un nivel alto como trofeo, en lugar de para resolver un problema real, produce ceremonia sin valor. Lee cada “Nivel 5” abajo como “apropiado cuando lo que está en juego lo justifica”, y deja que el riesgo, la escala, y la exposición regulatoria decidan qué tan alto escalar.
Parte 1. Personas
| Tema | Nivel 1 Iniciar | Nivel 2 Desarrollar | Nivel 3 Estandarizar | Nivel 4 Gestionar | Nivel 5 Orquestar |
|---|---|---|---|---|---|
| Cultura y valores de ingeniería | La cultura es accidental y guiada por personalidades; los incidentes significan culpa; el conocimiento vive en pocas cabezas. | Algunos equipos ejecutan autopsias y escriben documentos, pero la práctica es inconsistente y no reforzada por el liderazgo. | El aprendizaje sin culpa, los modelos de propiedad, y una cultura de escritura son normas de toda la organización con expectativas y herramientas claras. | La salud de la cultura se mide (encuestas de seguridad psicológica, tasas de aprendizaje de incidentes, retención) y se rastrea contra líneas base y se actúa. | La cultura se mejora continuamente y las prácticas se propagan entre equipos; el liderazgo adapta las normas conforme la organización crece y aprende. |
| Topologías de equipo | Los equipos se forman por accidente o cantidad de personal; la estructura refleja la jerarquía heredada; dependencias por todas partes. | Existen algunos equipos alineados a flujo, pero persisten los cuellos de botella compartidos y los silos funcionales. | Los cuatro tipos de equipo y los modos de interacción explícitos se usan deliberadamente; las plataformas e InnerSource cortan las dependencias. | La carga cognitiva, el flujo, y los conteos de dependencia se miden por equipo contra objetivos; los límites se ajustan cuando los números se deslizan. | La organización remodela continuamente los equipos y modos de interacción para sostener el flujo conforme evolucionan los productos y plataformas. |
| Roles, escalafones profesionales, crecimiento | Sin escalafón escrito; los ascensos y el salario son improvisados y guiados por personalidades. | Existe un escalafón básico pero se aplica inconsistentemente; sin calibración; la contratación es no estructurada. | Las vías duales, una matriz de competencia clara, la calibración, y la contratación estructurada son estándar. | Las tasas de progresión, la equidad salarial, y el tiempo en nivel se miden contra líneas base; los resultados de calibración se analizan por sesgo. | El marco evoluciona continuamente con el trabajo; el patrocinio y el aprendizaje son deliberados y de toda la organización conforme cambian los roles. |
| Formas de trabajar | El proceso es improvisado o de imitación; la comunicación es guiada por reuniones y no documentada; las estimaciones se tratan como promesas. | Se sigue una metodología consistentemente, pero las ceremonias son mecánicas y la coordinación entre equipos es pesada. | Las prácticas se eligen para ajustarse al contexto; la comunicación asíncrona y basada en documentos es la norma; la estimación informa, no controla. | Las métricas de flujo (tiempo de entrega, trabajo en progreso, rendimiento) se rastrean contra líneas base y se revisan cada ciclo. | Los equipos ajustan continuamente su forma de trabajar a partir de esas métricas; la necesidad de coordinación se minimiza en la fuente y la buena práctica se propaga en toda la organización. |
| Toma de decisiones y gobernanza | Las decisiones son improvisadas y no registradas; la gobernanza está ausente o es un cuello de botella general; la deuda es invisible. | Algunas decisiones se documentan y existe cierta revisión, pero el proceso es inconsistente y desajustado al peso de la decisión. | Los ADR, un camino pavimentado, la delegación basada en reversibilidad, y un inventario de deuda son estándar y transparentes. | El tiempo de ciclo de decisión, las tasas de reversión, y los niveles de deuda se miden; el escrutinio se calibra por el peso de la decisión contra esos números. | La gobernanza se ajusta continuamente en toda la organización; el escrutinio apunta a las decisiones irreversibles; la deuda y el abastecimiento se gestionan como portafolios en evolución. |
Parte 2. Programación de software
| Tema | Nivel 1 Iniciar | Nivel 2 Desarrollar | Nivel 3 Estandarizar | Nivel 4 Gestionar | Nivel 5 Orquestar |
|---|---|---|---|---|---|
| Estándares de codificación y estilo | El estilo es por autor; sin configuraciones compartidas; el formato se discute en la revisión. | Cada equipo tiene un formateador y linter, pero las configuraciones y reglas varían entre equipos. | Configuraciones compartidas centrales por lenguaje; aplicación en CI; los repositorios nuevos heredan estándares mediante plantillas. | La adopción del estándar, las tasas de violación, y el impacto en el tiempo de revisión se miden contra líneas base; las configuraciones están versionadas y gobernadas. | Los estándares se refinan continuamente a partir de esos datos y se comparten en toda la organización; la aplicación es casi sin fricción y se adapta a nuevos lenguajes. |
| Principios de diseño de software | El diseño es improvisado; el acoplamiento se acumula; los principios son desconocidos o se invocan como eslóganes. | Los equipos conocen los principios y los aplican, pero inconsistentemente y a menudo dogmáticamente. | Vocabulario de diseño compartido, análisis deliberado de acoplamiento/cohesión, y contextos delimitados alineados a los equipos. | Las métricas de acoplamiento, cohesión, y tasa de fallo de cambio informan las revisiones de diseño contra líneas base; las decisiones se registran. | Las decisiones de diseño se revisitan conforme se acumula evidencia; los principios se aplican con matiz y las elecciones de paradigma se adaptan en toda la organización conforme evoluciona el dominio. |
| API y diseño de interfaces | Las API emergen de la implementación; sin convenciones compartidas; los cambios disruptivos son comunes y no anunciados. | Los equipos siguen convenciones REST básicas y versionan informalmente, pero la consistencia y los documentos varían. | Diseño primero-el-contrato, especificaciones legibles por máquina, una política de obsolescencia, y convenciones consistentes de error/paginación. | La adopción, la latencia, las tasas de error, y la frecuencia de cambios disruptivos se miden por API contra objetivos. | Las API son productos gobernados en un catálogo con fuerte DevEx; la práctica se adapta continuamente y las rupturas son raras y bien gestionadas en toda la organización. |
| Estrategia de pruebas | Las pruebas son manuales e improvisadas; la cobertura automatizada es mínima; las regresiones son frecuentes. | Existen pruebas unitarias automatizadas y algo de integración, pero la suite es lenta o inestable y la confianza es baja. | Una suite equilibrada, rápida, y confiable condiciona cada cambio; la inestabilidad se gestiona; las pruebas no funcionales están integradas. | La cobertura, la inestabilidad, los defectos escapados, y las métricas de duración de la suite se rastrean contra líneas base para dirigir el esfuerzo. | Las técnicas avanzadas (propiedades, mutación, difusas) apuntan al código de alto valor; la estrategia mejora continuamente y se propaga entre equipos. |
| Revisión de código y colaboración | La revisión es inconsistente o se salta; los problemas mecánicos dominan; las normas de retroalimentación no están establecidas. | La revisión se requiere pero es lenta y variable; la automatización es parcial; el tamaño y la calidad de las PR varían ampliamente. | PR pequeñas, verificaciones mecánicas automatizadas, estándares y normas de retroalimentación claros, y latencia monitoreada. | La latencia de revisión, el tamaño de la PR, y las tasas de escape de defectos se rastrean contra objetivos; la profundidad se ajusta al riesgo medido. | La organización mejora continuamente la revisión a partir de esos datos; el emparejamiento y la asistencia de IA se adoptan deliberadamente y las prácticas se propagan entre equipos. |
| Control de versiones y gestión de fuente | Ramificación improvisada; ramas de larga vida; mensajes deficientes; sin escaneo de secretos; dolor de fusión frecuente. | Existen un modelo de ramificación consistente y convenciones de mensaje, pero las ramas viven demasiado y la aplicación es parcial. | Desarrollo basado en tronco, línea principal protegida, convenciones de commit aplicadas, escaneo de secretos, estructura de repositorio deliberada. | El tiempo de vida de la rama, la frecuencia de fusión, y las tasas de reversión se miden contra métricas de entrega y líneas base. | La automatización aplica la higiene de extremo a extremo; la estructura del repositorio y el flujo de trabajo evolucionan continuamente en toda la organización conforme cambian las necesidades de entrega. |
| Documentación | La documentación es escasa, dispersa, y obsoleta; el conocimiento vive en las cabezas de la gente. | Existen documentos clave (README, algunos manuales de operación) pero se mantienen inconsistentemente y son difíciles de encontrar. | Documentación como código con estructura clara, documentos de API generados y registros de cambios, registros de decisión, y expectativas de actualización. | La cobertura, la frescura, y la precisión de los documentos se miden contra líneas base; la obsolescencia se marca automáticamente. | Los documentos son vivos, en gran parte generados o probados contra el sistema, con dueño y descubribles; la práctica mejora continuamente en toda la organización. |
Parte 3. Sistemas
| Tema | Nivel 1 Iniciar | Nivel 2 Desarrollar | Nivel 3 Estandarizar | Nivel 4 Gestionar | Nivel 5 Orquestar |
|---|---|---|---|---|---|
| Fundamentos de arquitectura | La arquitectura es implícita y vive en las cabezas; sin atributos de calidad ni ADR; las decisiones salen a la superficie durante incidentes. | Existen diagramas clave y las decisiones mayores a veces se registran; los atributos de calidad se nombran pero rara vez se cuantifican; los documentos se desactualizan. | Los escenarios de atributos de calidad y los ASR se especifican; los ADR son rutinarios; los documentos C4/arc42 se mantienen cerca del código; ocurren revisiones de intercambio. | Las funciones de aptitud aplican los atributos de calidad en CI y registran resultados medidos contra líneas base; los intercambios se cuantifican. | La arquitectura evoluciona continuamente con esos datos en toda la organización; los documentos permanecen lo suficientemente confiables para los auditores conforme se adapta el sistema. |
| Estilos y patrones arquitectónicos | Un monolito enredado o un desastre distribuido accidental; los límites siguen capas o la historia; el estilo se elige por moda. | Límites modulares deliberados o unos cuantos servicios gruesos; algunas preocupaciones transversales consistentes; las divisiones siguen siendo improvisadas. | Servicios alineados a contextos delimitados poseyendo sus datos; puerta de enlace/BFF donde es apto; capas limpias/hexagonales estándar. | Las decisiones de estilo están basadas en evidencia, usando datos medidos de acoplamiento, latencia, y costo de cambio contra líneas base. | Una plataforma madura hace barata la distribución; la organización reconsolida cuando una división deja de pagar y adapta el estilo conforme cambia la evidencia. |
| Sistemas distribuidos | Las llamadas remotas se tratan como locales; sin reintentos o ingenuos; los fallos se propagan en cascada; la depuración es excavación de registros por máquina. | Existen tiempos de espera y reintentos básicos pero inconsistentes; algo de idempotencia; los registros están centralizados pero no correlacionados. | Idempotencia, retroceso, disyuntores, compartimentos vía bibliotecas compartidas; sagas; trazado distribuido; consistencia documentada por flujo. | La resiliencia se mide contra los SLO; los resultados de inyección de fallos y las tasas de fallo se rastrean contra líneas base. | La resiliencia es el predeterminado de la plataforma, probada continuamente con inyección de fallos; la degradación elegante se diseña desde el principio y evoluciona en toda la organización. |
| Arquitectura de datos y almacenamiento | Una base de datos para cada propósito; sin disciplina de migración; caché incidental; escala mediante máquina más grande. | Las elecciones de almacenamiento son mayormente deliberadas; una caché y quizás un almacén de datos; las migraciones versionadas a veces necesitan tiempo de inactividad. | Persistencia poliglota ajustada a las cargas de trabajo, cada almacén con dueño; migraciones automatizadas sin tiempo de inactividad; caché y réplicas explícitas. | Las elecciones de almacenamiento se miden contra patrones de acceso, latencia, y líneas base de costo; las decisiones de fragmentación y caché están basadas en datos. | La arquitectura de datos se revisa y evoluciona continuamente en toda la organización; las migraciones son automatizadas y auditadas conforme cambian las cargas de trabajo. |
| Escalabilidad, rendimiento, resiliencia | Instancia única o escalada verticalmente; estado del lado del servidor; sin pruebas de carga ni presupuestos; los fallos causan interrupciones completas. | Capas sin estado escaladas horizontalmente; autoescalado básico; algo de prueba de carga previa al lanzamiento; DR documentado pero rara vez probado. | Capacidad planificada con margen; presupuestos de rendimiento en CI; patrones de resiliencia estándar; RTO/RPO definidos y DR probado. | La capacidad se pronostica a partir de la carga medida; los presupuestos de rendimiento y RTO/RPO se rastrean contra líneas base. | La conmutación por error automatizada multi-región, el caos continuo, y los días de juego prueban y mejoran los objetivos de recuperación conforme el sistema evoluciona en toda la organización. |
| Modernización de sistemas heredados | Lo heredado se teme y se congela; sin inventario; la modernización es todo o nada mediante reescritura; el conocimiento está en cabezas que se retiran. | Existe un inventario y se entiende algo del riesgo; lo heredado se envuelve con API; sigue el pensamiento de gran explosión; la migración se subestima. | Los sistemas se priorizan por riesgo y valor; la higuera estranguladora y la bifurcación por abstracción son estándar; la migración se reconcilia con ejecución dual. | La modernización se gestiona como portafolio con riesgo, valor, y progreso medidos contra líneas base. | La modernización es continua en toda la organización; el reemplazo incremental es rutinario, reversible, y se adapta conforme cambian las prioridades. |
Parte 4. Seguridad
| Tema | Nivel 1 Iniciar | Nivel 2 Desarrollar | Nivel 3 Estandarizar | Nivel 4 Gestionar | Nivel 5 Orquestar |
|---|---|---|---|---|---|
| Fundamentos y cultura de seguridad | La seguridad es reactiva y centralizada; las revisiones son tardías si acaso; sin modelado de amenazas; la seguridad es “el problema de alguien más”. | Un equipo de seguridad define estándares; algo de modelado de amenazas en proyectos mayores; entrenamiento básico; la seguridad se ve como una puerta. | Campeones de seguridad incrustados; el modelado de amenazas es rutinario; el SDLC seguro está documentado; priorización basada en riesgo; revisiones sin culpa. | Las métricas de seguridad (cobertura de modelado de amenazas, tiempo de hallazgo a corrección, adopción de controles) se rastrean contra líneas base. | La seguridad es genuinamente el trabajo de todos; el modelado de amenazas es habitual; la confianza cero se realiza en gran parte y la práctica mejora continuamente en toda la organización. |
| Seguridad de aplicaciones | La seguridad depende del conocimiento individual; sin controles estándar; secretos en el código; dependencias obsoletas; autenticación improvisada. | Conciencia de OWASP Top 10; algunas protecciones de marco; el gestor de secretos se usa desigualmente; escaneo de dependencias ocasional. | Requisitos basados en ASVS por nivel; consultas parametrizadas; identidad central con MFA; secretos gestionados; SBOM y escaneo de pipeline. | La densidad de vulnerabilidades, el tiempo medio de remediación, y la cobertura de controles se miden contra líneas base en todos los servicios. | Los valores predeterminados seguros se envían en marcos de camino pavimentado; las credenciales de corta duración y la garantía completa de cadena de suministro (SLSA) se verifican continuamente en toda la organización. |
| Seguridad de infraestructura y nube | Aprovisionamiento manual; permisos amplios y claves estáticas; redes planas; cifrado inconsistente; sin gestión de postura. | Algunos roles IAM y MFA; capas de red básicas; cifrado en reposo para almacenes principales; revisiones manuales periódicas; IaC parcial. | RBAC/ABAC de privilegio mínimo con credenciales de corta duración; segmentación de denegación predeterminada; cifrado por defecto con KMS; CSPM con política. | La postura, la deriva, y las métricas de violación de política se rastrean contra líneas base; la efectividad de las barandas se mide. | Los valores predeterminados seguros se envían en zonas de aterrizaje e IaC; la microsegmentación y las barandas preventivas evolucionan continuamente y la deriva se autorremedia en toda la organización. |
| Operaciones de seguridad | Las pruebas de seguridad son manuales y raras; sin registro central ni SIEM; sin plan de incidentes; parcheo improvisado; nunca probado adversarialmente. | Algunos escáneres en el pipeline; registro central; un plan de incidentes básico; cronogramas de parcheo laxos; prueba de penetración anual. | Escaneo DevSecOps completo con puertas basadas en riesgo; SIEM con algo de SOAR; RI ensayada con simulacros de mesa; SLA de remediación; ejercicios de equipo rojo. | El MTTD y el MTTR se miden contra líneas base; la cobertura de detección se mapea a técnicas de adversarios y se rastrea. | Las pruebas y la respuesta están altamente automatizadas; el equipo púrpura y la ingeniería de detección mejoran continuamente y se adaptan a nuevas amenazas en toda la organización. |
| Privacidad y protección de datos | Los datos personales se recolectan libremente; sin inventario, minimización, ni retención; el consentimiento es una ocurrencia tardía; sin proceso de derechos. | Existe una política de privacidad y consentimiento básico; algo de conciencia de retención; las solicitudes de derechos se manejan manual y lentamente. | Privacidad por diseño con DPIA; datos mapeados y clasificados; retención aplicada; base legal documentada; derechos cumplidos en fecha límite. | La postura de privacidad se mide: cobertura del inventario de datos, cumplimiento de retención, y tiempo de respuesta a solicitudes de derechos contra líneas base. | La privacidad es una restricción de ingeniería predeterminada; la minimización y la retención automatizada son estándar; las solicitudes de derechos son autoservicio y la práctica se adapta en toda la organización. |
| Cumplimiento y gobernanza | El cumplimiento es reactivo; sin marco de control; la evidencia se ensambla manualmente bajo fecha límite; hallazgos frecuentes. | Se identifican marcos clave; algunos controles documentados; las auditorías pasan pero con esfuerzo manual pesado; la accesibilidad se considera tarde. | Un marco de control unificado mapea cruzadamente los estándares; la evidencia está parcialmente automatizada; se prueba la accesibilidad; se establecen registros y autorizaciones. | La efectividad del control y la cobertura de evidencia se miden continuamente contra líneas base; los hallazgos se rastrean en tendencia. | El cumplimiento es continuo con evidencia siempre activa y cumplimiento como código; las nuevas certificaciones son de bajo costo y el marco se adapta en toda la organización, listo para auditoría en cualquier momento. |
Parte 5. Diseño UI/UX
| Tema | Nivel 1 Iniciar | Nivel 2 Desarrollar | Nivel 3 Estandarizar | Nivel 4 Gestionar | Nivel 5 Orquestar |
|---|---|---|---|---|---|
| Fundamentos de UX | Sin práctica de UX dedicada; decisiones por opinión; investigación improvisada; flujos y terminología inconsistentes. | Algunos diseñadores y pruebas de usabilidad ocasionales; personas sin mantener; UX es una fase, a menudo evadida. | La investigación continua de métodos mixtos alimenta la priorización; personas compartidas, mapas de recorrido, e IA; puertas de calidad de UX en la DoD. | Las métricas de UX (éxito de tarea, satisfacción, puntuaciones de usabilidad) se rastrean contra líneas base junto con las métricas de negocio. | La investigación es continua y vinculada a resultados; los experimentos controlados cierran el ciclo y las perspectivas se propagan entre equipos conforme evolucionan los productos. |
| Diseño de UI y sistemas de diseño | Cada equipo construye su propia UI; sin componentes compartidos; apariencia inconsistente; colores y espaciado codificados de forma fija. | Existe una guía de estilo parcial o biblioteca de componentes pero es opcional y a menudo está desincronizada entre diseño y código. | Un sistema de diseño tokenizado con una biblioteca codificada mantenida, documentos, y gobernanza se usa entre equipos; a11y incorporada. | La paridad diseño-código, la adopción de componentes, y la deriva se miden contra líneas base; el versionamiento se rastrea. | El sistema es un producto gobernado con una hoja de ruta; mejora continuamente en toda la organización y los rediseños de marca se convierten en cambios de tokens. |
| Accesibilidad | Sin práctica de accesibilidad; los problemas se encuentran por queja o demanda; marcado no semántico y sin probar. | Existe conciencia; algo de escaneo automatizado y una auditoría previa al lanzamiento; la a11y es una lista de verificación tardía, a menudo despriorizada. | WCAG 2.2 AA es el estándar; la a11y está incorporada en el sistema de diseño, probada, y en la DoD; los equipos están entrenados con un dueño. | El cumplimiento de accesibilidad se mide en CI contra líneas base WCAG; las tasas de defectos y resultados de auditoría se rastrean. | La accesibilidad es continua; las personas con discapacidad se involucran en la investigación; está incrustada en la adquisición, los tokens, y CI y mejora en toda la organización. |
| Diseño de contenido y comunicación | Sin práctica de contenido; las palabras se escriben improvisadamente; terminología y tono inconsistentes; errores y estados vacíos inútiles. | Puede existir una guía de estilo; algo de conciencia de lenguaje llano; el contenido sigue siendo de etapa tardía y por equipo con poca reutilización. | Una estrategia de contenido, guía de voz y tono, y glosario usados entre equipos; el lenguaje llano es estándar; patrones compartidos. | El contenido se mide contra resultados (comprensión, finalización de tareas, tasas de error) versus líneas base. | El contenido mejora continuamente a partir de esa evidencia; los patrones oscuros están prohibidos y auditados; los patrones se localizan y son accesibles por defecto en toda la organización. |
| Internacionalización y localización | Idioma único; cadenas codificadas de forma fija; supuestos no Unicode; las regiones nuevas requieren cambios de código. | Las cadenas están externalizadas y se usa Unicode, pero la localización es un lote manual previo al lanzamiento; formato y plurales inconsistentes. | Arquitectura i18n compartida y formato consciente de la configuración regional; un TMS y pipeline continuo; pseudolocalización y CI multi-región. | La cobertura de localización, la frescura de cadenas, y las tasas de defectos por región se miden contra líneas base. | La i18n se aplica mediante herramientas y linting entre equipos; la localización es continua, la adaptación cultural es sistemática, y las nuevas regiones se lanzan rápido. |
| Ingeniería de frontend | Frontend improvisado por equipo; código pesado del cliente; sin presupuestos; probado solo en dispositivos del equipo; el marco se elige por moda. | Algo de herramientas compartidas y una biblioteca de componentes; el rendimiento se mide ocasionalmente, no se presupuesta; pruebas entre dispositivos limitadas. | El marco y el renderizado se eligen deliberadamente por superficie; los presupuestos se aplican en CI con RUM; la mejora progresiva es estándar. | El rendimiento, la resiliencia, y el alcance se miden contra líneas base de usuario real y presupuestos; las regresiones fallan la construcción. | Esas señales se atan a resultados y se mejoran continuamente entre superficies conforme evolucionan el frontend y sus usuarios. |
Parte 6. Inteligencia artificial
| Tema | Nivel 1 Iniciar | Nivel 2 Desarrollar | Nivel 3 Estandarizar | Nivel 4 Gestionar | Nivel 5 Orquestar |
|---|---|---|---|---|---|
| Estrategia y preparación en IA | Experimentos improvisados; sin estrategia compartida; las decisiones se guían por la moda y el entusiasmo individual. | Enmarcado de problemas en algunos proyectos; una primera línea base de plataforma; construir versus comprar se discute pero es inconsistente. | Un portafolio de casos de uso con métricas claras, un árbol de decisión, evaluaciones de preparación, y análisis de bloqueo/TCO. | El valor del caso de uso, la adopción, y la preparación se miden contra líneas base; el ROI del portafolio se rastrea. | La estrategia de IA está integrada con la planificación de negocio y riesgo; la preparación se mantiene continuamente y los sistemas redefinen su alcance con evidencia en toda la organización. |
| MLOps | Modelos construidos improvisadamente en cuadernos; despliegue manual; sin versionamiento de datos/modelo; sin monitoreo. | Algo de rastreo de experimentos y un registro de modelos; despliegue semiautomatizado; monitoreo básico para unos cuantos modelos. | Plataforma compartida con almacén de características, registro, pipelines reproducibles, linaje; monitoreo de deriva/calidad; promoción gobernada. | La calidad del modelo, la deriva, y el impacto de negocio se miden contra líneas base; el reentrenamiento se activa por umbrales con puertas. | El ciclo de vida está completamente automatizado y es auditable; los caminos pavimentados de autoservicio y la evaluación continua mejoran los modelos en toda la organización conforme cambian los datos. |
| IA generativa y aplicaciones de modelos de lenguaje | Prompting improvisado en proyectos aislados; sin fundamentación, barandas, ni evaluación; alucinaciones encontradas en producción. | Algo de RAG y versionamiento de prompts; validación básica de salida; un pequeño conjunto de evaluación manual. | Patrones compartidos para RAG, barandas, y uso de herramientas; evaluación automatizada fuera de línea en cada cambio; métricas en línea y revisión humana. | Las puntuaciones de evaluación fuera y en línea, las tasas de alucinación e inyección se miden contra líneas base. | La evaluación se ata a resultados y mejora continuamente; las defensas de inyección, los agentes observables gobernados, y la mitigación se adaptan en toda la organización. |
| Desarrollo de software asistido por IA | Los individuos usan asistentes improvisadamente; sin política; sin medición; secretos y PI en riesgo. | Guía de uso básica y reglas de datos; algo de escaneo de seguridad; afirmaciones anecdóticas de productividad. | Normas claras por nivel de riesgo; revisión y escaneo obligatorios; métricas de resultado honestas; despliegue seguro y divulgación. | El impacto de la asistencia en la entrega y la calidad se mide contra líneas base; la cobertura de verificación se rastrea. | La verificación es fuerte en el pipeline; el desarrollo de habilidades es deliberado y la política se adapta continuamente conforme cambian las herramientas y la evidencia en toda la organización. |
| IA responsable y de confianza | Sin prueba de equidad, explicaciones, ni gobernanza; la responsabilidad no está definida; los problemas se encuentran solo después del daño. | Algo de prueba de sesgo y documentación; supervisión improvisada; conciencia del marco pero adopción parcial. | Gobernanza mapeada a marcos reconocidos; prueba sistemática de equidad/seguridad/privacidad; supervisión y apelaciones documentadas; ejercicios de equipo rojo. | Las métricas de equidad, seguridad, y privacidad se monitorean en producción contra líneas base y umbrales. | La gobernanza está integrada en la entrega; la responsabilidad es el trabajo de todos y el enfoque mejora continuamente en toda la organización. |
| Infraestructura y operaciones de IA | Asignación de GPU improvisada; sin agrupamiento por lotes ni caché; sin visibilidad de costo; prompts sin versionar; monitoreo mínimo. | Algo de programación y caché compartidas; rastreo de costo básico; prompts en control de versiones; evaluación improvisada. | Plataforma compartida con programación, cuotas, agrupamiento por lotes, caché, dimensionamiento correcto; infraestructura vectorial; evaluación automatizada; atribución de costo. | La utilización, el costo por resultado, y la latencia se miden contra líneas base; los presupuestos y cuotas se aplican. | El enrutamiento y el escalado están automatizados, la observabilidad de LLMOps es completa, y la utilización y el costo se optimizan continuamente con portabilidad mantenida en toda la organización. |
Parte 7. Datos, analítica, y perspectivas
| Tema | Nivel 1 Iniciar | Nivel 2 Desarrollar | Nivel 3 Estandarizar | Nivel 4 Gestionar | Nivel 5 Orquestar |
|---|---|---|---|---|---|
| Estrategia y gobernanza de datos | Datos no documentados y sin dueño; definiciones en conflicto; la calidad se descubre cuando los reportes se rompen; sin catálogo ni linaje. | Algunos conjuntos de datos tienen dueños y documentos; un catálogo parcial; verificaciones de calidad manuales y reactivas; política escrita pero débilmente aplicada. | Los productos de datos críticos tienen dueños, contratos, SLA; catálogo con linaje automatizado; calidad continua; gobernanza federada. | La calidad de datos, el cumplimiento de contrato, y la frescura se miden contra SLA y líneas base. | Los datos como producto son la norma; los contratos se aplican automáticamente, las barandas de autoservicio se adaptan, y las definiciones son confiables en toda la empresa. |
| Ingeniería de datos | Scripts improvisados, ejecuciones manuales, sin pruebas ni monitoreo; los fallos los encuentran los consumidores; costos sin gestionar. | Algo de orquestación y programación; transformaciones básicas en control de versiones; pruebas ocasionales; apagar incendios reactivamente. | ELT con modelos en capas, probados, versionados; dependencias orquestadas con reintentos/rellenos; observabilidad; costos rastreados. | La fiabilidad, frescura, y costo del pipeline se miden contra SLA; las anomalías se detectan contra líneas base. | Los pipelines son software con CI/CD, contratos, y pruebas; la plataforma mejora continuamente y los nuevos productos de datos se envían rápido en toda la organización. |
| Analítica e inteligencia de negocio | Reportes construidos improvisadamente en hojas de cálculo; métricas inconsistentes; gráficos engañosos; sin gobernanza. | Una herramienta de BI con algunos tableros compartidos; las definiciones de métrica todavía divergen; comienza el autoservicio no controlado y la expansión. | Una capa semántica define las métricas centrales una vez; contenido certificado versus experimental; autoservicio dentro de barandas; ciclo de vida gestionado. | El uso de métricas, la frescura, y los cambios de definición se rastrean contra líneas base; el contenido certificado se monitorea. | Las métricas se gobiernan como API con dueños y registros de cambios; la analítica abarca de descriptiva a prescriptiva y se incrusta en los puntos de decisión en toda la organización. |
| Analítica de producto y experimentación | Instrumentación escasa/inconsistente; decisiones por opinión; sin experimentos; métricas de vanidad; consentimiento descuidado. | Se rastrean algunos eventos pero la taxonomía es inconsistente; pruebas A/B ocasionales sin análisis de poder; estrella polar propuesta, no incrustada. | Un plan de rastreo gobernado y validado; embudos/cohortes/retención rutinarios; experimentos en una plataforma compartida; consentimiento manejado apropiadamente. | El volumen de experimentos, el poder, y las tasas de victoria se miden contra líneas base; la cobertura de instrumentación se rastrea. | La experimentación es el predeterminado; un repositorio de resultados compartido y la instrumentación con dueño permiten a la organización aprender acumulativamente y adaptarse. |
| Ciencia de decisión y cultura de datos | Decisiones por jerarquía e intuición; la correlación se trata como causalidad; la incertidumbre se ignora; las métricas vigilan y se manipulan. | Los datos se consultan selectivamente para justificar decisiones; algo de conciencia de trampas causales; la incertidumbre rara vez se comunica. | Los análisis se atan a decisiones con criterios predefinidos; se distingue correlación de causalidad; la incertidumbre se comunica; enfoque en resultados. | La calidad de la decisión y la calibración del pronóstico se rastrean contra resultados y líneas base. | “¿Qué cambiaría nuestra opinión?” es rutinario; el rigor causal y la incertidumbre honesta son normas y los líderes actualizan visiblemente con base en evidencia en toda la organización. |
Parte 8. Automatización
| Tema | Nivel 1 Iniciar | Nivel 2 Desarrollar | Nivel 3 Estandarizar | Nivel 4 Gestionar | Nivel 5 Orquestar |
|---|---|---|---|---|---|
| CI/CD y entrega | Las construcciones y despliegues son en gran parte manuales e inconsistentes; integración tardía; liberaciones infrecuentes y estresantes; retroceso manual. | Construcciones y pruebas unitarias automatizadas por commit; despliegues programados pero supervisados manualmente; los artefactos pueden reconstruirse por etapa. | Un pipeline estandarizado promueve un artefacto inmutable a través de entornos con puertas automatizadas; canario/azul-verde; registros de cambio automáticos. | Las métricas DORA (tiempo de entrega, frecuencia de despliegue, tasa de fallo de cambio, MTTR) se rastrean contra líneas base y activan retrocesos. | La entrega progresiva desacopla la liberación mediante banderas; el pipeline se automejora y la evidencia de cumplimiento es automática en toda la organización. |
| Infraestructura como código y configuración | La infraestructura se aprovisiona manualmente; entornos inconsistentes y no documentados; recuperación lenta e incierta. | Algo de infraestructura escrita en scripts, pero las prácticas varían; estado inconsistente; deriva común; la política se aplica mediante revisión manual. | IaC declarativa estándar a partir de módulos versionados compartidos con estado remoto; barandas de política como código; detección de deriva regular. | La deriva, el tiempo de aprovisionamiento, y las tasas de violación de política se miden contra líneas base; la evidencia de cumplimiento es automática. | La infraestructura es inmutable, guiada por GitOps, y autorreparable; la biblioteca de módulos y políticas mejora continuamente y se adapta en toda la organización. |
| Contenedores, orquestación, nativo de la nube | Los contenedores se usan improvisadamente; imágenes construidas a mano sin escanear; despliegue manual; sin plataforma compartida ni modelo de aislamiento. | Los equipos contenedorizan y usan un orquestador, pero las prácticas varían; escaneo y límites inconsistentes; costo y arrendamiento sin gobernar. | Una plataforma estandarizada con imágenes reforzadas, puertas de firma/escaneo, arrendamiento de espacio de nombres con cuotas y política de red, asignación de costo. | La utilización, la densidad, y el costo por carga de trabajo se miden contra líneas base; la optimización de FinOps está basada en datos. | Una plataforma de autoservicio y autorreparable con fuerte multi-arrendamiento permanece portable y lista para híbrido/soberano y mejora continuamente en toda la organización. |
| Ingeniería de plataforma y DevEx | Sin plataforma; cada equipo ensambla sus propias herramientas inconsistentemente; transferencias guiadas por tickets; alta carga cognitiva. | Algunas herramientas y plantillas compartidas, pero fragmentadas y parcialmente manuales; autoservicio limitado; DevEx sin medir. | Un equipo de plataforma ejecuta caminos dorados, aprovisionamiento de autoservicio, un portal de desarrollador, y tarjetas de puntuación; barandas en caminos pavimentados; DevEx medida. | La adopción, las puntuaciones de DevEx, y las señales de carga cognitiva se miden contra líneas base y se revisan. | Un producto de plataforma maduro mejora continuamente a partir de esa retroalimentación; la adopción voluntaria es alta y la gobernanza permanece invisible en el flujo de trabajo en toda la organización. |
| Automatización de pruebas y procesos | Las pruebas y operaciones son en gran parte manuales; cobertura inconsistente; procedimientos en cabezas o documentos obsoletos; evidencia de cumplimiento a mano. | Existen pruebas automatizadas pero son lentas/inestables y se ejecutan inconsistentemente; algunos scripts operativos; remediación manual; gobernanza de revisión periódica. | Infraestructura de pruebas rápida, paralela, y confiable; manuales de operación codificados; ChatOps; evidencia de cumplimiento autogenerada; gobernanza como verificaciones automatizadas. | La cobertura de automatización, las tasas de falsos positivos, y los tiempos de remediación se miden contra líneas base. | Los incidentes rutinarios se autorremedian con salvaguardas; el cumplimiento es continuo y listo para auditoría y los humanos se enfocan en el juicio en toda la organización. |
Parte 9. Operaciones, fiabilidad, y observabilidad
| Tema | Nivel 1 Iniciar | Nivel 2 Desarrollar | Nivel 3 Estandarizar | Nivel 4 Gestionar | Nivel 5 Orquestar |
|---|---|---|---|---|---|
| Ingeniería de confiabilidad de sitio | Operaciones manuales y reactivas; sin SLO; la fiabilidad es opinión; los mismos incidentes recurren; apagar incendios domina. | Los servicios clave tienen SLI/SLO básicos; algo de monitoreo y alertas; el trabajo penoso se reconoce pero no se mide; autopsias inconsistentes. | Los presupuestos de error influyen en la priorización; el trabajo penoso se mide y limita; planificación de capacidad rutinaria; automatización financiada; modelo de PRR y compromiso. | Los presupuestos de error, el trabajo penoso, y el cumplimiento de SLO se miden contra líneas base y guían la priorización. | La política de presupuesto de error está automatizada y se respeta; las operaciones de autoservicio y la capacidad proactiva permiten a la organización intercambiar velocidad y estabilidad con datos y adaptarse. |
| Observabilidad y monitoreo | Verificaciones básicas de tiempo de actividad y registros no estructurados por máquina; depurar significa SSH; alertas ruidosas e ignoradas. | Métricas centralizadas y agregación de registros; algunos tableros y alertas de umbral; trazas parciales/ausentes; correlación manual. | Instrumentación OpenTelemetry con ID de traza propagados; registros estructurados, trazado, tableros curados, alertas de síntoma de SLO; guardia sostenible. | La calidad de las alertas, el MTTD, y el costo de telemetría se miden contra líneas base; las alertas de tasa de consumo se ajustan a los SLO. | La observabilidad de alta cardinalidad y rica en eventos soporta la investigación improvisada; la retención está optimizada por costo y la telemetría informa decisiones en toda la organización. |
| Gestión de incidentes | Los incidentes se manejan improvisadamente por quien los note; sin roles, severidades, ni autopsias; guardia informal; los fallos recurren. | Rotaciones de guardia básicas y severidades; algunas autopsias, pero roles poco claros y acciones correctivas rastreadas inconsistentemente. | Un sistema formal de comando de incidentes con roles y criterios claros; autopsias sin culpa estándar; acciones rastreadas; guardia compensada. | La frecuencia de incidentes, el MTTR, y la carga de guardia se miden contra líneas base; las causas recurrentes se rastrean en tendencia. | La respuesta se ensaya mediante días de juego; la guardia permanece sostenible y silenciosa y el análisis agregado guía la inversión estructural conforme aprende la organización. |
| Costo, sostenibilidad, software verde | Los costos de nube son una sorpresa mensual; sin etiquetado, asignación, ni conciencia de carbono; aprovisionamiento generoso y sin revisar. | Visibilidad básica de costo y etiquetado; algo de redimensionamiento reactivo y limpieza de recursos ociosos; la sostenibilidad se reconoce pero no se mide. | Una práctica FinOps con atribución, presupuestos, pronósticos, alertas de anomalía, compromisos, redimensionamiento; el carbono se mide para servicios principales. | El costo y el carbono se miden por equipo contra presupuestos y líneas base; las anomalías se marcan. | El costo y el carbono son señales continuas con dueño de equipo; los valores predeterminados eficientes, la optimización automatizada, y la programación consciente del carbono mejoran continuamente en toda la organización. |
Parte 10. Gestión de proyectos, productos, y programas
| Tema | Nivel 1 Iniciar | Nivel 2 Desarrollar | Nivel 3 Estandarizar | Nivel 4 Gestionar | Nivel 5 Orquestar |
|---|---|---|---|---|---|
| Gestión de portafolio y programas | Las prioridades se establecen improvisadamente por quien pida más fuerte; sin vista de portafolio; las dependencias salen a la superficie como crisis; luchas de financiamiento anual. | Un inventario de portafolio revisado periódicamente; objetivos publicados débilmente vinculados al trabajo; un registro de dependencias; presupuesto basado en proyectos. | La estrategia cascada mediante OKR; un marco de priorización consistente; la planificación entre equipos gestiona las dependencias; financiamiento persistente de equipo. | Los resultados del portafolio, la previsibilidad de entrega, y los conteos de dependencia se miden contra líneas base. | El portafolio se reequilibra continuamente con base en evidencia de resultados; las dependencias se diseñan para eliminarse y la cadencia de financiamiento coincide con la cadencia de aprendizaje en toda la organización. |
| Riesgo, auditoría, y aseguramiento | El riesgo se maneja reactivamente después de incidentes; sin marco ni registro; controles no documentados; auditorías manuales dolorosas. | Registros de riesgo para sistemas mayores; se adopta un marco de control, las auditorías pasan pero son manuales y puntuales; los proveedores se evalúan al incorporarse. | Modelo de tres líneas y marco común en toda la organización; muchos controles automatizados; monitoreo continuo; inventarios de proveedores/SBOM; DR programado. | La efectividad del control, los conteos de riesgo abierto, y los hallazgos de auditoría se miden contra el apetito de riesgo y líneas base. | El aseguramiento es continuo y en gran parte automatizado; los auditores muestrean evidencia en vivo y la integridad de la cadena de suministro se verifica conforme evolucionan los riesgos en toda la organización. |
| Adquisición, código abierto, licenciamiento | El código abierto se agrega libremente; sin política ni inventario; las licencias no se examinan; el fin de vida se descubre por accidente; sin dueño. | Una política básica y lista de licencias aprobadas; algo de escaneo manual/tardío; un inventario para sistemas mayores; contribución improvisada. | Una OSPO posee la estrategia y las herramientas; escaneo automatizado de licencia/vulnerabilidad y atribución; SBOM; contribución clara; fin de vida rastreado. | El cumplimiento de licencias, la actualidad de dependencias, y la exposición a vulnerabilidades se miden contra líneas base. | El código abierto es un activo estratégico gestionado con cumplimiento completamente automatizado; la inversión río arriba es deliberada y la actualidad y el fin de vida se gestionan continuamente en toda la organización. |
| Sostener sistemas grandes y de larga vida | Los sistemas dependen de héroes; propiedad por memoria; conocimiento no documentado; los sistemas se congelan hasta que se rompen; los retiros nunca terminan. | La propiedad se asigna y registra para sistemas mayores; algo de documentos y manuales de operación; las funciones críticas obvias tienen una persona de respaldo; mantenimiento reactivo. | Propiedad a nivel de equipo en un catálogo que sobrevive las reorganizaciones; el factor de autobús se mide y mitiga; registros de decisión y manuales de operación; modernización incremental. | El factor de autobús, la cobertura de propiedad, y el progreso de transferencia de conocimiento se miden contra líneas base. | La administración es una disciplina financiada; ningún sistema crítico es un punto único de fallo humano y la transferencia de conocimiento y los finales planificados continúan en toda la organización. |
| Ética, responsabilidad, interés público | La ética no se aborda o es reactiva después de un escándalo; la accesibilidad se ignora; decisiones automatizadas opacas sin recurso; el sesgo sin probar. | Un código de conducta y algo de accesibilidad (tardía); las decisiones automatizadas de alto perfil reciben algo de supervisión; verificaciones de sesgo ocasionales. | La revisión ética es parte del proceso; la accesibilidad se diseña desde el principio y se prueba con usuarios; las decisiones consecuentes llevan explicación y recurso. | Los resultados de equidad, accesibilidad, y responsabilidad algorítmica se monitorean contra líneas base. | La responsabilidad está incrustada en cómo construye la organización; la equidad es un predeterminado no negociable y la responsabilidad algorítmica es estándar y mejora continuamente en toda la organización. |
Autoevaluación de madurez general
Usa las matrices de arriba para producir una puntuación ligera y honesta.
Rúbrica de puntuación
- Califica cada capítulo del 1 al 5 usando el nivel cuya descripción mejor coincida con tu realidad típica. Cuando el comportamiento es inconsistente, califica el nivel más bajo.
- Promedia por parte. Suma las puntuaciones de los capítulos en una parte y divide entre el número de capítulos. Esto da una madurez por parte (por ejemplo, “la Parte IV promedia 2.5”).
- Registra el mínimo, no solo la media. Una parte que promedia 3.0 pero contiene un capítulo de Nivel 1 carga el riesgo de ese capítulo sin importar la media.
- Traza la tendencia. Recalifica cada trimestre o dos y observa la dirección del viaje. Un dominio que se mueve de 2 a 3 es más sano que uno estancado en un 3 estático.
Una hoja de trabajo simple por parte:
| Parte | Capítulos calificados | Promedio (media) | Capítulo más bajo | Notas / prioridad |
|---|---|---|---|---|
| I-X | conteo | media | nivel mínimo | … |
Priorizar qué mejorar
No intentes elevar todo a la vez, y no persigas el promedio más alto. Prioriza por brecha de madurez ponderada por riesgo: ataca los dominios donde un nivel bajo se encuentra con una consecuencia alta.
- Primero: los capítulos de menor madurez en tus dominios de mayor riesgo. Para la mayoría de las organizaciones eso significa la seguridad, la privacidad, la fiabilidad, el cumplimiento, y cualquier sistema cuyo fallo dañe a la gente o viole la ley. Un Nivel 1 aquí es urgente.
- Después: los habilitadores fundamentales (cultura, formas de trabajar, CI/CD, IaC, observabilidad) que elevan el techo de todos los demás dominios. Mejorar estos hace más baratas las ganancias posteriores.
- Más tarde: los dominios que ya están en Nivel 3 y podrían escalar a Nivel 4 o 5. Empuja más allá del piso solo donde lo que está en juego y la escala justifiquen la inversión adicional.
La línea base empresarial y gubernamental
Los contextos empresariales y gubernamentales usualmente no pueden detenerse en “funciona”. Para pasar auditorías, sostener autorizaciones, y cumplir con obligaciones regulatorias y de responsabilidad pública, la mayoría de los dominios deben alcanzar al menos Nivel 3 (Estandarizar), el nivel donde las prácticas están estandarizadas, documentadas, aplicadas entre equipos, y producen evidencia. El Nivel 2 típicamente falla la auditoría porque es inconsistente y ensamblado manualmente bajo fecha límite; el Nivel 1 falla directamente.
Lee el Nivel 3 como el piso para cualquier cosa auditable o relevante para la seguridad, y los niveles superiores (4 y 5) como objetivos solo donde el aseguramiento continuo, la escala, o la confianza pública hagan que el rigor adicional valga la pena. La madurez sigue siendo un medio: el objetivo es un nivel de control defendible y proporcionado para el riesgo que realmente cargas, no una puntuación perfecta.