#20 El MVP o lo perfecto es enemigo de lo bueno
Hola soy Francisco Fernández @franferparra, Principal Director de Accenture y esta es mi newsletter dedicada a entender la tecnología a través de la simplificación. Porque no es lo mismo Simple que Fácil!
He estado ausente un par de semanas debido a que estoy haciendo un curso de Complex Problem Solving que me quita el poco tiempo del que disponía, de hecho, de momento la Newsletter va a pasar a ser quincenal hasta que termine el curso. Hoy traigo un nuevo post dedicado al famoso Producto Mínimo Viable (MVP) . Esta edición se la dedico a mi mujer que hoy es su cumpleaños y me aguanta y apoya en esta y otras frikadas. Así que espero que os guste y si os sentís identificados me encantaría conocer vuestra opinión.
El MVP de Leonardo Da Vinci
Leonardo Da Vinci estaba fascinado por el vuelo de los pájaros y soñaba con hacer que los seres humanos surcasen los cielos de la misma forma…
Así que se puso manos a la obra, comenzó a observar a los pájaros e insectos y redactó dos tratados sobre el vuelo de los animales. Parecía fácil trasladar ese mecanismo a los humanos, tan solo tenía que ponerle unas alas a un hombre y simplemente batiéndolas el hombre volaría. Enseguida se dio cuenta que un hombre no tiene la suficiente fuerza para batir las alas así que necesitaba una máquina basada en poleas y palancas para poder accionar las alas a la velocidad necesaria para volar. Diseñó planos exhaustivos con medidas y cálculos.
Construyó un prototipo y mandó a uno de sus aprendices a saltar desde el tejado de la casa. Te puedes imaginar el resultado… algún hueso roto y un buen susto en el cuerpo
¿Cómo puede ser que un genio como Leonardo fallase? El motivo principal es que no conocía los principios de la aerodinámica y partía de unas hipótesis que no eran del todo correctas. Pero el prototipo le sirvió para probar sus diseños y realizar modificaciones antes de subirlo a una montaña más alta y matar a varios “voluntarios”
El prototipo le sirvió a Leonardo para validar sus hipótesis iniciales y a obtener un feedback preciso para ir modificando el diseño aunque no llegó nunca a funcionar
Hoy, quinientos años después, en el ámbito del desarrollo de tecnología digital en las compañías está muy de moda hablar de un tipo de prototipo al que llamamos el MVP o Producto Mínimo Viable en español.
EL MVP hoy
Pero no voy a hablar del concepto del MVP aplicado al desarrollo de un nuevo producto en una startup sino del uso que se le está dando en un entorno empresarial “tradicional” sobre todo en el ámbito de IT. Además, lo que te voy a contar parte de mi experiencia personal tanto como consultor como desde el otro lado como responsable de proyecto.
Hoy en día parece que es obligatorio que cualquier proyecto tenga la palabra MVP en su planificación veamos con algo de detalle que implica eso:
¿Para qué sirve un MVP?
La obra de Leonardo está llena de diseños al igual que las propuestas de los consultores están llenas de Power Points o de Business Case en Excel. Sin embargo, cada vez nos estamos volviendo más escépticos al papel y necesitamos ver y probar antes de dar por buena una solución. Necesitamos confirmar todas las hipótesis antes de lanzar el proyecto a gran escala y ahí es donde nace el concepto del MVP
Aunque el término de Mínimo Producto Viable está bastante manido es importante parar un momento y analizar las tres palabras:
Mínimo: Significa que se debe incluir en el alcance la funcionalidad mínima que cumpla con el objetivo o con el time to market.
Producto: Debe poseer una serie de características y atributos que a un “comprador” le resuelven un problema o le satisfacen una necesidad.
Viable: Primero debe ser técnicamente viable, es decir, debe confirmar que se puede implementar y después debe validar que es viable desde el punto de vista de negocio.
Los principales beneficios de hacer un MVP son:
El cliente se hace una idea del producto en una fase inicial donde puede dar un feedback muy positivo
Puede evitar retrabajos. Es un trabajo iterativo e incremental, es decir, como dispongo de un producto básico en poco tiempo sobre él puedo tener algún retrabajo, pero a medida que voy avanzando la solución está mucho más cerca de lo que el cliente necesita
Si la construcción del MVP se asocia a metodologías ágiles se reducen los tiempos de desarrollo
Reduce riesgos, el MVP tiene que buscar despejar las incertidumbres iniciales a medida que vamos teniendo un producto que pueda ser testado en un entorno real. Si vamos probándolo poco a poco podremos ir haciendo modificaciones a diferencia de si desarrollásemos todo y luego lo lanzásemos con el 100% de funcionalidad
¿Qué diferencia hay entre definir un MVP o hacer un plan de proyecto por fases?
Los proyectos “tradicionales” siempre se han planificado en fases, pero esa división tenían más que ver con la gestión del proyecto y recursos que con el problema del cliente que quiero resolver.
La planificación de un “proyecto tradicional” estaba condicionada por la funcionalidad en alcance, es decir, cuanto más incluya más dura el proyecto. En el MVP generalmente pasa lo contrario, el alcance está condicionado por el tiempo en el que tiene que estar lista la solución, es decir, cabe lo que cabe.
En el MVP, el time to market fija el alcance mientras que en un proyecto tradicional la fecha de arranque es la consecuencia de una planificación óptima de actividades y recursos
Por ejemplo, una compañía quiere sacar al mercado un nuevo producto con una propuesta digital en 6 meses y necesita una nueva solución que de soporte a la venta de este producto. El objetivo del MVP en este caso debería ser tener una solución con lo mínimo o con manualidad que permita ofertar, contratar y facturar este nuevo producto en esos 6 meses ya que es parte de su estrategia comercial. Todo lo que no contribuya a vender este producto y ralentice o encarezca el desarrollo debería ser parte de una fase posterior
Tipos de MVP
Yo distinguiría al menos dos grandes tipos de MVP:
EL MVP de una nueva solución para probar la viabilidad sobre un nuevo problema a resolver. Este sería el MVP de Leonardo con la máquina de vuelo. Aquí es donde generalmente entran los proyectos de innovación donde el grado de incertidumbre sobre el beneficio final es alto. Por ejemplo, un proyecto de captura de datos con IoT para mejorar el proceso de mantenimiento de equipos. Podemos tener un modelo teórico y creer que si disponemos del suficiente volumen de datos podremos sacar conclusiones valiosas, pero es necesario validar esas hipótesis y esa viabilidad con casos reales ya que como dice el dicho el “El diablo está en los detalles”
EL MVP de una nueva solución sobre un problema conocido. Dentro de este subgrupo encontramos nuevas formas de resolver problemas o casos de uso conocidos mediante nuevas soluciones. Por ejemplo, la implantación de un nuevo CRM para mejorar mi gestión comercial. A priori conozco mis ineficiencias en el proceso comercial y busco un software que me ayude a mejorar esos procesos. En este caso la incertidumbre no está la solución sino más bien en cómo la compañía transforme sus procesos y cultura.
Errores en la definición y desarrollo del MVP
Definición incorrecta del alcance o “cuanto más mejor”: Para mí uno de los grandes problemas, se tiende a engordar el MVP con funcionalidades que no son imprescindibles y esto genera retrasos y pérdida de foco además de interminables discusiones de que es o no es crítico para la operativa. Digamos que no nos creemos que después del MVP vengan nuevos despliegues con más funcionalidad así que prefiero asegurar.
Ineficiencia en la toma de decisiones o “esto habrá que votarlo, ¿no? Es imprescindible que el equipo de proyecto tenga autonomía para tomar decisiones, si todo tiene que ser consensuado por diferentes unidades, la inacción está garantizada.
No alineamiento en el objetivo del MVP o “a mí es que me han dicho que…”. Muy habitual también, el concepto y objetivo del MVP no se le traslada al equipo del proyecto de manera uniforme así que hay diferentes entendimientos y por lo tanto, hay discusiones de si una funcionalidad debería o no estar en el lanzamiento.
Subestimar el coste del escalado o de la gestión del cambio o “esto está tirado…”. Por ejemplo, una solución que tengo que implantar en todos mis centros de producción, si mi equipo de despliegue es pequeño y tiene que hacer el proceso presencial, se me puede generar un cuello de botella que aunque la solución cumpla con las expectativa, la implantación total puede ser una tarea de años
Posibles buenas prácticas en la gestión del MVP
Recojo a continuación algunas cosas que me han sido útiles en la gestión de los MVPs.
La principal para mí sería tener un Business Case o unos KPIs sobre los que se vaya a medir el proyecto. Si las palancas del Business Case están directamente relacionadas a la funcionalidad del MVP, es más fácil objetivar que es importante y que no en las discusiones de alcance. Es decir, tan solo se desarrolla lo que realmente tiene un impacto medible en el corto plazo. Los desarrollos deseables, tienen que pasar a una siguiente fase
Identificación de incógnitas a resolver con el MVP. El feedback del producto es imprescindible para poder cambiar o deshacer funcionalidades que asumíamos al inicio que iban a ser necesarias. Por eso, en las funcionalidades donde tenemos muchas incógnitas de si el usuario o cliente las va a demandar hay que invertir el esfuerzo necesario porque puede que después haya que “tirar” esa funcionalidad
Aplicar Manualidad ver que es el MVP es satisfactorio y después automatizar. A veces es preferible salir antes sin automatizar funcionalidad y tener un proceso manual de forma transitoria
Hacer conceptualización con los futuros usuarios y no solo con los responsables del proceso. Por ejemplo, si estamos desarrollando un CRM el responsable del proceso querrá tener para cada oportunidad una lista interminable de informaciones para sus futuros informes. Sin embargo, el comercial que va a ser el usuario futuro puede ver que dedica más tiempo a rellenar datos en un sistema que a lo que realmente aporta valor que es captar clientes. El equilibrio es la clave
La importancia de la muestra. Tener una muestra de usuarios/clientes lo suficientemente heterogénea que permita sacar conclusiones. A veces el Friends&Familiy nos da resultados engañosos
Conclusión
El MVP es una fantástica herramienta para poder tener un producto en un tiempo récord y que nos permite probar e iterar. Además, con la velocidad a la que se mueve el mundo ya nadie tiene tiempo para desarrollar la mejor solución, es preferible tener algo pronto y a partir de ahí evolucionar
Sin embargo, este cambio de paradigma requiere de un cambio en los equipos de proyecto, en los implantadores, en los negocios y en los departamentos de IT. No podemos utilizar el MVP solo como herramienta para acortar los proyectos, porque ahí es donde entramos en el terreno de los conflictos. Si el MVP no responde a un objetivo a resolver con unos casos de uso concretos y con un Business Case por detrás las discusiones en cuanto a que forma tendrá el producto se pueden llegar a hacer eternas y retrasar o matar el proyecto
Aquí acaba el post de esta semana, espero que te haya gustado, si es así por favor, compártelo en LinkedIn para que lo pueda ver más gente.
Muchas gracias y hasta la siguiente edición.