por Vanessa Amaya

Es impresionante cómo ha evolucionado la tecnología en los últimos 10 años así como también impresiona cómo ha cambiado la manera de organizar el trabajo y la forma de hacer negocios. Pero lo que más me impresiona, es que a pesar de lo anterior, en la mayoría de las empresas se sigue sacrificando las prácticas alrededor del análisis.

“Has el análisis del sistema del que ya tenemos desarrollado el 60%”

“Tú que eres analista, documenta las minutas”

“No perdamos tiempo en análisis porque ya hay urgencia por desarrollar”

“Tienes 3 dias para hacer el análisis, perdón, tienes solo 2 dias y si puedes antes mejor”

“No hay tiempo para juntas de resolución de dudas”

“El que tiene la información es una persona de alto rango, muy ocupada y no puede participar en el análisis”

“El análisis no lo cobramos así que hay que tardar lo menos posible”

“Tú que eres analista, documenta el proyecto”

¿Cómo podemos esperar entregar a tiempo si no hay entendimiento compartido sobre lo que vamos a entregar?

De la Cascada a la Agilidad: cambio de paradigmas en análisis y gestión de la demanda.

Los marcos ágiles, intrínsecamente, promueven el análisis colaborativo: visualizar juntos, pensar juntos y decidir juntos.

Particularmente en Scrum, el rol de Product Owner es esencial para promover el entendimiento de las necesidades de los usuarios y sobre todo, del entendimiento del usuario mismo para fomentar la empatía. Debido a este conocimiento, el Product Owner prioriza el trabajo identificado en el Product Backlog, pero al final, si el resto del equipo y sobre todo quienes directamente van a encargarse de hacer realidad el trabajo, no comprenden contexto, necesidades y objetivos, se perderá tiempo valioso en compensar dudas y retrabajos.

En Kanban, aunque no se tienen roles pre-escritos, está muy enfocado a gestionar la demanda y el flujo, analizando la capacidad que tiene el equipo para que sea cada vez más productivo, no solo encontrar cuellos de botella sino hacer algo para que esos cuellos de botella no impacten o dejen de existir.

Tanto en Scrum como en Kanban, independientemente de sus diferencias y de sus similaridades, promueven el análisis colaborativo a través de la visibilidad del trabajo: que todos veamos cómo nace y cómo fluye el trabajo para que juntos podamos ir tomando decisiones.

Puede haber roles cuyo enfoque sea el dimensionamiento de requerimientos y el análisis, sin embargo, estos mismos roles deben de promover el análisis colectivo para que las decisiones contengan esencias de más de una perspectiva.

¿Y si ya sabemos cuál es el problema por qué no hacemos algo al respecto?

Lamentablemente no sabemos cuánto nos cuesta precisamente un mal entendido y menos sabemos con precisión monetaria, cuánto nos cuesta una omisión de comunicación, pero un día puedes hacer el ejercicio de registrar cuántos malos entendidos y omisiones de comunicación hubo en una semana, luego en un mes y ponerle el precio que quieras, pero un precio generoso porque muchas veces puede equivaler a un 5% de lo que tenemos presupuestado en el proyecto o puede equivaler al 50%.

Aunque no tengamos el valor exacto de cuánto nos cuesta un mal entendido y una omisión de comunicación, si sabemos cuánto cuesta nuestros retrasos y cuánta utilidad perdemos.

Cuando una estrategia de transformación se centra solamente en la parte operativa y no se trabaja con la parte estratégica es como trabajar con una mesa de dos patas del lado derecho ¿y las del izquierdo?

El reto es: contagiar a los equipos comerciales, de negocio y estratégicos con la agilidad, que desde ahí se cuide la gestión de la demanda, la compresión sobre el valor a generar y el entendimiento sobre la capacidad REAL que tienen los equipos.

Conclusiones.

• Promover el análisis colaborativo.

• Asegurar el entendimiento de objetivos y especificaciones es responsabilidad de todos: De los perfiles de negocio es responsabilidad dar todo el contexto posible e ir asegurando que se entendió, y de lado de la operación debemos aprender a preguntar (dejar de suponer) y pedir información que nos ayude a comprender mejor y tomar mejores decisiones de diseño y de desarrollo de nuestros productos.

• Precisamente algo que nos trajo la agilidad y la forma de trabajo basada en entregas frecuentes de valor, es precisamente la FRECUENCIA. En el esquema tradicional, solo tenemos UNA oportunidad de entregar, UNA oportunidad de saber si comprendimos y generalmente con una sola oportunidad es más probable que nos digan “esto no era lo que quería”.