Integración de Proyectos · Serie 2 · Semana 2 · Tema 2
Una pregunta que parece tonta y hunde proyectos: ¿qué versión exacta de qué cosa está funcionando ahora mismo?
En un proyecto pequeño la respuesta es obvia. En uno con cuatro entornos, tres proveedores y dieciocho meses de historia, esa pregunta puede tardar dos días en responderse, y la respuesta suele ser aproximada.
La gestión de configuración es la disciplina que existe para que eso no pase. Su objetivo es establecer y mantener la integridad de los productos a lo largo de todo el ciclo de vida. Suena a burocracia; en realidad es lo que permite volver atrás cuando algo sale mal.
Es una condición previa de cualquier verificación de calidad: no se puede certificar algo si no se sabe qué versión se certificó.
Qué es, en una frase
Gestión de configuración es saber, en cualquier momento, qué elementos componen el producto, en qué versión están, quién los cambió, cuándo y por qué.
No es control de cambios, aunque se confundan constantemente. La diferencia importa:
- Control de cambios decide si un cambio se aprueba. Es una decisión.
- Gestión de configuración mantiene el registro de qué hay y en qué estado. Es un inventario vivo.
Se necesitan las dos. Aprobar cambios sin saber sobre qué línea base se aplican produce aprobaciones que no significan nada.
Los cuatro procesos
1. Identificación de la configuración
Decidir qué elementos se controlan y cómo se nombran. Suena trivial y es donde se decide si todo lo demás va a funcionar.
Dos reglas que se pagan caras cuando se ignoran:
- Controla lo que puede romper algo. No todo documento necesita control de configuración. El plan de proyecto sí; las minutas de reunión probablemente no.
- El identificador tiene que ser único y hablar. Un esquema de versiones tipo mayor.menor.parche comunica el tipo de cambio en el número. «documento_final_v2_REVISADO_bueno.docx» no comunica nada, y todos hemos visto esa carpeta.
2. Control de cambios y de configuración
El circuito completo: solicitud, evaluación de impacto, aprobación o rechazo, implementación, verificación.
Lo más importante aquí es la evaluación de impacto, que es el paso que más se salta. Un cambio que parece de dos horas puede tocar tres componentes, invalidar cinco pruebas y requerir una actualización de documentación que nadie contó. La pregunta no es «¿cuánto cuesta hacer este cambio?» sino «¿qué más deja de ser cierto si lo hago?».
Quién aprueba también importa: un comité con demasiada gente convierte cualquier cambio en un trámite de dos semanas, y la consecuencia predecible es que el equipo empiece a hacer cambios «pequeños» sin pasar por ahí. Un proceso de cambios demasiado pesado no evita los cambios: los vuelve invisibles.
3. Auditorías y reportes de configuración
Verificar que lo que dice el registro coincide con lo que hay de verdad. Es el proceso que nadie quiere hacer y el único que demuestra que los otros tres funcionan.
Una auditoría de configuración responde a dos preguntas: ¿está todo lo que debería estar? y ¿lo que está es la versión que dice el registro? Cuando la respuesta a la segunda es «no» de forma sistemática, el registro dejó de ser útil y la gente ya lo sabe, aunque lo siga rellenando.
4. Control de interfaces
El punto donde tu producto se toca con otro. Es donde ocurren los fallos más caros, porque cada lado asume que el otro no cambió.
La regla práctica: una interfaz tiene dos dueños y por eso, en la práctica, no tiene ninguno. Si no está asignada explícitamente a una persona, los cambios de un lado llegarán al otro como sorpresa.
La línea base: el concepto que sostiene todo
Una línea base es una versión aprobada de un conjunto de elementos, que solo se modifica mediante el procedimiento formal de cambios. Es un punto fijo desde el cual medir.
Sin línea base no existe el concepto de desviación. Si el plan cambia cada vez que la realidad no lo cumple, el proyecto siempre va según lo previsto —y nunca se aprende nada—. Es la trampa más elegante de la dirección de proyectos: un cronograma que se actualiza para coincidir con lo que pasó es un registro histórico, no un plan.
Qué suele tener línea base
- Alcance: la EDT y el enunciado del alcance.
- Cronograma: fechas aprobadas.
- Costos: presupuesto aprobado.
- El producto mismo: versiones de entregables, configuraciones de entorno, documentación técnica.
Caso práctico: el entorno que nadie podía reproducir
Escenario construido con patrones habituales; las cifras son ilustrativas.
Un equipo entrega un sistema que funciona perfectamente en pruebas. En producción falla de forma intermitente, una vez cada tres o cuatro días, sin patrón aparente.
Tres semanas de diagnóstico. Se revisa el código, se revisan los datos, se revisa la carga. Todo correcto.
El problema resultó ser una librería. El entorno de pruebas tenía una versión y el de producción otra, con una diferencia de comportamiento en un caso límite. Nadie lo cambió a propósito: producción se había instalado cuatro meses antes que el entorno de pruebas actualizado, y ninguno de los dos tenía registrada su configuración exacta.
El coste de tres semanas de diagnóstico fue varias veces superior al de haber mantenido un inventario de versiones desde el principio. Y lo verdaderamente costoso fue lo que no se pudo hacer durante esas tres semanas.
Cuánta ceremonia hace falta
Aquí conviene ser honesto: la gestión de configuración formal, con comité y plan documentado, es excesiva para un proyecto de tres personas y dos meses. Aplicarla entera ahí solo consigue que nadie la use.
La versión mínima que sí vale la pena en cualquier proyecto:
- Un lugar único donde vive la versión buena de cada cosa. Uno, no tres.
- Un esquema de versiones que se respete, aunque sea sencillo.
- Un registro de qué está desplegado dónde, aunque sea una hoja de cálculo de diez filas.
- Un momento en el que se congela una versión y se le pone nombre.
Eso se monta en una tarde y resuelve el 80% de los problemas que la versión formal resuelve al 100%.
Checklist
- Si tuvieras que volver al estado de hace tres semanas, ¿podrías? ¿En cuánto tiempo?
- ¿Sabes exactamente qué versión de cada componente está en producción?
- ¿Tus entornos son reproducibles, o cada uno tiene su historia?
- ¿El proceso de cambios es lo bastante ágil como para que la gente lo use, o ya hay atajos?
- ¿Cada interfaz con un sistema externo tiene una persona responsable con nombre?
- Cuando el cronograma se desvía, ¿se registra la desviación o se actualiza la línea base?
Para cerrar
La gestión de configuración no evita los problemas: hace que los problemas sean investigables. Esa es toda su promesa, y es suficiente para justificarla, porque la alternativa —depender de que alguien recuerde qué cambió— falla exactamente cuando más se necesita.
Te leo en los comentarios: ¿cuánto tardarías hoy en decir con certeza qué versión de qué está corriendo en producción?
Referencias
- Project Management Institute, Guía del PMBOK, sobre el plan de gestión de la configuración dentro del plan para la dirección del proyecto.
- IEEE 828, estándar para planes de gestión de configuración de software.
- ISO 10007, directrices para la gestión de la configuración.
- Humble, J. y Farley, D., Continuous Delivery, sobre reproducibilidad de entornos.
← Anterior en la serie: Objetivo y alcance: la confusión que descarrila proyectos desde el primer día
Siguiente en la serie: El plan de gestión de configuración: qué escribir y qué dejar fuera →
Este artículo forma parte de Integración de Proyectos, una serie de 20 artículos. Ver todos los de esta serie · Índice completo por materia.