Iteración y cadencia de releases

Refinar · 6.2

Por qué esto importa ahora

Dos patrones habituales tras el go-live: (1) ya no cambia nada («estamos en marcha, listo») y (2) todo cambia de forma ad hoc (cada cambio es una crisis). Ambos conducen a la parálisis o al caos. Una cadencia de releases evita los dos: cambios pequeños, predecibles, con los mismos pasos.

¿Qué entregas?

Calendario de releases

Ritmo fijo (p. ej. mensual, primer martes) con alcance y ventanas de congelación.

Flujo RFC

Plantilla de Request for Change: solicitud → triaje → impacto → aprobación → release.

Estrategia de pruebas

Entorno de aceptación + smoke tests por release, con sign-off por responsable de servicio.

Plantilla de comunicación

Qué cambia, cuándo y para quién: notas de versión que los usuarios entienden.

Tres tipos de cambio, tres cadencias

Pequeño y seguro

Cuando haga falta

Añadir un campo, publicar un artículo de KB, cambiar una plantilla. El responsable lo aplica y lo registra en el change register.

Mediano

Release mensual

Cambio de flujo de trabajo, ampliación de clasificación, nuevo informe. Flujo RFC, prueba de aceptación, comunicación.

Grande / estructural

Release trimestral

Activar un módulo nuevo, añadir una integración, subir la IA al siguiente nivel. Miniproyecto, decisión del comité de seguimiento.

Preguntas clave

1Qué ritmo encaja: sprint (2 semanas), mes o trimestre para la capa «mediana». ¿Cuánto cambio absorben los usuarios?
2Quién hace el triaje de las change requests entrantes. ¿Qué criterios (impacto × frecuencia × esfuerzo) usas?
3Aprobación: qué change board aprueba qué. Qué cambios puede hacer un admin solo y cuáles requieren al sponsor.
4Entorno de aceptación: ¿lo tienes? ¿Cómo sincronizas la configuración de producción con test? ¿Cuánto pruebas antes de ir a producción?
5Smoke tests por release: un conjunto mínimo de escenarios que siempre debe pasar, sea cual sea el contenido.
6Roll-back por cambio: sobre todo para retoques de flujo. ¿Puedes revertir si el comportamiento falla?
7Notas de versión: quién las escribe, en qué idioma y con qué nivel de detalle. Para usuarios: cortas y en su idioma. Para admins: detalle técnico.
8Momentos de congelación: ¿nada de cambios en semana de auditoría, cierre fiscal, fin de año? Bloquéalos en el calendario.
9Backlog: ¿dónde vive la lista de change requests abiertas? Quién prioriza y con qué frecuencia.
10Actualizaciones de producto de Gfacility: leer las notas de versión, comprobar regresiones, informar a los usuarios. ¿Quién es dueño de ese ritmo?

Plantilla — Ficha de RFC

Campo	Valor de ejemplo
Título	Añadir la categoría «Asistente de IA» al flujo de tickets IT
Solicitante / responsable de servicio	Sara Janssen (Service manager)
Tipo	Mediano — ampliación de clasificación
Por qué	El 15% de los tickets son sobre Copilot/herramientas de IA, hoy clasificados como «otros»
Impacto	Informes, regla de routing por IA, etiquetas de KB
Riesgos	Los tickets existentes en «otros» requieren reclasificación
Roll-back	Desactivar la categoría: los tickets existentes mantienen su valor
Release propuesta	Release mensual de noviembre
Aprobación	CAB (service mgr, configurador, PM): no se requiere sponsor

Plantilla — Calendario de releases

Mes	Fecha de release	Freeze de/a	Foco del alcance	Comunicación
Oct	Mar 7 oct 20:00	Vie 3 oct — Mié 8 oct 9:00	Cambios de flujo IT	Notas de versión vie
Nov	Mar 4 nov 20:00	Vie 31 oct — Mié 5 nov 9:00	Ampliación de clasificación	Notas de versión vie
Dic	— (ninguna)	Mes completo	Freeze por cierre anual	Aviso a finales de nov
Ene	Mar 13 ene 20:00	Vie 9 ene — Mié 14 ene 9:00	Release trimestral: nuevo panel	Notas de versión + sesión informativa
…	…	…	…	…

← Monitorización de KPI y paneles Siguiente: Activar y escalar la IA →