Las 10 mejores prácticas recomendadas para la gestión de los cambios

Cuando se trata de encontrar el equilibrio entre riesgo y agilidad, en la gestión de los cambios no hay una solución buena para todo el mundo. Cada organización tiene su cultura, su tolerancia al riesgo y sus requisitos reglamentarios propios, y cada una debe integrar estos aspectos en sus prácticas de gestión de los cambios.

Para conocer el riesgo, es necesario conocer también las exigencias legales y de cumplimiento de normas de tu empresa. Cuando la regulación entra en escena, la cuestión deja de ser cuánto tiempo de inactividad del sistema es asumible antes de perder negocio o cuánto costará tener que solucionar un problema, porque tendrás un conjunto de reglas no negociables. Deberás tener ciertas aprobaciones y separarás obligaciones. Con reglamentos como SOX y el RGPD, ciertas actividades no son negociables, por mucho que ralenticen el procedimiento.

La buena noticia es que esta planificación no tiene por qué ser estática. Las empresas que optan por una estrategia conservadora con más aprobaciones y flujos de trabajo rígidos pueden reevaluar con el tiempo, y ajustar el nivel de rigor de sus procesos en equilibrio con el nivel de riesgo.

Con Jira Service Management, las aprobaciones y los flujos de trabajo se pueden personalizar según las especificaciones de la organización. Haz que los procesos sean tan flexibles o automáticos como desees. Quizá te interese automatizar más procesos de bajo riesgo y proteger procesos más complejos mediante aprobaciones.

Una base importante para mejorar las prácticas de gestión de los cambios es hacer un seguimiento de las métricas, especialmente las que vinculan cambios e incidentes. Los datos sacarán a la luz tendencias y mostrarán los tipos de gestión cambios, miembros del equipo y servicios con menos probabilidades de verse involucrados en un incidente. Esa información puede servir para equilibrar rigor con riesgo ante diferentes solicitudes de cambio.

Con una evaluación inteligente de riesgos, es más habitual poder asignar solicitudes de cambio a flujos de trabajo de aprobación menos rigurosos. Como sugiere el proceso de gestión de cambios adaptativo de Gartner, las organizaciones pueden clasificar más cambios habituales como cambios estándar que se puedan preaprobar y automatizar.

A continuación, hemos reunido algunos pasos prácticos para que los cambios estándar sean tu nueva normalidad.

1. Revisa los cambios realizados en los últimos meses
   • ¿Cuáles han sido los cambios más habituales?
   • ¿Qué cambios son "cambios estándar"?
   • ¿A qué servicios afectan?
   • ¿Qué cambios salieron bien?
   • ¿Qué tiempo se dedicó de media a implementar estos cambios?
   • ¿Qué cambios solicitaron los equipos de desarrollo?
2. Elige de tres a cinco cambios estándar que puedan optar a la automatización
3. Crea tipos de solicitud de autoservicio en tu software de gestión de asistencia para los cambios estándar
   • Añade descripciones para aclarar el propósito y el alcance de las solicitudes de cambio estándar
   • Recopila datos importantes, como el sistema, la aplicación o el servicio que se van a cambiar
   • Crea reglas de automatización para aprobar automáticamente el cambio, pasar de un estado a otro y notificar novedades al personal
4. Dedica un tiempo a informar y a formar a tu personal de TI y a los equipos de desarrollo sobre esta nueva capacidad
5. Supervisa los resultados a lo largo de unos meses
   • Obtén información con la que mejorar los servicios existentes
   • Identifica otros cambios estándar para la automatización

Después de evaluar las prácticas anteriores de gestión de los cambios del equipo y evaluar el riesgo del cambio, puede ser práctico compilar toda la documentación de la evaluación de riesgos en un solo lugar. Con la integración de Confluence de Jira Service Management, los equipos pueden consultar una fuente fiable alojada en un documento de plan de cambios. En esta página, los colaboradores pueden añadir una plantilla de plan de cambios además de la información de evaluación de riesgos.

Nadie quiere trabajar de más. Por eso, la gestión de los cambios suele ser vista como una molestia. Con las prácticas de gestión de los cambios, es habitual que los usuarios tengan que hacer registros en herramientas en la que no les gusta trabajar, así como que tengan que añadir pasos de trabajo a sus procesos. Además, los desarrolladores encargados de implementar código pueden tener la sensación de que estas tareas adicionales les roban tiempo de su verdadero trabajo. Aquí es donde una fuente central de veracidad, como una página de Confluence de plan de cambios, puede facilitar la documentación al involucrar a todo el equipo.

La respuesta a este gran reto es simplificar al máximo los procesos de gestión de los cambios. Reduce las aprobaciones al mínimo. Elige herramientas técnicas que se integren a la perfección, para que los desarrolladores no tengan que introducir la misma información una y otra vez en varios sistemas. Además, automatiza siempre que puedas. Estas funciones de Jira Service Management ofrecen a los equipos la flexibilidad de trabajar a su propio ritmo y a su manera.

Cuanto más sencillo puedas hacer el proceso, más fácil será también que los equipos se sumen (y sigan a bordo).

En la mayoría de las organizaciones de TI tradicionales, un comité asesor de cambios (CAC) se encarga de evaluar las consecuencias técnicas y empresariales de las solicitudes de cambio. El proceso tradicional tiene algunos contras: publicaciones lentas, procesos complejos y, a veces, falta de comunicación y colaboración. Por eso, los equipos con mejores resultados han redefinido el modelo CAC.

El objetivo es mantener el valor que estos comités aportan a nuestros procesos de TI (al permitir la comunicación y equilibrar la necesidad de cambios con los riesgos que estos suponen), haciendo al mismo tiempo más ágil y estratégico el proceso típico de CAC. Habitualmente, esto supone lo siguiente:

• Solicitar únicamente la aprobación del CAC para los cambios con mayor riesgo (y usar herramientas probadas como la revisión por pares, las checklists virtuales y la automatización para gestionar cambios con menor riesgo)
  
• Dejar a los CAC al cargo de la estrategia y ayudar a los equipos a desarrollar prácticas que reduzcan el riesgo y la carga de trabajo de la gestión de los cambios mediante la automatización y la eficiencia de los procesos
  
• Tener CAC virtuales y en tiempo real, en lugar de esperar a reuniones presenciales para resolver preguntas sobre procesos o cambios importantes

La clave es pasar a centrarse en la estrategia. En lugar de actuar como un cuerpo supervisor, el papel del nuevo CAC es hacer posible el cambio. En lugar de convertirse en un cuello de botella, el nuevo CAC es un recurso estratégico. La revisión de código y el acceso a los problemas técnicos se reservan a las revisiones de pares y a las personas más adecuadas para detectar errores en el código. Así, el CAC puede centrarse en el proceso, la estrategia y el apoyo a la entrega continua.

El enfoque tradicional era agrupar publicaciones y lanzarlas todas a la vez. Sin embargo, este enfoque se presta a incidentes importantes y dificulta encontrar la fuente de los problemas que puedan surgir. Unas publicaciones más pequeñas y habituales pueden limitar el alcance de los posibles incidentes. En la implementación progresiva, se comienza por la implementación de un valor controlado o una marca de función en un grupo pequeño de usuarios, que lo testea y prueba su estabilidad antes de pasar a la implementación completa.

Organizar publicaciones más pequeñas y controladas es más sencillo cuando los equipos pueden coordinar estas publicaciones en una planificación de cambios. Esto ayuda a los desarrolladores a evitar áreas de conflicto o a identificar fechas restringidas. Las funciones del gestor de cambios de Jira Service Management permiten a los equipos acceder a una planificación centralizada con la información que necesitan para ejecutar las publicaciones fragmentadas.

A veces, ITIL tiene mala reputación. Puede parecer restrictivo y anticuado. Sin embargo, ITIL tiene mucho que ofrecer a los equipos de TI, incluidos aquellos que han adoptado una cultura de DevOps. En este caso, además, el problema no es que ITIL sea demasiado rígido, sino el enfoque adoptado con respecto a sus pautas.

Si concibes ITIL como una serie de reglas absolutas, por supuesto que te resultará restrictivo. Sin embargo, si lo concibes como un conjunto de pautas de base a partir de las que tu empresa puede elaborar las suyas propias, lo verás como una ventaja para el desarrollo de tus prácticas de gestión de los cambios.

Esto se aplica a todos los conceptos de culturas y marcos de trabajo. ITIL, lean, DevOps, metodología ágil, CD... No hay marco de trabajo, por muy popular que sea, que vaya a resolver todos tus problemas en una simple jugada. Con demasiada frecuencia, buscamos un marco o una herramienta que resuelva los problemas internos, cuando deberíamos fijarnos en la cultura de equipo.

Desde CAC hasta los grupos de DevOps, los equipos de liderazgo apuestan por la colaboración, la mentalidad abierta y la información en tiempo real. La gestión de los cambios exige la coordinación entre equipos. Los efectos de cambios, incidentes y problemas se extienden a más de un equipo y esto se hace más evidente cuanto más compleja es la organización.

Una buena gestión de los cambios no puede estar segmentada. Las organizaciones que se esfuerzan por fomentar una colaboración más abierta tienen muchas papeletas de mejorar sus prácticas de cambio.

Todo en Jira Service Management está orientado a unificar a los equipos para cumplir los objetivos más rápido: en este caso, implementar cambios más rápido y sin incidentes. El mecanismo de los equipos cohesivos y de alta velocidad es la colaboración. Una plataforma transparente equipada con herramientas como Confluence, chat y videoconferencia integrados y flujos de trabajo personalizables permite a todos participar y hacer su parte, a su manera, con todo el contexto.

La ingeniería del caos es una práctica reciente que interrumpe o desconecta componentes de un producto o servicio para poner a prueba su resiliencia. De modo parecido, la ingeniería de la resiliencia aborda deliberadamente todos los posibles agentes de estrés en un sistema y lo lleva a sus límites, con un gran número de usuarios o tráfico elevado, por ejemplo.

Ambas prácticas permiten identificar problemas y determinar los cambios necesarios para evitar futuros incidentes. Este enfoque preventivo está aportando mucho valor a los equipos de gestión de los cambios y supone significativos ahorros de tiempo, presupuesto y fatiga por exceso de alertas a los equipos de gestión de incidentes.

Unos buenos procesos de gestión de los cambios deben integrarse en todas las herramientas que utilizan tus desarrolladores. Pedir a los equipos que aprendan a usar una nueva herramienta, introduzcan información en varias herramientas o manejen una herramienta que no conocen bien o que les resulta incómoda tiende a ralentizar la adopción. Esto, a su vez, afectará a tu capacidad para ofrecer actualizaciones valiosas a los clientes.

En Atlassian, hacemos un seguimiento de los cambios con Jira Service Management. Con la plataforma Jira, es sencillo reunir a los equipos de desarrollo y operaciones, lo que proporciona transparencia e información de contexto rastreable desde antes de que los desarrolladores comiencen a programar hasta que los cambios se implementan en la producción.