Por Henrik Kniberg. Publicado el 2016-01-25 – 12:14.
Hace un par de años
dibujé esta imagen y comencé a usarla en varias presentaciones sobre desarrollo
ágil y lean:
¡Desde
entonces el dibujo se ha vuelto viral! Aparece en todas partes, en artículos y
presentaciones, incluso en un libro ("User
Story Mapping" de Jeff Patton, una lectura excelente por cierto).
Muchos me dicen que el dibujo realmente captura la esencia del desarrollo
iterativo e incremental, la puesta en marcha ajustada, el MVP (producto mínimo
viable) y demás. Sin embargo, algunos lo malinterpretan, lo cual es bastante
natural cuando sacas una foto de su contexto original. Algunos lo critican por
simplificar demasiado las cosas, lo cual es cierto. La imagen es una metáfora.
No se trata del desarrollo real de un automóvil, se trata del desarrollo de un
producto en general, utilizando un automóvil como metáfora.
De todos
modos, con todo este rumor, pensé que era hora de explicar el pensamiento
detrás de esto.
Primer ejemplo: no así
La fila
superior ilustra un concepto erróneo común sobre el desarrollo iterativo e
incremental de productos (también conocido como Ágil).
Muchos
proyectos fracasan gravemente porque realizan una entrega tipo Big Bang (construya la cosa hasta que
esté 100% terminada y entregue al final). Perdí la cuenta de la cantidad de
proyectos fallidos que vi debido a esto (ve más adelante para ver algunos
ejemplos). Sin embargo, cuando Ágil se presenta como una alternativa, las
personas a veces se resisten a la idea de entregar un producto sin terminar,
¿quién quiere la mitad de un automóvil? Imagina esto:
“Aquí señor,
aquí está nuestra primera versión, un neumático delantero. ¿Qué piensa?"
El cliente
dice "¿Por qué diablos me entregas un neumático? ¡Pedí un COCHE! ¿Qué se supone
que debo hacer con esto?"
(Por cierto,
estoy usando el término "cliente" aquí como un término genérico para
representar a personas como gerentes de productos, dueños de productos y
usuarios pioneros en la adopción).
Con cada
entrega, el producto está más cerca de estar terminado, pero el cliente todavía
está enojado porque en realidad no puede usar el producto. Todavía es un auto
parcial.
Y finalmente,
cuando el producto está terminado, el cliente dice “¡Gracias! ¡Finalmente! ¿Por qué
no entregaste esto en primer lugar y te saltaste todas las demás entregas
inútiles?”.
En este
ejemplo, el cliente está contento con el producto final, porque es lo que
pidió. En realidad, eso no suele ser cierto. Ha pasado mucho tiempo sin ninguna
prueba de usuario real, por lo que es muy probable que el producto esté plagado
de fallas de diseño basadas en suposiciones incorrectas sobre lo que la gente
necesita. Entonces esa carita sonriente al final es bastante idealista.
De todos modos,
la primera fila representa “ágil bastardo”. Técnicamente, puede ser una entrega
incremental e iterativa, pero la ausencia de un ciclo de retroalimentación real
lo hace muy arriesgado, y definitivamente no es ágil.
De ahí el
título "No así".
Segundo ejemplo: ¡así!
Ahora para la
segunda fila.
Aquí
adoptamos un enfoque muy diferente. Comenzamos con el mismo contexto: el
cliente pidió un automóvil. Pero esta vez no solo construimos un automóvil. En
su lugar, nos centramos en la necesidad
subyacente que el cliente quiere que se satisfaga. Resulta que su necesidad
subyacente es "Necesito ir de A a B más rápido", y el Carro es solo
una posible solución para eso. Recuerda, el automóvil es solo una metáfora,
piensa en cualquier tipo de situación de desarrollo de productos
personalizados.
Entonces, el
equipo ofrece lo más pequeño que se les ocurre que hará que el cliente pruebe
cosas y nos dé su opinión. Algunos podrían llamarlo MVP (Producto mínimo
viable), pero yo prefiero llamarlo Producto Comprobable más Temprano (más sobre
esto más adelante).
Llámalo como
quieras (algunos incluso llaman a su primer lanzamiento "la versión en
patineta" del producto, basándose en esta metáfora...).
Es poco
probable que el cliente esté satisfecho con esto porque no está cerca del auto
que ordenó. ¡Pero eso está bien! Aquí está el truco: no estamos tratando de hacer feliz al cliente en este momento.
Podríamos hacer felices a algunos de los primeros en adoptarlo (o a los pragmáticosque están sufriendo), pero nuestro
principal objetivo en este momento es simplemente aprender. Idealmente, el equipo explica esto claramente al
cliente con anticipación, para que no se sienta demasiado decepcionado.
Sin embargo,
a diferencia de la rueda delantera en el primer escenario, la patineta es en
realidad un producto utilizable que ayuda al cliente a pasar de A a B. No es
genial, pero es un poquito mejor que nada. Entonces le decimos al cliente
"no se preocupe, el proyecto no está terminado, esta fue solo la primera
de muchas iteraciones. Seguimos
intentando fabricar un coche, pero mientras tanto, intente esto y envíenos sus comentarios”.
Piensa en grande, pero entrega en pequeños incrementos funcionalmente viables.
Podríamos aprender algunas cosas
realmente sorprendentes. Supongamos que el cliente dice que odia la patineta,
le preguntamos por qué y dice "Odio el color". Estamos como "uh...
¿el color? ¿Eso es todo?". Y el cliente dice “¡Sí, hazlo azul! Aparte de
eso, ¡está bien!”. ¡Acabas de ahorrar *mucho* dinero sin construir el auto! No
es probable, pero ¿quién sabe?
La pregunta
clave es "¿Cuál es la forma más
barata y rápida en que podemos empezar a aprender?" ¿Podemos entregar
algo incluso antes que una patineta? ¿Qué tal un tiquete de autobús?
¿Ayudará esto
a resolver el problema del cliente? Tal vez, tal vez no, pero definitivamente
aprenderemos algo al poner esto en manos de usuarios reales. Lean Startup ofrece un gran modelo
basado en enumerar sus hipótesis reales sobre los usuarios y luego trabajar
sistemáticamente para validarlas o invalidarlas.
No es
necesario que pruebes el producto en todos los usuarios y no es necesario crear
un producto para probar algo. Probar un
prototipo incluso en un solo usuario te enseñará más que nada.
Pero bueno,
volvamos al ejemplo de la patineta.
Después de
jugar con él en la oficina, el cliente dice: “Está bien, es un poco divertido y
me lleva a la máquina de café más rápido. Pero es inestable. Me caigo con
demasiada facilidad”.
Así que en la
próxima iteración intentamos resolver ese problema, o al menos aprender más
sobre él.
¡El cliente
ahora puede moverse por la oficina sin caerse!
¿Contento? En
realidad, no, todavía quiere ese coche. Pero mientras tanto, en realidad está usando este producto y nos está dando
su opinión. Su mayor queja es que es difícil viajar distancias más largas,
como entre edificios, debido a las ruedas pequeñas y a la falta de frenos.
Entonces, el siguiente lanzamiento, el producto se transforma en algo así como
una bicicleta.
Ahora el
cliente puede moverse por el campus. ¡Yiihaaa!
Aprendemos
algunas cosas en el camino: al cliente le gusta la sensación de aire fresco en
su rostro. El cliente está en un campus y el transporte consiste principalmente
en desplazarse entre edificios.
La bicicleta puede llegar a ser un
producto mucho mejor que el automóvil que se imaginó originalmente. De hecho, mientras probamos este
producto, podemos aprender de todos modos que los caminos son demasiado
estrechos para un automóvil. ¡Le ahorramos al cliente toneladas de tiempo y
dinero, y le dimos un producto mejor en menos tiempo!
Ahora puedes
estar pensando "¿pero no deberíamos haberlo sabido ya a través de un
análisis inicial del contexto y las necesidades del cliente?" Buen punto.
Pero en la mayoría de los escenarios de desarrollo de productos de la vida real
que he visto, no importa cuánto análisis
inicial hagas, todavía te sorprendes cuando pones la primera versión real en
manos de un usuario real y muchas de tus suposiciones resultan estar muy
lejos.
Entonces, sí, haz algo de análisis inicial, descubre
todo lo que puedas antes de comenzar el desarrollo. Pero no le dediques
demasiado tiempo y no confíes demasiado en el análisis; en su lugar, comienza
a crear prototipos y a publicar, ahí es cuando ocurre el verdadero aprendizaje.
Como sea,
volviendo a la historia. Quizás el cliente quiera más. A veces necesita viajar
a otra ciudad y el paseo en bicicleta es demasiado lento y sudoroso. Entonces,
en la próxima iteración agregamos un motor.
Este modelo
es especialmente adecuado para software, ya que el software es, bueno, Soft. Puedes "transformar" el
producto a medida que avanzas, a diferencia del hardware en el que
esencialmente debes reconstruir cada vez. Sin embargo, incluso en proyectos de
hardware, la entrega de prototipos tiene un gran beneficio para observar y
aprender de cómo el cliente usa su producto. Es solo que las iteraciones
tienden a ser un poco más largas (meses en lugar de semanas). Incluso las
empresas de automóviles reales como Toyota y Tesla hacen muchos prototipos
(bocetos, modelos 3D, modelos
de arcilla a gran escala, etc.) antes de desarrollar un nuevo modelo de
automóvil.¿Y ahora qué?
Una vez más, tal vez el cliente esté contento con la motocicleta. Podríamos
finalizar el proyecto antes de lo planeado. La mayoría de los productos están
plagados de complejidad y características que nadie usa. El enfoque iterativo
es realmente una forma de entregar menos
o encontrar la forma más sencilla y económica de resolver el problema del
cliente. Minimiza la distancia a Impresionante. Muy zen.
O, nuevamente,
el cliente puede optar por continuar, con o sin modificaciones a los
requisitos. De hecho, podemos terminar con exactamente el mismo automóvil que
se imaginó originalmente. Sin embargo, es mucho más probable que obtengamos
conocimientos vitales en el camino y terminemos con algo ligeramente diferente.
Me gusta esto:
¡El cliente
está encantado! ¿Por qué? Porque en el camino aprendimos que aprecia el aire
fresco en su rostro, así que terminamos con un descapotable. Después de todo, consiguió un coche, ¡pero
mejor de lo planeado originalmente!
Así que
retrocedamos un paso.
¿Cuál es tu patineta?
El escenario
principal (entregar una llanta delantera) apesta porque seguimos entregando
cosas que el cliente no puede usar en absoluto. Si sabes lo que estás haciendo
(tu producto tiene muy poca complejidad y riesgo, tal vez hayas construido ese
tipo de cosas cientos de veces antes), entonces sigue adelante y haz una única
entrega tipo “big bang”. Construye la
cosa y entrégala cuando esté lista.
Sin embargo,
la mayoría de los esfuerzos de desarrollo de productos que he visto son
demasiado complejos y arriesgados para eso, y el enfoque del Big Bang con demasiada frecuencia
conduce a fallas enormes y costosas. Entonces, la pregunta clave es ¿Cuál es tu patineta?
En el
desarrollo de productos, una de las primeras cosas que debes hacer (después de
describir qué problema estás tratando de resolver para quién) es identificar su
equivalente en patineta. Piensa en la
patineta como una metáfora de lo más pequeño que puedes poner en manos de
usuarios reales y obtén retroalimentación real. O usa un "boleto de
autobús" si esa metáfora funciona mejor.
Esto te dará
el circuito de retroalimentación vitalmente necesario y te dará a ti y al cliente
el control sobre el proyecto; puedes aprender y hacer cambios, en lugar de
simplemente seguir el plan y esperar lo mejor.
Veamos
algunos ejemplos de la vida real.
Ejemplo 1: reproductor de música Spotify
“Con más de 75 millones de usuarios,
es difícil recordar un momento sin Spotify. Pero hubo una época en la que todos
estábamos reflexionando sobre los pasillos de Target en busca de nuevos CD. Un
momento de nuestras vidas en el que todos nos convertimos en ladrones en
Napster. Una época en la que iTunes nos obligaba a comprar canciones por 2
dólares la pieza. Y luego vino Spotify". –Tech Crunch.
Spotify es un producto bastante elegante
ahora. Pero no empezó de esa manera. Tuve la suerte de estar involucrado
muy temprano en este viaje increíble (y todavía lo estoy).
Como startup
en 2006, Spotify se fundó sobre algunas suposiciones clave: que la gente está
feliz de transmitir (en lugar de poseer) música, que los sellos discográficos y
los artistas están dispuestos a permitir que la gente lo haga legalmente y que
la transmisión rápida y estable es técnicamente factible. Recuerda, esto fue en
2006 cuando la transmisión de música (como Real Player) era una experiencia
bastante horrible, y la música copiada por piratas era prácticamente la norma.
La parte técnica del desafío fue: “¿Es posible crear un cliente que transmita
música instantáneamente cuando presionas el botón Reproducir? ¿Es posible
deshacerse de esa molesta barra de progreso de 'Buffering'?"
Empezar de a poco no significa que no
puedas pensar en grande.
Este es uno de los primeros bocetos de lo que tenían en mente:
Pero en lugar
de pasar años construyendo todo el producto y luego averiguar si las
suposiciones se mantenían, los desarrolladores básicamente se sentaron y
piratearon un prototipo técnico, pusieron cualquier música copiada que tuvieran
en sus computadoras portátiles y comenzaron a experimentar salvajemente para
encontrar formas de hacer que la reproducción fuera rápida y estable. La métrica
de conducción fue "¿cuántos milisegundos se necesitan desde que presiono
Reproducir hasta que escucho la música?". ¡Debería reproducirse casi
instantáneamente y continuar reproduciéndose sin problemas sin tartamudear!
“Pasamos una gran cantidad de tiempo
enfocándonos en la latencia, cuando a nadie le importaba, porque estábamos
empeñados en hacer que pareciera que tenías toda la música del mundo en tu
disco duro. Obsesionarse con los pequeños detalles a veces puede marcar la
diferencia. Eso es lo que creo que es el mayor malentendido sobre el concepto
de producto mínimo viable. Esa es la V en el MVP". -Daniel Ek, cofundador y CEO.
Una vez que
tenían algo decente, comenzaron a probarse a sí mismos, con su familia y amigos.
La versión
inicial no se pudo lanzar a una audiencia más amplia, estaba totalmente sin
pulir y básicamente no tenía características excepto la capacidad de encontrar
y reproducir algunas canciones codificadas, y no había acuerdo legal o modelo
económico. Era su patineta.
Pero descaradamente pusieron la patineta en
manos de usuarios reales, – Amigos y
familiares – y rápidamente obtuvieron
las respuestas que necesitaban. Sí, era técnicamente posible. Y sí, a la gente
le encantó el producto (o más bien, ¡en lo que el producto podía convertirse!)
¡Las hipótesis fueron validadas!
Este prototipo en ejecución ayudó a convencer a los sellos discográficos y a
los inversores y, bueno, el resto es historia.
Ejemplo 2: Minecraft
Minecraft es uno de los juegos más exitosos
en la historia del desarrollo de juegos, especialmente si se tiene en cuenta el
costo de desarrollo. Minecraft es también uno de los ejemplos más extremos de
la mentalidad de lanzamiento temprano y frecuente. El primer lanzamiento
público se realizó después de solo 6 días de codificación,
¡por un solo hombre! No
se podía hacer mucho en la primera versión: era básicamente un paisaje en 3D
feo y en bloques donde se podían desenterrar bloques y colocarlos en otro lugar
para construir estructuras toscas.
Esa fue la
patineta.
Sin embargo,
los usuarios estaban muy comprometidos (la mayoría de las comunicaciones entre
desarrolladores y usuarios se realizaban a través de Twitter, bastante
divertido). Entre los primeros usuarios estábamos mis cuatro hijos y yo. Se
realizaron más de cien
lanzamientos durante el primer año. El desarrollo de juegos es todo acerca de encontrar la diversión (algunas compañías de juegos con las que he trabajado
usan el término "Definición de Diversión" en lugar de
"Definición de Terminado"), y la mejor manera de hacerlo es haciendo
que personas reales efectivamente jueguen ese juego. – En este caso, se trataba de miles de personas reales que
habían pagado para probar la versión de acceso anticipado y, por lo tanto,
tenían un incentivo personal para ayudar a mejorar el juego.
Gradualmente,
se formó un pequeño equipo de desarrollo alrededor del juego (en realidad, eran
2 chicos), y el juego se convirtió en un gran éxito en todo el mundo. No creo
haber conocido a ningún niño en ninguna parte que no jugara Minecraft. Y el año
pasado, el juego (bueno, la compañía que se
formó alrededor del juego) se vendió a Microsoft por $ 2.5 mil millones.
Bastante sorprendente.
Ejemplo 3: Un gran proyecto gubernamental
Alrededor de
2010, la policía sueca lanzó una gran
iniciativa para permitir que la policía pasara más tiempo en el campo y menos
en la estación: PUST (Polisens Utrednings STöd). Un proyecto fascinante,
participé como coach y escribí un libro sobre lo que hicimos y lo que
aprendimos (Lean
from the Trenches).
La idea era
colocar computadoras portátiles en los automóviles y software personalizado
para que la policía tuviera acceso a los sistemas que necesitaran en tiempo
real, por ejemplo, mientras se interroga a un sospechoso (estábamos en la era
anterior a las tabletas).
Habían
intentado construir sistemas similares en el pasado y fracasaron
estrepitosamente, principalmente debido al pensamiento Big Bang. Me dijeron que uno de sus intentos anteriores tomó 7 años
desde el inicio hasta el primer lanzamiento. ¡SIETE AÑOS! Para entonces, por
supuesto, todo había cambiado y el proyecto fue un fracaso total. Así que esta
vez querían hacerlo de otra manera.
El proyecto
de 60 personas (más tarde denominado "PUST Java") tuvo un éxito
sorprendente, especialmente por ser un gran proyecto gubernamental (incluso
quedó en segundo lugar en los premios CIO "Proyecto del año").
Uno de los principales factores de éxito fue que no intentaron construir todo de una vez, sino que dividieron al
elefante en dos dimensiones:
- Por
región. No es necesario que lo publiquemos en TODA Suecia a la vez, podríamos
comenzar publicando solo en una región.
- Por
tipo de delito. No es necesario que soportemos TODOS los tipos de delitos
inicialmente, podríamos comenzar apoyando solo 1-2 tipos de delitos.
La primera
versión, la 1.0, fue su patineta.
Era un
sistema pequeño, que soportaba solo un par de tipos de delitos, y se probó
sobre el terreno con un puñado de policías en Östergötland (una región de
Suecia). Otros tipos de delitos tenían que tratarse a la antigua: conducir
hasta la estación y hacer el papeleo. Sabían
que eran conejillos de indias y que el producto no estaba ni cerca de estar
terminado. Pero estaban felices de probarlo, porque conocían la
alternativa. Habían visto qué tipo de sistemas asquerosos surgían de procesos
que carecían de retroalimentación temprana de los usuarios, ¡y ahora finalmente tenían la oportunidad de influir
en un sistema mientras se estaba construyendo!
Sus
comentarios fueron duros y honestos. Muchas de nuestras suposiciones volaron
por la ventana, y uno de los grandes dilemas fue qué hacer con todas las
especificaciones de casos de uso cuidadosamente elaboradas que se estaban
volviendo cada vez menos relevantes a medida que llegaba la retroalimentación
de los usuarios reales (esta era una organización con un historial en cascada y
el hábito de hacer un extenso análisis al principio de los proyectos).
De todos
modos, en pocas palabras, la
retroalimentación temprana se canalizó hacia mejoras del producto y,
gradualmente, a medida que a los policías de Östergötland les empezó a gustar
el producto, pudimos agregar más tipos de delitos y difundirlo a más regiones.
Para cuando llegamos al gran lanzamiento (1.4), con el despliegue a nivel
nacional y la capacitación de 12000 policías, no estábamos tan preocupados. Habíamos hecho tantos lanzamientos, tantas
pruebas de usuarios, que dormimos bien la noche del lanzamiento nacional.
Desafortunadamente,
la victoria duró poco. Un proyecto de seguimiento (PUST Siebel) lo estropeó
y volvió al pensamiento de cascada, probablemente debido a un viejo hábito. 2
años de análisis y pruebas sin lanzamientos ni pruebas de usuario, seguidos de
un lanzamiento espectacular de la "próxima generación" del producto
para los 12.000 policías a la vez. Fue un desastre absoluto, y después de medio
año de hemorragia cerraron todo. El costo del desarrollo fue de unos 20
millones de euros, pero los estudios internos estiman que el coste para la
sociedad sueca (porque la policía se vio perjudicada por el horrible sistema)
fue del orden de mil
millones de euros.
¡Una forma
bastante cara de aprender!
Ejemplo 4: Lego
Actualmente
estoy trabajando en Lego y estoy asombrado
por su capacidad para ofrecer nuevos éxitos, año tras año, sin falta. Escucho
muchas historias interesantes sobre cómo hacen esto, ¡y el tema común es la
creación de prototipos y las primeras pruebas de usuario! A menudo veo grupos
de niños en la oficina y los diseñadores colaboran con los jardines de infancia,
las escuelas y las familias locales para probar sobre el terreno las últimas
ideas de productos.
Aquí hay un
ejemplo reciente: Nexo Knights
(lanzado en enero de 2016):
Cuando
comenzaron a explorar este concepto, hicieron prototipos en papel y se los
llevaron a los niños pequeños. La primera reacción de los niños fue "oye,
¿quiénes son los malos? ¡No veo quién es bueno y quién es malo!". ¡Ups!
Así que los diseñadores siguieron iterando y probando hasta que encontraron un
diseño que funcionó con los niños. Apuesto a que incluso tú puedes ver quién es
el bueno y quién es el malo en la imagen de arriba...
No estoy
seguro de dónde está exactamente la patineta en esta historia, pero entiendes
la idea: ¡retroalimentación temprana de
usuarios reales! No te limites a diseñar el producto y construirlo todo.
¡Imagínate si hubieran construido el producto basándose en sus supuestos de
diseño originales y hubieran aprendido sobre el problema después de entregar miles de cajas a tiendas de todo el mundo!
Lego también
tiene su parte de fracasos duramente ganados. Un ejemplo es Lego Universe, un mundo
Lego en línea multijugador masivo. Suena divertido, ¿eh? El problema es que se
volvieron demasiado ambiciosos y terminaron tratando de construir todo a la
perfección antes de lanzarlo al mundo.
Aproximadamente
250 personas trabajaron durante 4-5 años (por el constante cambio de
alcance debido al perfeccionismo), y cuando finalmente llegó el lanzamiento, la
recepción fue... tibia. El juego terminado fue hermoso, pero no tan divertido
como se esperaba, por lo que el producto se cerró después de 2 años.
¡No hubo patineta!
¿Por qué no?
Porque las patinetas no son geniales (al menos no si esperas un automóvil), y
la cultura de Lego se trata de brindar experiencias increíbles. Si trabajas en los
cuarteles generales de Lego en Billund, Dinamarca, pasas por este enorme mural
todos los días:
Se traduce
aproximadamente como "Solo lo mejor es suficientemente bueno". Ha
sido el principio rector de Lego desde que la empresa comenzó hace más de 80
años y les ha ayudado a convertirse en una de las empresas más exitosas del
mundo. Pero en este caso se aplicó mal el principio. La búsqueda de la perfección retrasó la retroalimentación vital, lo
que significó suposiciones erróneas sobre lo que a los usuarios les gusta y no
les gusta. Exactamente lo contrario de Minecraft.
Curiosamente,
los equipos de Lego Universe estaban usando Scrum e iterando en gran medida, al
igual que los chicos de Minecraft. Pero los comunicados fueron solo internos.
Así que lo más probable es que hubiera una patineta y una bicicleta, etc., pero
esos productos nunca llegaron a los usuarios reales. No es así como se pretende
utilizar Scrum.
Fue una falla
costosa, pero Lego aprendió de ella y constantemente mejoran en las primeras
pruebas y de la retroalimentación de los usuarios.
Mejora sobre el "MVP"
Y eso
(respiración profunda…) me lleva al tema de MVP - Producto Mínimo Viable.
La idea
subyacente es genial, pero el término en sí mismo causa mucha confusión y
angustia. He conocido a muchos clientes que dicen "De ninguna manera
quiero una entrega de MVP – ¡esa es la última entrega que recibiré!" Con
demasiada frecuencia, los equipos entregan el llamado Producto Mínimo Viable, y
luego rápidamente son llevados al siguiente proyecto, dejando al cliente con un
producto sin terminar y con errores. Para
algunos clientes, MVP = MRC (Basura Mínima Liberable - Minimum Releasable Crap).
Lo sé, lo sé,
esto se reduce a una mala gestión en lugar del término MVP, pero aun así... el
término invita a malentendidos. “Mínimo” y “Viable” significan cosas diferentes
para diferentes personas y eso causa problemas.
Así que aquí
hay una alternativa.
En primer
lugar, reemplaza la palabra "Mínimo" por "Temprano". La
idea principal detrás del lanzamiento de un MVP es obtener retroalimentación
temprana: al entregar un producto mínimo en lugar de un producto completo,
podemos obtener la retroalimentación antes.
¡Pocos clientes quieren
"mínimo", pero la mayoría de los clientes quieren
"temprano"!
Entonces ese es nuestro primer cambio:
Mínimo =>
Más temprano
A
continuación, elimina la palabra "Viable", ya que es demasiado vaga. Tu "viable" es mi
"horrible". Algunas personas piensan que Viable significa “algo
que puedo probar y de lo que puedo obtener comentarios”, otras piensan que
significa “algo que el cliente realmente puede usar”. Así que seamos más
explícitos y dividámoslo en tres cosas diferentes:
El producto comprobable* más temprano es la patineta o el tiquete de
autobús, el primer lanzamiento con el
que los clientes pueden hacer algo. Puede que no resuelva su problema, pero
genera al menos algún tipo de retroalimentación. Dejamos muy claro que el
aprendizaje es el objetivo principal de esta versión y que cualquier valor real
para el cliente será una ventaja.
El producto utilizable más temprano es quizás la bicicleta. La primera versión que los primeros
usuarios realmente usarán, de buena gana. Está lejos de estar terminado y
puede que no sea muy agradable. Pero pone a tus clientes en una mejor posición
que antes.
El producto adorable más temprano es quizás la motocicleta. El primer lanzamiento que los clientes
adorarán, les contarán a sus amigos y por el que estarán dispuestos a pagar.
Todavía hay mucho que mejorar y es posible que acabemos con un descapotable, un
avión o algo más. Pero hemos llegado al punto en el que tenemos un producto
realmente comercializable.
Consideré
agregar un paso anterior, "Producto
con retroalimentación más temprana", que es básicamente el prototipo
en papel o equivalente que usas para obtener tu primera retroalimentación del
cliente. Pero cuatro pasos parecen demasiados, y la palabra retroalimentable... ¡Uf! Sin embargo,
ese también es un paso importante. Algunos llamarían a un prototipo de papel el
Producto que se puede probar más temprano, pero supongo que eso se reduce a
cómo se define “Comprobable”. Consulta
la Guía de MVP de Martin para conseguir
más información – tiene muchos ejemplos muy concretos de cómo obtener retroalimentación
temprana con una inversión mínima.
Por supuesto,
la gente todavía puede malinterpretar el Más temprano probable / Usable /
Adorable, pero es al menos un paso más explícito que el nebuloso Producto
mínimo viable.
Puntos para llevarte
Buen momento
para terminar. Nunca pensé que sería tan largo, ¡gracias por quedarte!
Conclusiones clave:
- Evita la entrega Big Bang para el
desarrollo de productos complejos e innovadores. Hazlo de manera iterativa e
incremental. Eso ya lo sabías. ¿Pero, lo estás haciendo realmente?
- Empieza por identificar tu patineta, el
producto comprobable más temprano. Apunta a las nubes, pero trágate tu orgullo
y comienza entregando la patineta.
- Evita el término MVP. Sé más explícito
acerca de lo que realmente estás hablando. El más temprano comprobable /
utilizable / adorable es solo un ejemplo, usa los términos que sean menos
confusos para tus partes interesadas.
Y recuerda:
el dibujo de la patineta / automóvil es solo una metáfora. No lo tomes
tan literal: o)
PD: aquí hay
una historia divertida sobre cómo mis hijos y yo usamos estos principios para
ganar una competencia
de sumo de robots: o)
Gracias Mary
Poppendieck, Jeff Patton, Alistair Cockburn, Anders Haugeto, Sophia, colegas de
Crisp, Spotify y Lego, y todos los demás que dieron toneladas de retroalimentación
útil.
***
***
