¿En qué se parece ducharse al desarrollo de producto?
- Alfredo Artiles from Pensando en Sistemas el Desarrollo de Producto <alfredoartiles@substack.com>
- Hidden Recipient <hidden@emailshot.io>
¿En qué se parece ducharse al desarrollo de producto?Cuando desconocer los retrasos en los sistemas que intentas intervenir te lleva al bandazo-driven development.
Artículo publicado originalmente en Junio de 2023 en mi blog. De vez en cuando rescataré en esta newsletter los artículos que he escrito a lo largo de los años y que han generado mayor interés. Continuando con mi serie de artículos sobre pensamiento sistémico, uno de los ejemplos que más me fascinó cuando empecé a leer sobre el tema en Pensar en Sistemas de Donella Meadows fue el de la ducha de agua caliente. ¿Quién (en el primer mundo) no se ha peleado con el grifo de la ducha? Giras un poco al lado rojo y sale agua fría, le das un poco más y nada, le vuelves a dar y sale hirviendo. Luego giras hacia el lado azul, pero nada cambia, le das un poco más y sigue así hasta que finalmente sale agua congelada directamente desde el Polo Norte. Después de 15 minutos y cientos de litros derrochados, terminas mal duchándote entrando y saliendo del chorro con una temperatura incómoda. Lo que sucede en estos casos es que el agua tarda un tiempo en cambiar de temperatura, posiblemente debido a la distancia entre la ducha y el calentador. Si reaccionamos antes de este tiempo, entraremos en un bucle de ensayo y error con el que difícilmente acertaremos. Si conocemos el tiempo que tarda en cambiar de temperatura del agua, basta con esperar ese tiempo antes de realizar correcciones y llegar a la temperatura deseada. Este es un ejemplo de retraso en un sistema de tuberías muy simple.
HistéresisLa histéresis es una propiedad de un sistema que provoca que el impacto esperado se retrase respecto a la intervención debido a demoras en los bucles de retroalimentación del sistema. La histéresis ocurre en todas partes, desde la física hasta las organizaciones humanas. Nos va mucho mejor cuando reconocemos la histéresis a tiempo. De lo contrario, podemos sentir la tentación de sobrerreaccionar. Sobrecorregimos, pero no nos damos cuenta hasta que es demasiado tarde. Es un gran enigma que, en un mundo lleno de histéresis, los humanos seamos tan malos para lidiar con ella. Hay algo en los retrasos que nos confunde y nos lleva a zigzaguear torpemente, cayendo en los extremos pendulares del efecto látigo. Sólo entender esto me cambió la vida cuando lo descubrí, pero si necesitas más ejemplos, veamos cómo aplicarlo al desarrollo de producto iterativo incremental. Imagina que la ducha es tu producto y el calentador el equipo de producto que te da capacidad para modificarlo. Tenemos un problema que resolver y establecemos una forma de validar el éxito de las soluciones que probaremos, por ejemplo con un KPI. El grifo sería nuestro sistema de despliegue. El retraso de este sistema sería el tiempo que tardamos en validar los efectos que una iteración ha provocado en nuestros clientes. Esto lo podemos modelar con un diagrama de flujos y reservas así:
Nota: Estas simulaciones y sus números están muy lejos de ser reales. No te quedes con los números absolutos sino con los patrones. El objetivo es simular los patrones de comportamiento desencadenados según accionamos algunas palancas del sistema. Simulemos algunos escenarios de este sistema. La ducha perfecta¿Cómo sería para ti la ducha perfecta? Pues a no ser que seas Win Hof, una en la que a cada milímetro que muevas el grifo la temperatura del agua cambie inmediatamente a la temperatura que esperabas. Eso mismo desearía para mi flujo de desarrollo de producto: que el tiempo de retraso entre que ponemos una funcionalidad en producción y medimos el impacto en nuestros clientes sea cercano a cero. En la gráfica vemos que después de 7–8 días de iteraciones, el valor del KPI (línea azul) se acerca al objetivo (línea amarilla) con incrementos cada vez más pequeños (línea verde). Imagínate un producto B2C (empresa a consumidor) con capacidad de exponer un cambio de su producto a millones de usuarios en un día, en poco tiempo habrán expuesto el cambio a suficientes usuarios para poder tomar una decisión del siguiente incremento. La ducha que me ha tocadoAhora imagina una ducha que tiene los retrasos que mencioné al principio, pero que entendemos perfectamente. En este caso, no podemos cambiar el retraso a menos que cambiemos el tipo de sistema de calentador, pero sí podemos tenerlo en cuenta para hacer las esperas adecuadas y ajustar la temperatura. No es la ducha ideal, pero la entendemos y somos capaces de sacar lo mejor de ella. En desarrollo de producto, esto no es ideal como vimos en el caso anterior, pero según la industria o el tipo de producto, muchas veces no podemos eliminar esos retrasos. Al simular el sistema con un validation time delay de 2 días, en la gráfica ves cómo se generan oscilaciones y tardamos 2–3 veces más que en el ejemplo anterior en acercarnos al objetivo. Imaginad un producto B2B (empresa a empresa) con pocos clientes donde, en vez de millones de usuarios, tienes miles, y para validar los efectos de un cambio, tienes que esperar varios días o semanas. En estos casos, debemos esperar estos tiempos antes de hacer otro cambio o corremos el riesgo de tomar una decisión sobre un valor percibido que aún no es el real. La ducha del gymEsta es la ducha de tu gimnasio, esa que depende de lo que haga el colega de al lado con su ducha y de otros factores. Hay retrasos y no sabemos cuáles, además son bastante aleatorios para nosotros porque no entendemos los factores que los desencadenan. Al simular el sistema con un validation time delay de 4 días, en la gráfica ves cómo se generan oscilaciones y, en vez de acercarnos al objetivo, nos alejamos. En desarrollo de producto, esto es lo que nos encontramos en las feature factories. La única métrica que tiene el equipo es el número de características en producción, y vamos a ciegas dando bandazos a ver si algo termina encajando. ConclusionesLa próxima vez que un sistema (una organización, equipo, otra persona o tu propio cuerpo) no parezca reaccionar a una intervención, presta atención: ¿dónde están los retrasos? ¿Cuáles son los bucles de retroalimentación que los muestran? Los retrasos son omnipresentes en los sistemas complejos y son fuertes determinantes de sus comportamientos. Cambiar la duración de un retraso puede provocar un gran cambio en el comportamiento del sistema. El desarrollo de producto, como sistema complejo que es, no está exento de estos retrasos. Identificarlos y entenderlos nos permitirá modificarlos si están bajo nuestro control o gestionarlos para no sobrereaccionar basándonos en una percepción retrasada de la realidad. Debemos evitar precipitarnos en hacer ajustes basados en reacciones inmediatas, o corremos el riesgo de caer en un ciclo interminable de ensayo y error. Puedes jugar tú mismo con el diagrama y sus simulaciones en InsightsMaker e incluso clonarlo para adaptarlo a tu antojo. |
Similar newsletters
There are other similar shared emails that you might be interested in: