En este artículo expongo algunos consejos sobre cómo hacer el triaje de funcionalidades que podría contener un producto.

Existe un axioma bien conocido en marketing que afirma que ningún producto satisface todas las necesidades. Sin embargo, por razones de mercado, la tendencia en diseño suele ser intentar que el producto satisfaga el máximo de necesidades posibles. En software, los comerciales se quejan al principio de que el programa no se vende bien porque no hace suficientes cosas. Entonces en el departamento de desarrollo empiezan a añadirle funcionalidades y más funcionalidades y más funcionalidades, hasta que los comerciales se quejan de que el producto no se vende bien porque es demasiado complejo. Es fácil ver este dilema en muchos otros productos. Por ejemplo, es posible diseñar un coche deportivo, ligero, con un potente motor y suspensión dura, o es posible diseñar un coche familiar de gran tamaño y confortable con gran autonomía, o es posible diseñar un utilitario eléctrico para conducir por la ciudad sin emisiones de CO2 y con rápida aceleración cuando los semáforos se ponen en verde. Sin embargo, el intento de diseñar una ranchera familiar con motor híbrido de alta velocidad punta y autonomía y bajo consumo por kilómetro está casi inexorablemente condenado al fracaso.

El principio más importante en diseño de sistemas complejos

Antes de entrar en las técnicas para la selección y priorización de funcionalidades, me gustaría exponer uno de mis principios de diseño favoritos:

Cualquier producto grande y complejo que no ha evolucionado a partir de otro pequeño y sencillo (que funcionaba bien) no funciona y, además, es imposible arreglarlo para que funcione.

Este principio (creo que) lo leí en el libro The Design and Evolution of C++ de Bjarne Stroustrup.

Los ingenieros de software veteranos saben por experiencia que en programación menos es más. El software exitoso no es, en general, aquel que hace muchas cosas de forma aceptable sino el que hace sólo unas pocas cosas de forma excepcionalmente bien.

Cómo se crean los monstruos

Antes de entrar en las técnicas para priorizar funcionalidades, conviene reflexionar sobre cómo se crean los monstruos. Muy resumidamente, la mayoría de los monstruos son el fruto de una visión sin estrategia. La estrategia consiste en elegir unas cosas renunciando a otras. Priorizar las funcionalidades con el propósito de implementarlas todas no es una estrategia, sólo es una forma de organizar el desastre venidero de forma eficiente y militar.

El problema se agrava en muchas organizaciones modernas debido a la obsesión con el consenso. El consenso es algo muy deseable cuando no imprescindible para que las personas colaboren. Pero tiene al menos cinco desventajas:

Se tarda más tiempo en tomar una decisión consensuada. Las decisiones consensuadas casi nunca son lo bastante audaces, o todo lo contrario, son absolutamente temerarias. La responsabilidad se diluye en el grupo causando que ningún individuo se sienta culpable de las malas decisiones en las que participó activamente. Los participantes en una decisión pueden tener intereses enfrentados. Los participantes en una decisión tienen tendencia pensar que lo último que acaba de pasar es más importante y urgente que lo que sucedió anteriormente.

Además de lo anterior, es frecuente que el gerente del proyecto deba enfrentarse a los siguientes desafíos:

Liderar el equipo sin autoridad real sobre los miembros. Trabajar con equipos externos. Influenciar en las decisiones a través de terceros. Construir relaciones de colaboración.

En teoría, los objetivos de negocio deberían dictar la naturaleza y plazos de los entregables a producir y estos, a su vez, definir las tareas necesarias para fabricarlos. En la práctica, el consenso y la estructura de poder causan que el producto crezca cómo una solución de compromiso entre las partes interesadas más que cómo una solución para satisfacer una demanda de mercado.

Es frecuente que se añadan funcionalidades porque:

Un cliente lo bastante importante las exige.

Un miembro del comité tiene más poder o grita más que los otros.

La competencia ha añadido la funcionalidad y hay que alcanzarles.

Es una moda o una tendencia de mercado.

La regla simple para hacer el triaje y priorizar

El método propuesto aquí para puntuar cambios se basa en los siguientes factores:

Alcance : El número de usuarios beneficiados (o afectados) por el cambio.

: El número de usuarios beneficiados (o afectados) por el cambio. Impacto : Estimación cuantitativa de lo que afectará el cambio a cada usuario individual.

: Estimación cuantitativa de lo que afectará el cambio a cada usuario individual. Beneficio : Cuanto mejorará la cuenta de resultados de la empresa con el cambio.

: Cuanto mejorará la cuenta de resultados de la empresa con el cambio. Coste de oportunidad : Es el coste de no resolver el problema.

: Es el coste de no resolver el problema. Esfuerzo: La cantidad de trabajo y recursos que se necesitan para implementar el cambio.

La fórmula es sencilla:

Alcance × Impacto × Beneficio × Coste de Oportunidad ÷ Esfuerzo

A mayor puntuación mayor prioridad. Y lo quede por debajo de cierto umbral simplemente no se hace nunca.

Hay que tener en cuenta que el esfuerzo depende de lo grande que sea el producto. Una broma común entre desarrolladores es que realizaron la primera versión de la aplicación en tres días durante una hackaton pero en la versión 3.0 se necesitan tres días de esfuerzo sólo para cambiar un icono.

Marcos de trabajo para la priorización

Siendo el establecimiento de prioridades una función crítica para todos los negocios, se han creado múltiples marcos de trabajo para dicha función de los cuales comentaremos aquí sólo algunos. Grosso modo, los métodos pueden clasificarse en “de afuera a dentro versus de dentro a fuera” y en “cuantitativos versus cualitativos”. En los métodos de fuera a adentro la pregunta es: “¿Qué quiere el mercado que yo fabrique?” En los métodos de fuera a adentro la pregunta es: “¿Qué podría fabricar yo que el mercado desease?”.

La regla de Zuck

Antes de comentar modelos sofisticados, me gustaría mencionar el lema de Mark Zuckerberg: “move fast and break things”. Esto en la práctica se traduce en empezar haciendo lo que es fácil y reporta beneficios, difiriendo todo aquello que es complicado y lo que nos podríamos fácilmente atascar. Un consejo similar ha dado en repetidas ocasiones Bill Gates: “en Microsoft las cosas fáciles las hacemos muy fáciles, las cosas difíciles las hacemos fáciles y las muy difíciles solemos evitarlas”.

El modelo de Kano

El modelo de Noriaki Kano postula que el nivel de satisfacción de un cliente depende del nivel de funcionalidad que recibe. Se puede determinar cómo se siente el cliente respecto de cada calidad mediante cuestionarios. Y las funcionalidades se pueden agrupar en cuatro categorías:

Rendimiento. Son la clase de funcionalidades sobre las que más en mejor. Debe tener. Lista de cosas que es absolutamente imprescindible que tenga el producto. Atractivas. Son funcionalidades que sobrepasan las expectativas iniciales del cliente. Indiferentes. Funcionalidades que el cliente considera que el producto podría tener o no.

Para cada funcionalidad, en los cuestionarios de Kano, a cada usuario se le hacen dos preguntas: 1ª) ¿Cómo se sentirían si el producto tuviese esta funcionalidad? y 2ª) ¿Cómo se sentirían si el producto no tuviese esta funcionalidad? Las respuestas posibles son: “Me gusta”, “Esperaría tenerla”, “Soy neutral”, “La puedo tolerar”, “Me disgusta”. Finalmente Kano monta una tabla de decisión combinando ambas respuestas.

Lo que a mi personalmente no me convence del Modelo de Kano es que parte de dos hipótesis: 1ª) el usuario sabe lo que quiere, y 2ª) el usuario sabe cómo priorizar lo que quiere. En mi experiencia, ambas hipótesis son falsas. De hecho, el diseño iterativo Agile se basa en ir descubriendo lo que el cliente necesita. En Agile, todavía se le permite al cliente fijar prioridades pero se asume que la lista de funcionalidades no es por completo conocida al inicio del proyecto. Entonces ¿cómo priorizar lo que no se conoce?

El modelo de Akao

El modelo de otro japonés, Yoji Akao, es comúnmente conocido cómo Quality Function Deployment (QFD). El método se fundamenta en enumerar, por un lado, lo que el cliente quiere (la voz del cliente) y, por otro lado lo que la empresa necesitaría hacer para satisfacer la demanda del cliente (la voz de la empresa). Entonces se trata de compatibilizar el qué con el cómo. Las prioridades se fijan empezando primero por lo que el cliente desea y la empresa puede proporcionar de forma eficiente y conveniente. El método tiene su origen en el diseño industrial de barcos petroleros Mitsubishi y furgonetas Toyota en los setenta derivados del Keystroke Level Modeling de los sesenta en cuyo proceso había que compatibilizar por fuerza lo que el cliente quería con lo que realmente podía salir del astillero o de la factoría.

La Puntuación de Oportunidad de Ulwick

Esta técnica figura en el libro “What Customers Want” de Anthony Ulwick. Dentro de lo que él denomina Outcome-driven Innovation (ODI). Según Ulwick, lo que importa es lo que el cliente quiere conseguir. Sin embargo, los propios clientes no son una buena fuente para determinar cómo conseguirlo. Su aporte es imprescindible para saber cual es el resultado esperado pero no para saber cuales son los medios para alcanzar dicho resultado.

La puntuación de oportunidad (Opportunity Score) de Ulwick para cada funcionalidad tiene la siguiente formula:

Importancia + máx(Importancia – Satisfacción, 0) = Oportunidad

La satisfacción es el grado en que la funcionalidad está ya cubierta. Esta fórmula es especialmente útil para identificar oportunidades de innovación donde la funcionalidad es importante pero no está para nada satisfecha actualmente.

Subasta de oportunidades

La subasta de oportunidades es una variante gamificada en la que un grupo de usuarios tiene que pujar por funcionalidades cada una de las cuales tiene un coste. El usuario puede “comprar” una funcionalidad. Entonces tiene que explicarle a los otros usuario porqué la ha comprado. Obviamente existe una cantidad limitada de dinero imaginario para todos los usuarios.

Poda de Hohmann

Es otra técnica gamificada llamada en inglés product tree pruning en la que las funcionalidades se representan cómo ramas en un árbol. Entonces los usuarios deben permitir crecer o por el contrario podar determinadas ramas.

Ranking de funcionalidades

El ranking es una forma de priorizar el backlog consistente en puntuar las funcionalidades mediante la opinión de expertos. Puede ser una forma rápida de crear una lista ordenada. Pero hay que tener siempre presente que se fundamenta en una opinión y no en una prueba real de demanda del mercado.

Mapeo de Historias de Usuario

El Story Mapping, se basa en un artículo de Jeff Patton en el cual afirma que los backlogs son una mala forma de organizar el trabajo pendiente. La razón es que el backlog se convierte en un saco enorme de cosas que la aplicación podría hacer. Para salir del atolladero, lo que hay que hacer es describir cómo utiliza el usuario el producto y mejorar los puntos débiles de la secuencia. Un enfoque similar se encuentra en las herramientas cómo JIRA que permiten asignar las funcionalidades a épicas.

MoSCoW

Sería imperdonable escribir sobre técnicas de priorización sin mencionar MoSCoW. En este método se asigna a cada una de las funcionalidades una etiqueta:

Must Have . Debe tener.

. Debe tener. Should Have . Debería tener.

. Debería tener. Could have . Podría tener.

. Podría tener. Won’t have. No tendrá.

La belleza de MoSCoW es su simplicidad.

Los Feature Buckets de Adam Nash

La técnica de los feature buckets se basa en que las funcionalidades deben clasificarse en cuatro grupos:

Funcionalidades que impactan en una métrica de negocio. Estas deben ser cuantitativamente medibles. Cómo el ratio de adquisición o la tasa de abandono. Peticiones explícitas de los clientes. Maravillas. Ideas que no se le han ocurrido al cliente pero que harán su vida mejor. Funcionalidades estratégicas. Por ejemplo, aquellas que el producto debe poseer para integrarse y crear sinergias con otros productos.

Scorecards

Los scorecards son muy populares en los masters de administración de empresas. Aplicados la priorización de funcionalidades, consisten básicamente en puntuar cada funcionalidad en base a un conjunto de criterios negociados previamente con los incumbentes. Además, es posible asignar un “peso” a cada uno de los criterios. Supongamos que estamos desarrollando una aplicación de banca por Internet. Cada funcionalidad podría puntuarse, por ejemplo mediante los siguientes criterios:

Seguridad. La seguridad y la percepción de seguridad son muy importantes en este caso, de modo que este criterio debería tener un gran peso. Facilidad de uso. Debido a que la mayoría de los clientes intentarán acceder desde el móvil, este es otro criterio de peso. Consistencia. Por ejemplo para que las operaciones en banca personal y banca de negocio sean lo más parecidas posibles. Este criterio es deseable pero no imprescindible. Completitud. Para que cualquier operación se pueda realizar a través de Internet. Funcionalidades estratégicas. Por ejemplo el pago de impuestos.

Métricas financieras

En aplicaciones comerciales, cuando se entrega un producto, todas las técnicas anteriormente descritas deben contribuir a mejorar los resultados de la empresa. Esta mejora de resultados puede producirse de cuatro formas:

Generando ingresos de nuevos clientes. Generando más ingresos de los mismos clientes. Reduciendo la tasa de abandono. Abaratando costes.

Es por ello deseable que cada funcionalidad se puedan relacionar de alguna manera con uno o varios de los puntos anteriores que se corresponden con las fases del ciclo de ventas:

Adquisición. Activación. Beneficio. Retención. Referencias.

Lo que suele ser difícil es estimar directamente el impacto de las nuevas funcionalidades sobre las métricas financieras clásicas: Retorno de Inversión (ROI), Tasa Interna de Retorno (IRR), Valor Actual Neto (NPV), Periodo de Recuperación, etc. No voy a comentar aquí estas métricas, sobre las que existen innumerables libros.

Conclusión

Durante el desarrollo de un producto es igual de difícil decidir qué hacer que decidir que no hacer.

Además, en ausencia de una buena metodología de gestión de prioridades el backlog crece imparablemente hasta resultar imposible de acometer.

Para gestionar el backlog hay que separar la misión de la estrategia y encontrar una forma de agrupar y ordenar funcionalidades en base a los objetivos.

Del backlog se puede obtener una lista de tareas y entregables que proporciona a los desarrolladores quienes deben aportar un plan de implementación.