Los beneficios de contar con un modelo de gobernanza en tu plataforma Atlassian

Definir un uso homogéneo de tu plataforma Atlassian es indispensable. Cuando los equipos no cuentan con un marco de trabajo claramente definido en Atlassian y cada uno solicita su propia configuración, acaba siendo imposible tener una visión común. Así, los malentendidos se multiplican, y el tiempo y los recursos se desperdician en intentar resolver ambigüedades.

La coherencia es clave. No por usar todos la misma plataforma se garantiza la comunicación y sincronización del trabajo y objetivos. Hay que asegurarse de que «todos hablen el mismo idioma» dentro de ella. Es lo que denominamos el modelo de gobernanza Atlassian: ese conjunto de reglas, políticas y buenas prácticas que sirve para asegurar que la plataforma se explote de manera consistente facilitando su evolución, mantenimiento y gestión. Cuando el modelo de gobernanza no se define junto con la primera implantación, además, será necesaria una refactorización posterior para simplificar, alinear y reordenar elementos.

Atlassian, con su enfoque de «System of Work», busca dotar a cualquier equipo de una plataforma donde centralizar sus objetivos, trabajo, conocimiento y resultados, independientemente de cual sea su misión: IT o no IT. Alcanzar esta situación ideal, en la que Atlassian es single source of truth sin que exista un orden previo, es una utopía.

En este caso de éxito vamos a contarte cómo la definición de un Modelo de Gobernanza, junto con un proceso de refactorización en Jira, pueden suponer un antes y un después en la sincronización, alineamiento y eficiencia laboral.

La necesidad

Hace unos años, contactó con Deiser una empresa dedicada al alquiler de vehículos con presencia internacional y equipos de trabajo geográficamente distribuidos por Europa. Acudieron a Deiser porque buscaban llevar a cabo una refactorización de su instancia de Jira. Llevaban tiempo con la herramienta y notaban fragmentación en su configuración provocando la aparición de silos.

Sobre el cliente

Compartimos, a continuación, algunos datos clave para conocer la compañía a la que ayudamos en este caso de éxito real:

La libertad con la que contaban cada uno de los 50 squads a la hora de definir su configuración de Jira más óptima había resultado en equipos que no trabajaban de forma homogénea. Es decir, Jira era la suma de 50 espacios de trabajo (proyectos Jira) aislados dificultando su propia realidad. En un alto porcentaje de sus iniciativas colaboraba más de un equipo y les resultaba complicado tanto localizar información relevante —silos de información— como identificar el estado de los trabajos y sus dependencias —silos de función—.

La solución

Al cliente se le hizo una propuesta de un proyecto de consultoría e implementación, con ocho meses de duración, en el que participaron:

• Un equipo multidisciplinar de Deiser formado por una jefa de proyecto, un consultor Agile, un arquitecto Atlassian y una experta Atlassian.
• La líder del área de producto y desarrollo del cliente.
• Tres personas del equipo de Transformación del cliente. Se encargaban de promocionar la iniciativa, dar soporte en el día a día a los equipos —tanto en metodología Agile como en el uso de la plataforma—, y realizar un seguimiento de forma estrecha con ellos.

Los trabajos que se llevaron a cabo fueron:

1. Etapa de descubrimiento para obtener la foto actual de la instancia. Se conoció y entrevistó a varios de sus equipos y Directores para entender qué necesitaban y cómo podíamos ayudar.
2. Con los datos obtenidos (puntos de dolor y oportunidades), comenzamos la definición de un Modelo de Gobernanza para definir ese marco de trabajo y configuración común, dándoles cierta libertad en su operativa. Entre otras actividades, definimos:
   1. Un glosario de issue types que explicaba qué representa una Epic, Story y Task en su contexto; la diferencia entre Defect y Bug; de qué datos mínimos había que informar en cada issue type; e introducía un nuevo elemento de trabajo Release para representar todo lo necesario para el despliegue en producción.
   2. El conjunto mínimo necesario de workflows para representar sus modelos de trabajo.
   3. El conjunto de tableros para que, en todo momento, cada persona contara con una vista clara del estado de los trabajos. Así se definió uno para el momento de Refinamiento del backlog, otro para el desarrollo y otro para el depliegue en Producción.
3. Terminamos con una fase de refactorización y roll-out, en la que se aplicaba el modelo de gobernanza y se ayudaba a transicionar a ocho de los squads al nuevo marco. Se pasó por una etapa intensiva de UAT en el entorno de Sandbox, con una atención directa y colaboración estrecha entre Deiser, el equipo de Transformación y los equipos, tras la puesta en producción.

¿Qué impacto ha tenido esta solución?

Tras la realización del proyecto se evidencian varias mejoras, como la homogeneización y estandarización de los elementos de la configuración de Jira más importantes. Como resultado, cada equipo siente que Jira le acompaña y da soporte a su operativa diaria. Ya no hay dificultades para discernir qué significa qué en cada contexto.

Al usar la misma terminología, la capa de gestión de la empresa obtiene el reporte de los estados de los trabajos e iniciativas en un menor tiempo —y con una mayor calidad de los datos—.

El modelo de gobierno resultó tan flexible que el equipo de Transformación consiguió ser autónomo a la hora de ayudar a los otros 42 squads en su transición.