Cómo los equipos comparten los roles y las responsabilidades de la gestión de los cambios

Coordinadores/gestores del cambio

Los gestores del cambio (a veces denominados "coordinadores del cambio") suelen encargarse de gestionar todos los aspectos relacionados con los cambios de TI. Priorizan las solicitudes de cambio, evalúan su impacto y aceptan o rechazan los cambios. También documentan los procesos de gestión de los cambios y los planes de cambio. Es importante subrayar que preparan, organizan y presiden las reuniones de los CAC. El éxito de un gestor del cambio suele evaluarse en función del cumplimiento de los objetivos de tiempo y presupuesto.

Autoridades/aprobadores del cambio

Las autoridades del cambio se ocupan de decidir si aprobar o no un cambio. A veces se trata de una sola persona, como un gerente o un ejecutivo. Otras, es un grupo de personas en un comité asesor de cambios y otras, un par encargado de la revisión. Según ITIL 4, "en las organizaciones más ágiles, es habitual descentralizar la aprobación de cambios, haciendo de la revisión por pares un elemento clave para predecir el alto rendimiento".

Los gestores del cambio suelen colaborar estrechamente con la autoridad del cambio para aprobar los cambios y llevarlos adelante dentro de una organización. En algunos casos, especialmente en las organizaciones pequeñas, el gestor del cambio es también la autoridad del cambio y tiene el poder de tomar estas decisiones sin tener que recurrir a más personas o equipos.

Partes interesadas de la empresa

Las partes interesadas de la empresa suelen participar en la gestión de los cambios y pueden intervenir en el proceso de autorización. Esto es cada vez más habitual, dada la importancia fundamental que los servicios de software tienen para la mayoría de las empresas.

Por ejemplo, si un cambio afecta a la conexión entre el software de seguimiento de pagos del equipo financiero y el CRM del equipo de ventas, es posible que las partes interesadas de los equipos de finanzas y ventas deban participar en las reuniones del CAC y en las decisiones definitivas sobre un cambio.

Ingenieros/desarrolladores

Los equipos de desarrollo suelen presentar cambios para su aprobación y documentan el caso en función de su necesidad. Una vez que se aprueba un cambio, en las empresas que han optado por una estrategia de "tú lo compilas, tú trabajas con él" (es decir, de responsabilidad sobre la implementación de las propuestas), son los propios equipos los que implementan el cambio, lo supervisan y, a menudo, responden ante cualquier incidente o problema relacionado con él. En otros casos, el equipo de gestión de incidentes responsable de cualquier incidente causado por el cambio puede ser independiente de los desarrolladores que lo implementan.

Agentes del centro de asistencia

Los agentes del centro de asistencia pueden aportar una perspectiva única y de primera línea sobre incidentes y problemas de servicio habituales que un cambio puede ocasionar.

Gestores de operaciones

Dado que se encargan de mantener los sistemas funcionando a diario, los gestores de operaciones ponderan los riesgos y las dependencias.

Gestores de relaciones con los clientes

Para representar la voz del cliente, los gestores de relaciones pueden ofrecer información sobre las actitudes de los clientes, sus insatisfacciones y necesidades en constante cambio.

Ingenieros de redes y responsables de seguridad de la información

Los expertos en seguridad de redes e infraestructura de nube aportan información importante sobre amenazas y vulnerabilidades.

¿Qué es un CAC?

En los comités asesores de cambios se reúnen las personas con las responsabilidades detalladas anteriormente y son grupos encargados de evaluar los riesgos de las solicitudes de cambios y de aprobarlas (o no). Habitualmente, los CAC celebran reuniones programadas con regularidad para revisar los próximos cambios propuestos. Además, recurren a expertos según sea necesario para que aclaren, defiendan o evalúen el cambio. Los CAC tradicionales son entidades supervisoras que controlan la publicación de los cambios.

Por esta razón, los CAC no suelen tener muy buena fama (por no olvidar las tediosas reuniones, los largos tiempos de respuesta a las solicitudes de cambio y la distancia que tienen con respecto al trabajo en sí). Afortunadamente, muchos CAC están evolucionando para permitir una mejor entrega de software ágil y asumiendo un papel asesor más estratégico. Los CAC se están transformando en cuerpos asesores encargados de supervisar las tendencias de cambio, recomendar prácticas que permitan responder a ellas y buscar formas de que los equipos ofrezcan valor a los clientes y reduzcan el riesgo.

El reto de los CAC

Todos los estereotipos que rodean a las malas reuniones también se aplican a los CAC. Todos hemos oído que son una pérdida de tiempo, que no sirven de nada, que involucran a personas poco relevantes o que se celebran cuando habría bastado enviar un correo electrónico. En parte, esto se debe a que lo habitual ha sido atribuir demasiadas responsabilidades a los CAC.

Ilustraremos el reto que esto supone con una metáfora. El CAC vendría a ser como la torre de control de un aeropuerto. Esa torre de control tiene un cometido: decir a los aviones cuándo pueden aterrizar. No se encarga de valorar su seguridad estructural ni de comprobar si el piloto tiene la titulación necesaria, porque estos aspectos son responsabilidad de Aviación Civil o de la Agencia Europea de Seguridad Aérea.

Sin embargo, muchos CAC reúnen a diferentes partes interesadas y se encargan de tomar decisiones de seguridad amplias sobre todo tipo de cambios. Además, suelen reunirse al final de la semana, cuando la gente está cansada y deseando marcharse a casa para disfrutar de un merecido descanso. Así las cosas, los CAC no comienzan con buen pie.

Además, es frecuente que el foco de atención de los CAC sea el riesgo de que se produzcan cambios que causen incidentes. Por supuesto, es una cuestión importante, pero también deben sopesar el riesgo que supone retrasar cambios de valor. Ser demasiado lentos puede perjudicar a los clientes y, en un software tan competitivo como el del mundo de los servicios, puede llegar a hundir una organización.

Es posible especializar el papel de los CAC y llevarlos a un nivel superior. Con las prácticas adecuadas, muchos cambios podrían automatizarse. Con ello, el CAC podría convertirse en un asesor importante, ocupado de seguir tendencias y de colaborar con equipos para agilizar los cambios que sean positivos para los clientes.

Cómo posicionar tu CAC como asesor estratégico

El primer paso para redefinir la posición del CAC es abandonar la idea de que una gestión de los cambios compleja siempre se traduce en resultados positivos. Según el Informe del estado de DevOps, 2019, los procesos que requieren la aprobación de un CAC repercutieron negativamente en la entrega de software. Por su parte, los encuestados que siguieron estos procesos tenían más del doble (concretamente, el 2,6) de probabilidades de tener un bajo rendimiento. Además, nada pudo probar que los procesos de aprobación formales redujeran la posibilidad de fallo de los cambios.

Por ello, los equipos modernos están tomando estos pasos para mejorar sus CAC.

Deja de aplicar un mismo procedimiento a todas las solicitudes de cambio

Cada solicitud nos da la oportunidad de rastrear y recopilar información. Así, podemos conocer mejor los porcentajes de éxito, los incidentes relacionados y los factores correspondientes. Con el tiempo, la aplicación de esos datos permitiría preaprobar y automatizar cada vez más cambios. Solo los cambios más significativos y arriesgados deberían requerir la aprobación presencial.

Aúna la gestión de cambios y de publicaciones

El enfoque tradicional era agrupar publicaciones y lanzarlas todas a la vez. A continuación, los CAC revisaban con detalle y aprobaban grandes paquetes de cambios. Este enfoque puede prestarse a incidentes importantes y dificulta encontrar la fuente de los problemas que puedan surgir. También ralentiza el ritmo al que los equipos pueden ofrecer valor a sus clientes. Por todo esto, además, los gestores de cambios y publicaciones pueden dedicar menos tiempo a las tareas de gestión de proyectos.

Utiliza publicaciones progresivas para realizar pruebas e iteraciones

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. Esto limita el alcance de un posible incidente y demuestra el éxito de una implementación antes de introducirla en todos los entornos.

Utiliza la automatización y herramientas para agilizar la gestión de los cambios

Los equipos más ágiles están empezando a redefinir los modelos de aprobación anteriores. En lugar de abordar un largo backlog de solicitudes de cambio en una reunión semanal en persona, se puede recurrir a la colaboración virtual. Puede ser algo tan sencillo como enviar un correo electrónico que detalle las solicitudes de cambio, para poderlas revisar antes de que el CAC se reúna. En otros casos, elementos como los tickets de Jira y las páginas de Confluence pueden ofrecer a los revisores de cambios el contexto que necesitan para colaborar y aprobar cambios de manera asíncrona. Con Jira Service Management, los equipos pueden colaborar de estas maneras, incluso para participar en una videoconferencia o crear un canal de Slack específico. Según cómo prefiera tu equipo mantenerse en contacto, seguirá alojado en el mismo lugar para que todos los integrantes permanezcan coordinados.

Unas herramientas heredadas de ITSM dificultan que los equipos de infraestructura, operaciones y desarrollo generen solicitudes de cambio. Apuesta por la automatización y por un software actual que reduzca el esfuerzo de introducir manualmente la información sobre los cambios. Lo último que quiere hacer un desarrollador es rellenar tickets en un sistema diferente y tedioso, y mucho menos si ese trabajo pudiera resolverse automáticamente. Dentro de Jira Service Management, los equipos pueden aprovechar la automatización para agilizar el proceso de cambios, minimizar los riesgos y reducir el tiempo de inactividad.

Adopta una estrategia Shift Left y acerca la gestión de los cambios a los profesionales

Una de las estrategias más habituales que suele sustituir las aprobaciones de los CAC (o reducir su número) es la revisión por pares. Con este procedimiento, los responsables de identificar problemas en el código son quienes mejor lo conocen. ITIL 4 señala que "en las organizaciones más ágiles, es habitual descentralizar la aprobación de cambios, haciendo de la revisión por pares un elemento clave para predecir el alto rendimiento". Del mismo modo, el Informe del estado de DevOps, 2019 recomendaba que "las organizaciones deberían adoptar una estrategia Shift Left y cambiar a la aprobación basada en la revisión por pares durante el proceso de desarrollo".

Para garantizar el cumplimiento normativo, este enfoque debe documentarse meticulosamente. Aquí es donde entran sistemas como Bitbucket, que hacen un seguimiento automático de autores y revisiones de pares, y evitan que los cambios se implementen sin el procedimiento requerido.

En Atlassian, la revisión por pares es una parte fundamental del proceso de aprobaciones. Como explica uno de nuestros expertos en cumplimiento y riesgos de TI: "Todo el código de Atlassian se almacena en Bitbucket. Cuando un desarrollador quiere hacer un cambio, extrae el código desde Bitbucket en su portátil. Cuando lo devuelve al repositorio de Bitbucket, en lugar de actualizar el código, el sistema está configurado para requerir la revisión por pares. Solo después de que esa revisión se haya hecho y aprobado, el código se devuelve al repositorio. Pero ¿qué sucede si no se aprueba el código? En tal caso, se envía de vuelta al desarrollador original con las notas de revisión. Él se encargará de corregir los errores y lo enviará de nuevo a revisión".

Reúne expertos para hacer posibles las prácticas recomendadas

A medida que las organizaciones se vuelven más complejas, se hace más importante facilitar el flujo de información y la coordinación entre los equipos. En lugar de aprobar solicitudes de cambio sueltas, los CAC pueden centrarse en mejorar las prácticas. En este paradigma, pueden dar recomendaciones para la mejora de prácticas, implementar capacidades mejores y proporcionar recursos y herramientas que mejoren el rendimiento. Esto amplía el ámbito de competencia del CAC y se reduce el riesgo de ser demasiado lentos a la hora de lanzar cambios que aporten valor.

Incluso en las organizaciones de TI más tradicionales, el CAC puede convertirse en un centro de soluciones creativas. En un caso, una universidad reacia al riesgo con prácticas y herramientas heredadas de ITSM debía encontrar un modo de notificar a los alumnos la interrupción de un servicio importante. En el CAC se debatieron todo tipo de propuestas para la comunicación. Optaron por el reparto de caramelos y carteles, en una campaña que consiguió evitar la entrada de consultas sobre una mejora prevista de los sistemas.