Cómo volver a enamorarse de los proyectos de analítica apalancados en Scrum

Cuando iniciamos proyectos de datos siempre nos enfrentamos a diferentes situaciones que nos retan a ser mejores y a evolucionar.

Leer este artículo en inglés.

Uno de los desafíos más comunes en los proyectos de tecnología es la resistencia al marco de trabajo Scrum, otro gran desafío son los temas propios de cada cliente — que pueden ser tan diversos como los colores — y finalmente están los desafíos de gestión.

Veamos en qué consiste cada uno de ellos y cómo podemos hacerles frente.

La resistencia a Scrum

Iniciar un proyecto con un nuevo cliente siempre es como una lotería. Nunca sabes si aman u odian Scrum, no tienes idea si tuvieron alguna experiencia desagradable con proyectos de la misma índole y tampoco sabes cómo es su ambiente laboral, qué tan abiertos o conservadores son.

Cuando hablamos de clientes conservadores, nos referimos a esas organizaciones que son cautelosas a la hora de gestionar, de planear o de iniciar cosas nuevas. Son las que prefieren ir por lo conocido, por el camino que les ha funcionado antes probar uno totalmente innovador.

La particularidad de la mayoría de los proyectos de análisis de datos es que son innovadores, es decir, invitan a las organizaciones a salir de sus zonas de confort desde muchos ámbitos.

Existe una característica común a todos estos proyectos y es que siempre traen a la luz problemas técnicos o de datos que estuviron ocultos durante mucho tiempo y/o que nadie realmente quiso ver.

Adicional a esto, hacen cuestionar a las organizaciones su forma de gestionar los proyectos. En el caso de los de analítica, comúnmente utilizamos Scrum, por eso es común que nos enfrentemos a situaciones en las que las organizaciones no conozcan este marco de trabajo, no sepan cómo se utiliza, o simplemente no les guste 🤷‍♀️. De esta manera, se plantea un desafío grande para la organización que, además de tener que lidiar con todo lo que se trae a la luz desde la parte técnica, deben enfrentarse a una nueva forma de trabajar, de entender las necesidades y de comunicarse.

Es un gran desafío interno para el proyecto y para el Scrum Master lograr que el marco de trabajo se adopte de la mejor manera posible para poder lograr buenos resultados. El amor u odio a Scrum puede deberse a muchos factores, en ocasiones es porque simplemente lo ven como la moda y como algo que realmente no aporta valor, también puede pasar que lo consideran como algo propio de las nuevas generaciones y que antes todo funcionaba mejor.

En las organizaciones que conocen y adoptan Scrum todo fluye con mayor facilidad. Sin embargo, en las que no es así, primero debemos observar y analizar muy bien dónde está la resistencia, es decir, hay que entender si el rechazo se debe realmente al marco de trabajo o si corresponde a un proyecto de datos anterior fallido que les generó desconfianza.

• Malas experiencias previas: Cuando existe una historia fallida, tenemos un camino importante que recorrer porque debemos reconstruir la confianza, debemos aprender a comunicarnos y ganarnos la credibilidad de ese cliente mostrando resultados. En este punto Scrum nos puede apalancar, ya que si tienes un equipo sólido que entiende el trabajo iterativo de esta metodología y los principios del agilismo, en cada Sprint se pueden mostrar avances incrementales, y tener resultados productivos al final de los Release para ir ganando la credibilidad y la confianza requeridas.
• Rechazo al agilismo: Cuando la desconfianza es directamente con el marco de trabajo la mejor estrategia es tener paciencia y, poco a poco, ir enseñando los pilares, los principios, los eventos y que todo vaya fluyendo como debe fluir. En este punto me refiero a que no debemos ceder a gestionar los proyectos como se hacía anteriormente porque en proyectos de datos necesitamos la cercanía y la evidencia de los impedimentos que nos regala Scrum. Sin embargo, tampoco debemos ser agresivos con el marco de trabajo.

Scrum es de ese tipo de cosas que aprendes haciendo, que pocas veces puedes aprender sin practicar.

Desde mi experiencia, ha sido muy satisfactorio ver como clientes que eran totalmente opositores de Scrum, al final del proyecto alaban sus resultados e incluso están muy interesados en aprenderlo a profundidad y aplicarlo en otros proyectos.

Desde la psicología humana lo desconocido siempre genera temor, y lo que he evidenciado es que en ocasiones el recelo hacia Scrum no es más que desconocimiento.

¿Cómo blindar el proyecto de datos del caos externo?

Este es un desafío bien interesante porque cada organización es un mundo. Es un sistema que se interrelaciona, que tiene conflictos, cosas buenas, cosas no tan buenas. Entonces, cuando entramos como equipo externo a apoyar en el desarrollo de un proyecto hacemos parte de ese sistema, pero a la vez debemos ser lo suficientemente sólidos como para no permearnos por lo que ocurre afuera.

Esto es importante, porque el proyecto como tal es un sistema que tiene un inicio, un fin, un propósito, relaciones internas y externas. Un proyecto es un ente del que se espera un resultado — preferiblemente satisfactorio — y como sistema independiente, que hace parte de otros múltiples sistemas, debe blindarse y autosostenerse para poder dar los resultados que se esperan de él.

Hay retos que nos sacan de nuestra zona de confort como son la relación con las áreas de TI internas de cada cliente. Esta es una relación que se tiene que fortalecer y llevar de la mejor forma posible pero, como lo mencione anteriormente, por lo general los proyectos de analítica traen a la luz errores que tienen una relación directa con el área de tecnología, por esto las habilidades de comunicación y negociación son tan relevantes.

Lo más común es que la deuda técnica que sale a la luz tenga efectos negativos sobre el proyecto, generando atrasos en las entregas. Por esto es importante ser muy recursivos y creativos, buscar la manera de tener soluciones alternativas mientras el conflicto de origen se soluciona, documentar el problema raíz, la solución alternativa, y hacerle seguimiento a los hallazgos.

Lo mismo sucede con la organización en general, no solo con el área de tecnología sino con todas las áreas con las que nos debamos relacionar y de las que necesitemos algún tipo de insumo. Se puede presentar que tengamos clientes que trabajan sobre la inmediatez y el día a día, y otros que son más estructurados y con planeación. En estos casos lo más adecuado es observar primero, analizar y ejecutar después. Es clave adaptarnos a cada tipo de cliente, independientemente del funcionamiento de la organización con la que nos toque interactuar nuestro sistema y engranaje interno deben funcionar perfectamente.

Desafíos de gestión: Cómo hacer que el cliente se vuelva a enamorar de analytics 💔

En carrera larga hay desquite como dicen por ahí, y los proyectos de analítica no son la excepción. Como en el amor, a veces tenemos decepciones con algunos proyectos, o creemos que va ser mucho más sencillo de lo que en realidad es. También nos puede pasar que tengamos una decepción y ya no deseemos volver a confiar.

Pero igual que en la vida, no nos podemos negar la oportunidad de encontrar el amor solo por miedo a volver a sufrir, por eso debemos volver a intentarlo y con más ganas. En el caso de los proyectos intentarlo con más motivación y convencimiento de que lo vamos a lograr.

Lo más importante de todo, es ser impecable con la gestión y ser orientados 100% a los logros, mostrar resultados que evidencien todo el trabajo realizado para que, de esta forma, las personas puedan tener una nueva experiencia con los datos, borrando los momentos negativos anteriores.

Los recuerdos negativos pesan en el inconsciente pero las sensaciones, los sentimientos y los nuevos recuerdos positivos ayudan a mitigar lo malo.

La importancia de la gestión radica principalmente en lograr que los impedimentos se observen, se enfrenten y se solucionen. Por esto el liderazgo juega un papel primordial en el camino de (volver a) enamorarnos de los proyectos de analítica, donde gracias a ese liderazgo, a la gestión y a la planeación se puede mejorar y aprender de los tropiezos del camino.

En ocasiones también es aprender a valorar cada paso, cada resultado por pequeño que parezca, reconocer cómo hemos mejorado y todo lo que hemos logrado.

La vida todo el tiempo nos enseña que buscar la perfección nos puede alejar de valorar lo bueno que se ha logrado.

Cuando el cliente viene de un proyecto fallido lo primero es no dejarnos impregnar de la energía negativa o de los comentarios pesados que puedan existir en el ambiente. Principalmente no tomarlo personal, dejar que el comentario llegue pero que resbale porque estamos ahí precisamente para mostrar que las cosas siempre pueden mejorar.

Cuando el cliente tiene una resistencia al marco de trabajo, lo principal como facilitadores es mostrarle las ventajas de su utilización y entrar al corazón de la cultura de la organización. Adicional antes de iniciar el proyecto, es necesario generar acciones que mitiguen la falta de conocimiento o los supuestos. Esto implica hacer capacitaciones, conferencias previas y, sobre todo, lograr que Scrum hable por sí mismo mostrando sus resultados.

Finalmente, cuando tenemos un escenario donde el proyecto ha traído a la luz muchos errores de los sistemas fuentes hay que mostrar y lograr ver esta situación con una mirada positiva. Ver el vaso medio lleno y no medio vacío, contemplar esto como una oportunidad de hacer las cosas bien y de mejorar problemas que siempre han existido. No hay que tomar una actitud negativa frente al proyecto, después de todo, un proyecto de datos es el eslabón final que muestra todo lo bonito — o todo lo feo — que tengamos en su parte de atrás.