Los equipos de alto desempeño despliegan varias veces al día. Los marcos tradicionales de gestión de configuración fueron diseñados para ciclos de cambio medidos en semanas o meses. Cuando la velocidad del software supera a tu modelo de gobernanza, el instinto suele ser concluir que el marco está roto.
El problema no suele ser el marco, sino cómo se aplica
Ese instinto normalmente es incorrecto.
El problema no es el marco en sí. El problema es la granularidad con la que se aplica.
La industria ya no solo habla de velocidad, sino de riesgo y resiliencia
Un análisis de tendencias DevOps de 2026 encontró que la industria está dejando de enfocarse únicamente en la frecuencia de despliegue y está dando más importancia a métricas como resultados, riesgo y resiliencia.
La pregunta está cambiando de:
“¿Qué tan rápido podemos liberar?”
a:
“¿Qué tan bien pueden nuestros sistemas absorber cambios constantes?”
Ese cambio de enfoque suena bastante familiar para cualquiera que haya trabajado en gestión de configuración. Es la diferencia entre velocidad y control, y la respuesta nunca ha sido elegir solo una de las dos.
El error más común: usar el mismo nivel de gobernanza para todos los cambios
Lo que muchas organizaciones hacen mal es aplicar el mismo umbral de gobernanza a cada cambio.
Una actualización cosmética de interfaz y un cambio en un algoritmo crítico para la seguridad no requieren el mismo nivel de revisión.
Sin embargo, cuando no existe un marco que defina con claridad dónde está ese límite, las organizaciones suelen caer en uno de estos dos errores:
- Todo pasa por una revisión completa, lo que crea cuellos de botella que los equipos terminan buscando cómo evitar.
- Nada recibe una revisión realmente significativa, lo que genera riesgos que terminan apareciendo en producción.
Qué aporta CM2 en este contexto
Aquí es donde CM2 ofrece algo distinto.
No se trata de una cuarta respuesta específica para una industria, sino de un vocabulario neutral frente al marco para formular la pregunta correcta.
No pregunta:
“¿Qué exige tu estándar?”
Sino más bien:
“¿Qué está intentando lograr realmente tu estructura de gobernanza y dónde debería estar el límite entre lo rápido y lo lento?”
La relación entre CM2 y la gobernanza escalonada del cambio
Esto se relaciona directamente con la idea de una gobernanza escalonada del cambio.
- Los cambios de bajo riesgo, con cobertura de pruebas suficiente, pueden avanzar por rutas de aprobación ligeras.
- Los cambios de alto riesgo, que afectan la seguridad, la interoperabilidad o el cumplimiento regulatorio, requieren una revisión completa del CRB y una planificación de implementación del CIB.
El modelo ServiceNow DevOps Change Velocity implementa exactamente este patrón: aprueba automáticamente los cambios de bajo riesgo mientras conserva la revisión manual para los de alto riesgo.
La idea clave: no se necesita menos CM, se necesita CM más granular
La idea más importante aquí es que los productos intensivos en software no necesitan menos gestión de configuración.
Necesitan una gestión de configuración más granular.
La estructura de gobernanza debe corresponder al perfil de velocidad de cada categoría de cambio, en lugar de aplicar una sola velocidad a todos los cambios por igual.
La pregunta final para tu organización
Entonces, la pregunta importante sería esta:
¿Tu marco de CM está frenando la entrega de software?
¿O en realidad es la forma en que lo estás aplicando la que no puede distinguir entre los cambios que requieren gobernanza y los que requieren velocidad?
¿Listo para profundizar?
Usa el código Martijn10 para obtener un 10% de descuento en la capacitación, y no olvides decirles que Martijn te envió 😉.
Derechos de autor del Institute for Process Excellence
Este artículo fue publicado originalmente en ipxhq.com y mdux.net.