Claves de la priorización por valor

Imaginemos un momento que frotamos una taza de café (para los adictos) y se aparece un genio y que está dispuesto a cumplirnos tres deseos. ¿Qué pedimos? Obviamente tendríamos en mente mucho más que tres cosas, posiblemente tengamos veinte. Entonces lo que nos queda es priorizar. Escoger lo que más necesitamos en este momento, lo que nos haría más feliz, lo que nos daría mejores resultados (si nos gusta invertir), etc.

Uno de los principios más importantes de Scrum es la priorización basada en valor, pero algo tan simple como entregar el máximo valor para el cliente en el menor tiempo posible ¿puede convertirse en un verdadero reto? Desde luego, sí. Saber lo que genera valor no es algo muy fácil. A los Product Owner (P.O.), muchas veces, les cuesta priorizar los requerimientos del cliente y más aún, mantenerlos priorizados. Se requiere de mucha visión de negocio, habilidades comunicativas y capacidad para consensuar. En sí, priorizar por valor es mucho más complejo que priorizar por dificultad. Y pasa que creemos que lo más difícil debe hacerse primero, o que lo más simple se nos escapa. A continuación, presentaré un par de ejemplos en el que veremos dos situaciones que pueden suceder al momento de priorizar ítems.

Ejemplo Nro. 1: ¿El huevo o la gallina?

Un sistema de e-commerce (de esos que abundan últimamente), comúnmente está constituida por tres módulos: el catálogo, el carrito y el pago. ¿Qué es lo más difícil? Obviamente la comunicación con el módulo de pagos puede ser una tarea difícil, pero ¿sería lo primero que hay que hacer?

Muchos dirán que si no existe la parte de pagos ¿cómo ganaremos dinero? Por supuesto, una pasarela de pagos es importante, pero no es la única forma de conseguir que nos paguen por el producto. En el caso que el tiempo apremie y nuestro catálogo es único o muy especial y mientras el público que compre pueda tener el producto que desea en el tiempo que desea, no importará mucho el medio de pago. Entonces lo que da más valor al dueño de la tienda, en este caso, es poder mostrar el catálogo de productos sin que eso sea lo más difícil que hay que hacer.

A esto nos referimos con priorizar por valor, ponemos como primer ítem del Producto Backlog lo que le generará al cliente un pronto retorno de la inversión. No lo más complejo. Si volvemos a la metáfora del inicio de este artículo deberíamos preguntarnos, ¿qué elegiríamos cómo primer deseo?

Ejemplo Nro. 2: el grave error de suponer

Una vez, en una empresa de publicidad en la que trabajé por un tiempo, la relación entre TI y Marketing era muy estrecha, pero a la vez muy confusa. Los requerimientos eran muy volátiles, en una semana podían deshacerse requerimientos muy complejos. En fin, esa es otra historia. Un día, me pidieron que hiciera una intranet que muestre unas gráficas para una conferencia muy importante. Querían lograr que los asistentes pudieran entrar desde su laptop a la intranet y poder visualizar las gráficas (que por cierto eran resultados de una encuesta muy importante que hicieron). Lo interesante fue que en ningún momento advirtieron que el local en el que estaban tenía una red de wifi lentísima y que las gráficas apenas y se cargarían a medias. Claro, en ese momento yo era desarrollador y poco me decían del objetivo de mis desarrollos. El gran momento de la solicitud del requerimiento fue algo como “necesitamos una intranet, que muestre los resultados que te vamos a pasar y…nada más”.

Una cosa tan simple como asegurar la conexión de una red, utilizar un modem móvil de alta velocidad, por ejemplo, más allá de lo complejo que resultó hacer la intranet, pudo haber evitado la vergüenza y, por supuesto, pudo haberse hecho en paralelo. Y esto pasa mucho: damos cosas por sentado, asumimos hechos con la falacia de que es lo más simple y se puede resolver en minutos. Pues bien, les comento que nunca lograron hacer que la red vaya más rápido. La conferencia perdió valor y la intranet de poco sirvió. Por supuesto, desde ese momento empecé a preguntar ¿para qué voy a hacer esto? Y ¿cuál es el ambiente de producción?

La priorización basada en valor, nos obliga a pensar en todo. Y para ello existen una serie de técnicas. Lo que hacemos en los talleres de Scrum cuando llegamos a este punto es, primero definir un objetivo: lo que queremos construir o el problema que queremos resolver. Esto lo define el Product Owner (P.O.), en este caso como facilitador del taller, me ocupo de presentar el problema o el producto. Luego, les pido a los integrantes del equipo que redacten en notas de post-it las épicas (historias de usuario a alto nivel) que creen conveniente para la solución. En ese momento llueven las ideas. Debo decir que en este punto, escribir ideas resulta mejor cuando tienes un equipo introvertido y les cuesta soltar ideas. En unos minutos se tienen más de 40 ideas. Finalmente, se invita al equipo a un panel que está dividido en columnas según la técnica de MoSCoW (por decir una, puede ser otra técnica de priorización) y se pide que coloquen las notas según lo que consideren como requisitos que: Must Have (Debe tener), Should Have (debería Tener), (Podría tener) y Won’t (No debe Tener).

Finalmente, los participantes, sin necesidad de mucha comunicación, llegan a un acuerdo de lo que realmente genera valor para ellos y en muchos casos se sorprenden de algunos requisitos que nunca se les habría ocurrido. Esto nos demuestra también que el trabajo en equipo funciona mucho mejor.

¿Principales problemas?

Los hay y mucho tiene que ver con lo “Urgente”. ¿Cuándo no nos ha llegado una llamada “importante” sobre un requisito que se le había pasado al cliente? Y, peor aún, cuando estábamos en medio de un sprint o en plena fase de construcción (para los que aplican el método tradicional). Con Scrum sabemos que debemos esperar al siguiente Sprint para re-priorizar la Product Backlog, y para los que aplican el método tradicional, lo que viene es la conocida gestión de cambios (solicitud, aprobación, etc.) Sin embargo, existen clientes “especiales” que no pueden con esto de ser ágil, y quieren paralizar todo a toda costa. Por supuesto, necesitaremos de nuestro Scrum Master para que, luego de un momento de relajación y meditación, pueda tomarlo todo con calma, hablar con el cliente e impedir que el equipo se vea afectado.

No podemos evitar que el cliente aparezca con nuevas ideas, pero si podemos evitar que esto impacte negativamente el desarrollo del equipo. Para ello el Scrum Master debe poder manejar las situaciones de urgencia y siempre exigir del P.O. “priorización basada en valor”, ya que muchas veces, lo que era “urgente” no era tan importante. Y, aun así, sería costoso paralizar un Sprint (lo cual implica que luego se tenga que retomar algo ya avanzado, lo cual toma tiempo para repensar) solo por uno o dos requisitos. Salvo que uno de ellos sea que el producto inicial ya haya sido reemplazado. En ese caso, no hay muchas opciones.

En resumen, la priorización basada en valor nos permite entregar características esenciales de un producto, sin que esto signifique construir lo más complejo. Además, podemos utilizar técnicas muy fáciles pero productivas para priorizar y tomar en cuenta algunas cosas que no nos percatamos en un inicio. Llegar a un acuerdo sobre los requisitos a priorizar es una tarea entre todo el equipo, ya que cada uno cumple un rol en el proyecto, sin embargo, el P.O. es el que tiene la última palabra. En otro post explicaré sobre algunas otras técnicas de priorización para que puedan aplicarlas en sus equipos.

Please follow and like us:
0

Leave a comment

Hey, so you decided to leave a comment! That's great. Just fill in the required fields and hit submit. Note that your comment will need to be reviewed before its published.