Por César Porfirio
"Amazing how fire exposes our priorities.” – Sherlock
Uno de los principales desafíos cuando estamos desarrollando productos es cómo priorizar nuestro backlog de funcionalidades.
Las metodologías ágiles proponen capturar los requerimientos desde la perspectiva del usuario. Como ya sabemos, los requerimientos ágiles son expresados a través de UserStories (US), con el formato conocido de
Como <rol> quiero <funcionalidad> para lograr <objetivo>.
Sin embargo, una vez descrito el comportamiento esperado del sistema en un conjunto de UserStories (denominado backlog) existe un problema a resolver: en qué orden se irán implementando cada una de ellas, es decir, por dónde arrancar.
El principio de Pareto establece que el 80% de los efectos provienen del 20% de las causas. Dicho de otra manera: el 80% de los beneficios de la empresa o del proyecto proceden del 20% del tiempo invertido por su personal. En un contexto de desarrollo Agile, la misma regla sería algo como que el 80% del valor del producto proviene del 20% de sus funcionalidades básicas. Pero, ¿cómo definir qué tareas incluir en ese 20% mágico? Obtener ese 20% para contener las tareas más vitales de un producto significa resolver el problema de la priorización de la manera más óptima.
La priorización como principio significa "hacer lo primero, primero". Como proceso, significa "evaluar un grupo de elementos y clasificarlos en orden de importancia o urgencia". En realidad, la priorización es nuestra actividad cotidiana. Continuamente tomamos decisiones y dirigimos nuestra actividad a alguna tarea. A veces es una decisión entre dos tareas: 1) llamar a un cliente potencial o 2) llenar vacíos en un informe regular. A veces, es priorizar entre tres tareas: 1) ir a un supermercado, 2) cenar con colegas o 3) visitar a un médico.
Pero otras veces, especialmente en el desarrollo de software ágil , tratamos el problema de la priorización de N tareas según los criterios de M. Este es el tipo de problema que no se resuelve fácilmente para el cerebro humano y, por lo tanto, necesita soluciones especiales.
El problema de la priorización
La priorización de requisitos en todas las metodologías de desarrollo de software se considera una parte vital del proyecto, pero es especialmente importante en el desarrollo de software Agile. Cuando hablamos de algunas de las actividades del propietario del producto en los proyectos de Scrum como "Solicitar artículos en el Product Backlog para lograr los mejores objetivos y misiones" , "Mostrar en qué trabajará Scrum Team a continuación" y "Optimizar el valor del trabajo del equipo de desarrollo” , como se describe en la guía de Scrum, en realidad estamos hablando de la priorización de un Backlog.
Todo lo que estamos tratando de hacer es ordenar los elementos del Backlog de acuerdo con su prioridad. En esencia, estamos tratando de determinar las tareas principales del usuario y ordenarlas de esa manera, al mismo tiempo que tenemos en cuenta algunos otros criterios (organizar las historias de usuarios a partir del Backlog de Funcionalidades N según el criterio M). Por ejemplo, para priorizar las historias de usuario, podríamos utilizar cinco criterios de priorización, tales como el valor que los usuarios asignan a la visión del producto, la urgencia, las limitaciones de tiempo, la complejidad técnica y las preferencias de los interesados.
Para lograr el éxito, los proyectos deben tener una prioridad adecuada tanto para los objetivos principales del proyecto, como para las tareas específicas que lograrán los objetivos. Así que nos ocupamos del problema de priorización en dos niveles:
- Nivel de tareas: defina qué piezas de trabajo (historias de usuario o tareas) se deben realizar, y en qué orden, durante el proceso de desarrollo del producto de software.
- Nivel del producto: determine qué características del producto podrían contribuir mejor al logro de los objetivos principales del proyecto.
Analizaremos diferentes técnicas en función del enfoque anterior.
Opciones para priorizar, teniendo en cuenta las historias de usuario
Existen distintos factores y dimensiones a considerar:
- Tiempo.
- Esfuerzo.
- Valor Funcional.
- Opinión de los stakeholders.
- Opinión del equipo de desarrollo.
- Valor de Mercado.
- Y seguramente varios más...
A partir de los mismos, han surgido distintas técnicas para priorizar los UserStories del backlog.
Las siguientes líneas describen algunas de las técnicas más comúnmente utilizadas. Para facilitar la comparación, se introduce un pequeño ejemplo de un backlog. El mismo luego será priorizado según la visión de cada técnica. El ejemplo consiste en una aplicación de comercio electrónico, con las siguientes UserStories:
US-01. Como usuario registrado quiero poner artículos en el carrito de compras para armar mi pedido.
US-02. Como dueño del comercio quiero que las personas puedan recorrer el sitio sin estar registradas para facilitar la visibilidad del mismo.
US-03. Como dueño del comercio quiero que únicamente los usuarios registrados puedan realizar compras para lograr fidelidad.
US-04. Como jefe de finanzas quiero que los pagos con tarjeta de crédito sean seguros para evitar fraudes.
US-05. Como usuario registrado quiero hacer “check-out” del carrito para finalizar mi pedido.
US-06. Como jefe de marketing quiero que sea sencillo e intuitivo agregar productos al carrito para que los usuarios les resulte atractiva la página.
US-07. Como jefe de marketing quiero que los usuarios puedan realizar búsquedas para que puedan encontrar los productos que desean.
1. Técnica de clasificación de lista
Esta es una de las técnicas más usadas y que no requieren ningún tipo de entrenamiento ni preparación. Forma parte de nuestra actividad cotidiana. Tomamos decisiones en base a una priorización simple. Hacemos esto antes que esto otro, por un motivo o una razón y así clasificamos gran parte de las tareas de nuestra vida.
En la gestión de Proyectos, se trata de indicar a cada US un orden de prioridad, empezando por el 1, luego el 2, 3, y continuando hasta n, que es la cantidad total de registros de US.
Las dos grandes ventajas de este tipo de técnica son:
- Solo puede haber un número uno. Evita el escollo de mucho responsables de negocio que quieren que todos los US tengan prioridad 1.
- Aporta precisión y evita la confusión. Se prioriza cada elemento en relación con el resto de elementos, lo que simplifica el proceso y lo hace más claro.
La gran desventaja es que requiere un conocimiento profundo de todas las US definidas y un esfuerzo grande por parte del equipo, para situar cada uno de los US en la posición correcta.
2. Técnica Business Value&StoryPoints
Esta técnica proponer priorizar las UserStories basándose en factores como el esfuerzo y la opinión del ProductOwner, del cliente y del equipo de desarrollo, o incluso combinándolas. El Business Value es un valor numérico asignada a cada UserStory (US) donde a más alto el valor, mayor valor para el cliente.
Entonces una manera de priorizar el backlog sería utilizando el Business Value de las US. Sin embargo, llevarlo acabo de manera “aislada” puede traer problemas.
Uno de ellos radica en que el cliente muchas veces se deja llevar por detalles superfluos y esto puede llevar a dejar de lado alguna funcionalidad realmente importante.
Otro problema es que no se considera el esfuerzo que lleva implementar cada US. Esto último puede resolverse con StoryPoints, que son valores numéricos que introduce el equipo de desarrollo estimando el esfuerzo que le llevará desarrollar cada US. Luego, una manera inteligente de priorizar el backlog es utilizando el cociente Business Value/StoryPoints. Es decir, lo más sencillo de implementar que devenga en mayor interés para el usuario. Para ilustrar esta técnica, suponer los siguientes valores para las US del ejemplo:
Dados estos valores, el equipo de desarrollo dará más prioridad a las US #01 y #05, que son las referidas al manejo del carrito. Son las US que más la interesan al usuario que implican menos esfuerzo para el equipo. Luego seguirán las US #06, US#03, y US #04, para terminar con las US #07 y #02. Es importante notar que estos valores no son fijos y se pueden actualizarse al terminar cada sprint.
3. Técnica Urgente
Otra técnica para priorizar el backlog es utilizando una tabla de dos dimensiones, pero cambiando el concepto de StoryPoints por otro: la urgencia en tener lista una funcionalidad. Se introducen valores de 1 a 5, donde 5 implica que esa US debe estar lista ya o de lo contrario perderá sentido, mientras que un valor 1 indica que no hay apuro en tenerla lista.
También se tienen en cuenta para este valor de urgencia si la funcionalidad tiene que estar desarrollada por cuestiones contractuales, o porque de ella dependen muchas otras US, por lo debe implementarse antes. Los Business Value siguen la misma escala y se asignan valores de 1 a 5.
Obtenidas todas las asignaciones, se multiplican los valores de urgencia por los de Business Value (obteniendo números entre 1 y 25) y se ubican en una tabla como la que sigue:
Dada esta tabla, la priorización es evidente: primeros las US en el sector rojo, luego naranja, amarillo y finalmente las verde.
Retomando el ejemplo del comercio electrónico, se pueden asumir los siguientes valores:
Utilizando esta técnica, el equipo de desarrollo comenzará con la US #01, y luego atacará las US #05 y #06. Finalmente, las US #02 y #04, para terminar con las US #03 y #07. Comparado con la técnica anterior, la US #06 ha adquirido mayor prioridad, ya que con esta visión que el carrito sea sencillo de utilizar ha sido catalogado como más relevante.
Razones similares pueden utilizarse para justificar la mayor prioridad de la US #02 en esta ocasión.
La posibilidad de navegar el sitio para usuarios invitados ha sido clasificada con un alto valor de urgencia, por lo que ha subido su prioridad final.
A diferencia de las técnicas numéricas que en ocasiones no resultan efectivas, se ha desarrollado esta técnica que plantea una categorización de las US en función a palabras que tengan un significado concreto, para ello esta técnica propone utilizar las siguientes etiquetas:
M: Esta funcionalidad debe estar (MUST).
S: Esta funcionalidad debería estar (SHOULD).
C: Esta funcionalidad podría estar (COULD).
W: Esta funcionalidad no estará ahora, quizás en un futuro (WON’T).
Luego, las US se llevan a cabo siguiendo esta clasificación: primero las US etiquetadas con M, luego con S, en tercer término aquellas con C y finalmente aquellas con W.
Esta manera de categorizar las US en base a palabras, permite una discusión posterior en función al significado de las mismas como veremos a continuación.
Los requisitos de "MUST" no son negociables si no se entregan, en este caso, el proyecto es un fracaso, por lo tanto, es de interés para todos acordar qué se puede entregar y será útil.
Es bueno tener características que están clasificadas en las otras categorías de "SHOULD" y "COULD".
Los requisitos "MUST" deben formar un conjunto coherente. No pueden ser simplemente "seleccionados" de todos los demás. Si lo son, lo que sucede es que, de forma predeterminada, todos los demás requisitos se convierten automáticamente en "MUST" y se desperdicia todo el ejercicio.
Los requisitos marcados como "WON’T" son potencialmente tan importantes como la categoría "MUST". No es inmediatamente obvio por qué esto es así, pero es una de las características que hacen de MoSCoW una técnica tan poderosa. La clasificación de algo como "WON’T" reconoce que es importante, pero se puede dejar para una versión futura. De hecho, se puede pasar una gran cantidad de tiempo tratando de producir una buena lista de "WON’T". Esto tiene tres efectos importantes:
- Los usuarios no tienen que luchar para obtener algo en una lista de requisitos.
- Al pensar en lo que se requerirá más adelante, afecta a lo que se pide ahora.
- Los diseñadores que ven la tendencia futura pueden producir soluciones que puedan adaptarse a estos requisitos en una versión futura.
5. Basados en Riesgos
Esta técnica propone simplemente hacer primero las US que involucren mayores riesgos. Lo cual implica realizar un análisis de riesgo completo antes de priorizar el backlog.
Para realizar el análisis de riesgos, ya hay mucha documentación escrita al respecto y por ello no vamos a entrar en este artículo en su análisis.
Las opciones para priorizar, teniendo en cuenta el negocio
Si tenemos en cuenta, principalmente, el Valor del Negocio nos encontramos con distintas técnicas a las ya vistas, en la que priman principalmente el resultado del producto y su impacto en el negocio.
A modo introductorio, podemos observar las distintas técnicas en la siguiente matriz, en función de la complejidad y la exactitud en los resultados:
1. Juicio de Expertos
Complejidad: baja
Exactitud: baja
El juicio de expertos es la opción más simple y menos exacta: básicamente se prioriza según la opinión del propio product manager, o de algún stakeholder con conocimiento de la industria (o incluso puede ser en base a juicio de clientes).
Esto se hace (y funciona relativamente bien) en proyectos pequeños con un “dueño de negocio” que tiene mucho conocimiento del problema y la solución que quiere; en estos casos, no vale la pena hacer ejercicios de priorización (considerando incluso que los vetaría si no estuviesen de acuerdo a sus decisiones).
Se deben usar con cuidado, ya que aporta una visión muy sesgada de la visión del negocio.
2. El modelo de KANO
Complejidad: medio baja
Exactitud: medio baja
El modelo de Kano propone dividir las funcionalidades que quiero implementar en 3 categorías:
- Necesidades básicas: si no están generan gran insatisfacción, pero si están no generan una satisfacción mayor (por ejemplo, la capacidad de escribir en un editor de texto).
- Necesidades de performance: estos son los que generan mayor satisfacción cuando están y mayor insatisfacción cuando no. No son críticos para el uso del producto, pero serán un factor de decisión contra competidores (por ejemplo, la capacidad de agregar imágenes en un editor de texto).
- Deslumbrantes: son aquellas características no esperadas por el usuario, que generan gran satisfacción si están, pero no generan insatisfacción si no se encuentran (por ejemplo, la capacidad de dictar oralmente a un procesador de texto).
Uno de los principales problemas es que si bien categorizamos los resultados, no nos provee ninguna facilidad para priorizar entre 2 features del mismo grupo. Buen modelo para compararse contra competidores y entender qué y cómo valor el usuario tu producto. Es limitado como técnica de priorización.
3. Matriz de Priorización
Complejidad: media
Exactitud: medio baja
También conocida por su nombre en inglés “Scorecard”, consiste en armar un cuadro de doble entrada con las funcionalidades que voy analizando y su puntuación (de 0 a 10 o de 0 a 100) para cada dimensión alineada con los objetivos del producto. Cada dimensión suele tener un peso relativo, así que el valor final de la idea que está siendo evaluada es la sumatoria de la multiplicación de su puntuación por el peso de la dimensión. En el siguiente ejemplo queda más claro y es relativamente fácil de implementar con un simple excel:
La principal desventaja es que la evaluación de la puntación para cada dimensión sigue siendo muy subjetiva y muy cercana al juicio de expertos. Pero deja más claro el análisis que el experto hace sobre los atributos clave.
4. Fórmula
Complejidad: alta.
Exactitud: medio baja.
La fórmula de priorización en algún punto es muy similar a la matriz: se tienen en cuenta una serie de factores para cada funcionalidad que, en lugar de explayarse, en una matriz se completan en una fórmula que da un valor. Es más intrincada que la matriz ya que desarrollar y ajustar la fórmula puede requerir más esfuerzo, teniendo en cuenta que no es una simple sumatoria si no que en general hay factores que se combinan con otros de forma más compleja. De todas formas, tiene el mismo valor que la matriz de priorización, termina siendo susceptible al juicio de expertos y en general no agrega mucha más exactitud al cálculo.
5. Evaluación de Oportunidad
Complejidad: media.
Exactitud: media.
La evaluación de oportunidad es una simplificación de una evaluación financiera. Básicamente es una serie de preguntas que hacemos para cada funcionalidad que queremos explorar, siendo las principales:
- ¿Qué problema estamos tratando de resolver?
- ¿Para quién? (segmento)
- ¿Cuán grande es la oportunidad? (tamaño del mercado)
- ¿Por qué ahora? (potenciales tendencias)
- ¿Cómo vamos a determinar si tuvimos éxito? (KPIs)
Responder estas preguntas requiere algo de complejidad y evaluación, pero es mucho menor a la evaluación financiera. En general, la priorización suele hacerse por tamaño del mercado, pero no se hace un cálculo complejo sobre qué penetración espero o qué niveles de conversión voy a alcanzar en base a la historia pasada.
6. Evaluación Financiera
Complejidad: alta.
Exactitud: medio alta.
La evaluación financiera consiste principalmente en traducir cualquier beneficio que pueda darnos la implementación que estamos evaluando en un resultado económico. Hay algunos aspectos más “literales” (por ejemplo, más ventas se traduce directamente a un valor monetario), y otros más complejos (por ejemplo, más satisfacción del cliente, se traduce en más fidelidad, que da más recompra en el tiempo, lo cual se traduce en dinero). La idea es simple, la ejecución es difícil.
En general suelen tener más éxito aquellas empresas o productos que tienen más tiempo en el mercado, que pueden usar historial pasado para predecir el valor financiero de una nueva idea similar a algo que ya se hizo.
Por ejemplo, si estoy bajando el tiempo de carga de mi página de resultados de búsqueda de 5 segundos a 4 segundos, espero un incremento de conversión. Predecir ese incremento es mucho más fácil si ya en el pasado lo baje de 6 segundos a 5 y medí el impacto que tuvo. De todas formas, si no dispones de un historial, deberás de hacer una “suposición informada”, ya sea haciendo un poco de investigación de este impacto en otras compañías que hayan expuesto resultados o tomando aproximaciones en base a información relacionada de tu producto (por ejemplo, cuánta gente deja la página luego de 4 segundos que no carga).
Este método tiene 3 ventajas:
- Es sin duda el más preciso de los mencionados hasta ahora.
- Tiene capacidad para equiparar funcionalidades muy disímiles (por ejemplo, comparar algo que aumente las ventas contra algo que automatice un proceso y ahorre costos -ambos serán traducidos a dinero-).
- Suele ser la mejor carta para justificar con stakeholders u otros miembros de la organización (al menos, la menos sujeta a opiniones).
7. Priorización por Experimentos
Complejidad: medio alta.
Exactitud: alta.
Priorizar en base a experimentos consiste en no hacer un cálculo de cuánto aportará una funcionalidad, si no ejecutar un experimento que no te lleve más de un día realizar y te dé información concreta aportada por los usuarios para estimar el valor que tendrá la funcionalidad.
Pongamos un ejemplo: Spotify quiere aumentar 2% el ratio de conversión de usuarios pagos, y supongamos que quiero experimentar agregar la posibilidad paga de que los usuarios busquen una canción “cantando al micrófono” de su celular o computadora. Para ejecutar el experimento no tengo más que escribir un mail: “Querido usuario, estamos agregando esta nueva funcionalidad que costará $X por mes. Por favor, para suscribirse oprima el botón que ve a continuación”. Creo que ejecutar esta prueba les llevaría alrededor de 20 minutos (contrastado con el complejo y posiblemente subjetivo análisis financiero). La información que obtienen es un número muy preciso de la gente que estaría dispuesta a suscribirse al servicio.
Desde ya la prueba tiene algunas otras opciones:
- Segmentar la base, no queremos bombardear a todos nuestros usuarios y quizás tengamos un segmento más “dispuesto” a optar por esto.
- Podemos complejizar aún más llevando al usuario a una landing con la posibilidad de ingresar la tarjeta de crédito. Con soluciones cómo Wix, Leadpages u otras, esto sería muy fácil de hacer aún sin saber programación, y me daría la validación más certera de que realmente quieren este producto (por más que después no les cobre y les muestre un mensaje de disculpas).
Tras esperar unas horas el resultado del experimento voy a tener un muy preciso porcentaje de conversión, que es ni más ni menos de lo que necesito para priorizar. Al ser estas pruebas tan rápidas, voy a poder ejecutar muchas en paralelo (o a lo largo de pocos días), y entonces tendré funcionalidades candidatas con sus resultados asociados:
- Búsqueda por canto - 0,8% conversión.
- Incorporar video clips - 1,3% conversión.
- Reproducir canciones de adelante hacia atrás - 0,01% conversión.
Las ventajas de éste método:
- Valores precisos para comunicar con stakeholders.
- Dado por usuarios reales (basta de suposiciones).
- Se pueden ejecutar estas pruebas en muy poco tiempo.