Confluence: ¿un camino de ida?

¿Qué es Confluence? Una herramienta muy versátil que se utiliza tanto en Agile como en Waterfall, pero que claramente no puede substituir a JIRA. Aquí te explico más.

Como ya hemos mencionado en el post sobre JIRA, Confluence también ha sido desarrollado por Atlassian. ¿Su objetivo? Completamente diferente al de JIRA, el objetivo de Confluence es convertirse en un único repositor de contenido y documentación con respecto al proyecto. Es decir, es el gran “wikipedia” del proyecto.

Muchas empresas, principalmente aquellas que trabajan con la metodología en cascada (probablemente por la sobre-abundancia de documentación) y/o con Microsoft Office/Project, al cabo de poco tiempo se percatan que la información se encuentra diseminada en varios lados (la computadora de uno u otro, SharePoint, algo en los tickets de JIRA o en los discos compartidos, algunos empleados empiezan a intercambiar archivos via Google Drive u otras herramientas cloud, emails, etc.). Y esto no es sólo nefasto para los miembros del equipo que pueden sentirse perdidos o desorientados en algún punto, sino que además compromete la seguridad de la empresa y la integridad de la información.

¿Qué es Confluence exactamente?

Confluence es un plataforma cloud sencilla, amigable y adaptable según las  necesidades y circunstancias en las cuales se encuentre cada equipo. Además, se integra muy bien con JIRA, siendo muy fácil hacer seguimientos de tickets directamente en Confluence con diferentes formatos de tablas. También se pueden guardar las minutas de las reuniones, hacer cuadros de procesos, seguimiento de tareas personales, armar un glosario de palabras y subir directamente documentos de diferentes formatos para crear un repositorio centralizado.

Ahora bien, como sucede con JIRA, muchas empresas creen erróneamente que al utilizar Confluence están siendo “ágiles”. Y ese no es el caso. He conocido empresas que inclusive cometen el error de gestionar el proyecto via Confluence, lo cual crea una intoxicación de información formidable para todos los miembros del equipo. ¿El resultado final? La gran mayoría del equipo deja de utilizar Confluence y pasa a ser una mera herramienta del gestor de proyectos.

Algunos errores frecuentes al utilizar Confluence

En mi experiencia profesional, Confluence no es siempre fácil de utilizar en equipo, particularmente si todos echan mano a todo, y no existen reglas básicas para su funcionamiento. Aquí nombraré algunos de los errores más comunes que he visto:

Conflunce es utilizado como un mero repositor de información:

Algunos equipos utilizan sólo la opción de subir archivos a Confluence, es decir, como un mero repositor de archivos. Esta práctica no es en sí misma inadecuada, pero limita en gran medida el poder de participación e intercambio de información de Confluence. Lo que sucede muchas veces en estos casos es que la gente simplemente arrastra allí los archivos y nunca más se tocan. Quedan perdidos en la nube. De esta manera, Confluence se vuelve obsoleto y en el peor de los casos, diferentes equipos terminan utilizando diferentes herramientas. Conocí el caso de una empresa que utilizaba Confluence, Google docs y el cloud de Microsoft 365.

Para que la utilización de Confluence sea exitosa, debemos minimizar su uso como un mero repositor de información. Si hay muchos archivos que se quieren guardar, lo aconsejable es que algún miembro del equipo se tome el tiempo de resumir la información, o mantener al día la última versión del tema en alguna página aparte, incluyendo un link hacia los documentos en caso de querer ver el historial sobre dicho tema.

Confluence reemplaza reuniones o trabajos de brainstorming grupal:

Otro problema que veo generalmente es la utilización de Confluence para reemplazar reuniones o sesiones de trabajo (como por ejemplo, la lluvia de ideas o brainstorming). Una vez, tuve de cliente a una empresa que “construía” el producto en Confluence: alguna persona influyente del equipo tiraba líneas directrices y pretendía que el responsable de cada área (logística, atención al cliente, etc.), rellenara lo suyo. Esta práctica no es simplemente nociva para el trabajo en equipo, sino también al producto general que sea desea alcanzar.

Ninguna herramienta informática podrá jamás reemplazar el trabajo de los seres humanos. Crear tickets en JIRA o mantener discusiones al pie de página de Confluence es completamente improductivo y se termina pagando un alto precio al final del camino: los objetivos no son claros para los participantes, los stakeholders tienen expectativas diferentes sobre el producto/servicio final, el equipo de desarrollo/operaciones no entiende claramente qué debe construir, etc. Hay que recordar siempre uno de los principios básicos de Agile: “individuos e interacciones sobre procesos y herramientas”.

Confluence reemplaza al trabajo del Product Owner

Otro error muy grave es pretender que el Product Owner puede escribir todas las indicaciones y Roadmap (mapa de ruta) en Confluence y luego desaparecer. Este error muchas veces se realiza en empresas que tienen Product Owners “consultores” (aunque no lo crean, ¡existen!).

El Product Owner es un integrante fundamental del equipo Agile. Por supuesto que Confluence puede ser una herramienta valiosa para compartir información y que la misma esté siempre disponible para todos los miembros del equipo que deseen consultarla en cualquier momento. Pero esto no significa que el Product Owner sea un simple creador de “órdenes” y luego pueda desaparecer. El rol de Product Owner es siempre estar disponible para el equipo, ir adaptando el “scope” del proyecto en base a las realidades cambiantes cotidianamente, y aportar al éxito del equipo en cuanto sea capaz. De nuevo: “individuos e interacciones sobre procesos y herramientas”. ¡A veces es necesario repetir esta frase hasta el cansancio!

Las conversaciones se llevan a cabo en Confluence

De nuevo, aunque repetitivo, este punto se entrelaza con los dos anteriores. Como una suerte de blog, Confluence permite comentar al pie de cada página. Pero los comentarios deberían ser, simplemente, comentarios. Se puede utilizar, por ejemplo, para referir a otra versión futura, o avisar al propietario de la página que ha olvidado algún punto. Pero es altamente nocivo mantener debates al pie de una página del estilo: “no estoy de acuerdo con esta idea porque…”, “creo que deberíamos hacer esto otro…”, “¿quién decidió esto?”. Si esto sucede en Confluence, significa que hay algo que no está funcionando bien en el equipo. La comunicación está fallando.

De nuevo, Confluence es simplemente un wiki de nuestro proyecto. Esto significa implícitamente que lo que se ha escrito es algo ya discutido y bien masticado por todos los miembros del equipo. Pero Confluence no puede, ni debe en ningún momento, substituir estas interacciones humanas tan valiosas dentro de un equipo.

No existe un esqueleto funcional que se adapte a todos los miembros del equipo

Este es otro de los errores comunes que he visto en la utilización de Confluence. Porque Confluence “pertenece a todo el equipo”, no termina perteneciéndole a nadie… y cada uno termina haciendo lo que quiere. Y hay algunos individuos más organizados que otros. Y porque para colmo de males, seguramente no hay reglas claras de su utilización o un esqueleto formal compartido por todos, el espacio Confluence del equipo termina siendo lo que en Argentina denominamos “un quilombo” – y disculpen la expresión, pero no hay mejor manera de describirlo.

He visto realmente desastres atómicos en la mala utilización de Confluence, a tal punto que ya nadie sabe dónde encontrar la información; en cuyo caso, todo el tiempo invertido en documentar en Confluence, es tiempo literalmente perdido.

En resumen…

  1. Confluence debe ser simplemente una herramienta, una combinación entre wiki y blog, útil y disponible a todos los miembros del equipo. No debe substituir jamás la interacción humana.
  2. Es necesario contar con reglas de “gobernanza” del espacio que sean conocidas por todos los miembros del equipo, utilizando un “esqueleto” principal que sea respetado por todos. Este esqueleto debería favorecer el acceso rápido a la información que sea desea obtener, un poco de la misma manera en que funciona Wikipedia.
  3. Si bien Confluence permite guardar archivos de diferentes formatos, es aconsejable que no sea utilizado sólo a esos fines, sino pierde sentido en sí mismo. Como buena práctica, se recomienda que la información sea traducida de forma concisa, pues esto garantiza además que la información sea bien conocida por todos los miembros del equipo.

En síntesis, en mi humilde experiencia profesional, Confluence puede convertirse en un arma de doble filo. He visto muchos fracasos en su utilización que luego traen más problemas que el problema de partida que se intentaba solucionar al elegir Confluence. Esta herramienta no es un camino de ida, sino más bien un camino de muchas vueltas: es un wiki del proyecto que debe mantenerse vivo y actualizado constantemente.

Finalmente, esto no significa que el problema sea la herramienta en sí misma. Confluence es una herramienta muy poderosa y útil. El problema es que quiénes la utilizan piensan que una herramienta informática podrá convertirles en profesionales “ágiles”. En realidad, los casos de fracasos nos demuestran que sin una mentalidad Agile clara (de la organización, del equipo y de los individuos), una herramienta por sí misma jamás podrá hacer magia.

One thought on “Confluence: ¿un camino de ida?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *