En los productos digitales lo importante es el valor.

En Internet, el entorno cambia a la velocidad de la luz: aparecen constantemente avances tecnológicos que ofrecen nuevas oportunidades; los usuarios no sólo se adaptan más rápido a los cambios que en otros ámbitos, sino que los demandan y, además, la competencia es mucho más amplia. No basta con vigilar a los rivales dentro del sector, ya que en cualquier momento puede aparecer un nuevo actor que dé un vuelco al mercado.

Ante este entorno complicado, cuando trabajamos con productos digitales, no podemos emplear los mismos métodos que si fuésemos a construir un edificio o un puente: es imposible recoger todos los requisitos al inicio.

Además, cualquier requisito cambiará en el tiempo y, por supuesto, siempre querremos tener el máximo con la menor inversión. Los métodos tradicionales no dan respuesta ante esta necesidad de cambio constante.

El manifiesto ágil ya nos da una visión sobre cómo prepararnos para el cambio constante: centrarnos en lo importante y valorar software funcionando como medida de avance, interacciones, individuos y colaboración frente a negociación, etc. Pero esto no es suficiente, necesitamos más detalle de cómo centrarnos en lo importante de nuestro producto si queremos alcanzar el éxito.

El valor como eje de la agilidad

En Scrum se define un Product Backlog con todas las funcionalidades a incluir en nuestro producto. Dicho Product Backlog debe estar priorizado por el Product Owner y las funcionalidades más prioritarias deben estar definidas en detalle para que el equipo se enfoque en ellas.

Pero ¿cuál es el método correcto para priorizar el Product Backlog? ¿Cómo saber qué es lo más importante para que un equipo esté centrado 100% en ello? Es ahí donde surge el concepto de valor.

El valor se define como el beneficio que un determinado producto o funcionalidad individual aporta a una organización, representado en términos monetarios. Y es esa la visión que tiene que tener el Product Owner para priorizar el backlog.

Si el valor es el beneficio monetario que obtiene una organización del uso del producto, ninguna funcionalidad va a conseguir obtener dinero si no se desarrolla y se pasa a producción.

Trabajando con una metodología tradicional en cascada, con sus fases de definición, análisis, desarrollo, testing… hasta que no lancemos el producto completo al final de todas estas fases no vamos a poder obtener nada. Ni valor, ni feedback de los usuarios. Es decir, en el mejor de los casos, vamos a estar meses sin obtener valor. Y meses, en el mundo digital, es un plazo de tiempo que no te puedes permitir.

Sin embargo, si empleamos métodos ágiles comenzamos a obtener este valor mucho antes. Con Scrum, desde las primeras iteraciones, ya deberíamos tener algo que aporte valor.

El concepto del MVP

Es ahí donde entra el concepto de MVP (Mínimo Producto Viable). Una de las cuestiones que deben resolverse desde el inicio es cuál es la mínima versión que me va a permitir lanzar el producto y empezar a obtener valor real del mismo.

En Scrum, por ejemplo, esto se traduce en “a partir de qué Sprint vamos a lanzar la primera release a producción”. Y por tanto, en qué Sprint comenzamos a obtener valor, reduciendo el plazo de meses a semanas, rango de tiempo más aceptable cuando hablamos de Internet.

Existe un falso mito de que una vez lanzado el MVP ese será el producto final y no se evolucionará. Pero nada más lejos de la realidad, trabajar con el concepto de MVP e incrementar su funcionalidad en releases posteriores es importante por dos cosas principalmente:

• Cuanto antes lances una versión, antes podrás comenzar a obtener beneficios que reporten ingresos a la compañía y permitan seguir financiando la evolución del producto.
• Por muy trabajada que tengas la estrategia y definición del producto, hasta que el usuario no interaccione con él, no se va a conocer exactamente qué es útil para él y cómo usa el producto. En la era Customer Centric, el usuario tiene la batuta, y esta no comienza a dirigir hasta que el usuario y el producto se conocen.

Mide y vencerás

Para potenciar aún más el valor obtenido y poder valorarlo hay que introducir las mediciones. Cada funcionalidad lanzada tendrá un valor previo basado en hipótesis, pero, una vez que esta funcionalidad esté disponible para los usuarios tendremos que comprobar si efectivamente está aportando el valor que creíamos para que esta información nos permita reenfocar el producto o la priorización de funcionalidades posteriores.

Para ello, cada funcionalidad lanzada tendrá que tener definidos unos indicadores a medir y, al igual que se incluyen tareas de maquetación, desarrollo de test automáticos, etc., también se incluirá el desarrollo de la analítica necesaria que nos permita obtener datos objetivos en cuanto esa funcionalidad sea lanzada.

En Paradigma hemos definido un método para hacerlo e incorporarlo en el ciclo de trabajo de Scrum, si quieres saber más sobre cómo lo hacemos puedes leerlo aquí más en detalle.

En resumen, trabajar con el concepto de MVP y métodos ágiles que permitan ampliar el producto en iteraciones posteriores reduce riesgos, costes y proporciona información muy valiosa para próximas releases. Permite trabajar con unos plazos más adecuados a lo que el mundo digital necesita. Y, sobre todo, supone un cambio de mentalidad para que los equipos se centren en entregar productos que aporten valor de negocio, y no solo en ejecutar proyectos en tiempo y coste.