Skip to main content

A lo largo de mi carrera como consultor tecnológico para grandes entidades bancarias he participado en infinidad de proyectos, todos diferentes en cuanto a contenidos y todos similares en cuanto a resultados. Poca usabilidad, falta de funcionalidad, grandes esfuerzos… Siempre me he preguntado cuál era el motivo para acabar en la misma situación.

¿No estábamos entendiendo los requerimientos? ¿No éramos lo suficientemente buenos a la hora de ejecutarlos? ¿El cliente no estaba entendiendo el producto? Muchas preguntas y pocas respuestas, hasta que en una conversación de cafetería alguien habló sobre la iteración y el hecho de aprender en cortos periodos de tiempo.

Después de investigar un poco sobre estos conceptos empecé a conocer que existían otras maneras de llegar al resultado final de un proyecto, más ágiles, más sencillas y con más garantía de éxito.

En mi cabeza empezaron a sonar nuevos términos, metodologías de trabajo, iteraciones, manifiestos, equipos multidisciplinares… Pero sobre todo llamó mi atención, no por la palabra, sino por su significado, la palabra MVP (Producto Mínimo Viable).

Según las definiciones más técnicas, un MVP es una versión de un producto que permite a un equipo recabar la mayor cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo posible. Un MVP tiene sólo aquella funcionalidad requerida para mostrar el producto al cliente y su principal objetivo es evitar el desarrollar productos que los clientes no quieran y maximizar la información obtenida sobre los clientes con base en el costo y esfuerzo invertidos.

En mi opinión, un MVP sería el mínimo valor que puede aportar un producto a un cliente dedicando el mínimo esfuerzo posible.

Esta forma de resolver problemas cambió mi perspectiva sobre cómo ejecutar mis proyectos en el futuro. A partir de ese momento trataría de minimizar los problemas y sobre todo intentaría que mis equipos entendieran esta nueva forma de enfocar la ejecución de proyectos.

Todo iba sobre ruedas. Nos propusimos dedicar el mínimo esfuerzo posible a la hora de desarrollar. Creamos un nuevo entorno de trabajo donde todos podíamos opinar. Y conseguimos entender que todos debíamos tener la misma visión sobre lo que era importante y lo que no.

Pero como en todas las facetas de la vida, habíamos olvidado lo más importante.

El cliente no estaba dispuesto a cambiar la forma de trabajar y sus exigencias seguían siendo las mismas: ejecución y revisión al final del proyecto.

Nada más lejos de desistir en nuestro afán por cambiar las cosas, utilizamos las reuniones con el cliente para recabar la máxima información posible. Así, pudieron darnos pistas que nos permitieron entender cuáles eran los motivos que les llevaban a no querer evolucionar su forma de trabajar por una más efectiva.

Y fue así, sin darnos cuenta, cómo habíamos lanzado nuestro primer MVP.

Lo primero que entendimos es que les costaba visionar cómo «dividiendo» un producto en pequeñas funcionalidades podrían llegar a tener la misma funcionalidad que tenían con otro sistema que usaban en su día a día. Tenían miedo a no pulsar las mismas teclas que pulsaban todos los días, aunque eso le llevase mucho tiempo.

También detectamos muchas carencias a la hora de entender el ciclo de vida del proyecto. No solo en la nueva “metodología” que tratábamos de introducir, sino también en la forma de trabajar que habían seguido durante años.

Con esta información sobre la mesa, la verdad es que teníamos complicado cumplir nuestro objetivo. Pero no nos rendimos. Continuamos con nuestro cambio de mentalidad y pensamos en un nuevo MVP que nos permitiese avanzar un poco más.

¿Qué hicimos para lanzar nuestro MVP?

  • Creamos una formación básica sobre gestión de proyectos que impartimos una vez a la semana durante 1 hora.
  • Nos comprometimos a mantener el 100% de la funcionalidad que usaban en su día a día si nos permitían partir la funcionalidad total en pequeños hitos.

Con ello, vimos como en los meses siguientes las cosas cambiaron hasta tal punto que el propio equipo del cliente se convirtió en “embajador” del cambio dentro del área. La formación había servido para entender los pros y contras de cada una de las formas de trabajo.

Pero lo más interesante fue ver cómo la forma de ejecutar el proyecto, no sin dificultades, les hizo entender que disponer de pequeñas funcionalidades en cortos periodos de tiempo les había facilitado la toma de decisiones sobre lo que de verdad era importante para ellos.

En la actualidad, para que los proyectos tengan el mayor éxito posible se ejecutan utilizando el sentido común y las herramientas que cada metodología ofrece.

Después de contar esta larga historia de sufrimientos y alegrías, es momento de animaros a dar un vuelco a vuestra mentalidad. De no tener miedo a los cambios, de aplicar el sentido común en vuestro día a día y, sobre todo, de que empecéis a experimentar, lanzando pequeños MVP que os permitan aprender de manera rápida y eficaz.

¿Quieres saber cómo hacerlo? En nuestro curso de Product LAB aprenderás sobre ello.

Escribir un comentario