Close

Ready for ITSM at high velocity?

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

La gestión de los cambios tiene fama de ser compleja y de tener unos procesos arduos, pero no tiene por qué ser así. Si se lleva a cabo correctamente, la gestión de los cambios de TI reduce los incidentes, al tiempo que garantiza la agilidad de los procesos y reduce al mínimo las interrupciones de la actividad.

¿Cómo debería llevarse a cabo la gestión de los cambios? Estas 10 prácticas recomendadas te ayudarán a comenzar con buen pie:

1. Conoce la tolerancia al riesgo de tu organización y planifica en consecuencia

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.

2. Utiliza la evaluación de riesgos basada en datos para adaptar de forma continua tu práctica de gestión de los cambios

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 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

3. Simplifica al máximo la gestión de los cambios

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, y tener 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.

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.

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

4. Redefine el modelo de CAC tradicional

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.

5. Utiliza herramientas para automatizar y perfeccionar los procesos

Automatizar tus herramientas es una de las mejores maneras de minimizar la carga de los procesos de gestión de los cambios en tus equipos. Contar con comprobaciones y balances sencillos dentro de nuestras herramientas nos sirve para garantizar el cumplimiento. Además, reduce significativamente el riesgo, sin que las personas tengan que dedicar tiempo innecesario a nuevos procesos.

Como explicó el experto en riesgos de Atlassian, Guy Herbert, en un artículo reciente sobre riesgo y cumplimiento: “La verdad es que la mayoría de nosotros no necesita un proceso de aprobación de seis capas y meses de idas y venidas con comités de evaluación del cumplimiento… Lo que realmente necesitamos son unas comprobaciones y unos balances sencillos que bloqueen los cambios que no garanticen el cumplimiento. Gran parte de este trabajo se puede hacer con nuestras propias herramientas. Bitbucket, por ejemplo, impide a nuestros desarrolladores que vuelvan a insertar el código en el que han estado trabajando en la base de datos si no lo ha revisado antes otro desarrollador apropiado. Bamboo no lanza código nuevo si este no ha pasado por los procesos de cumplimiento en Bitbucket”.

6. Implementa publicaciones más pequeñas y de forma progresiva

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 un indicador 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.

7. ITIL marca pautas, no reglas absolutas

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.

8. Da prioridad a la colaboración

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.

9. Saca partido de la ingeniería del caos y de la resiliencia

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.

10. Elige herramientas que sean familiares y aceptadas en los equipos de desarrollo

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.