¿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.
Entender los retrasos de un sistema es muy importante, ya que la sobrereacción provoca oscilaciones e ineficiencias. En estos casos, tardamos mucho en obtener información del efecto de nuestras acciones y actuamos sobre esa percepción retrasada.
Histéresis
La 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í:
Reserva “valor actual del KPI” (current KPI value): El valor actual del KPI tal como el equipo de producto lo percibe después de implementar un incremento del producto.
Flujo “incremento de producto” (product increment): Incremento de producto que se supone que debe mover el estado actual hacia el estado deseado. Ten en cuenta que esta acción puede ser en cualquier dirección, podemos empeorar o mejorar el valor del KPI.
tamaño del incremento (increment size): Un factor para controlar la cantidad de la brecha que realmente resulta en flujo. Una correlación con el tamaño de las ramas o lotes de cambios en cada incremento.
objetivo del KPI (KPI goal): El valor del KPI que marca el éxito del experimento y en el que podemos dejar de iterar.
retraso de tiempo de validación (validation time delay): El tiempo que tarda en validarse los efectos de una iteración del producto con los clientes y en ser percibido en la brecha para luego influir en el flujo.
estado de retraso (delay state): La retención del valor antes de que se pase a la brecha (gap). Esto es algo técnico del producto con el que estoy modelando el sistema para poder simular los retrasos.
brecha (gap): La diferencia percibida entre el estado deseado y el valor retrasado del estado actual.
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 tocado
Ahora 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 gym
Esta 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.
Conclusiones
La 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.