El mundo Agile está trayendo nuevos conceptos que estamos aplicando en  nuestro día a día. Uno de ellos es el Producto Mínimo Viable (MVP) que básicamente consiste en definir el mínimo conjunto de funcionalidades que necesito para poder subir a producción.

El concepto de MVP tiene una parte beneficiosa. Muchas organizaciones se están empezando a plantear el reducir el alcance y eso es un ejercicio de madurez que no es sencillo. El problema es que se está utilizando el MVP como el nuevo paradigma para cerrar un proyecto.
Por ejemplo, hay equipos que en vez de firmar un año de desarrollo firman cuatro meses con un alcance y una fecha cerrada y lo llaman MVP. Una vez más, entramos en la mentalidad de proyecto, después aparecerán los cambios porque el software es complejo y no podemos preveerlo todo. Esos cambios habrá que afrontarlos y finalmente acabaremos con un software deficiente al no tener tiempo para la calidad. ¡Lo que nos lleva pasando toda la vida pero reducido a cuatro meses!

Otro ejemplo típico ocurre cuando seleccionamos un conjunto de elementos del Product Backlog (PBIs), decimos que son nuestro MVP y los abordamos en cascada.

A esto le sumamos que volvemos a la falacia de que el éxito es entregar el MVP en fecha. ¿Dónde queda la inspección y adaptación de mercado? ¿Y si nuestros usuarios rechazan ese MVP? Con esta mentalidad perderemos la flexibilidad de un marco como Scrum para hacer lanzar hipótesis sobre lo que da valor a nuestros usuarios y tratar de contrastarlas.

Lo ideal es ir al mercado lo antes posible; En el primer Sprint es muy difícil y más cuando nuestro software sustituye a otro existente. Aún así, siempre se puede reducir el alcance para hacer lo que de verdad es mínimo para salir y no esperar varios meses. Algunos autores como Jeff Patton hablan de Experimento Mínimo Viable (MVE) como una manera de hacer lo mínimo para experimentar el éxito de nuestro producto aunque todavía no queramos lanzarlo a todos los usuarios y hacer el lanzamiento mundial. En un Sprint se pueden hacer muchas más cosas de las que creemos, y los equipos maduros en Scrum lo hacen.

Otro de los problemas del MVP es que hay mucho miedo a que “lo que no entra en el MVP no se hace nunca”. Este es el miedo tradicional de las organizaciones que trabajan con proyectos. Esta manera de pensar acaba por engordar tanto el MVP que acabas desarrollando Productos Mínimos de 18 meses ¡Eso es una locura en el 2018!. Pensemos que en el manifiesto Agile se hablaba de máximo 2 meses, y eso fue en el año 2001, seguramente hoy esos tiempos se vean excesivos.

¿Qué alternativas tenemos al MVP? Personalmente a mi me gusta más el Plan de Releases o de Sprints. Es una herramienta que utiliza el Product Owner para hacer una estrategia de subidas que trate de maximizar el valor y el impacto en el mercado. Esta herramienta consiste en distribuir los elementos del Product Backlog a lo largo del tiempo en Sprints. Bien entendida ayuda mucho como guía para saber el futuro del producto, mal entendida se  convierte en un proyecto cerrado con fechas de entrega. Una vez más, aquí dependerá de la mentalidad de producto o de proyecto que tengamos en el equipo.

Por tanto, me llena de ilusión que el mundo del management esté evolucionando. Esto es una necesidad por la manera tan pobre en la que hemos venido desarrollando software y la competitividad en el mercado internacional. Eso sí, utilizar palabras modernas para referirnos a conceptos antiguos refleja que la mentalidad sigue sin cambiar; Solo por cambiar el léxico no vas a conseguir el impacto en el mercado deseado. Desde mi humilde punto de vista te recomiendo que no pares de aprender y ser crítico con todos los conceptos nuevos que aprendas ya que mal entendidos te pueden llevar al lado oscuro.

Entradas relacionadas

Cómo crear un objetivo motivador

Cómo crear un objetivo motivador

¿Alguna vez te has marcado un objetivo y no los has alcanzado?. ¿Has experimentado algún objetivo que no te servía ...
Leer Más
product owner en Scrum

¡Nadie quiere ser Product Owner!

Muchas organizaciones están apostando por integrar Scrum en sus equipos. Scrum tiene un inconveniente cuando empezamos a usarlo y es ...
Leer Más

¿Te ha gustado el post?

¡Valóranos!

Promedio de puntuación 0 / 5. Total de votos: 0

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar