Buscar en Gazafatonario IT

martes, septiembre 29, 2020

Entiende el MVP (Producto Mínimo Viable) y por qué prefiero Producto que se pueda probar, utilizar y adorar más temprano

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.

***

Artículo original de Henrik Kniberg: Making Sense of MVP

***

sábado, septiembre 12, 2020

El Scrum Master y el Scrum Diario

 

Según la guía de Scrum, “los Scrum Diarios mejoran la comunicación, eliminan la necesidad de realizar otras reuniones, identifican impedimentos a remover relativos al desarrollo, resaltan y promueven la toma rápida de decisiones y mejoran el nivel de conocimiento del Equipo de Desarrollo. El Scrum Diario es una reunión clave de inspección y adaptación”.

“El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos para el Equipo de Desarrollo”.

Pero el Scrum Master, ni mucho menos el Dueño de Producto ni ninguna otra persona facilitan, conducen o gestionan este evento de Scrum. Es el mismo Equipo de Desarrollo en pleno el encargado de llevarla a cabo, si bien alguien como el Scrum Master se asegura de que el Equipo de Desarrollo tenga la reunión.

En el nivel Shu de Scrum, para que haya una reunión Diaria efectiva y se mantenga el espíritu de Scrum y ágil, el Scrum Master enseña al Equipo de Desarrollo a:

1.    Mantener el Scrum Diario en los límites del bloque de tiempo de 15 minutos.

2.    Planificar trabajo para las siguientes 24 horas

3.    Optimizar la colaboración y el desempeño del equipo mediante la inspección del progreso en el trabajo diario y haciendo una proyección del trabajo del Sprint a realizar a continuación

4.    Realizar el Scrum Diario a la misma hora y en el mismo lugar todos los días para reducir la complejidad

5.    Usar el Scrum Diario para evaluar el progreso hacia el Objetivo del Sprint y para evaluar qué tendencia sigue este progreso hacia la finalización del trabajo contenido en la Lista de Pendientes del Sprint.

6.    Entender cómo intenta trabajar diariamente en conjunto como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado hacia el final del Sprint

7.    Establecer la estructura de la reunión

8.    Conducirla de diferentes maneras siempre que se enfoque en el progreso hacia la Meta del Sprint

9.    Usar preguntas para llevar a cabo la reunión, pero también a basarse en discusiones y en otras tácticas para conducirla

10. Volverse a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar o replanificar el resto del trabajo del Sprint

11. Ser los responsables de dirigir el Scrum Diario

12. Adueñarse de la reunión. A tratarla como una reunión interna del equipo, aunque haya otras personas presentes.

Cuando el Equipo de Desarrollo ha interiorizado y practica todos estos comportamientos, para lo cual puede pasar un tiempo considerable que depende más de la actitud y el compromiso de los miembros del equipo, que del acompañamiento, necesario por demás, de un líder como el Scrum Master o un coach ágil, entonces es posible pasar a un nivel Ha de la reunión, pero eso, mi estimado amigo, podrá o podrá no ser motivo de otro trabajo.

Para saber más de la Reunión Diaria, lee también mi artículo de 2014, Compendio Sobre el Scrum Diario, en este mismo Gazafatonario:

http://www.gazafatonarioit.com/2014/01/compendio-sobre-el-scrum-diario.html

Y te invito a descargar el póster en alta resolución para que lo compartas con tu equipo y con toda tu empresa:




Descarga el póster en alta resolución y en tamaño gigante (100 x 70) para que lo compartas con tu equipo y con toda tu empresa:


jueves, septiembre 10, 2020

Planificar historias de usuario en tareas


El trabajo a realizar durante el Sprint se planifica en la Planificación de Sprint. Este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo.

En particular, en esta presentación  muestro algunos ejemplos de cómo descomponer historias de usuario de un backlog de producto en tareas de un backlog de sprint. También explico algunas prácticas y guías a tener en cuenta a la hora de la planificación.

Estas y otras ideas, en la presentación que puedes ver y descargar aquí.



domingo, agosto 23, 2020

El extraño caso de las historias de usuario técnicas

 

Photo by fauxels from Pexels

Nota: la versión en inglés de este artículo en:

https://luchosalazar.com/2020/08/25/the-strange-case-of-technical-user-stories/

Advertencia

La atención continua a la excelencia técnica y al buen diseño mejora la agilidad”.

[Manifiesto por el desarrollo ágil de software]

Cuando Kent Beck llegó con la idea de las historias de usuario como parte del juego de planificación de eXtreme Programming (XP Planning Game), no imaginó el impacto que esa idea tendría en el desarrollo de software y, por extrapolación, en el desarrollo de productos, varios años después; fue como un “efecto mariposa”. De hecho, al principio solo las describió como algo con lo que los clientes definen el alcance del proyecto "con historias de usuarios, que son como casos de uso". Pueden encontrar más sobre esto en “La historia de las historias de usuario”.

Pero una de las prácticas que ha perdurado hasta nuestros días es esta de querer expresar todo como una historia de usuario. En la práctica, esto es posible. Ya que las historias de usuario se pueden representar de infinitas formas. En el libro Historias de usuario: una visión pragmática, que escribimos con Jorge Abad, quien también  me compartió algunas de sus ideas para este artículo, hablamos precisamente de algunos de los modos de representación de las historias de usuario, incluyendo el User Stories Conversation Canvas, un lienzo para mantener y registrar conversaciones sobre estos elementos del backlog de producto.

Sin embargo, hay algunas cosas que definitivamente no son historias de usuario. El “apellido”, ese “de usuario” está allí por una razón muy importante que ni siquiera el mismo Kent Beck imaginó al comienzo. Él hablaba de “stories”, simplemente historias: estas se ven, se perciben, se entienden, se describen desde el punto de vista de quien las va a usar una vez estén implementadas o de quienes las van a consumir una vez hagan parte de los productos o servicios que se desarrollen usando esta técnica.

Las cosas así, cuando se trata de software, las llamadas historias técnicas no son una buena idea. ¿Quién es el usuario de “quiero integrar la IA de Google para hacer la traducción del texto”? ¿O de “quiero optimizar la base de datos para acelerar las consultas”? Pero sí es posible saber quién es el usuario de “quiero traducir un texto para entenderlo mejor” y de “quiero consultar la información del cliente” con la condición de que el resultado de la consulta se presente en menos de dos segundos.

Es un hecho, representar algo en forma de historia de usuario cuando no se trata de usuarios-personas del sistema es un error. Hay mejores formas de documentar o registrar este otro tipo de actividades “internas” de un sistema. Una de ellas es precisamente poniéndolas en su lugar como tareas que el equipo debe realizar para lograr finalmente algo de valor para el usuario-persona a través de una o varias historias de usuario. Pensemos en historias de usuario como “historias de persona”. Quizás esto nos ayude a entender la diferencia.

Una de las formas de saber si algo es una “historia de usuario-persona” o no, es cuando al mantener conversaciones con los representantes del negocio, por ejemplo un Dueño de Producto, estas conversaciones fluyen naturalmente y la fuente de información casi siempre es ese representante del negocio. Pero si este empieza a preguntar por términos o expresiones técnicas que emergen en el diálogo y el equipo de desarrollo tiene que dar explicaciones intrincadas que no son del dominio de aquel, entonces quizás hemos traspasado el plano del valor o beneficio de la historia para los usuarios a uno del dominio del equipo técnico.

Photo by fauxels from Pexels

Tenemos que hacer un left outer join seguido de una eliminación de duplicados” es algo con lo que perdemos a los usuarios. “Diariamente hacemos refactoring del código y luego lo integramos con el del resto del equipo usando Bamboo o Jenkins”, mientras “automatizamos los escenarios de prueba usando behaviour-driven development” y “consumimos el web service de [INSERTA AQUÍ TU PROVEEDOR DE WS FAVORITO] para conocer el valor del dólar minuto a minuto”, son conversaciones clásicas que dejarán en ascuas a un Dueño de Producto o a cualquier otra persona de las áreas del negocio.

Y no, no es porque usamos los términos en inglés. Aun en español van a sonar muy extraños a los usuarios. Más, cuando muchas de esas expresiones no tienen un equivalente apropiado en nuestro idioma o, en la vida cotidiana, significan algo totalmente distinto para el común de las personas:

¿Una “combinación externa por la izquierda”? – ¿A qué estará jugando?

¿“Desarrollo conducido por comportamiento”? – ¿Estará hablando de que su comportamiento en la empresa lo tiene a prueba?

¿Y mi consulta de los datos del cliente?”, preguntan con los ojos bien abiertos y con esa expresión de desánimo que solo significa que no están recibiendo lo que quieren y que incluso los lleva a pensar que los miembros del equipo no han entendido del todo lo que los usuarios necesitan. Por lo general, es una combinación de ambos. El asunto se pone más grave si alguien del equipo intenta explicar con mayor detalle lo que significa todo ese galimatías* técnico o trata de justificar con ello los tiempos estimados de desarrollo. A estas alturas es a todas luces evidente que se requiere la presencia de un facilitador, coach, Scrum Master o similar, para abortar la conversación y llevarla por otro camino.

Finalmente, no entendamos las historias de usuario-persona o las historias de persona como aquellas que solo abordan el “front-end” o la experiencia del usuario, de la persona. No. Toda historia de usuario tiene componentes “verticales” que van desde la forma cómo se comunica una persona con el sistema, hasta cómo se almacena y se procesan los datos que intercambia esa persona con el sistema o el entorno: base de datos, servicios, lógica del negocio, presentación, etcétera.

Más sobre cómo conducir conversaciones con historias de usuario en nuestra serie de historias de usuario altamente efectivas:

http://www.gazafatonarioit.com/p/la-serie-historias-de-usuario-efectivas.html

Y todavía mucho más en el libro Historias de usuario: una visión pragmática.

Llamado a la acción

Separemos explícitamente las historias de usuario, las de valor para el negocio, usuarios o clientes, de las tareas del equipo y de los componentes “internos” del sistema (producto) con los que se logra obtener ese valor o beneficio. Como agentes de cambio, asegurémonos de que los miembros del equipo desarrollen habilidades y destrezas en el dominio del negocio, ayudándolos a ellos y a los Dueños de Producto e interesados a mejorar las interacciones entre unos y otros mediante la conversación continua, ojalá cara a cara (¡en 2020 encendamos la cámara!) y a que no todo tiene que ser una historia de usuario, al menos no representadas de la misma manera.

Conclusión

Si en la conversación sobre una historia de usuario es el Dueño de Producto quien termina interrogando al equipo para aclaraciones y no al contrario, quizás el diálogo no sea realmente sobre la historia de usuario.

Epílogo

*Usé intencionalmente la expresión “galimatías”, quizás poco conocida, pero que tiene un lugar en mi Gazafatonario, para dejar la sensación en el ambiente de lo que percibe o siente un usuario final cuando lo confundimos con tecnicismos propios del desarrollo de software.

galimatías

Del fr. galimatias 'discurso o escrito embrollado', y este del gr. κατὰ Ματθαῖον katà Matthaîon 'según Mateo', por la manera en que este evangelista describe la genealogía que figura al comienzo de su evangelio.

1. m. coloq. Lenguaje oscuro por la impropiedad de la frase o por la confusión de las ideas.

2. m. coloq. Confusión, desorden, lío.

Real Academia Española © Todos los derechos reservados