En otro artículo que escribí sobre métricas básicas para tu equipo, un lector hizo una pregunta muy interesante sobre cómo medir el valor en un proyecto de datos.
Al formular la respuesta, me di cuenta de que este es un tema muy interesante. Y eso, basado en mi reciente experiencia con varios equipos de datos, puede ser la duda de algunas otras personas.
Así que decidí escribir este breve artículo.
Según Scrum Guide, “The Product Backlog is an ordered list of everything that is known to be needed in the product”. El Backlog es una lista priorizada de lo que sabemos que se necesita para este producto. Por tanto, para tener un backlog necesitamos un criterio de priorización.
Como ya hemos mencionado en algunas otras publicaciones del blog, debemos trabajar con valor. Esta directriz está presente en varios momentos en el manifiesto ágil, por ejemplo al principio: “Nuestra máxima prioridad es satisfacer al cliente mediante la entrega continua y avanzada de software con valor agregado“.
Pero en el caso de un proyecto de datos, ¿Cuánto valdría? ¿Qué unidad o práctica podría usar para medirlo?
El backlog de un proyecto de datos
En esta publicación sobre la labor del Product Owner hablamos de cómo rebanar un producto y cómo esta tarea es una búsqueda constante de la parte más pequeña que realmente agrega valor al usuario final.
Pero en el caso de un proyecto de datos, las cosas cambian un poco.
El reto de rebanar la entrega de valor y priorizar el backlog es aún mayor en un proyecto de datos
Para responder a la pregunta de nuestro lector, comenzaremos analizando la inversión, y luego pasaremos a analizar el retorno, para poder calcular el Return On Investiment, cariñosamente llamado ROI.
Inversión
Un proyecto de datos generalmente comienza con la adquisición de una herramienta (que no suele ser la más barata). Y el desarrollo del proyecto de datos consiste en la inclusión de nuevos datos y construcción de informes y visiones dentro de la herramienta adquirida.
Esto por sí solo ya mortifica un poco el siguiente principio del manifiesto ágil: “Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados“. La compra de una herramienta ya es una decisión arquitectónica que tú, debido a que ya tiene un coste explícito adjunto, no podrás (tan fácilmente) cambiar a lo largo del proyecto de dados.
Por consiguiente, partimos desde el punto cero, de una inversión que fue la adquisición de la herramienta. Es posible que tengamos el impulso de prorratear este coste para todos los elementos del proyecto de datos. Pero acabará jugando en tu contra en un futuro próximo.
Imaginemos que cada elemento conlleva una parte de la inversión para comprar la herramienta. Esto significa que cuanto más elementos haya, menor será la porción de inversión para cada elemento individualmente.
Por lo tanto, cuantos más elementos, o cuantos más datos, informes y visiones estén disponibles en la herramienta, mejor. Es decir, aumentar la cantidad de elementos entregados reduce la “I” lo que mejora tu ROI.
El problema con esta perspectiva es que pronto estarás “matando una mosca a cañonazos”. Utilizar la herramienta para cosas sencillas, donde no es necesario, y en ocasiones ni siquiera es la mejor opción, porque no fue diseñada para eso.
El problema con este enfoque es que generará altos costes de mantenimiento. Llevando cosas a la herramienta que podrían haberse resuelto con una consulta directa, un flat file o un simple informe.
Estas tecnologías más rudimentarias permiten que varias personas de la organización realicen el mantenimiento, en lugar de quedarse atrapadas en una herramienta o tecnología que requiere una licencia o la formación en esa competencia.
¡Así que huye de eso, como el diablo de la cruz! Lo importante es dejar tu proyecto con la menor carga de mantenimiento posible.
Retorno
Dicho esto, vayamos a la visión de resultados. La mejor manera de medir el retorno es observar la velocidad (cuanto más rápido, mejor) y la calidad (cuanto más asertivo, mejor) de las decisiones tomadas en base a lo que la herramienta pudo presentar.
Pero esto es muy difícil de medir. Tendrías que consultar históricamente cuáles fueron los impactos de la decisión tomada, y medir cuándo surgió una pregunta hasta el momento en que se resolvió. Todos estos son el tipo de cosas que normalmente no se registran en sistemas de control o gestión. Por eso siempre es muy difícil tener estos datos.
Sin embargo, hay una excepción. Cuando nuestro proyecto de datos tiene como clientes áreas que toman decisiones corrientes (o cotidianas), podemos recopilar estos datos en el sistema de gestión de esas áreas.
Ahora podemos medir la velocidad de la decisión midiendo el progreso en la productividad o la duración de una tarea.
También podemos medir la calidad. Como se trata de decisiones cotidianas, debe haber sistemas de calidad para validar estas decisiones. Es decir, calcula el valor por encima de las mejoras notables en los resultados en la operación de tu cliente.
Ejemplo: un proyecto de datos que tiene como objetivo generar el informe de ventas de una business unity. La persona que ha solicitado esta información posiblemente esté trabajando en un equipo y debe tener un ticket en algún sistema, o una tarea en alguna pizarra. Al observar los impactos en este equipo, podrás medir el valor de tu entrega.
Es posible, pero a veces es muy caro.
Otra solución, a veces más viable
La solución se convierte entonces en medición de uso. Tú, como PO, deberías empezar a preguntarte con frecuencia: “¿Se están utilizando, de hecho, las herramientas que estamos poniendo a disposición?”
La medición del uso puede no ser la mejor métrica, pero definitivamente es mucho más barato. Puedes, por ejemplo, medir el número de veces que se ha realizado una consulta.
La mayoría de estas herramientas ya brindan monitoreos, pero si por alguna razón tu herramienta no las prepara, puedes programar un disparador. O incluso agregar una tag a la página para medir cuántas veces se ha “cargado” o “impreso” la misma.
También puedes medir el tiempo de sesión. “¿Cuánto tiempo ha estado expuesta esta pantalla?” Por supuesto, si tu visión es un dashboard, medir el tiempo de sesión en pantallas que están expuestas todo el tiempo será un indicador sesgado, y debes tener un criterio para ignorar los datos de esta fuente.
Al analizar el uso, puedes crear una línea de tendencia y, siguiendo la línea de tendencia, tendrás una métrica que refleja el valor y podrás utilizarla para (re)priorizar.
Esto permitirá, en base a la experiencia del día a día, que el equipo del proyecto de datos pueda participar de manera más activa en el rumbo estratégico, ofreciendo no solo una visión tecnológica de cómo construir, sino también una visión de dónde están las mejores oportunidades, cuáles deben ser los primeros informes e incluso influir en la calidad del dato.
La línea de tendencia de uso es para que argumentes con tus clientes sobre las funcionalidades que se ofrecen.
Después de cada entrega, dedica un tiempo para medir el uso de cada informe o visión. Es muy común que los equipos tengan columnas en sus boards que significan que se está midiendo la entrega, tanto para garantizar la calidad técnica como para asegurar que está siendo útil para sus clientes.
Es importante recordar que este enfoque será más efectivo cuanto más pequeñas y mejor rebanadas sean tus entregas. Rebanar bien y entregar constantemente. De esta manera, podrás ver la evolución de la tendencia después de cada entrega.
Si haces grandes entregas, tu tendencia de uso tardará en ser un dato relevante y, posiblemente, cuando tengas estos datos, ya no será posible cambiar de dirección, porque ya lo has hecho todo.
Obtén más información sobre la priorización y Product Owner
Comprende el rol del Product Owner y lo que hace en el Equipo de Scrum.
Si estás comenzando esta jornada y deseas leer acerca de ello, vale la pena echar un vistazo al artículo: El Trabajo del Product Owner.
¿Te gustó el tema? ¿Quieres mejorar tus conocimientos y habilidades como PO? ¡Asegúrate de consultar nuestra formación Certified Scrum Product Owner!
