Históricamente a quienes nos dedicamos al desarrollo de software se nos ha estereotipado como «nerds» cuya única fuente de satisfacción es comunicarnos con máquinas a través de un teclado y una pantalla monocromática.

Durante mucho tiempo, yo mismo caí en la trampa de esa profecía autocumplida. Cual horóscopo, cada vez que leía algo como «eres una persona súper analítica, amante de los sistemas, que prefiere unas especificaciones claras y programarlas antes que interactuar con personas», pensaba: «Soy!».

Hace ya mucho tiempo de esto. Si me leéis habitualmente, sabréis que hoy pienso todo lo contrario. Aunque me considero una persona introvertida — en el sentido de que recargo mi energía en la introspección — y algo tímida (aunque esto varía según el círculo en el que me mueva), esto no me ha impedido desarrollar la empatía como una habilidad fundamental para ejercer un rol en el que siento que estoy gran parte del tiempo fuera de mi zona de confort.

Durante mucho tiempo pensé que mi inclinación natural hacia la reflexión interna era incompatible con habilidades como la empatía, que requieren conectar con los demás. Pero aprendí que la introversión y la empatía no están en conflicto; al contrario, la introspección puede ser una herramienta poderosa para cultivar una comprensión más profunda de las emociones, tanto propias como ajenas.

La empatía no es una cualidad fija; todos la experimentamos en distintos grados y formas. Incluso en el caso de personas con diagnósticos dentro del espectro autista, la empatía no está ausente, sino que puede manifestarse de maneras diferentes, como una mayor sensibilidad emocional o ciertos desafíos en interpretar señales sociales.

En fin, creo que la empatía es una habilidad que, como cualquier otra, se puede desarrollar con práctica deliberada y atención. En el ámbito del desarrollo de productos digitales, esta habilidad es clave no solo para entender mejor a los usuarios, sino también para construir equipos más colaborativos y humanos.

Ya exploré este tema en profundidad cuando hablé sobre Empathy-Driven Development.

Teoría de empatía-sistematización

Hoy vuelvo a tocar este tema porque, mientras leía La mente de los justos de Jonathan Haidt, me encontré con la teoría de empatía-sistematización desarrollada por el psicólogo británico Simon Baron-Cohen. Esta teoría busca explicar las diferencias cognitivas entre individuos, especialmente en relación con el autismo y las diferencias de género.

Aunque no está exenta de críticas — como simplificar en exceso las diferencias individuales o perpetuar ciertos sesgos de género — , no pretendo entrar en esos debates aquí. Lo que me interesa es cómo este marco puede servir para reflexionar sobre la empatía, especialmente en el contexto del desarrollo de productos y equipos.

Y es que cualquier idea que nos aleje del pensamiento binario me resulta interesante. Como vimos al hablar de homeostasis, «en la dosis está el veneno»: el equilibrio es clave, y para alcanzarlo necesitamos pensar en dimensiones continuas en lugar de dicotomías rígidas.

Esto es precisamente lo que me atrajo del marco de Baron-Cohen. Para entender las diferencias cognitivas entre las personas, propone dos dimensiones que forman un continuo:

• En un extremo, la empatía.
• En el otro, la sistematización.

Empatía

La empatía es la capacidad y el impulso para identificar los pensamientos y sentimientos de otras personas, comprenderlos y responder de manera adecuada. Implica:

• Reconocer estados mentales ajenos.
• Responder emocionalmente de forma adecuada.
• Predecir el comportamiento de otros.

Si prefieres la ficción a la no ficción, o disfrutas de conversaciones sobre personas que no conoces, es probable que tengas un nivel de empatía por encima del promedio.

Sistematización

La sistematización, por otro lado, es la habilidad para analizar y construir sistemas basados en reglas. Es el impulso de identificar las variables de un sistema y derivar las reglas que gobiernan su comportamiento.

Implica:

• Identificar patrones y reglas.
• Predecir y controlar el comportamiento de sistemas.
• Un interés marcado por cómo funcionan las cosas.

Si eres bueno interpretando mapas o manuales de instrucciones, o disfrutas descubriendo cómo funcionan las máquinas, es probable que tengas un nivel alto de sistematización.

El peligro de los extremos

Todos estamos en algún punto de esta escala, donde los extremos rara vez son efectivos. Si pasas todo el día angustiado por empatizar excesivamente con usuarios porque una pantalla tarda más de un segundo en cargar, quizá necesites replantearte las prioridades. Del mismo modo, alguien completamente analítico, desprovisto de empatía hacia el mundo que le rodea, tendría serias dificultades para integrarse en la sociedad o en un equipo.

Haidt rescata la teoría de empatía-sistematización para criticar la filosofía moral excesivamente racionalista, señalando que la psicología moral necesita observación y empatía para comprender cómo funciona realmente la mente humana.

Según Haidt, durante el siglo XIX el pensamiento moral se alejó de enfoques más empáticos y holísticos, como el sentimentalismo de Hume, hacia teorías más analíticas y sistemáticas, como el utilitarismo y la deontología.

Por un lado, Jeremy Bentham, fundador del utilitarismo, propuso que todas las acciones deben maximizar la felicidad total, medida mediante su famoso «cálculo felicific».

Bentham propuso que un principio único debería regir todas las reformas, todas las leyes e incluso todas las acciones humanas: el principio de utilidad, que definió como «el principio que aprueba o desaprueba cada una de las acciones según la tendencia que aparenta tener para aumentar o reducir la felicidad de la parte cuyo interés está en cuestión».

Bentham exhibió altos niveles de sistematización y baja empatía, características que algunos expertos asocian al síndrome de Asperger. Su enfoque excesivamente racional lo llevó a descuidar aspectos más subjetivos de la experiencia humana, lo que le valió críticas incluso de contemporáneos como John Stuart Mill.

Por otro lado, Immanuel Kant, creador del imperativo categórico, buscó una moralidad universal basada en la razón, eliminando la influencia de los sentimientos subjetivos.

Kant propuso una regla abstracta de la cual, según él, derivarían todas las demás reglas morales válidas. La llamó el imperativo categórico:

Obra como si la máxima de tu acción pudiera convertirse, por tu voluntad, en una ley universal de la naturaleza.

Mientras leía sobre esto, no podía evitar pensar: ¿y si estamos dejando el desarrollo de software en manos de sistematizadores extremos (o sistematizadores por autoconvencimiento) incapaces de empatizar, no solo con los consumidores de su software, sino también con el ecosistema, los demás actores y los sistemas que impactamos con nuestras decisiones?

¿Tenemos capacidad para cambiar algo de esto?

Daniel Nettle, profesor de neurociencia de la conducta en la Universidad de Newcastle, publicó en 2007 un artículo donde replicaba y ampliaba los hallazgos de Baron-Cohen, argumentando que la sistematización y la empatía son funciones biológicas más que simples rasgos de personalidad. Esto sugiere que nuestras inclinaciones hacia una u otra dimensión pueden estar en parte predeterminadas. Sin embargo, esto no significa que no podamos trabajar en desarrollar habilidades complementarias.

En mi caso particular, he aprendido que es posible moldear la empatía a través de la práctica deliberada, lo que me lleva a pensar que, aunque haya una predisposición biológica, el contexto, el aprendizaje y la intención tienen un papel clave en cómo estas funciones se manifiestan en la práctica.

En el término medio está la virtud

No creo que ser más sistematizador que empatizador sea algo intrínsecamente malo, ni lo contrario. Ambos perfiles tienen ventajas, y lo importante es encontrar el equilibrio adecuado.

En este sentido, la tendencia actual hacia un enfoque de product engineering requiere un equilibrio perfecto entre sistematización y empatía.

Por ejemplo, los equipos de sistemas — mal llamados DevOps — han sido estereotipados históricamente como equipos de «puros sistematizadores». Sin embargo, la evolución hacia el platform engineering, con un enfoque en plataforma como producto, exige una dosis considerable de empatía con sus clientes, que en este caso son otros equipos dentro de la organización. Entender sus necesidades, frustraciones y flujos de trabajo es tan importante como crear herramientas técnicamente sólidas.

Huyendo de los extremos, hay espacio para todo el espectro. Lo importante no es dónde se encuentra cada individuo, sino lograr una combinación adecuada a nivel de equipo. Un equipo balanceado, que incluya perspectivas tanto empáticas como sistemáticas, es más capaz de afrontar los desafíos complejos de desarrollar productos.

Empatizador vs Sistematizador was originally published in Pensando en Sistemas el Desarrollo de Producto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Este artículo es una continuación de la entrega sobre sistemas de doble loop. Si bien no es imprescindible haberlo leído para entender lo que voy a contar hoy, creo que puede ser interesante que le eches un vistazo antes, ya que aporta un marco útil para lo que exploraremos aquí.

Si eres lector habitual de este blog, es muy probable que hayas formado parte de equipos que realizan retrospectivas con regularidad, por ejemplo, al final de cada sprint. O que llevan a cabo análisis postmortem después de incidentes. Seguramente también mantienes reuniones periódicas 1:1 con tu manager o reports.

También asumo que compartimos un interés común por entender las razones detrás de nuestras prácticas, metodologías, etc. ¿Alguna vez te has detenido a reflexionar por qué participas, o si como líder promueves estas ceremonias?

Voy a seguir asumiendo: probablemente estemos de acuerdo en que todas estas ceremonias constituyen feedback loops. Son mecanismos para obtener retroalimentación periódica que nos permiten «medir» la brecha entre un estado actual y una meta, e identificar acciones que puedan ayudar a reducirla.

Sistemas orientados a alcanzar objetivos

Este tipo de mecanismos, orientados a alcanzar objetivos, buscan equilibrar el estado actual con un estado deseado. De hecho, representan una de las estructuras arquetípicas fundamentales en la dinámica de sistemas.

La estructura orientada a alcanzar objetivos comienza con un [estado deseado] y un [estado actual], cuya diferencia genera un [gap].

El [gap] actúa como un impulso para la [acción], que tiene como objetivo mover el [estado actual] en dirección al [estado deseado], reduciendo así el [gap]. A medida que el [gap] se reduce, la [acción] también disminuye, aunque el [estado actual] sigue acercándose al [estado deseado]. Cuando el [estado actual] iguala al [estado deseado], el [gap] es cero y no se requiere más acción.

Esta estructura demuestra un comportamiento orientado a objetivos, que es una característica emergente de la estructura en su conjunto. Ninguno de los elementos por separado exhibe este comportamiento.

Cualquier situación en la que se toma una [acción] para mover algo hacia un [estado deseado] constituye una estructura orientada a alcanzar objetivos. Estas estructuras pueden tener muchos elementos, pero lo que las caracteriza es que siempre hay un número impar de restas o influencias opuestas en el bucle.

Gene Bellinger. Goal Seeking

Pero la pregunta clave es: ¿es suficiente con identificar ese gap y definir acciones?

Paremos de filosofar por un momento y aterricemos esto en un ejemplo concreto.

Al finalizar el sprint, haces una retrospectiva y se detecta que prácticamente no se ha podido avanzar en lo planificado porque surgió mucho trabajo no previsto, principalmente bugs.

El gap identificado es la brecha entre la expectativa de avanzar en lo que se consideraba el foco del sprint y la realidad que vivió el equipo.

Para reaccionar a ese gap, el equipo propone algunas acciones: asignar a una sola persona para gestionar cualquier interrupción. Esta persona se encargará de atender las demandas emergentes, permitiendo que el resto del equipo mantenga el foco en lo planificado. Con esta medida, el objetivo es proteger el foco del equipo y avanzar hacia la meta del sprint.

Aunque este ejemplo sea hipotético, lo cierto es que en Audiense creamos hace 10 años este rol rotativo, al que llamamos the monkey, por entonces no tuvimos en cuenta todo lo que veremos a continuación y tardamos bastante tiempo en enfocarnos en el problema real.

Esto no está mal del todo. El equipo, en su proceso de mejora continua, ha identificado impedimentos y ha tomado medidas para mejorar. De hecho, en las siguientes retrospectivas se evaluará si estas acciones han tenido el efecto deseado y, de no ser así, se propondrán otras.

Single loop learning

Esta forma de enfocar una retrospectiva se enmarca en lo que se conoce como single loop learning (aprendizaje de un solo bucle). Consiste en responder a discrepancias o errores ajustando las acciones sin cuestionar los valores, normas o estrategias subyacentes. Es un proceso reactivo que busca mantener el sistema operando dentro de su marco actual.

Ya en la entrega sobre sistemas de doble loop vimos cómo la combinación de dos bucles, uno que requiere más esfuerzo y otro más económico, puede ayudarnos a perseguir una meta de forma eficiente.

El aprendizaje de un solo bucle es nuestra forma económica de operar en la búsqueda de la mejora continua. Es óptimo en situaciones donde estamos bien entrenados, las soluciones son conocidas y existen mejores prácticas de referencia.

No considero que este sea un enfoque inferior. El hecho de que sea reactivo y se centre en eventos y patrones visibles no tiene por qué ser algo negativo, peor es no cuestionar nada. En muchos casos, este tipo de aprendizaje es suficiente para mantener el sistema funcionando de manera efectiva dentro de sus parámetros actuales, pero no es adecuado para todas las situaciones.

Los seres humanos producen acción activando diseños almacenados en sus cabezas (mente/cerebro) que, al ser activados, generan las acciones necesarias para implementar sus intenciones. Los seres humanos también desarrollan diseños para evaluar en qué medida logran lo que pretendían producir. Si logran lo que pretendían, hay una correspondencia entre las intenciones y las acciones. Si no lo logran, hay una discrepancia.

Para realizar evaluaciones válidas sobre su eficacia, los seres humanos deben detectar las discrepancias y corregirlas. En el núcleo de actuar de manera efectiva está el aprendizaje. El aprendizaje también ocurre si las acciones generan un resultado nuevo por primera vez.

— Smith, Ken G. and Hitt, Michael. Great minds in management: the process of theory development

Muchas veces esta forma de aprendizaje no es suficiente, ya que operar constantemente en este modo nos lleva a abordar problemas sistémicos con soluciones superficiales, que terminan por alimentar y agravar el problema subyacente como ya hemos visto con la trampa de la adicción al parche.

Double loop learning

Cuando enfrentamos problemas que parecen imposibles de resolver, tendemos a redoblar esfuerzos sin detenernos a reflexionar sobre las razones fundamentales de nuestras acciones. Nos quedamos atrapados en los límites de cómo entendemos el problema, repitiendo los mismos patrones una y otra vez, sin lograr mejoras ni resultados diferentes. Es como avanzar sin rumbo.

En estos casos, el double loop learning (aprendizaje de doble bucle) se convierte en una herramienta imprescindible. Aunque representa el enfoque más exigente, es también el que permite abordar problemas desde su raíz y generar cambios profundos y sostenibles.

Este enfoque implica cuestionar los supuestos fundamentales y las normas que sustentan las decisiones. Es más costoso porque exige una reflexión profunda, que a menudo lleva a replantear objetivos, estrategias o valores. Por eso no es viable aplicarlo constantemente, pero su capacidad para romper círculos viciosos lo hace esencial cuando las soluciones habituales dejan de ser efectivas.

El concepto de double loop learning proviene del trabajo de Chris Argyris y Donald Schön y es una teoría clave en la mejora organizacional y en la forma en que los individuos y grupos abordan problemas complejos.

El aprendizaje de doble bucle se refiere a la distinción entre el aprendizaje que mantiene un sistema de comportamiento operando dentro de un campo de constancia y el aprendizaje que cambia lo que el sistema busca lograr o mantener constante. Está relacionado con la distinción entre cambio de primer orden y de segundo orden. El énfasis en el aprendizaje en lugar del cambio destaca los procesos mediante los cuales los miembros del sistema buscan mejorar su funcionamiento. El aprendizaje de doble bucle es un concepto importante para la investigación-acción porque se centra en lo que se necesita para que las personas y los sistemas realicen cambios fundamentales.

— Robert W. Putnam. Double-Loop Learning

Aplicaciones

Nada de esto es nuevo en esta newsletter; ya hemos explorado varios enfoques basados en ir más allá de lo superficial.

Slow systems thinking con el modelo del iceberg, es uno de ellos. Es una herramienta muy efectiva para trascender los eventos, tendencias y patrones, y centrarnos en el por qué: qué ha influido en estos patrones y qué modelos mentales nos llevan a operar de esta manera.

Otro enfoque relevante es el Pensamiento de Primeros Principios (First Principles Thinking), que vimos cuando reflexionamos sobre ¿por qué hacer reuniones 1:1s?. Es una forma de cuestionar supuestos básicos para descubrir las razones fundamentales detrás de nuestras acciones.

También están técnicas como Los cinco ¿Por qué?, donde iterativamente nos preguntamos el por qué de una discrepancia observada, hasta llegar a capas más profundas y fundamentales en el iceberg.

Además, he dedicado varios ensayos al espacio del problema vs el espacio de la solución. Muchas de las herramientas y técnicas exploradas en ese contexto como la disolución de problemas mediante inversión, se basan en el double loop learning, ya que buscan ir más allá de las soluciones más inmediatas o superficiales.

Continuando con el ejemplo

Volviendo al ejemplo de la retro, un caso de aprendizaje de doble bucle habría sido cuestionar por qué salen tantos bugs.

En un primer nivel, podrían surgir soluciones como invertir más en QA, mejorar los entornos de staging, dedicar más tiempo a probar antes de desplegar o involucrar a más personas en las pruebas. Estas medidas probablemente reducirían el número de bugs, pero también el flujo de valor, pues aumentar el costo del proceso podría contribuir al círculo vicioso de la burocracia.

Un análisis más profundo podría llevarnos a evaluar nuestras prácticas de desarrollo: ¿hacemos suficientes tests? ¿Son lo suficientemente buenos? ¿Por qué no lo son? ¿Es porque no escribimos código fácil de testear? ¿Por qué? ¿Es nuestro sistema demasiado complejo y frágil? ¿Por qué? Y así sucesivamente, hasta llegar a las raíces del problema.

Pero un nivel aún más allá sería cuestionar nuestros modelos mentales. Esto podría implicar salir de nuestra zona de confort y explorar otras formas de plantear el desarrollo de producto, como por ejemplo, Lean. No es casualidad que Mary y Tom Poppendieck propongan que Lean es una mentalidad, dedicando la introducción de su libro The Lean Mindset: Ask the Right Questions a explicar qué es un mindset y cómo funciona, apoyándose en la teoría de proceso dual, que ya hemos explorado en esta newsletter.

En términos generales, operamos en modo piloto automático. Si surgen circunstancias inusuales, cambiamos del piloto automático al modo manual. Es en este modo manual donde desarrollamos o modificamos nuestros modelos mentales. Para cambiar un modelo mental establecido, necesitamos pasar una buena cantidad de tiempo en modo manual, con el Sistema 2 plenamente activo.

— Mary Poppendieck, Tom Poppendieck. The Lean Mindset Ask the Right Questions

Este tipo de cuestionamiento puede llevarnos a promover cambios muy profundos en nuestras formas de trabajar. Cambios que, como mencioné en el último radar, requieren tirar de coraje para llevarse a cabo. Pero son precisamente estos cambios los que pueden transformar verdaderamente el sistema y romper patrones disfuncionales.

Concluyendo

Una vez más, hemos explorado dos formas de abordar los desviaciones de la meta: una lenta, más profunda y transformadora, pero que requiere un mayor esfuerzo y coste; y otra más rápida, que permite operar eficientemente la mayor parte del tiempo sin renunciar a la mejora continua.

Ambos enfoques son necesarios y se complementan. Mientras el aprendizaje de un solo bucle nos ayuda a mantenernos operativos y mejorar en el corto plazo, el aprendizaje de doble bucle nos impulsa a cuestionar nuestras bases y lograr cambios sostenibles a largo plazo.

El aprendizaje de doble bucle puede ser desconcertante porque obliga a las personas y organizaciones a salir de su zona de confort y a repensar sus supuestos básicos. Sin embargo, es esencial para el crecimiento y la adaptación a largo plazo. — Robert W. Putnam. Double-Loop Learning

Es fundamental darnos el espacio necesario para aplicar el esfuerzo que requiere el aprendizaje de doble bucle. La Teoría de Restricciones (TOC) plantea que intentar mantener un sistema funcionando a su máxima capacidad es un antipatrón, ya que, lejos de optimizar el flujo, genera cuellos de botella y sobrecarga en las partes críticas del sistema, lo que reduce la eficiencia global y amplifica las interrupciones.

Pero las implicaciones van más allá de la eficiencia. Cuando operamos continuamente al 100%, nos quedamos sin margen para la reflexión y el ajuste estratégico, dejando como única opción trabajar desde un enfoque de single loop learning. Actuando en piloto automático, con el sistema 1 y el elefante al mando y reaccionando de manera caótica cada vez que descubrimos lo alejados que estamos de nuestras metas reales.

Bola extra

Se acerca el fin de año, y algunos tenéis por tradición plantearos objetivos para el próximo. Un enfoque de double loop learning puede ser clave para enfocar los esfuerzos en lo que realmente importa, en lugar de crear propósitos de año nuevo que se rompen en febrero.

Muchas personas comienzan el proceso de cambiar sus hábitos enfocándose en lo que quieren lograr. Esto nos lleva a hábitos basados en resultados. La alternativa es construir hábitos basados en la identidad. Con este enfoque, empezamos por centrarnos en quién queremos llegar a ser.

— James Clear

Lecturas recomendadas

• Double Loop Learning in Organizations — Chris Argyris
• Double-Loop Learning — Robert W. Putnam
• Double-loop vs single-loop learning — Sheril Mathews
• Double-Loop Learning — Pat Kua
• Great minds in management: the process of theory development — Smith, Ken G. and Hitt, Michael.
• Identity-Based Habits: How to Actually Stick to Your Goals This Year — James Clear

Double loop learning was originally published in Pensando en Sistemas el Desarrollo de Producto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Si necesitas desplazarte de un punto A a un punto B que está a una distancia suficientemente lejana como para que tu vista no pueda alcanzarlo, es normal que necesites apoyarte en algo que te ayude a mantener la dirección.

De niño solía competir en carreras de orientación. Nos daban un mapa específico de la zona y una brújula con cada punto de control marcado. Para completar el recorrido, debíamos pasar por todos estos puntos en orden, guiándonos únicamente con el mapa y la brújula, y ganaba quien los encontrara en el menor tiempo posible.

La velocidad era clave, así que mi estrategia solía ser encontrar un punto de referencia cercano en la dirección correcta usando la brújula y el mapa. Una vez identificado, corría hacia ese punto sin detenerme a comprobar la orientación de forma constante.

Esta técnica generaba dos tipos de retroalimentación:

• Un bucle corto y rápido, en el que simplemente verificaba el punto de referencia para seguir avanzando.
• Otro más largo y más costoso, en el que recalibraba la orientación y establecía un nuevo objetivo cercano.

Claramente por entonces no pensaba en sistemas, pero la realidad es que, en estas situaciones de orientación, tendemos a aplicar un sistema de doble feedback loop como este de manera inconsciente.

Pensar rápido, pensar despacio

Lo anterior no es de extrañar pues como propone Daniel Kahneman en su libro Pensar rápido, pensar despacio, operamos con dos sistemas de pensamiento.

El sistema 1 es rápido y económico en cuanto a esfuerzo cognitivo. Es una respuesta intuitiva que recurre a heurísticos que hemos desarrollado durante nuestra evolución y que nos han salvado de muchos depredadores y amenazas sociales. No es perfecto, pero acierta la mayoría de las veces y funciona con gran rapidez consumiendo muy poca energía. Este sistema suele ser nuestro bucle interno: nos permite desenvolvernos con fluidez.

Por otro lado, el sistema 2 es más lento y consciente. Requiere un esfuerzo cognitivo mayor y desafía a los heurísticos del sistema 1. Este sistema es como el bucle externo: nos detiene, recalibra, cuestiona y redefine la dirección para evitar errores acumulados.

El jinete y el elefante

Este mes estamos leyendo en La Biblioteca Polymatas La mente de los justos de Jonathan Haidt. En el grupo de Telegram ha surgido un debate interesante sobre los paralelismos entre la metáfora del jinete y el elefante de Haidt y la propuesta de Kahneman sobre los sistemas de pensamiento.

En este contexto de sistemas de doble loop, el elefante representa nuestro bucle interno, que simboliza las emociones, los instintos y los deseos que nos impulsan a actuar rápidamente. Es una parte de nuestra mente gobernada por los «módulos morales» que, según Haidt, hemos evolucionado para reaccionar de manera instantánea ante ciertas situaciones. Es intuitivo, inmediato y a menudo difícil de controlar, lo que se alinea con el sistema 1 de Kahneman.

Por otro lado, el jinete representa nuestro bucle externo: la parte racional, consciente y lógica que intenta guiar al elefante y comprender sus impulsos. Al igual que el sistema 2 de Kahneman, el jinete es más reflexivo y, en muchos casos, busca explicar o justificar a posteriori (post-hoc) las decisiones que ya ha tomado el elefante. Este bucle externo, aunque más lento y demandante en términos de esfuerzo cognitivo, es crucial para recalibrar y corregir el rumbo, cuestionando si el impulso del elefante está alineado con nuestros objetivos a largo plazo.

North star framework

Durante miles de años, los marineros han utilizado las estrellas para orientarse, mucho antes de que existieran brújulas o instrumentos de navegación modernos. La clave era identificar ciertas estrellas y constelaciones «fijas» en el cielo. La más importante de ellas es la Estrella Polar (Polaris), que siempre apunta al norte en el hemisferio norte y ha servido de guía constante y confiable.

El North Star Framework toma esta analogía para orientarnos en el desarrollo de productos. Su bucle interno se compone de métricas de entrada: al igual que los marineros consultaban otras estrellas para corroborar su rumbo, este framework se apoya en métricas secundarias que los equipos de producto pueden influenciar directamente y que ayudan a validar el progreso y dar contexto al avance.

El bucle externo lo representa la North Star Metric, un objetivo que encapsula el valor central que el producto ofrece a sus usuarios. Esta métrica actúa como una «estrella guía» para todo el equipo, asegurando que las decisiones y esfuerzos de todos estén alineados hacia un propósito común.

Continuous Coordination

Continuous Coordination es un framework open source para dirigir equipos de ingeniería, cuyo principio número uno es: Mantén un ritmo constante.

Los enfoques ad-hoc para mantener a todos informados y alineados son frágiles, consumen mucho tiempo y resultan tediosos. Reemplázalos con bucles de comunicación estructurados y automatizados para crear un ritmo constante que mantenga a todos en sincronización sin tanto esfuerzo ni interrupciones.

En organizaciones de cierto tamaño (>50 personas), y especialmente en entornos de trabajo en remoto, mantener la alineación entre todos se vuelve complejo. Los mensajes deben repetirse en múltiples ocasiones, y son necesarias reuniones constantes que interrumpen el flujo de trabajo, desgastan al equipo y afectan la productividad. Esto nos deja atrapados en «la trampa de alineación».

Este framework propone un enfoque de doble loop para salir de esta trampa, desglosando el trabajo de alineación en bucles asíncronos más pequeños, de mayor frecuencia y automatizados:

Bucles diarios: Funcionan como el bucle interno, manteniendo a los equipos individuales en sincronía. Estos loops ayudan a los colaboradores a priorizar tareas, abordar problemas emergentes y coordinar planes de acción de forma ágil y rápida.

Bucles semanales, quincenales o mensuales: Actúan como el bucle externo, alineando varios equipos y a la organización en general, proporcionando una visión compartida y actualizada para todos.

Este enfoque crea un ritmo de trabajo fluido, donde la comunicación estructurada permite que cada miembro y equipo esté alineado con menos esfuerzo y menos interrupciones.

Double loop TDD

En un plano más técnico, tenemos la técnica de Double Loop TDD, que añade una capa de tests de aceptación al ciclo clásico de TDD (Rojo -> Verde -> Refactorizar). La idea es combinar dos ciclos de tests: un ciclo externo de aceptación que verifica un requisito de negocio, y un ciclo interno de tests unitarios. Este bucle externo funciona como una versión automatizada de nuestra «definition of done».

Al comenzar una nueva funcionalidad, iniciamos escribiendo un test de aceptación que inevitablemente fallará, ya que aún no existe una implementación. Antes de avanzar, es fundamental verificar que este test de aceptación está fallando correctamente, lo que confirma que el requisito no se está cumpliendo. Esto suele implicar definir la API externa de nuestro sistema.

Una vez que tenemos un test de aceptación que falla por la razón correcta, pasamos al ciclo interno, que corresponde al ciclo de tests unitarios de TDD. Nos mantenemos en este ciclo interno hasta que el test de aceptación finalmente pase.

Podéis ver este flujo de trabajo en acción en este clásico screencast de Sandro Mancuso implementando la Bank Kata siguiendo un enfoque de outside-in TDD.

Micro feedback loops

Tim Cochran define los micro feedback loops como aquellas acciones que los desarrolladores realizan 10, 100 o incluso 200 veces al día, como es el caso de los bucles internos del Double Loop TDD. Estos micro-bucles de retroalimentación se acumulan y, con el tiempo, afectan a ciclos de retroalimentación más grandes. Por eso, cuanto más rápidos y menos costosos sean, más frecuentemente se ejecutarán, proporcionando un flujo constante de retroalimentación temprana.

Evitar largas pausas entre la ejecución de estos bucles ayuda a mantener el contexto y la concentración. Este estudio sugiere que recuperar el estado de concentración y productividad máxima puede tomar hasta 23 minutos tras una interrupción.

Si dependiéramos solo de los tests de aceptación (o de un QA manual), es probable que entre cada ejecución nos distrajéramos revisando correos, redes sociales o incluso tomando un café, lo cual nos sacaría del estado de concentración. Esto también podría tentarnos a iniciar otra tarea en paralelo, aumentando el WIP y, por lo tanto, elevando la carga cognitiva con todas sus consecuencias negativa. En algunos casos, incluso podríamos sentir la necesidad de omitir los tests de aceptación para «avanzar más rápido».

Objetivos móviles

En el desarrollo de productos, el contexto es un objetivo en constante movimiento. Aunque al inicio de un proyecto pueda existir un alto nivel de comprensión compartida, esta claridad suele disminuir con el tiempo debido a cambios en el entorno y nuevos aprendizajes. La capacidad y flexibilidad para actuar con agilidad, junto con la posibilidad de recalibrar nuestra dirección de forma rápida, nos permite adaptarnos a las demandas dinámicas del mercado.

Estas desviaciones del camino óptimo, en forma de fluctuaciones, son lo que Lean Software Development denomina desperdicio: trabajo parcialmente hecho, procesos adicionales, funcionalidades innecesarias, cambios de tareas, tiempos de espera, etc.

Sin embargo, al combinar feedback loops que protegen el objetivo a largo plazo con pequeños pasos asegurados con loops más cortos, logramos mantenernos más cerca de ese camino óptimo, minimizando el desperdicio y maximizando la eficiencia.

Conclusiones

Hoy hemos explorado diversos escenarios en los que la presencia de feedback loops anidados permite actuar con fluidez, minimizando la desviación respecto al objetivo final. Estos bucles incluyen uno rápido y de bajo costo, que puede ejecutarse con mayor frecuencia, y otro más preciso, aunque más costoso, que se emplea ocasionalmente para recalibrar.

Estos son solo algunos de los muchos ejemplos que podrías encontrar en entornos con culturas y mentalidades alineadas con Lean, XP y DevOps.

Es esencial encontrar el equilibrio adecuado entre ambos bucles. Si solo ejecutamos el bucle interno, avanzaremos rápido, pero existe el riesgo de desviarnos de la meta y desperdiciar esfuerzos. En cambio, si dependemos únicamente del bucle externo, podríamos avanzar demasiado tiempo en una dirección que deje de ser correcta.

En próximas entregas hablaré sobre double loop learning, que, aunque comparte ciertas palabras clave, abre un melón más complejo y orientado a un nivel estratégico y organizacional. Subscríbete para asegurarte de que no te los pierdes.

Lecturas recomendadas

• Outside-In TDD part 1 — Sandro Mancuso
• Outside-In development with Double Loop TDD — Emily Bache
• North Star Playbook
• Maximizing Developer Effectiveness — Tim Cochran
• Continuous Coordination
• Product-Market Fit is a Moving Target — Maja Voje
• Chalk Talk: Mapping the Why, Assumptions, and Solutions — John Cutler
• Thinking big, working small — John Cutler
• CPSLive — Mental Models for Product Developers — Eduardo Ferro

Persiguiendo objetivos móviles: Adaptación continua con sistemas de doble loop was originally published in Pensando en Sistemas el Desarrollo de Producto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recientemente leí Las leyes del Serengeti: Cómo funciona la vida y por qué es importante saberlo de Sean B. Carroll. Si Pensando en Sistemas nos introduce a los conceptos fundamentales para comprender la dinámica de sistemas, este libro nos presenta una serie de ejemplos concretos donde el pensamiento sistémico ha sido clave para resolver problemas complejos en el ámbito de la biología, medicina y ecosistemas. Una de las ideas clave que propone es que los sistemas vivos — desde células a ecosistemas — tienden a mantener un equilibrio mediante diversos mecanismos de regulación, evitando así su autodestrucción.

Como sabéis, tengo una obsesión por encontrar analogías y modelos mentales que sirvan como nuevas lentes para abordar problemas en sistemas sociotécnicos. Así que mientras leo este tipo de libros, no puedo evitar reflexionar sobre hasta qué punto estos principios pueden aplicarse a los equipos de producto.

Dinámica de sistemas 101

Para lo que me propongo escribir hoy, creo necesario refrescar algunos conceptos clave de la dinámica de sistemas. La mayoría ya los he mencionado en artículos anteriores, y podréis encontrar explicaciones más detalladas en otras fuentes, como mi hipercitado Pensando en Sistemas. Si ya estás familiarizado con estos conceptos, siéntete libre de saltarte esta sección.

En la dinámica de sistemas, trabajamos con los siguientes elementos:

• Reservas (Stocks): Son los elementos del sistema que puedes ver, sentir, contar o medir en cualquier momento. Representan la acumulación de material o información. Por ejemplo: la cantidad de agua en un depósito, el número de tareas en un backlog, el nivel de calidad del código, la carga cognitiva, o el grado de burnout en un equipo.
• Flujos: El estado de una reserva cambia a través de sus flujos de entrada o salida. Estos flujos son las variables que modifican las reservas.

• Bucles de retroalimentación (Feedback loops): Cuando un flujo de salida está conectado con un flujo de entrada en la misma reserva. También puede ocurrir cuando varias reservas están encadenadas y terminan cerrando el bucle en la primera.
• Bucles de refuerzo: Estos bucles impulsan al sistema en una dirección y se auto-refuerzan, siendo frecuentemente responsables de crecimiento exponencial, erosión o colapso en los sistemas. Sin un corrector, estos bucles pueden llegar a destruir el sistema, a menos que un bucle estabilizador lo corrija. Un ejemplo de esto es el bucle de exclusión competitiva que describí en La trampa del «rockstar developer»:

• Bucles de estabilización: Cuando una variable del sistema se desvía de un valor de equilibrio o de una tendencia estable, el bucle estabilizador actúa reduciendo la desviación o impulsando la variable en la dirección opuesta al cambio inicial. Los bucles de retroalimentación negativa evitan que el sistema se desestabilice, buscando equilibrio y resistiendo cambios drásticos no deseados. Un ejemplo de esto son las revisiones de código asincrónicas, que constituyen un feedback loop de estabilización de la calidad. Si se detectan aspectos a mejorar, se corrigen mediante refactorización como vimos en La trampa de la erosión de metas y el síndrome de la rana hervida.

• Retrasos: Cuando las reservas cambian lentamente, aunque la velocidad de sus flujos se modifique actúan como amortiguadores (buffers) o retrasos en los sistemas. Por ejemplo, añadir más personas a un equipo no aumenta la productividad de manera inmediata, ni revela problemas de integración cultural hasta pasado un tiempo. Lo mismo sucede cuando esperamos validar si una funcionalidad resuelve el problema: como describí en mi analogía sobre el desarrollo de producto y los retrasos del cambio de temperatura en el sistema de tuberías de una ducha.

Homeostasis

La homeostasis se refiere al proceso mediante el cual la tendencia de la materia a derivar hacia el desorden es contrarrestada para mantener el orden, pero en un nuevo nivel, el permitido por el estado estacionario más eficiente. — António Damásio, El extraño orden de las cosas

El fisiólogo Walter Cannon fue el primero en hablar de la innata «sabiduría del cuerpo» y su capacidad para reaccionar ante perturbaciones, manteniendo las funciones críticas dentro de unos márgenes relativamente estrechos. La mayoría de los órganos están conectados por terminaciones nerviosas que suelen transmitir impulsos opuestos — estimulantes e inhibidores — , lo que permite aumentar o disminuir su actividad según las condiciones.

Cannon acuñó el término homeostasis (del griego homeo, «similar», y stasis, «estabilidad»), para describir los procesos fisiológicos que mantienen o regulan las condiciones corporales dentro de ciertos límites. Cuando introdujo este término, la teoría de sistemas aún no existía como campo de estudio formal.

En términos de sistemas, un sistema se encuentra en equilibrio estático cuando está en un estado estable y todas las fuerzas que actúan sobre él están en balance. Sin embargo, los sistemas complejos del mundo real tienden a experimentar equilibrio dinámico, lo que significa que las variables del sistema fluctúan dentro de un rango determinado. Este equilibrio dinámico es mantenido por bucles de estabilización. Si una variable se desvía de su rango óptimo, los bucles de retroalimentación se activan para devolverla al rango deseado.

Visto así, el cuerpo humano es un sistema complejo de reservas conectadas a sensores que funcionan como bucles de retroalimentación para prevenir oscilaciones extremas y mantener constantes las condiciones internas esenciales — como la temperatura, acidez, niveles de agua, sales, oxígeno y glucosa — dentro de márgenes óptimos.

Estos parámetros deben mantenerse dentro de límites muy estrechos, o de lo contrario, el cuerpo puede sufrir una grave enfermedad o incluso la muerte. Por ejemplo, el pH de la sangre, que es un indicador de acidez, se mantiene en torno a 7,4. Si baja a 6,95, puede provocar coma y la muerte, mientras que si sube a 7,7, se producen convulsiones y ataques.

Homeostasis en equipos de producto

Hay muchos aspectos en un equipo de producto que sin un feedback loop que los mantenga bajo control — en equilibrio — , pueden llevar al producto o al equipo al colapso, por ejemplo:

• Número de bugs: Tener cero bugs puede ser un objetivo extremo, ya que implicaría un alto coste de oportunidad y podría llevar a desaprovechar oportunidades de mercado. Sin embargo, existe un umbral en el que la cantidad de bugs se vuelve inaceptable y requiere intervención para evitar perder la confianza en el producto y su equipo.
• Burnout: Un mal día o una mala semana al año no hace daño y puede formar parte del ciclo normal de trabajo. Sin embargo, cuando el estrés se vuelve crónico, el estado se vuelve insostenible para el equipo. Tampoco se trata de estar siempre en modo «superrelajado»; existe un punto óptimo en el que pequeños picos de estrés, combinados con espacios de recuperación, ayudan a mantener al equipo motivado y resiliente.
• Deuda técnica: Siempre estamos incurriendo en deuda técnica, consciente o inconscientemente. Sin embargo, cuando la deuda técnica alcanza un nivel crítico, puede comprometer la estabilidad y la evolución del producto.
• Carga cognitiva: Un dominio demasiado sencillo puede limitar el aprovechamiento del potencial del equipo, mientras que uno excesivamente complejo, con múltiples iniciativas simultáneas y una mala experiencia de desarrollo, puede dañar el rendimiento y la salud mental del equipo.

El hecho de que un sistema esté en equilibrio no significa necesariamente que esté funcionando de la manera más óptima; solo indica que las variables están estables. A veces los sistemas logran un equilibrio de forma ineficiente. Por ejemplo, si un equipo se compromete a cumplir con una estimación de puntos en un sprint y, para hacerlo, debe trabajar horas extras, habrán mantenido el equilibrio, pero a costa de la sostenibilidad a largo plazo.

A veces es necesario romper ese equilibrio temporalmente para conseguir una estabilidad duradera. Invertir tiempo en refactorizaciones o mejorar la cobertura de tests, aunque pueda desacelerar momentáneamente el avance, permitirá un ritmo más sostenible a largo plazo, reduciendo tensiones y mejorando la calidad general del producto. Ralentizar, simplificar y amplificar para ganar.

El potencial de la homeostasis radica en su capacidad para devolver al sistema a un estado donde «se siente bien» bajo nuevas condiciones. Cómo un sistema define este «estado de bienestar» influirá en su capacidad de adaptarse al estrés y al cambio. Por ello, es importante definir claramente qué significa «hacer las cosas bien». Acuerdos sobre principios, objetivos y KPIs pueden funcionar como feedback loops que nos indiquen cuándo nos estamos desviando de ese estado deseado.

De vez en cuando es necesario romper con el status quo o salir de la zona de confort. Aunque un sistema parezca estable, podría no ser sostenible a largo plazo o estar impidiendo el acceso a un escenario mejor aún por descubrir.

Masa crítica

Como vimos, la homeostasis busca mantener al sistema dentro de su rango óptimo. Pero, ¿qué sucede cuando nos salimos de ese rango? ¿Dónde están los límites?

Un sistema se vuelve «crítico» cuando está al borde de cambiar de un estado a otro. En mi pueblo, solíamos decir: «es la gota que colma el vaso», refiriéndonos a ese último detalle que, al añadir más presión de la que el sistema puede soportar, termina teniendo un impacto desproporcionado y desencadena un cambio drástico.

En el momento de escribir esto, el equipo de producto de Audiense ronda las 40 personas, divididas en 7 equipos. Estos números no se alcanzaron de golpe. Debido al crecimiento orgánico, la baja rotación y la incorporación de unas 3–4 personas de media al año durante 12 años, algunos cambios en la topología han tenido que esperar a acercarse a esos puntos críticos.

Uno de los primeros equipos creció hasta 10 personas porque no teníamos suficiente escala para dividirlo en todos dominios que teníamos y lo mismo sucedía con otros criterios de fractura. Sin embargo, la carga cognitiva comenzaba a volverse inmanejable. Podríamos haber aguantado hasta 11 ó 12, pero con alguna de esas incorporaciones alguien habría terminado muy quemado, lo que provocaría otras consecuencias negativas en el rendimiento del equipo. En otra ocasión compartiré mi experiencia con la evolución topológica del equipo.

Cuando un sistema cambia de un estado a otro, se dice que ha alcanzado la masa crítica, también conocida como punto de inflexión o tipping point. En los sistemas sociales, alcanzar la masa crítica significa que suficientes personas han adoptado algo — como una creencia o un producto — y que su crecimiento puede sostenerse por sí mismo.

Una vez más, me remito a la Design Stamina Hypothesis de Martin Fowler, que he mencionado en varias ocasiones en esta newsletter.

Ese momento («Punto Crítico» en la gráfica) en el que el último commit que contribuye al mal diseño del código comienza a impedir el ritmo esperado para añadir nuevas funcionalidades es el punto de inflexión: la base de código se vuelve insostenible, y cualquier cambio adicional se vuelve lento y doloroso.

Concluyendo

En mi experiencia, a medida que los sistemas sociotécnicos en el contexto del desarrollo de productos alcanzan cierta complejidad, comienzan a manifestarse mecanismos que requieren autorregulación para mantener la homeostasis.

Lo que me interesa remarcar de esta analogía es la importancia de identificar y dar visibilidad a los aspectos del sistema que generan tensiones y que, por lo tanto, necesitan un equilibrio adecuado.

Equilibrio es posiblemente la palabra que más repito en mis artículos. Ya en En busca del equilibrio entre empoderamiento y alineación introduje el principio dialógico según Edgar Morin:

El principio dialógico nos anima a ver estas tensiones no como problemas a resolver mediante la eliminación de una de las perspectivas, sino como oportunidades para crear un sistema más dinámico, lejos de los extremos.

Entender estos extremos y los límites de las reservas dentro de nuestros sistemas, así como la criticalidad que pueden alcanzar, es crucial.

Con el tiempo, he desarrollado una sensibilidad especial para detectar dinámicas que nos empujan a dar bandazos. Son estas fluctuaciones descontroladas las que nos pueden llevar a puntos de no retorno una vez que nos salimos de los límites del equilibrio dinámico: como un pH de 8 que nos mate a convulsiones, una gran bola de lodo que haga imposible evolucionar el producto y nos haga plantearnos esa v2 que casi nunca es mejor, o el burnout que acabe con nuestro equipo. Pero cuidado, porque el otro extremo también es peligroso: un pH de 6 que nos deje en coma, un código con 100% de cobertura de tests, DDD, pura fantasía y libre de bugs, o un equipo tan relajado y feliz que el producto nunca llega al mercado. En ambas direcciones, encontraremos puntos de no retorno.

En próximas entregas hablaré sobre «criticalidad autoorganizada» y algunas estrategias para salir reforzados del cambio.

Lecturas recomendadas

• Las leyes del Serengeti: Cómo funciona la vida y por qué es importante saberlo de Sean B. Carroll
• Pensando en Sistemas — Donella H. Meadows
• The Great Mental Models, Volume 3: Systems and Mathematics — Shane Parrish

Homeostasis y masa crítica en sistemas sociotécnicos was originally published in Pensando en Sistemas el Desarrollo de Producto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Seguramente alguna vez has experimentado cómo en un grupo de personas conversando en un espacio cerrado, — no hace falta que sean tantas — el volumen de las voces comienza a elevarse progresivamente, hasta que es imposible escuchar sin gritar directamente al oído.

No fui consciente de la dinámica detrás de este fenómeno hasta que un profesor nos lo explicó en el instituto. Ese día el profesor original se había ausentado y el profe del otro grupo que impartía su clase en el aula contigua, nos echaba un ojo para asegurarse de que no la liábamos demasiado. Evidentemente, no pasaron ni diez minutos antes de que el bullicio se escuchara en toda la planta. El profesor tuvo que venir y, tras un par de chillidos para llamar nuestra atención y que se hiciese silencio, nos explicó:

Chicos, si cada uno habla más alto para hacerse escuchar, sus compañeros harán lo mismo y seguirán subiendo el volumen hasta que todos estén gritando.

Y a continuación, nos compartió un truco sencillo para evitar esta escalada de gritos. Sigue conmigo y te lo comparto al final del artículo.

El «equipo DevOps»

Imagina una organización con una cultura DevOps poco desarrollada. Tenemos por un lado, el equipo de desarrollo de producto, y por otro, el equipo de… llámale sistemas, infraestructura, plataforma, SRE, o para exagerar el que no han entendido de que va la cultura DevOps, el equipo de DevOps. En principio, ambos equipos comparten un objetivo común como: captar el mayor número posible de clientes y hacerles upselling de tantas funcionalidades como sea posible.

El equipo de desarrollo se enfoca en lanzar nuevas funcionalidades rápidamente para atraer nuevos usuarios o retener a los ya existentes. Cada vez que logran lanzar una nueva característica, el número de usuarios crece y, con él, también la carga sobre la plataforma.

Mientras tanto, el equipo de DevOps se encarga de la infraestructura y de mantener el sistema en producción. Cada vez que el equipo de producto lanza nuevas funcionalidades y atrae más usuarios, la infraestructura sufre presión adicional. Para responder a esta demanda, DevOps opta por soluciones rápidas y atajos, como escalar verticalmente — aumentar prestaciones de la infraestructura actual — o aplicar parches apresurados, lo que permite a producto seguir lanzando nuevas características sin tener que preocuparse demasiado por las limitaciones técnicas.

Este aumento de capacidad valida que la forma de trabajar funciona e incentiva aún más al equipo de desarrollo a lanzar más y más funcionalidades, lo que a su vez vuelve a poner presión sobre la infraestructura. De este modo, ambos equipos entran en un ciclo de escalada: el equipo de desarrollo sigue lanzando nuevas funcionalidades, y el equipo de DevOps sigue aumentando la infraestructura a toda prisa para mantener el sistema a flote.

A largo plazo, este ciclo se vuelve insostenible. A medida que el sistema se vuelve más complejo y los costos de infraestructura aumentan, tanto la velocidad de desarrollo de nuevas funcionalidades como la estabilidad de la plataforma comienzan a verse comprometidas, afectando negativamente el objetivo común inicial de ambos equipos.

Escalada

Estamos ante otro de los arquetipos de sistemas descritos por Donella Meadows en Pensar en Sistemas. Esta trampa se refiere a un ciclo competitivo en el que dos o más partes intentan superarse mutuamente, generando una espiral ascendente que puede terminar siendo destructiva para todos los involucrados.

El arquetipo se manifiesta cuando los agentes dentro de un sistema compiten por ganar ventaja o por acceder a recursos limitados, lo que desencadena un ciclo de «uno más que tú». Este ciclo tiende a acumular consecuencias negativas a medida que los involucrados se ven atrapados en una carrera sin fin.

Cuando el estado de una reserva viene determinado por el afán de sobrepasar el estado de otra reserva –y viceversa–, se activa un bucle de retroalimentación reforzador que conduce al sistema a una carrera armamentística, a una carrera por la sanidad, a una campaña de desprestigio, a una escalada de ruido, de violencia. Los procesos de escalada crecen de manera exponencial y pueden llegar hasta el límite a una velocidad sorprendente. Si no se pone ningún remedio, la espiral solo se detendrá con la destrucción de uno de los dos rivales: porque el crecimiento exponencial no puede durar eternamente.

— Donella Meadows. Pensar en sistemas

La estructura de este sistema se basa en la interacción de dos bucles de equilibrio que, al competir entre sí, se refuerzan mutuamente. Debido a este comportamiento competitivo — o incluso paranoico — de los participantes, la situación oscila entre los actores mientras cada uno intenta superar al otro.

Cuando desglosas la estructura, el motivo de su crecimiento se vuelve mucho más evidente. Los dos bucles de equilibrio, que en teoría deberían equilibrarse, en realidad actúan como un solo bucle de refuerzo, lo que lleva a cada participante a una situación no deseada. Si analizáramos la media de las oscilaciones de estos bucles combinados, podríamos ver que la salud de la plataforma empeora continuamente. Dada la naturaleza exponencial de este ciclo de refuerzo, pronto alcanzaríamos puntos de no retorno debido a la deuda técnica y el aumento de complejidad.

Competencia vs colaboración

La escalada se torna más peligrosa cuando se fomenta una cultura competitiva en los equipos sin equilibrarla adecuadamente con incentivos de colaboración. Si los equipos solo compiten por cumplir sus propios objetivos sin alinearse con el resto de la organización, el ciclo puede volverse destructivo. Hemos visto casos similares cuando exploramos la trampa de perseguir el objetivo equivocado.

No obstante, con la cohesión adecuada y metas claras compartidas, la competencia bien canalizada puede transformar la escalada en algo positivo. En lugar de desencadenar una espiral destructiva, se puede convertir en una carrera hacia la mejora continua, donde los equipos, motivados tanto por competir como por colaborar, impulsen el crecimiento y la innovación de la organización de manera sostenible. Este equilibrio entre competencia y colaboración es clave para evitar caer en las trampas del sistema, tengo a medias un artículo específico sobre este tema.

Escalada de crutrés

La escalada también puede verse como una versión de la trampa de la erosión de metas, donde la espiral competitiva va en un sentido negativo, compitiendo no con otros, sino con el desempeño anterior. En lugar de un crecimiento exponencial positivo, el sistema cae en una espiral descendente en la que las metas se ajustan a la baja, erosionando la calidad o el desempeño esperado. Esto es particularmente evidente en organizaciones donde la presión para mantener la velocidad o la cantidad de lanzamientos acaba degradando la calidad de las funcionalidades o la estabilidad del sistema.

La salida

Como hemos visto, este arquetipo se convierte en una peligrosa trampa cuando se combina con otras trampas que he ido mencionando en mis artículos anteriores. Como ocurre con la mayoría de las trampas, la mejor forma de evitarlas es no haber caído en ellas en primer lugar, y para lograrlo es crucial fomentar una cultura de cohesión y de búsqueda de objetivos comunes.

En el ejemplo del equipo DevOps, una cultura DevOps correcta habría evitado caer en la trampa. Como sugiere «La primera vía de DevOps», es fundamental enfatizar el rendimiento del sistema completo en lugar del rendimiento de un silo o departamento en particular.

Para romper este ciclo de escalada, ambos equipos deben colaborar y establecer límites claros (ver Team API) y prioridades comunes, en lugar de trabajar de forma reactiva. Trabajando de forma coordinada y persiguiendo los mismos objetivos, ambos equipos podrían desarrollar soluciones escalables a largo plazo, reduciendo la reactividad.

Si ya nos encontramos atrapados en la trampa, la clave para romper el ciclo es intervenir en los bucles de retroalimentación, buscando crear bucles de equilibrio en lugar de refuerzos continuos de la competencia. Si eres parte del ciclo, una opción viable es buscar un desarme unilateral: en ocasiones, si una de las partes detiene la escalada, la otra pierde incentivos para continuar.

Si lo que llamamos equipo de DevOps, adoptara un enfoque de equipo de plataforma que provea una plataforma como servicio, podría haber ofrecido una salida efectiva para retirarse de la escalada de la infraestructura. Una técnica interesante para lograr esto es el «backpressure». En lugar de simplemente escalar infinitamente los recursos disponibles, con el «backpressure» se puede aplicar alguna de estas estrategias:

• Controlar al productor: la velocidad de producción es decidida por el consumidor, ralentizándola o acelerándola según sea necesario.
• Almacenar temporalmente: crear un buffer para manejar picos de datos entrantes de manera temporal.
• Descartar: muestrear un porcentaje de los datos entrantes para reducir la carga.

Os recomiendo este artículo donde Jay Phepls explica detalladamente esta técnica.

Cerrando

Volviendo al fenómeno de la escalada del volumen de voz, en 2019 asistí a mi primer open space, el SOSZ19. En medio del evento, me encontré con el mismo fenómeno de escalada de gritos para hacerte escuchar, lo típico en todo networking al que había asistido antes. De repente, noté que todos a mi alrededor comenzaban a levantar la mano. Extrañado, hice lo mismo y detuve mi acalorado networking. En cuestión de segundos, el silencio reinó en la sala. Un ejemplo brillante de desarme de la escalada, esta vez mediante la introducción de otra escalada, pero que utilizaba el sentido visual en lugar del auditivo.

No he sido capaz de encontrar el origen de esta técnica, creo que viene de la comunidad agile, a ver si alguien lo sabe y nos lo amplía en los comentarios.

Y respecto al truco del profesor de instituto, también aplicó la escalada, pero dándole la vuelta al objetivo. Nos explicó que si poníamos el foco en hacer lo contrario, el único límite sería que nuestro grupo no nos escuchara. Nos dijo algo como:

Qué tal si os proponéis hablar lo más bajo posible, retándoos a hablar lo más bajo que vuestro subgrupo pueda escuchar.

Voilà, funcionó! De repente pasamos a un murmullo suave y constante, el aula parecía un velatorio, que casualmente es el objetivo en un velatorio — al menos en los de mi pueblo en Cuba en aquella época.

Sin embargo, en cuanto un grupo se sale del protocolo u objetivo global, es fácil volver a caer en la escalada en la otra dirección. En realidad esto ocurre con cualquier dinámica que implique un contrato social, basta con que una masa crítica rompa el contrato para que se provoque una escalada paranóica del «yo uno más que tú».

Bonus para padres

Si ves a dos hermanos insultándose, luego pasando a los empujones, tirones de pelo y eventualmente a los golpes, ya sabes que esto no tendrá fin por sí solo. Edúcalos para que esta escalada nunca ocurra (y de paso escribe un libro sobre cómo 😉), o intervén en cuanto detectes los primeros signos.

Serie: las trampas de los sistemas complejos

Este post forma parte de una serie sobre las trampas de los sistemas complejos aplicadas al desarrollo de productos:

• Elusión de las reglas y persecución del objetivo equivocado: La trampa del testing coverage.
• Desplazamiento de la carga hacia la intervención: La trampa de la adicción al parche.
• Deriva hacia el bajo rendimiento: La Trampa de la Erosión de Metas y el Síndrome de la Rana Hervida.
• Tragedia de los recursos comunes: La tragedia del código compartido.
• Exclusión competitiva o «el éxito que atrae el éxito»: La trampa del «rockstar developer». La exclusión competitiva y el efecto Pigmalión.
• Exclusión competitiva: La trampa del «rockstar developer».
• Resistencia a las políticas: La trampa de los atajos y el falso dilema entre calidad y velocidad.

Si te interesa el tema del pensamiento sistémico aplicado al desarrollo de producto, de vez en cuando organizo talleres sobre cómo usar y sacarle partido a estas herramientas. Si estás interesado en que lo imparta para tu equipo o en algún evento, escríbeme.

El «equipo DevOps» y la trampa de la escalada was originally published in Pensando en Sistemas el Desarrollo de Producto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Disclaimer 1: Mi nivel de ajedrez es el de un jugador de club (1700–1800 ELO FIDE), así que no tomes demasiado en serio ningún consejo ajedrecístico que no sea una cita literal.

Disclaimer 2: Este es el ensayo más largo que he escrito en mi vida. Es un tema sobre el que llevaba mucho tiempo queriendo reflexionar, una forma de saldar mi deuda por haber dejado de lado esta pasión. Soy consciente de que el público objetivo de este artículo es muy reducido, ya que necesitas un mínimo de comprensión sobre ajedrez y estar en mi misma sintonía en cuanto a mindset de desarrollo de producto, lean y XP. Si encajas en este perfil, relájate y disfrútalo. Si no, seguro conoces a alguien que lo haría, ¡compártelo por favor! 🙏🏼

Disclaimer 3: Para las afirmaciones sobre estudios científicos he utilizado Consensus. No he profundizado en ninguno de los artículos referenciados.

Suponga que un día la vida y la suerte de todos nosotros dependieran de que ganara o perdiera una partida de ajedrez. ¿No cree que uno de nuestros principales deberes debería ser aprender al menos los nombres y los movimientos de las piezas? […] Sin embargo, hay una verdad muy sencilla y elemental, y es que la vida, la suerte y la felicidad de todos nosotros, y, en mayor o menor medida, de quienes están vinculados a nosotros, dependen en realidad de que conozcamos un poco las reglas de un juego mucho más difícil y complejo que el ajedrez. Es un juego que se practica desde tiempo inmemorial. […] El tablero de ajedrez es el mundo, las piezas son los fenómenos del universo, y las reglas del juego son las leyes de la Naturaleza. — Thomas H. Huxley. A Liberal Education (1868) vía Sean B. Carroll en Las leyes del Serengeti

Nunca podré agradecerle lo suficiente a mi padre por haberme introducido al ajedrez cuando era muy pequeño, y a mi madre por haberme impedido que, al terminar la secundaria, ingresara en una escuela especializada para dedicarme por completo a ello. No se me daba mal, ¿eh? Pero jamás habría alcanzado un nivel que me permitiera vivir de ello, ni habría descubierto el fascinante mundo del desarrollo de software (al que también me introdujo mi padre) y todo lo que ha venido después.

A pesar de todo, el ajedrez sigue siendo una de mis grandes pasiones. Desde que existen plataformas online, pocas veces me he ido a la cama sin jugar al menos una partida rápida, y mi racha de práctica en Chessable roza lo obsesivo 🤭.

Además de ser un excelente pasatiempo, el ajedrez aporta grandes beneficios más allá del tablero. Mi primer ejemplo particular es que me alejó de Instagram en un momento en que me robaba muchísima atención, y aún no he pisado TikTok ni demás moderneces (mantengo sólo Twitter/X y LinkedIn para temas profesionales). Consigo mis dosis de dopamina jugando partidas rápidas; es como cambiar el azúcar por la miel: sigue siendo dañino en exceso (algún toque me da la familia de vez en cuando), pero con la miel al menos obtienes algunas enzimas, aminoácidos, minerales, vitaminas y polifenoles. Hoy te voy a contar sobre los polifenoles del ajedrez.

¿El ajedrecista nace o se hace?

Varios estudios confirman que la práctica del ajedrez contribuye a mejoras cognitivas, especialmente en habilidades matemáticas. Aunque se ha encontrado evidencia de cambios estructurales en el cerebro asociados con la práctica prolongada, el grado de transferencia de estos beneficios a otros dominios cognitivos sigue siendo motivo de debate.

En el sentido opuesto, la investigación sugiere que alcanzar un alto nivel en ajedrez está relacionado con habilidades intelectuales superiores, en particular en áreas como el razonamiento fluido, las habilidades numéricas y las capacidades cognitivas generales.

Además, el ajedrez aporta demostrados beneficios para la salud mental. Mi compañero de club, Cristóbal Blanco, ha profundizado en los beneficios del ajedrez para la actividad cerebral y cómo puede ayudar a prevenir enfermedades y trastornos mentales como la depresión y el Alzheimer.

¿Qué mejor que un juego en el que te diviertes mucho mientras piensas? Y si, además, como el autor de este libro ha demostrado científicamente, ese juego es terapéutico, no se me ocurre un solo argumento razonable en contra. — Leontxo García en el prólogo de Jaque mate al TDAH

¿El ajedrez mejora las habilidades de toma de decisiones?

Más allá de las mejoras cognitivas, el ajedrez también nos ofrece lecciones valiosas en el arte de tomar decisiones estratégicas. Se le atribuye una mejora en la capacidad de deliberación, en la toma de decisiones rápidas bajo presión, y en la habilidad de generar opciones viables con rapidez. Estas habilidades estratégicas y analíticas pueden tener un impacto positivo en diversos ámbitos de la vida, incluido el entorno profesional y la estrategia empresarial.

Aterricemos cómo estas habilidades estratégicas y analíticas pueden realmente extrapolarse de un juego al mundo real.

Llevaba tiempo queriendo escribir sobre este tema, pero sabía que no debía hacerlo sin antes leer el libro Cómo la vida imita al ajedrez, escrito por el campeón mundial y mi principal referente cuando comencé en el ajedrez: Garry Kasparov. Aprovecharé muchas de las citas que marqué en el libro para intentar aterrizarlas en nuestro contexto de toma de decisiones en producto e ingeniería.

Nota: A partir de ahora, para evitar repetirme, todas las citas que no especifiquen su autor serán de Garry Kasparov en Cómo la vida imita al ajedrez.

Del «mundo bueno» al «mundo malo»

En golf o ajedrez, una bola o pieza se mueve conforme a unas reglas y dentro de unos límites, sus consecuencias son fáciles de ver y desafíos similares ocurren con frecuencia. — David Epstein. Amplitud

Antes de entrar en las analogías entre el ajedrez y situaciones del mundo real, es importante entender el contexto en el que se desarrolla este juego, pues evidentemente, un juego de mesa dista mucho de la vida real.

El ajedrez se juega en lo que David Epstein, en su libro Amplitud, llama «mundos buenos»: entornos diseñados por humanos y acotados por reglas definidas. En estos mundos, un especialista no necesita prácticamente ningún conocimiento externo para operar. Si bien el ajedrez es extremadamente complicado debido a la cantidad de combinaciones posibles, no se compara con la complejidad del «mundo malo».

En los entornos «malos», las reglas del juego no suelen ser muy equitativas ni claras, o son incompletas. Pueden o no haber patrones repetitivos y pueden o no ser obvios, y las respuestas no siempre son inmediatas o precisas, o ninguna de las dos. En los entornos más malos y diabólicos, la experiencia reforzará las lecciones erróneas. — David Epstein. Amplitud

Por otro lado, en los «mundos malos» reina la incertidumbre y el caos. Las reglas no son claras y los resultados de nuestras acciones pueden ser lentos o imprecisos.

Desde la lente del modelo Cynefin, desarrollado por Edward Snowden, el ajedrez encajaría dentro del dominio lo complicado. En este tipo de entornos, las reglas son conocidas, pero requieren de expertos para interpretar las múltiples combinaciones y aplicar soluciones. Aunque el ajedrez es intrincado y difícil de dominar, sus reglas están claramente definidas, lo que lo convierte en un sistema donde los expertos pueden utilizar su conocimiento especializado para operar con éxito.

En cambio, la mayoría de los entornos donde necesitamos pensamiento estratégico — como en el desarrollo de productos o la toma de decisiones empresariales — suelen estar en el dominio lo complejo. Aquí, las relaciones de causa y efecto no son evidentes hasta después de que las decisiones se han tomado, y la incertidumbre es un factor dominante. En estos entornos, las soluciones no se pueden predecir fácilmente y requieren experimentación, aprendizaje continuo y adaptabilidad.

¿Significa esto que no sirven de nada las analogías entre la estrategia en ajedrez y el mundo real?

Entender si operas en un entorno bueno o malo, o si estás en un dominio complicado o complejo, es crucial porque cada uno requiere enfoques diferentes. No puedes pretender que las estrategias que te funcionan en el ajedrez sean directamente extrapolables al mundo real sin tener en cuenta la complejidad del contexto en el que te encuentras.

Como hemos visto en la disolución de problemas, podemos intentar reducir la «maldad» del entorno al que nos enfrentamos disolviendo su complejidad. Parte de esta disolución consiste en aplicar modelos mentales y analogías que nos ayuden a acotar el alcance del problema.

En un sistema matemáticamente finito se puede calcular todo, pero el ajedrez es demasiado grande para eso. Hay un gran malentendido acerca de la naturaleza del juego de ajedrez. Para la matemática el juego es finito, pero para nosotros, los seres humanos, el ajedrez es un juego matemáticamente infinito. El número de posiciones, es decir la suma de todas las posiciones posibles, contiene 45 ceros. Creo que es suficiente como para considerarlo matemáticamente infinito.

— Garry Kasparov. Entrevista exclusiva concedida en Madrid a Gestión

Además, el ajedrez se convierte en un sistema abierto en el momento en que lo juegan dos humanos, ya que podemos cometer errores, pues somos, en definitiva, humanos. Factores externos como el clima o el ruido de un petardo durante la partida también pueden desconcentrarnos. Es aquí donde cobran valor muchas de las analogías, ya que esto devuelve el ajedrez al plano de lo complejo. De repente, intervienen tanto el factor psicológico del contrincante como nuestra propia incapacidad de cálculo exhaustivo, añadiendo un nivel de incertidumbre y complejidad al juego que trasciende las reglas y las jugadas estrictamente lógicas.

Estrategia y táctica en el ajedrez

La estrategia en ajedrez se refiere a la planificación a largo plazo y a la creación de un plan general para la partida. Se basa en principios generales, que incluyen la estructura de peones, el control del centro, la colocación óptima de las piezas y la seguridad del rey. La estrategia busca mejorar gradualmente la posición, asegurando que tus piezas estén bien colocadas para explotar las debilidades del oponente. Es un enfoque más abstracto y conceptual, que no siempre se enfoca en movimientos inmediatos o calculados.

Por su parte, la táctica se refiere a movimientos concretos y calculados que producen una ganancia inmediata de material o que mejoran significativamente la posición. Las tácticas suelen implicar secuencias específicas de movimientos que obligan al oponente a cometer errores o perder piezas. La táctica es más específica y depende de los detalles concretos de la posición en el tablero. Ejemplos comunes de tácticas incluyen el ataque doble, la clavada, la horquilla y el jaque mate forzado.

El triángulo de hierro del ajedrez

Tanto en el ajedrez como en los demás campos, pronto nos damos cuenta de que en la vida hay mucho más que material. Enfrentarse por primera vez a un jaque mate, aunque se disponga de mucha ventaja material, es una lección muy valiosa. El valor definitivo del rey está por encima de todo lo que hay en el tablero, y así empieza a ajustarse nuestro sistema de valores. El material no lo es todo.

El Triángulo de Hierro en la gestión de proyectos se basa en tres restricciones principales: alcance (lo que se debe hacer), tiempo (cuándo debe entregarse) y costo (recursos disponibles). Estas tres variables están interrelacionadas: cambiar una afecta a las otras dos. Por ejemplo, si quieres aumentar el alcance, necesitarás más tiempo o más dinero. Habrás escuchado lo de «Bueno, rápido, barato: elige dos», lo que viene a decir que no se pueden maximizar las tres a la vez sin hacer compromisos.

Según Kasparov, en ajedrez, existen tres factores cruciales para evaluar y tomar decisiones estratégicas durante una partida:

• Tiempo (Desarrollo/Tempo): En ajedrez, el «tiempo» se refiere a cuántas jugadas (tempos) se han utilizado para desarrollar las piezas o mejorar la posición. Un jugador que desarrolla sus piezas rápidamente está «ganando tiempo». Perder tiempo implica hacer jugadas innecesarias o subóptimas. Si decides invertir en ganar tiempo, puede que debas ceder material o aceptar una posición menos favorable.
• Material: El «material» se refiere a las piezas en el tablero. Una ventaja material significa tener más piezas o piezas de mayor valor que el oponente (por ejemplo, un peón o una torre extra). Ganar material generalmente implica sacrificar tiempo o aceptar una posición menos favorable (perder calidad en la estructura o desarrollo). Por ejemplo, puedes ganar una pieza, pero a costa de que tus piezas queden mal coordinadas.
• Calidad de la posición: La «calidad de la posición» se refiere a lo bien que están coordinadas tus piezas, tu control del tablero y la seguridad del rey. A veces, una posición con menos material puede ser preferible si las piezas están mejor colocadas, controlando más espacio o ejerciendo presión sobre el oponente. Mejorar la calidad de la posición a menudo implica sacrificar material (con un sacrificio estratégico) o tiempo en el desarrollo.

El tiempo no se gana simplemente por movernos más aprisa o por tomar un atajo. El tiempo a menudo se compra, se intercambia por ventajas materiales. En combate, una fuerza ligera y rápida puede maniobrar y vencer a un enemigo numéricamente superior. Un ejército menos numeroso puede vencer si consigue romper el flanco más débil de su enemigo. Tiempo por material es el primer intercambio compensatorio de nuestro sistema de evaluación.

Al igual que en el Triángulo de Hierro en la gestión de proyectos, en ajedrez es difícil maximizar los tres factores simultáneamente. Si decides ganar tiempo, probablemente sacrifiques material o la calidad de la posición. Si priorizas el material, es posible que termines con una peor posición o pierdas tiempo en el desarrollo.

Recientemente, tanto Kent Beck (Scope Management 101) como Luca Rosi (On triangles…) han escrito dos pequeñas pero importantes reflexiones sobre este modelo, destacando que el trade-off entre las variables no siempre es lineal. Rosi resalta que más recursos no siempre implican mayor rapidez, de la misma manera que tener cuatro damas en el tablero no garantiza una mejor posición si el tiempo está a favor de tu oponente (y tiene mate forzado en la siguiente jugada).

Beck destaca que en el desarrollo de software no trabajamos con un conjunto fijo de tareas, ya que los requisitos tienden a cambiar durante el proceso, lo que nos obliga a ajustar continuamente el alcance. Entregar de manera incremental, mediante ciclos cortos, permite a los equipos reevaluar constantemente estos factores. Este enfoque es algo que tenemos «por diseño» en ajedrez: jugada a jugada, podemos reevaluar nuestras opciones. Al igual que un gran maestro evalúa continuamente el equilibrio entre material, tiempo y calidad de posición, los equipos de producto deben ser capaces de ajustar su dirección en ciclos cortos.

Positional Stamina Hypothesis

Alekhine fue un adelantado de su tiempo. Según mi teoría, el ajedrez está formado por tres componentes: material, tiempo y calidad de posición. (…) Con el concepto material todo está claro: se trata del nivel aritmético con que «piensan» las computadoras: peón, pieza de ventaja, etc., el abc de la ciencia ajedrecística. El segundo factor, tiempo, es más complicado, pero también comprensible. La ganancia de tiempo, la velocidad de avance de un peón pasado, o el asalto a la fortaleza de un rey. Al sacrificar material por un rápido ataque es el tiempo lo que tenemos en cuenta. El tercero, calidad de posición, es el menos evidente, porque se trata de un factor estratégico: estructura de peones, casillas fuertes y débiles, piezas activas y pasivas, pareja de alfiles, rey expuesto… La calidad de una posición no puede dictaminarse mediante una evaluación numérica. (…) Digamos que la verdadera maestría se compone de la sutil evaluación de los tres factores. (…) Alekhine fue el primero que empezó intuitivamente a combinar los tres factores en su juego, vinculándolos entre sí. — Garry Kasparov. Mis geniales predecesores (vol. 1)

En ajedrez, puedes intentar avanzar rápido en una partida sin preocuparte por el desarrollo adecuado de tus piezas o el control del centro, lo que puede parecer una ventaja a corto plazo. Sin embargo, al igual que en el diseño de software, esto acumula una forma de «deuda estratégica» que te deja en una posición débil más adelante.

Al igual que en ajedrez, donde la calidad de la posición no puede evaluarse únicamente en términos de material o tiempo, en el desarrollo de software, la calidad no es simplemente un costo adicional. En muchos casos, mejorar la calidad puede reducir tanto el costo como el tiempo, al evitar el desperdicio y el trabajo repetido. ¿Fowler fans, os suena de algo esto?

Las actividades de diseño ciertamente requieren tiempo y esfuerzo, pero compensan porque facilitan la evolución del software en el futuro. Puedes ahorrar tiempo a corto plazo al descuidar el diseño, pero esto acumula Deuda Técnica, lo que ralentizará tu productividad más adelante. Invertir esfuerzo en el diseño de tu software mejora la resistencia de tu proyecto, permitiéndote avanzar más rápido durante más tiempo — Martin Fowler. Design Stamina Hypothesis

Si no has desarrollado tus piezas correctamente o no has prestado atención a la calidad de tu posición, terminarás luchando cuesta arriba en la segunda mitad de la partida, ralentizando tu capacidad para tomar decisiones efectivas y generando problemas tácticos que tu oponente puede aprovechar.

La hipótesis tiene un corolario, que proviene de la línea de retorno del diseño (design-payoff line). Si la funcionalidad de tu versión inicial está por debajo de la línea de retorno del diseño, entonces puede valer la pena sacrificar la calidad del diseño por velocidad; pero si está por encima de la línea, el intercambio es ilusorio. — Martin Fowler. Design Stamina Hypothesis

La calidad de la posición es el factor más sutil y estratégico, ya que, al igual que la calidad del producto o del código, es subjetiva. No puede evaluarse numéricamente con facilidad y es difícil de reducir a una simple métrica, de ahí que me resulte sencillo aplicar modelos mentales de un campo al otro; las ideas del desarrollo de producto pueden trasladarse al ajedrez y viceversa.

Centrarse únicamente en la ventaja material es equivalente a lanzar funcionalidades como churros en el desarrollo de productos, sacrificando la calidad. La calidad estratégica (en ajedrez o en software) no siempre conlleva un sacrificio, y en ocasiones, puede ser la clave para desbloquear eficiencias en otros factores.

Razonamiento sistémico

Diana Montalion propone la técnica del «razonamiento sistémico» en su reciente libro, Learning Systems Thinking.

El razonamiento sistémico es un método de indagación: un proceso a través del cual exploramos, analizamos, discernimos, deliberamos, probamos y expandimos nuestro conocimiento. Fortalecer nuestras razones implica comprender proactivamente y adquirir conocimiento — Diana Montalion.

Para mí, jugar ajedrez es puro razonamiento sistémico y pensamiento crítico. No hay una jugada que consideres sin antes verificar qué haría tu oponente como respuesta, con la mayor profundidad que te permita tu mente y el tiempo disponible (el marcado por el reloj). No hacerlo es un acto temerario. Cuando no tienes más opción que jugar rápidamente, te das cuenta de cuán limitada es la intuición, ya que el ajedrez es concreto y calculable.

En el ajedrez, el éxito y el fracaso se miden con patrones muy estrictos. Si te equívocas en las decisiones, tu posición se debilita y el péndulo oscila hacia la derrota; si aciertas, se mueve hacia la victoria. Cada uno de los movimientos es el reflejo de una decisión, y, con el tiempo suficiente, podría analizarse con perfección científica si esa decisión fue la más eficaz o no.

El ajedrez me ha demostrado cuán imprecisa puede ser mi intuición. En cada partida, he tomado decenas de decisiones convencido de que eran las mejores, solo para darme cuenta al analizarlas de cuán equivocado estaba, ya sea por falta de conocimientos, por errores de cálculo o por lapsus mentales. Incluso cuando revisaba la situación, veía como correcto lo que claramente era un error.

En el día a día, no hacer un análisis crítico de tus acciones es igualmente temerario. Dependiendo de la importancia de lo que estés a punto de hacer o comunicar, deberías realizar un análisis similar.

Hay una gran diferencia entre considerar los movimientos posibles y evaluar la situación. Fácilmente quedamos atrapados buscando opciones en lugar de hacer un análisis en función de las necesidades que nos indique cuál es la alternativa mejor.

Uno de los principales errores de un principiante en ajedrez es jugar sin evaluar la posición. Hacer jugadas solo porque puede. Si se le presenta una pieza para capturar, lo hará sin pensar en la respuesta del rival. A medida que el jugador avanza de nivel, gana capacidad de cálculo y empieza a operar en un espacio más concreto: si hago esto, mi oponente hará aquello, y así, con la profundidad que su habilidad le permita.

Una de las habilidades más complicadas en ajedrez, y que en mi opinión marca la diferencia entre los niveles, es nuestra capacidad de analizar una posición desde ambos bandos. Implica eliminar cualquier sesgo sobre con qué piezas juegas tú e intentar ponerte en el lugar del oponente, viendo la posición desde su perspectiva y explorando posibles planes del rival para poder anticiparlos.

No solo calculas, sino que realmente analizas la posición desde la perspectiva estratégica de tu oponente. Empiezas a preguntarte: ¿Qué planes tiene mi rival? ¿Hacia dónde quiere llevarme? ¿Cuál es la intención detrás de su última jugada?

Aunque no se trate de conectar con las emociones como lo haría la empatía, creo que requiere un esfuerzo deliberado similar.

Ese mensaje en Slack, ¿cómo lo leerá la otra persona? ¿Tiene todo el contexto que necesita?

Esa propuesta de cambio, ¿qué preguntas surgirán? ¿Cómo responderé?

Diana Montalion propone considerar cuidadosamente los puntos de vista opuestos, poner a prueba tus ideas y ser honesto sobre los posibles inconvenientes de tu propuesta. Para ello, al igual que en el ajedrez es necesario anticipar varios movimientos y cómo responderán tus oponentes:

• Cuando haces una recomendación, casi siempre hay otras opciones. ¿Por qué no las elegiste?
• Casi siempre hay personas que no están de acuerdo contigo. ¿Qué buenas razones dan y por qué piensas de manera diferente?
• Casi siempre hay posibles inconvenientes… las cosas podrían salir terriblemente mal. ¿Cuáles son los obstáculos que amenazan con descarrilar tu recomendación?
• ¿De qué es lo que más dudas? ¿Cómo vas a monitorear estos riesgos a medida que avanzas con esta idea?

Otro enfoque útil en este sentido sobre el que ya he escrito es el Empathy-Driven Development.

El campeón mundial Boris Spassky dijo una vez que «el mejor indicador del nivel de un ajedrecista es su capacidad para detectar el momento culminante de una partida». Es virtualmente imposible jugar siempre los mejores movimientos, porque la exactitud está a expensas del tiempo, y viceversa. Pero si podemos detectar los momentos clave, podremos tomar las mejores decisiones en los momentos más cruciales.

Evidentemente, no podemos pasar todo el tiempo haciendo análisis detallados en cada situación de la vida. El cálculo constante tiene un coste de oportunidad, y su utilidad depende de la asimetría entre los riesgos de equivocarse y los beneficios de acertar. El verdadero arte radica en discernir cuándo ese esfuerzo analítico es realmente necesario y compensa el tiempo invertido.

Pensamiento estratégico

Si jugamos sin objetivos a largo plazo, nuestras decisiones se convierten en exclusivamente reactivas y nos vemos jugando el juego de nuestro oponente, no el nuestro.

Como mencioné antes, aunque el ajedrez se basa en la concreción y, con suficiente capacidad de cálculo, se podría predecir el resultado a partir de la primera jugada, entre humanos el juego entra en el terreno de lo complejo, y esto es más evidente cuanto menor es el nivel de los jugadores.

Incluso los súper grandes maestros no tienen la capacidad de calcular todas las variantes de decenas de jugadas. Aquí es donde la estrategia entra en juego. Es fundamental diseñar estrategias que nos permitan optimizar nuestro esfuerzo de cálculo, evitando divagaciones innecesarias. Del mismo modo, en el desarrollo de productos, no puedes permitirte explorar todas las posibles soluciones por fuerza bruta, ya que estás limitado por tiempo y recursos.

Limitar desde el inicio el alcance de nuestras investigaciones es nuestro primer deber. La experiencia y los cálculos preliminares nos permiten reducir las opciones casi inmediatamente.

Solamente cuando las opciones iniciales se muestran inadecuadas tras un análisis, debemos retroceder y reconsiderar nuestras alternativas. Esta lógica pone en valor los enfoques de desarrollo iterativo incremental y los pequeños pasos, donde avanzamos basados en resultados intermedios y ajustamos según sea necesario.

Demasiado a menudo señalamos un objetivo y nos dedicamos a él, sin tener en cuenta los pasos necesarios para alcanzarlo. ¿Qué condiciones deben cumplirse para que nuestra estrategia sea un éxito? ¿Qué debe cambiar y qué podemos hacer para introducir esos cambios?

Al igual que discutimos en el modelo mental de inversión para disolver problemas, utilizando técnicas como el Escenario más allá del problema y las Apelaciones de la indirecta, se trata de visualizar el escenario ideal e ir moldeándolo hasta llegar a una posición ganadora, considerando el equilibrio entre material, tiempo y calidad de la posición.

El estratega empieza con un objetivo para un futuro lejano y trabaja retrocediendo hasta el presente. Un gran maestro hace los mejores movimientos porque están basados en lo que quiere que suceda en el tablero, después de unos diez o veinte movimientos. Para ello no es necesario que calcule las incontables variables de veinte movimientos. Evalúa cuál será el resultado de su posición y establece una meta. Luego va paso a paso hasta conseguir su propósito. Esos objetivos intermedios son esenciales.

(…) Mi instinto, o el análisis, me dicen que una posición determinada encierra un ataque potencial al rey de mi adversario. Entonces, en lugar de dirigir todas mis fuerzas a atacar al rey busco los objetivos que debo conseguir para llevarlo a cabo con éxito; por ejemplo, debilitar la protección alrededor del rey del oponente, canjeando una pieza defensiva esencial. Primero debo saber qué objetivos tácticos me ayudarán a conseguir mi propósito de atacar al rey y solamente entonces empiezo a planear exactamente cómo conseguirlos, y a considerarlos movimientos concretos que me conducirán a la consecución del éxito. De lo contrario, trazaré un plan osado y simplista con pocas posibilidades de éxito.

Pensamiento lateral

El pensamiento lateral, propuesto por Edward de Bono, es una técnica que nos invita a abordar los problemas desde perspectivas no convencionales, rompiendo con los patrones de pensamiento tradicionales y buscando soluciones creativas e innovadoras.

Muy a menudo descartamos inmediatamente las ideas y las soluciones extravagantes, especialmente en áreas con patrones establecidos desde hace mucho tiempo. Nosotros mismos nos imponemos ese rechazo a pensar con creatividad, casi tanto como nos lo imponen los parámetros de nuestro trabajo y de nuestra vida. «¿Y si…?», a menudo lleva a «¿Por qué no?», y, llegados a ese punto, debemos armarnos de coraje y averiguarlo.

En ajedrez, existen puzzles o problemas diseñados para poner a prueba nuestras habilidades tácticas y nuestra creatividad. Cuando te enfrentas a un problema de este tipo, pruebas todo, incluso lo más absurdo, porque ya sabes que hay una solución creativa detrás, especialmente si te dan pistas como «juegan las blancas y dan mate en 3».

Sin embargo, en medio de una partida real, rara vez se te ocurre pensar en jugadas contraintuitivas o grandes sacrificios de material, porque nadie te ha avisado de que hay un mate en tres, y además, el reloj corre. No puedes permitirte explorar un alto nivel de creatividad en cada jugada.

Es en este punto donde nos diferenciamos de un ordenador: si alguna vez has seguido los comentarios en directo de una partida de alto nivel, habrás visto como el comentarista, apoyado por un módulo de ordenador, conoce la evaluación de la posición y a menudo dice: «la mejor jugada es tal, pero no es un movimiento muy humano, no creo que la haga».

En el día a día del desarrollo de productos, nos pasa algo similar. Al analizar un problema, nos resulta difícil salirnos de los patrones establecidos, a menudo porque estamos pensando en el nivel de abstracción incorrecto o porque nos imponemos restricciones que no existen realmente. Como mencioné en los límites del espacio de la solución, para romper paradigmas es fundamental alejarse del espacio de las soluciones tradicionales.

Inercia estratégica

Hemos de saber qué preguntas hacer y hacerlas a menudo. ¿Han cambiado las condiciones de tal modo que requieren un cambio de estrategia, o basta con un pequeño reajuste? ¿Han cambiado los objetivos por algún motivo? Evitemos el cambio por el cambio.

En ajedrez, es bastante común apegarse a una estrategia ya establecida, lo que a veces lleva a caer en la inercia estratégica. Has invertido tanto en una dirección que, aunque las condiciones cambien, algo te impide reevaluar la posición y ajustar tu plan. Esto pasa especialmente en la transición de fases, por ejemplo la transición del medio juego al final, cuando quedan pocas piezas y es crucial detenerse y replantear la situación con más calma.

Un ejemplo reciente en nuestro equipo, estamos analizando la deprecación de una infraestructura antigua. Habíamos avanzado mucho: ya teníamos la nueva infraestructura en funcionamiento y la mayoría de las funcionalidades se habían desacoplado de la anterior. Sin embargo, aún quedaba un esfuerzo adicional para completar el desacoplamiento, lo que implicaba un coste de oportunidad, ya que tendríamos que dar menor prioridad a otras iniciativas.

La inercia de la discusión seguía enfocada en cómo finalizar el desacople para eliminar la infraestructura antigua, pero nos costaba ver que las condiciones habían cambiado. Habían surgido nuevas opciones intermedias que posiblemente nos permitirían ganar más tiempo, como deshabilitar el reindexado o redimensionar la infraestructura actual, ahora que los servicios restantes requerían menos recursos.

Tomamos decisiones así a diario, escribí sobre otro ejemplo en Kubernetes — Una fábula sobre sesgos y coste de oportunidad.

Aprendizaje continuo

El éxito raramente se analiza tan detenidamente como el fracaso, y siempre atribuimos rápidamente las victorias a nuestra superioridad, en lugar de a las circunstancias. Cuando las cosas van bien, es más importante, si cabe, cuestionarlas. El exceso de confianza conduce al error, a la sensación de que nada es lo bastante bueno.

Una de las cosas que me apasiona del ajedrez es la posibilidad de analizar mis partidas, independientemente de si he ganado o perdido. El resultado no es lo relevante, porque estoy seguro de que ambos jugadores cometieron errores.

Esta mentalidad de aprendizaje y mejora continua es algo que intento promover en mis equipos. Los análisis postmortem o las retrospectivas no son útiles solo cuando las cosas salen mal. A veces, hay más que aprender de los casos en los que todo salió bien. Identificar buenas prácticas y aprendizajes es tan valioso como encontrar áreas de mejora.

«Analizar el resultado» se considera un error muy común. Es decir, asumir que, si las blancas ganaron, es porque jugaron mejor y consiguieron una victoria merecida. Desde luego, el plan de las negras fue erróneo; al fin y al cabo, perdieron. Es extraordinariamente difícil evitar esa actitud, dado que cuando nos sentamos a analizar la partida ya conocemos su resultado final. Todos los movimientos del vencedor nos parecen ligeramente mejores, porque sabemos que al final funcionaron.

Es cierto que en el ajedrez, al igual que en otros deportes, el resultado es lo que importa en términos competitivos. Como aquello de, «jugaron como nunca, perdieron como siempre». Sin embargo, al igual que en el desarrollo de productos, cada partida la considero un experimento del cual aprender. Podríamos haber lanzado una funcionalidad que selló el mayor acuerdo comercial de la historia de la empresa, pero eso no significa necesariamente que el producto esté perfectamente alineado con las necesidades del mercado. Tal vez fue pura coincidencia o circunstancias externas. Esto no garantiza que el resto de los clientes compren.

En el argot popular del ajedrez competitivo, llamamos a esto un «atraco», cuando un jugador que estaba claramente perdido sigue presionando hasta que su rival comete un error grave. Creer que esta habilidad te salvará siempre, ignorando las razones por las que estabas en desventaja antes del error del rival, es perder una gran oportunidad de aprender al igual que una venta aislada no confirma un market fit ni una estrategia acertada.

(…) la preparación de las aperturas exige tanto creatividad como dedicación. Es como un inventor que trabaja en su laboratorio con nuevos aparatos y artilugios.

No nos pagan por escribir código, nos pagan por resolver los problemas de nuestros clientes. Para mí, a nivel competitivo, jugar una partida es como escribir código o lanzar funcionalidades. Es, como mencioné antes, experimentar. Es lo que Nick Tune define como el «espacio de implementación» en su ampliación del modelo de problem, strategy, and solution space de Indy Young.

Al más alto nivel, el 99% del resultado de una partida depende de la preparación: estudiar lo que juega tu rival, preparar tu apertura para sacarlo de su zona de confort y llevarlo a tu terreno. Poner a prueba tus hipótesis contra el ordenador, en partidas online, en partidas amistosas o con tus asesores o preparadores.

De la misma forma, no puedes escribir una línea de código sin haber estudiado a tus clientes, sin empatizar con ellos, sin entender a tu competencia, sin formular correctamente el problema que necesitas resolver y sin explorar todas las oportunidades disponibles.

La preparación, la experimentación durante la partida y el análisis post-partida constituyen el círculo virtuoso del ajedrez, tal como lo es el ciclo de discovery, el desarrollo iterativo incremental y la validación lo es para el desarrollo de producto.

El zugzwang y el sesgo de acción

En el ajedrez estamos obligados a mover; no existe la opción de ceder el turno cuando no sabemos qué hacer. Para un jugador sin visión estratégica, esa obligación puede convertirse en una carga. Incapaz de diseñar un plan si no se enfrenta a una crisis inmediata, es posible que él mismo provoque la crisis, y probablemente solo conseguirá poner en peligro su propia posición.

A diferencia del ajedrez, en el mundo real tenemos la opción de no mover. Sin embargo, el sesgo de acción nos puede, la épica de estar siempre construyendo y avanzando es lo que valoran la mayoría de culturas de producto. Si nos sobra tiempo, nos lanzamos hacia la siguiente big thing. En el mundo real, podemos optar por la vía negativa o la mejora continua, entendiendo que a veces, no hacer nada es la mejor opción. Además, es crucial reconocer los retrasos de los sistemas en los que actuamos, para evitar caer en el «bandazo driven development». Si te mueves demasiado rápido, sin esperar la reacción de tus usuarios o los resultados de una iteración, no sabrás si la solución que implementaste realmente funciona.

Siegbert Tarrasch solo exageró un poco cuando escribió «Cada movimiento genera una debilidad». A menos que el movimiento lleve al jaque mate, tiene su parte negativa, además de la positiva. Y lo mismo sucede en las modalidades estáticas. Por ejemplo cuando nuestros peones avanzan, ganamos espacio de maniobra para nuestras piezas a costa de debilitar nuestra defensa. Cuando un ejército avanza, sus líneas de comunicación y suministros pueden quedar aisladas o desorganizadas.

Cuando estoy en apuros de tiempo y tengo la obligación de mover, la falta de un plan me lleva a menudo a hacer un movimiento que termina empeorando mi posición. En el desarrollo de software, este sesgo de acción nos empuja a construir características o soluciones que luego cargan con un coste basal, el coste constante de mantener software en producción.

El «zugzwang», un término de ajedrez de origen alemán que más o menos se traduce como «la desfavorable obligación de moverse» («movicide» es el equivalente inglés; un término más práctico que nunca hizo fortuna). Por norma, el tiempo es una ventaja, pero en ciertas ocasiones, puede ser peor verse obligado a mover.

Un claro ejemplo de zugzwang en el desarrollo de productos son las estimaciones con deadlines. Cuando llegamos justo al deadline, nos vemos obligados a lanzar algo a producción que, en lugar de beneficiar al negocio, puede acabar generando más problemas, desde fallos hasta deuda técnica que arrastraremos por mucho tiempo.

Cerrando

Bueno, no me extiendo más. Podría haber dividido este contenido en varias entregas, pero no quiero ocupar demasiado espacio en el blog con este tema, ya que reconozco que no hay mucho nuevo en lo que respecta al desarrollo de producto aquí. Como en la mayoría de mis artículos, simplemente intento ofrecer una nueva lente desde la que mirar el desarrollo de producto. Si veo que hay interés, tengo muchísimos borradores con reflexiones y analogías relacionadas con el ajedrez. Si os interesa, dadme alguna señal y me planteo hacer algo alternativo dedicado al tema.

Mi reseña de Cómo la vida imita al ajedrez

Cómo la vida imita al ajedrez, por Garry Kasparov.

Tenía expectativas muy bajas con este libro. Pensaba que sería el típico libro de efecto halo, en el que alguien exitoso en un ámbito te ofrece recetas para triunfar en general. Nada más lejos de la realidad.

Lo que más me ha cautivado es que, a lo largo de todo el libro, Kasparov apenas usa un diagrama de ajedrez (y, de hecho, es prescindible), y aun así logra introducir aspectos clave del juego a nivel estratégico. Ha sabido intercalar estos elementos del ajedrez con su autobiografía, pasajes biográficos de las principales figuras de la historia del ajedrez mundial, y ejemplos en el ámbito de los negocios y eventos históricos, aplicando algunos principios estratégicos y psicológicos del ajedrez.

Creo que a un profesional del ajedrez el libro podría resultarle superficial y básico en términos ajedrecísticos, pero yo me considero su target ideal:

• Kasparov fue mi ídolo cuando empecé a jugar ajedrez, así que leer lo que pasaba por su mente por entonces, en aquellos momentos que fueron más cruciales de su carrera ha sido muy ameno para mí.
• Mi nivel de ajedrez es de jugador de club, pero creo que incluso un principiante podría sacarle partido, aunque algunos aspectos más avanzados se le escapen.
• Soy emprendedor y me interesa la estrategia empresarial.
• Soy disidente cubano con interés en la historia de la antigua Unión Soviética, especialmente desde la perspectiva de sus detractores.

Lo que el ajedrez me enseñó sobre el desarrollo de producto was originally published in Pensando en Sistemas el Desarrollo de Producto on Medium, where people are continuing the conversation by highlighting and responding to this story.

En la entrega anterior exploramos la disolución de problemas como una alternativa poderosa a la resolución directa de problemas complejos, destacando cómo este método permite evitar enfrentarlos de manera frontal. Vimos que este enfoque puede implicar la reestructuración o descomposición del problema en cuestión. Hoy quiero profundizar en uno de mis modelos mentales favoritos para reestructurar un problema complejo: la inversión.

Inversión

Afrontamos con más valentía aquello para lo que nos hemos preparado. Los que nunca se anticiparon son presa del pánico ante hechos insignificantes. Debemos asegurarnos que nada nos pilla por sorpresa. Y dado que es la falta de familiaridad la que hace a las cosas más imponentes de lo que son, este hábito de reflexión constante asegurará que no eres un novato ante cualquier tipo de adversidad — Séneca

La «inversión» es un modelo mental que consiste en abordar un problema desde el extremo opuesto del enfoque tradicional. Este enfoque nos permite darle la vuelta al problema, replanteando nuestras suposiciones y abriendo nuevas vías hacia la solución.

Imagina que tenemos una máquina del tiempo y podemos viajar al futuro para experimentar los resultados de haber resuelto con éxito o fracasado en nuestro proyecto. La inversión nos permite aplicar dos perspectivas sobre cómo se vería la situación futura al implementar nuestras soluciones:

• Visualización positiva: ¿Qué podemos aprender si alcanzamos el escenario ideal?

• Visualización negativa: ¿Qué podemos aprender si nos enfrentamos al peor escenario?

Visualización positiva

Asume que lo que intentas probar es verdadero o falso y luego analiza qué más tendría que ser cierto. Como vimos en la entrega anterior, al cambiar el contexto, el problema puede volverse irrelevante o más manejable y soluciones inesperadas pueden aflorar.

Veamos algunas técnicas que aplican esta perspectiva.

Apelaciones de la indirecta

Edward Bernays se hizo famoso por su enfoque de inversión llamado «apelaciones de la indirecta» para vender productos. En la década de 1920, cuando la American Tobacco Company le encomendó la misión de vender más cigarrillos a las mujeres, en lugar de preguntarse simplemente cómo venderles más, Bernays se planteó: «Si las mujeres fumaran cigarrillos, ¿qué más tendría que ser cierto?».

De esa reflexión surgió su conocida campaña de Lucky Strike, en la que promovió fumar como una alternativa para evitar el consumo de dulces y lo asoció con la delgadez. Con este enfoque indirecto, tuvo un impacto profundo en la cultura estadounidense, redefiniendo hábitos de consumo y logrando el objetivo final de su campaña.

Escenario más allá del problema

Giorgio Nardone propone una técnica conocida como «la técnica del escenario más allá del problema», la cual invita a ver más allá del problema actual y descubrir el contexto en el que este se desarrolla.

[…] imaginar el escenario ideal más allá del problema. En la práctica, se trata de preguntarse cuál sería el escenario, respecto a la situación que hay que cambiar, una vez que el problema estuviese completamente resuelto o, en el caso de que haya que obtener mejoras, una vez que el objetivo estuviese del todo alcanzado. En otras palabras, debemos inducir a nuestra mente a imaginar cuáles serían todas las características de la situación ideal, tras haber realizado el cambio estratégico. Esta labor, que puede parecer pura fantasía, es por el contrario un modo de descubrir las características de la «realidad ideal» que hay que alcanzar, que a menudo nos permite ver cosas que no seríamos capaces de concebir si nos limitáramos a trabajar sobre la realidad presente y pasada.

El objetivo de esta técnica es expandir la perspectiva para no solo abordar el problema de manera directa, sino imaginar el estado deseado una vez que se haya resuelto. Esto permite visualizar las características del nuevo contexto ideal, lo que ayuda a ver oportunidades y soluciones que no serían evidentes si nos limitamos a analizar la situación actual.

Como en el caso de la campaña de Lucky Strike de Bernays, comprender este contexto ideal nos permite explorar un nivel superior del problema, y, si logramos cambiar dicho contexto, es posible que el problema se disuelva en otros de menor complejidad para el nuevo entorno.

Visualización negativa

He wins his battles by making no mistakes. — Sun Tzu

Si me lees por Twitter, ya sabrás que suelo pintarme cosas estoicas en mi cuerpo. Una de las prácticas estoicas que más aplico es el «premeditatio malorum». Los estoicos creían que imaginar el peor escenario posible de antemano, como perder el trabajo o a un ser querido, ayudaba a prepararse mejor para esas situaciones. Mientras la mayoría se centraba en cómo alcanzar el éxito, ellos también consideraban cómo enfrentar el fracaso.

Enfocar los problemas desde la perspectiva del peor escenario disuelve la necesidad de buscar directamente la mejor solución. En su lugar, nos lleva a considerar lo que podríamos evitar o minimizar. A menudo, es más sencillo evitar lo que no queremos que alcanzar directamente lo que deseamos.

Esto seguramente te sonará de la filosofía de Charlie Munger y Warren Buffett:

• Es más fácil evitar la estupidez que buscar la brillantez.

• Es más fácil prevenir errores que garantizar el éxito.

• Es más sencillo evitar pérdidas que maximizar ganancias.

Veamos algunas estrategias que aprovechan el conocimiento del peor escenario para conseguir sus objetivos.

Campo de fuerzas

El psicólogo Kurt Lewin propuso su teoría del cambio, que también sirve como base para la visualización negativa. A través de su análisis del «campo de fuerzas», Lewin plantea que, para lograr un cambio, es necesario intervenir en las fuerzas opuestas que interactúan en ese proceso.

Resumido, su enfoque se puede simplificar así:

1. Identificar el problema.

2. Definir el objetivo.

3. Identificar las fuerzas que apoyan el cambio hacia el objetivo.

4. Identificar las fuerzas que impiden el cambio hacia el objetivo.

5. Estrategizar una solución, que puede implicar tanto aumentar o fortalecer las fuerzas del paso 3, como reducir o eliminar las fuerzas del paso 4.

La inversión ocurre cuando intervenimos en los pasos 3 o 4, dependiendo de desde qué ángulo abordemos el problema. Aunque parece de sentido común centrarse en las fuerzas que apoyan el cambio, a menudo olvidamos que intervenir en las fuerzas que lo bloquean puede generar un impacto aún mayor.

Vía negativa

La mayor (y más robusta) contribución al saber consiste en eliminar del mismo aquello que creemos que está equivocado: esto es la epistemología sustractiva. — Nassim Nicholas Taleb

El enfoque de evitar lo que no queremos encaja perfectamente con el concepto de la vía negativa que Nassim Nicholas Taleb presenta en Antifrágil. Taleb argumenta que, en muchos casos, es más sencillo y efectivo eliminar lo que no funciona o lo que es perjudicial, en lugar de centrarse en buscar lo que es correcto.

Bajo esta premisa, el conocimiento y la mejora crecen más por sustracción que por adición. Según Taleb, solemos saber más acerca de lo que está mal que de lo que está bien, y eliminar lo incorrecto nos deja en una posición más robusta y segura.

La vía negativa complementa al enfoque de inversión, ya que, al invertir un problema para explorar cómo podríamos empeorarlo, identificamos activamente errores, fallos y obstáculos. Una vez eliminados, estos dejan espacio para que las soluciones emerjan de manera natural.

Escribí más sobre esto en Vía negativa — Mejorando productos por sustracción.

Cómo empeorar

Giorgio Nardone lleva el concepto de la vía negativa un paso más allá con una técnica de inversión que denomina la «técnica del cómo empeorar». Esta estrategia se basa en explorar intencionalmente formas de empeorar una situación, lo que puede revelar caminos que no habíamos considerado.

El proceso comienza con hacernos preguntas clave según el tipo de problema:

• Si enfrentamos una situación disfuncional: «Si quisiera empeorar más la situación en vez de mejorarla, ¿cómo lo haría?».
• Si deseamos mejorar algo que ya funciona: «¿Qué métodos o estrategias, si se adoptaran, garantizarían el fracaso de mi proyecto?».

Luego, intentamos enumerar todas las formas posibles de empeorar la situación. El objetivo es describir cada una de estas de manera que quede claro cómo, en la práctica, el problema podría agravarse en lugar de resolverse.

[…] al obligar a mi mente a tratar de descubrir todas las soluciones fallidas, normalmente hago que esta, por contraste, vaya espontáneamente en busca de soluciones alternativas. Se trata de un proceso para incentivar la creatividad y la inventiva, que se desarrolla como respuesta a la obligación impuesta a la mente de ir en dirección opuesta. Como muchas personas habrán experimentado al menos en alguna ocasión, cuando nos esforzamos por hallar soluciones alternativas de forma voluntaria y racional, la mayoría de veces tenemos muchas dificultades para descubrir vías nuevas no halladas aún y tendemos a reproducir nuestros itinerarios mentales habituales.

En cambio, si forzamos a nuestra razón a buscar métodos para empeorar o para fracasar, hacemos que nuestra racionalidad se oriente en esta dirección y, por tanto, deje de impedir los procesos creativos. De este modo, nuestra mente podrá descubrir alternativas por el hecho de haberse liberado de la trampa paradójica del esfuerzo voluntario, que impide el descubrimiento espontáneo.

Al hacernos preguntas diseñadas para forzar a la mente a tomar una ruta no convencional, nos libera de patrones de pensamiento restrictivos y sesgos.

Premortem

El psicólogo investigador Gary Klein se inspiró en investigaciones que demostraban que la retrospección prospectiva — imaginar que un evento ya ha ocurrido — aumenta la capacidad de identificar correctamente las razones de resultados futuros en un 30%.

A partir de esta base, Klein desarrolló una técnica con un enfoque similar al «premeditatio malorum» estoico, conocida como análisis premortem.

Klein propone una dinámica grupal que se basa en la visualización negativa, anticipando el fracaso de un proyecto antes de que comience. En lugar de preguntar qué podría salir mal, el equipo asume que el proyecto ya ha fracasado y, partiendo de esa premisa, genera todas las razones plausibles de su fracaso.

El ejercicio consta de cuatro pasos:

(1) Divide al equipo en dos grupos:

• Un grupo debe imaginar que el proyecto fue un desastre total.
• El otro grupo debe fingir que el proyecto fue un éxito rotundo.

(2) Generar razones:

• Pide a cada miembro que trabaje de manera independiente.
• Cada persona debe generar razones o, mejor aún, escribir una historia detallada sobre por qué ocurrió el éxito o el fracaso.
• Asegúrate de que sean lo más específicos posible en sus explicaciones.
• Se deben incluir causas que normalmente no mencionarían por miedo a ser descorteses. Shreyas Doshi propone una alternativa interesante que usaban en Stripe para crear un espacio más seguro en este hilo de Twitter.

(3) Presentación:

• Cada persona del grupo del «fracaso» lee su lista o historia en voz alta.
• Repite el proceso con el grupo del «éxito»
• Registra y recopila todas las razones mencionadas.

(4) Análisis final:

• Utiliza las razones de ambos grupos para fortalecer el plan del proyecto.
• Si se descubren obstáculos insalvables, vuelve a la mesa de diseño para ajustar el plan.

Resumiendo

Hemos explorado la inversión como un modelo mental interesante para reestructurar problemas complejos abordándolos desde su opuesto, cuestionando nuestras suposiciones habituales y permitiéndonos explorar soluciones antiintuitivas.

La visualización positiva analiza el futuro desde la perspectiva del éxito y tiende a generar soluciones que impactan externamente, como el contexto o el entorno. Por otro lado, la visualización negativa se enfoca en la perspectiva del fracaso, lo que suele abrir más oportunidades en el ámbito interno del proyecto.

Resumo las estrategias que he introducido:

Visualización positiva: Nos enfocamos en cambiar el contexto hacia un escenario ideal que elimina la complejidad del problema, permitiendo que las soluciones afloren más fácilmente.

• Apelaciones de la indirecta: Basado en el enfoque de Edward Bernays, influimos en el entorno o las circunstancias del problema para que las soluciones se ajusten mejor al contexto, sin enfrentarlo directamente.
• Técnica del escenario más allá del problema: Visualizamos cómo sería el contexto ideal una vez que el problema esté resuelto, lo que nos ayuda a ver oportunidades y enfoques que no serían evidentes si nos limitamos a analizar la situación actual.

Visualización negativa: Nos situamos en el peor escenario posible para aprender cómo prevenir o minimizar las circunstancias negativas. Esta perspectiva nos ayuda a evitar problemas en lugar de centrarnos únicamente en alcanzar el éxito.

• Campo de fuerzas: Identificamos y analizamos las fuerzas que apoyan o impiden el cambio, con el objetivo de reforzar las fuerzas positivas y reducir las negativas para facilitar el logro del objetivo.
• Vía negativa: Eliminamos lo que no funciona o lo que es perjudicial, bajo la premisa de que quitar lo que no sirve nos deja en una situación más robusta que simplemente añadir cosas nuevas.
• Técnica del cómo empeorar: Nos forzamos a imaginar cómo podríamos empeorar activamente una situación. Esto paradójicamente, nos permite liberar nuestra creatividad y descubrir soluciones alternativas que no habríamos considerado inicialmente.
• Premortem: Imaginamos que nuestra solución ha fracasado antes de comenzar. A partir de esa premisa, el equipo genera las razones plausibles del fracaso que ayudan a identificar y mitigar los riesgos.

Libros recomendados

• Problem Solving Estratégico: El arte de encontrar soluciones a problemas irresolubles — Giorgio Nardone
• Antifrágil — Nassim Nicholas Taleb
• The Great Mental Models, Volume 1: General Thinking Concepts — Shane Parrish

Otras lecturas recomendadas

• Edward Bernays: cómo venderte algo que no necesitas
• Inversion: The Crucial Thinking Skill Nobody Ever Taught You — James Clear
• Inversion and The Power of Avoiding Stupidity — Shane Parrish
• Performing a Project Premortem — Gary Klein
• Daniel Kahneman’s Favorite Approach For Making Better Decisions — Shane Parrish
• The preventable problem paradox — hilo en X de @shreyas

Relacionado

• Pensamiento malthusiano y los límites del espacio de las soluciones
• Las fronteras del espacio del problema
• Disolución de problemas

Inversión: disolviendo problemas al revés was originally published in Pensando en Sistemas el Desarrollo de Producto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cuando los problemas son complejos, rara vez existen soluciones triviales o directas. En estos casos, en lugar de intentar resolver el problema original, podemos adoptar una estrategia diferente: «disolver el problema».

Disolver el problema difícil no es lo mismo que resolverlo, ni tampoco significa refutarlo de forma definitiva, pero sí es la mejor vía para realizar progresos en este ámbito, una vía mucho mejor que la de venerar la conciencia como si fuera un misterio mágico o que la de desestimar esta como si no pasara de ser un «no problema» metafísicamente ilusorio. — Anil Seth, La creación del yo

Me crucé con esta analogía mientras leía La creación del yo, uno de los mejores libros que he encontrado sobre la conciencia. Sin pretender entrar en detalles sobre este tema que me fascina pero se sale del alcance de este artículo, el «problema difícil» hace referencia a la dificultad de explicar cómo y por qué tenemos experiencias subjetivas. Seth, en lugar de buscar una respuesta directa, promueve un enfoque en lo que él denomina el «problema real», que se concentra en explicar los procesos mediante los cuales el cerebro genera percepciones conscientes, disolviendo así parte de la complejidad que rodea el debate original.

Otro ejemplo de aplicación de esta idea es el enfoque minimalista que propone Marie Kondo en su libro La magia del orden. En lugar de simplemente reorganizar los objetos, Kondo nos sugiere eliminar el apego emocional a las cosas, lo que permite que el problema del desorden se disuelva por completo, en lugar de simplemente gestionarlo de forma temporal.

Este enfoque resuena con el concepto de «pensamiento lateral» de Edward de Bono, que sugiere que, en lugar de enfrentar un problema directamente, es más efectivo cambiar el marco en el que se plantea el problema.

Disolver un problema puede abordarse desde dos perspectivas: reestructurando o descomponiendo.

Reestructuración

Esta perspectiva consiste en modificar el contexto o las condiciones que generan el problema. En lugar de atacar el problema en su forma actual, se reestructura la situación, preguntándonos: «¿Por qué el problema es un problema?». A veces, al cambiar las circunstancias que lo rodean, el problema se vuelve irrelevante o más manejable.

Por ejemplo, imagina que Netflix está recibiendo quejas sobre el orden en que aparecen las series recomendadas y cómo estas coinciden (o no) con las preferencias de los usuarios. Inicialmente, el problema parece estar en que el algoritmo no funciona como se esperaba. Sin embargo, al preguntarnos «¿Por qué es un problema que no coincidan las preferencias del usuario? ¿Qué es lo que realmente intentan resolver?», podríamos descubrir que el problema es más general: los usuarios no están encontrando contenido relevante.

Esto eleva el problema a un nivel superior, donde aumentar la complejidad del algoritmo es una opción, pero podríamos darnos cuenta de que la verdadera causa está en cómo se organiza la interfaz. Reestructurar el problema nos permite identificar la simplificación de las categorías o personalizar la experiencia de navegación de forma más intuitiva como posibles soluciones que disuelven la necesidad de añadir más complejidad al algoritmo de recomendación.

Este es un ejemplo relativamente trivial, en línea con el enfoque más abstracto que discutí en la entrega anterior:

[…] cuando planteamos una oportunidad en términos como «no se puede hacer X», «no existe X» o «los clientes piden X», es muy probable que «X» no sea más que una posible solución a un problema de mayor envergadura.

Descomposición

Este enfoque implica dividir el problema en partes más pequeñas y manejables. Al analizar cada componente, es posible encontrar soluciones específicas para los subproblemas que, una vez resueltos, pueden disolver la complejidad del problema mayor.

Por ejemplo, imagina que Netflix recibe peticiones de los usuarios para poder consumir contenido mientras viajan. El problema parece ser cómo ofrecer acceso sin interrupciones en diversas situaciones de movilidad. En lugar de abordar el problema como un todo, podríamos descomponerlo en subproblemas: el acceso a contenido mientras se viaja en tren, avión o coche, cada uno con sus propias limitaciones tecnológicas y de conectividad.

Descomponiendo el problema permite desarrollar soluciones específicas, como opciones de descarga para vuelos o áreas de baja conectividad, optimización para redes inestables en coches, o streaming adaptado para trenes con wifi limitado. De esta forma se disuelve el problema en enfoques más manejables.

Ya vimos en la entrega anterior una estrategia que encaja en esta categoría de descomposición: ciclos cortos de implementación de soluciones que retroalimentan la redefinición del problema. Al lanzarnos a implementar soluciones que nos permitan entender mejor la naturaleza del problema, y a través de pequeñas iteraciones, podríamos llegar a disolver tanto la necesidad como la complejidad del problema original.

Ninguna perspectiva es intrínsecamente mejor que la otra; sin embargo, ignorar la posibilidad de disolver un problema reestructurándolo puede hacernos perder oportunidades de generar un impacto mayor, cambiar el contexto o, incluso, modificar paradigmas establecidos — como ya mencioné en la entrega sobre los límites del espacio de la solución.

Dejarlo estar

En las siguientes entregas de esta serie exploraré estrategias de disolución de problemas que son más contraintuitivas, pero hoy para cerrar os dejo con la más sencilla de todas: «dejarlo estar».

Mientras buscaba referencias el término «disolver problemas», me encontré con un pequeño vídeo de autoayuda donde aplican este término a la psicología. El autor propone que los problemas también pueden «dejarse estar» para que se disuelvan solos, cual azucarillo que se disuelve en una taza de café. Disolver, en este contexto, significa apartar el problema y permitir que se desvanezca por sí solo, especialmente cuando la situación está fuera de nuestro control y más acciones podrían ser contraproducentes.

Aunque desconozco qué base científica tiene este enfoque en psicología, en nuestro mundo del desarrollo de producto, es una realidad que los problemas se acumulan en el backlog y después de unos meses, muchos de esos problemas han dejado de ser relevantes. Esto puede ocurrir porque ha cambiado el contexto, el mercado, la funcionalidad o incluso el producto fue eliminado. En algunos casos, avances como la GenIA han habilitado formas completamente nuevas de abordar problemas que antes parecían irresolubles, haciendo que desaparezcan por completo.

Resumiendo

El enfoque de disolución de problemas se basa en cambiar las condiciones o el marco que originan el problema en lugar de enfrentarlo directamente. En lugar de intentar resolver directamente el problema de máxima complejidad, buscamos modificar el contexto o descomponer el problema en partes más pequeñas para que, en muchos casos, el problema original se vuelva irrelevante o se disuelva por completo.

Como ya he comentado antes, en la próxima entrega de esta serie veremos otras estrategias de disolución de problemas.

Relacionado

• Pensamiento malthusiano y los límites del espacio de las soluciones
• Las fronteras del espacio del problema

Disolución de problemas was originally published in Pensando en Sistemas el Desarrollo de Producto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Llevo algunas entregas abordando el «espacio del problema» y cómo adoptar esta perspectiva nos puede conducir a soluciones más efectivas y, a menudo, más sencillas, que realmente respondan a necesidades genuinas.

Antes de llegar a una solución, es crucial entender si lo que percibimos como problema es una manifestación superficial o un síntoma de un desafío mayor. Sólo cuando vemos más allá de los síntomas, podemos empezar a identificar oportunidades de intervención más efectivas.

Las fronteras entre el espacio del problema y la solución a veces pueden ser ambiguas. Un ejemplo reciente que discutimos en el equipo fue la afirmación: «El producto A no tiene una API». ¿Es esto una oportunidad dentro del espacio del problema o una solución concreta a una necesidad de orden superior?

Como es habitual, depende del contexto. Como organización, es posible que ya hayas identificado que disponer de una API es una ventaja competitiva, alineada con tu estrategia de interoperabilidad dentro del ecosistema de productos del sector. En este caso, la ausencia de una API es claramente un problema a resolver.

No obstante, si este no fuera el escenario, quizás estés respondiendo a una serie de necesidades específicas de tus clientes para interoperar con tu producto. En tal caso, una API podría ser solo una de varias soluciones posibles. Otras alternativas podrían incluir la capacidad de exportar a formatos estándar de la industria, integrar tu producto directamente con las API de otros productos en el ecosistema, crear guías de integración detalladas, o incluso formar equipos dedicados a desarrollar integraciones personalizadas. Cada opción tiene su propio grado de complejidad, ventajas y desventajas.

Generalmente, cuando planteamos una oportunidad en términos como «no se puede hacer X», «no existe X» o «los clientes piden X», es muy probable que «X» no sea más que una posible solución a un problema de mayor envergadura. Sin embargo, esto no implica que lo que realmente necesitan los usuarios sea precisamente «X». Es probable que «X» sea la única solución que parece viable en el contexto actual, lo que genera esa necesidad. Si el contexto cambia, es posible que «X» deje de tener sentido o incluso de ser necesario.

El contexto no es solo el entorno externo o el mercado, sino también la visión estratégica de la organización, las capacidades técnicas, los recursos disponibles, y, sobre todo, las verdaderas necesidades del cliente. Todos estos factores en conjunto permiten que una solución sea relevante o no.

[…] muy a menudo cuando nos hallamos frente a un problema tendemos a buscar la explicación más que la solución. La trampa es que la solución no tiene necesidad de la explicación previa del problema, sino que será la solución lo que conducirá al descubrimiento del modo de funcionamiento del problema. Las explicaciones que no están probadas empíricamente son engañosas y están basadas en nuestro conocimiento a priori. Como nos indica Cioran: «Todo problema profana un misterio y es a su vez profanado por su solución». En otras palabras: son las soluciones las que explican los problemas y no al revés.

En su obra Problem Solving Estratégico, Giorgio Nardone nos alerta sobre el riesgo de quedarnos demasiado tiempo en el análisis del problema. Es importante abordar la planificación — como los opportunity trees, OKRs o roadmaps — como un proceso iterativo y continuo. Al tratar estas ceremonias como eventos únicos o definitivos, nos arriesgamos a buscar una precisión imposible y a quedarnos en parálisis por análisis.

Sea cual sea la metodología para establecer la hoja de ruta de tu organización o equipo, lo único constante debe ser que se aborde como un proceso continuo e iterativo, con ciclos lo más cortos posible y lazos de retroalimentación que permitan redefinir lo necesario y abortar lo que vaya en la dirección equivocada.

La eficacia de una solución, si es reproducible y predecible, nos permite conocer con precisión el problema que ha resuelto. Se supera la idea racionalista de conocer para cambiar, y se llega inevitablemente a la idea de cambiar para conocer. Ya no son las explicaciones de los fenómenos las que conducen a las soluciones, sino que son las soluciones que funcionan las que nos conducen a las explicaciones. Como nos indica Heinz von Foerster con su «imperativo estético», «si quieres ver, aprende a actuar».

Debemos encontrar un equilibrio entre el espacio del problema y el de la solución, ya que ambos se retroalimentan: el análisis del problema guía hacia posibles soluciones, y a su vez, la implementación de soluciones redefine y clarifica la verdadera naturaleza del problema.

En las próximas entregas exploraré diversas estrategias para abordar la resolución de problemas complejos, intentando ofrecer un enfoque más práctico.

Las fronteras del espacio del problema was originally published in Pensando en Sistemas el Desarrollo de Producto on Medium, where people are continuing the conversation by highlighting and responding to this story.

En la era de la toma de decisiones basada en datos, es cada vez más común utilizar información cuantitativa para guiar el desarrollo de productos. Sin embargo, aunque es tentador creer que más datos siempre conducirán a mejores decisiones, el análisis cuantitativo tiene sus limitaciones si no se comprende adecuadamente el contexto de los datos y no estamos alerta los sesgos típicos de la naturaleza humana.

Hace unas semanas escribí sobre los límites del espacio de la solución y cómo ejercicios como el opportunity mapping pueden ayudar a encontrar soluciones que realmente resuelvan los problemas de nuestros usuarios. Para que un ejercicio como este sea efectivo, es fundamental abordarlo con una mentalidad abierta y libre de ideas preconcebidas. Si ya llegamos con una solución en mente, no importa cuántos datos consultemos, siempre encontraremos las correlaciones necesarias para justificar la prioridad de nuestra solución favorita que requiere usar Kubernetes e IA.

Entonces, ¿usamos los datos para informar nuestras decisiones o para justificarlas a posteriori?

Démosle un repaso a algunos sesgos y malas prácticas a la hora de analizar datos para informar decisiones.

Tortuta de datos

¿Puedes creer que el número de avistamientos de ovnis en Missouri casi se correlaciona perfectamente con el consumo de petróleo en Kuwait? ¿Casualidad? ¿O es que los ovnis abastecen sus naves con el abundante petróleo de Kuwait antes de despegar?

Otro ejemplo curioso: hay una fuerte correlación entre los accidentes de avión y las búsquedas en Google de «cómo curar una resaca» ¿Coinciden estos accidentes aéreos con la tendencia en el consumo de alcohol? ¿Se caen los aviones porque se consume más alcohol o se consume más alcohol porque se caen más aviones?

Puedes encontrar miles de ejemplos de correlaciones interesantes como estos en la web de Tyler Vigen. Tyler explica cómo se pueden identificar estas correlaciones engañosas en grandes conjuntos de datos al realizar un «data dredging» o minería de datos sin una hipótesis previa:

Data dredging (dragado de datos): Tengo 25,237 variables en mi base de datos y comparo todas entre sí para encontrar coincidencias al azar, lo que implica 636,906,169 cálculos de correlación. Esto se llama «data dredging» y es un enfoque peligroso, ya que cualquier conjunto de datos lo suficientemente grande producirá correlaciones fuertes completamente al azar.

Falta de conexión causal: Es probable que no haya una conexión directa entre estas variables, a pesar de lo que pueda parecer. Esto se complica porque usé «Años» como la variable base, y muchas cosas ocurren en un año que no están relacionadas entre sí. La mayoría de los estudios usarían «una persona» en lugar de «un año» como la entidad estudiada.

Observaciones no independientes: En muchas variables, los años secuenciales no son independientes entre sí. Si una población de personas está haciendo algo continuamente todos los días, no es probable que cambien de repente el 1 de enero. Un cálculo simple de valor p no considera esto, por lo que matemáticamente parece menos probable de lo que realmente es.

Valores atípicos extravagantes: Hay «valores atípicos» o «outliers» en estos datos que destacan en el diagrama de dispersión. Intencionalmente manejé mal estos valores atípicos, lo que hace que la correlación parezca mucho más fuerte de lo que realmente es.

Ponte en el lugar de un producto como Netflix, que maneja un gran volumen de datos sobre los hábitos de visualización de millones de usuarios, es fácil que el equipo de producto, consciente o inconscientemente, busque justificar decisiones ya tomadas. Supongamos que tras un rediseño notan un cambio en la tendencia de consumo; podrían atribuirlo directamente a la reorganización de las categorías de contenido, sin considerar otros factores como el lanzamiento de una serie popular o cambios estacionales en el comportamiento de los usuarios.

Efecto de mirar en otra parte

Cuando se examina un gran conjunto de datos sin una hipótesis específica, aumenta la probabilidad de obtener falsos positivos. Sin una hipótesis clara antes de realizar el análisis de datos, corremos el riesgo de encontrar resultados espurios, un fenómeno también conocido como el «efecto de mirar en otra parte».

El matemático George Spencer-Brown, escribió que en una serie aleatoria de 10¹M ceros y unos deberías esperar al menos 10 subsecuencias no coincidentes de un millón de ceros consecutivos. De ahí que cuando los datos son abundantes, si buscas un patrón, es muy probable que lo encuentres. Como por ejemplo la imagen de la luna que al hacer zoom reveló la presencia de un rostro.

O el rostro capturado en la superficie de Marte por la misión Viking 1 en 1976.

Imagina que eres Amazon, con millones de transacciones diarias en su marketplace, y te pones a analizar datos sin una hipótesis concreta. Podrías encontrar una correlación entre la venta de ciertos productos en un día particular y otros eventos no relacionados, como un cambio en el clima o una campaña publicitaria en otro país.

Recordaréis el caso del aumento de comentarios negativos de las velas perfumadas durante la pandemia del COVID-19.

Sin una hipótesis clara, podrías malinterpretar estos patrones como señales de que deberías ajustar tu estrategia de marketing o inventario, cuando en realidad se trata de coincidencias sin relevancia para tu negocio.

Sesgo de confirmación

Estos son ejemplos del «sesgo de confirmación», la tendencia a favorecer, buscar, interpretar y recordar la información que confirma las propias creencias o hipótesis. Caemos en este sesgo cuando recordamos información de manera selectiva, o cuando la interpretamos sesgadamente como los ejemplos anteriores.

Hoy en día puedes encontrar estudios que parecen confirmar casi cualquier afirmación. ¿Hacen 45ºC en Córdoba, te gusta la cerveza pero no quieres sentirte culpable? Aquí tienes el titular perfecto: «La cerveza es mejor que el agua para la salud».

Este efecto es más fuerte cuando hay creencias firmemente enraizadas, como cuando vamos a un «opportunity mapping» enamorado de la solución que teníamos prevista y ya hemos visto que es relativamente sencillo justificar prácticamente cualquier cosa con un «análisis a posteriori».

Si torturas lo suficiente a tus datos, éstos te confesarán lo que quieras

— Ronald H. Coase (Premio Nobel de Economía, 1991)

Esto puede llevar a tomar decisiones de producto erróneas, basadas en patrones espurios, que resulten en inversiones en funcionalidades o mercados equivocados.

Correlación no implica causalidad y la regresión a la media

Los estudios científicos están plagados de errores como los que provoca Tyler en sus correlaciones. Aún aquellos realizados con el mayor rigor, pueden ser fácilmente sacados de contexto.

La falacia lógica de confundir correlación con causalidad ocurre cuando interpretamos erróneamente que una correlación (cuando dos variables se mueven juntas o están relacionadas) implica que una variable causa la otra. En otras palabras, vemos que dos cosas suceden al mismo tiempo o en paralelo, y asumimos incorrectamente que una es la causa de la otra, cuando en realidad pueden no estar relacionadas de manera causal.

Si a esto le sumamos nuestra tendencia a ignorar la «regresión a la media», los problemas se multiplican. Cuando una variable muestra un valor extremo (muy alto o muy bajo) en una medición, es probable que en futuras mediciones ese valor se acerque al promedio de la población.

Daniel Kahneman nos ofrece un buen ejemplo en Thinking, Fast and Slow de lo sencillo que es ignorar la regresión a la media:

Niños deprimidos tratados con una bebida energética mejoraron durante un período de tres meses.

Este titular de periódico me lo he inventado, pero el hecho del que informa es cierto: si durante un tiempo tratamos a un grupo de niños deprimidos con una bebida energética, mostrarán una mejora clínicamente significativa. También ocurre que los niños deprimidos que pasan algún tiempo haciendo el pino o abrazando a un gato durante veinte minutos al día mostrarán asimismo una mejora. La mayoría de los lectores de esta clase de titulares automáticamente deducirán que la bebida energética o abrazar a un gato producen una mejora, pero esta conclusión está totalmente injustificada. Los niños deprimidos constituyen un grupo extremo, pues están más deprimidos que la mayoría de los niños, y los grupos extremos regresan a la media con el tiempo. La correlación entre niveles de depresión y ocasiones sucesivas de prueba es menos que perfecta, y por eso habrá regresión a la media: los niños deprimidos estarán algo mejor con el tiempo incluso si no abrazan a los gatos ni toman Red Bull.

Para concluir que una bebida energética — o cualquier otro tratamiento — es efectivo, hemos de comparar un grupo de pacientes que reciben ese tratamiento con un «grupo de control» que no reciba tratamiento alguno (o, mejor, que reciba un placebo). Se espera que el grupo de control mejore solo por regresión, y la finalidad del experimento es determinar si los pacientes tratados mejoran más de lo que la regresión pueda explicar.

En ocasiones, las métricas proxy se eligen como indicadores de los outcomes de producto con la esperanza de que correlacionen con los objetivos de negocio finales. Por ejemplo, podrías utilizar el tiempo de uso de una aplicación como métrica proxy para la satisfacción del cliente. Sin embargo, si asumes que un mayor tiempo de uso causa una mayor satisfacción sin validar esta relación, podrías estar ignorando que otros factores, como la usabilidad o la calidad del contenido, son los que realmente impulsan la satisfacción del cliente, de ahí que sea crucial validar si existe una relación causal y no simplemente confiar en la correlación.

Además, debemos considerar los tiempos de reacción del entorno de tu producto. Tomar decisiones de manera apresurada, sin dar suficiente tiempo para observar los efectos, puede llevar a ignorar la regresión a la media y a malinterpretar los resultados. En Desarrollar productos, tan complejo como ducharse en el gym, discutí los peligros de no tener en cuenta los retrasos en los sistemas, lo que puede resultar en el «bandazo driven development».

Ley de los pequeños números

En entornos B2B, donde la base de usuarios es relativamente pequeña, es muy difícil demostrar que una correlación implique causalidad o evitar caer en la ignorancia de la regresión a la media.

Esto se debe a la «ley de los pequeños números», que describe la tendencia común a sobrestimar la representatividad de una muestra pequeña de datos. Este sesgo, popularizado por Kahneman, puede llevar a conclusiones incorrectas, ya que en muestras pequeñas es más probable que ocurran variaciones o anomalías que no serían tan comunes en una muestra más grande y representativa.

Por ejemplo, un pequeño grupo de usuarios que utiliza intensivamente una nueva funcionalidad puede hacer que parezca más popular de lo que realmente es.

Para evitar tomar decisiones basadas en datos no representativos, es fundamental complementar el análisis cuantitativo con técnicas de investigación cualitativa, como entrevistas en profundidad y prácticas como el continuous discovery. Estos enfoques permiten entender mejor las motivaciones y necesidades de los usuarios y mitigar el riesgo de tomar decisiones basadas en datos sesgados.

Heurístico de disponibilidad

El «heurístico de disponibilidad» es un atajo mental que usamos para tomar decisiones o hacer juicios basados en la facilidad con la que podemos recordar ejemplos o información relevante. En lugar de analizar toda la información disponible de manera objetiva, nuestras mentes tienden a darle más peso a la información que es más reciente, vívida o memorable, porque es más «disponible» en nuestra memoria.

Según Kahneman las «predicciones intuitivas» a menudo se basan en la disponibilidad de ejemplos recientes o llamativos, la representatividad (donde la gente juzga la probabilidad de un evento en función de qué tan similar es a otros casos conocidos), o el exceso de confianza en la exactitud de la propia intuición.

Es aquí donde una buena disciplina de análisis de datos nos puede ayudar, de lo contrario es fácil que nos enfoquemos demasiado en los ejemplos recientes o en las quejas más vocales de los usuarios. Esto puede llevar a priorizar problemas que son llamativos pero no representativos, desviando la atención de problemas más críticos que podrían estar afectando a una parte más amplia de la base de usuarios.

Aunque estas predicciones intuitivas pueden ser útiles en situaciones cotidianas, pueden ser engañosas en contextos más complejos o cuando se requiere una evaluación precisa y objetiva.

Sesgo de supervivencia

Al analizar los datos de usuarios activos, corremos el riesgo de ignorar los comportamientos de aquellos que abandonaron la plataforma. Por ejemplo, al interpretar datos de uso de una nueva funcionalidad, es fácil pasar por alto a los usuarios que dejaron de utilizar el producto, lo que podría llevar a una interpretación sesgada sobre el éxito de dicha funcionalidad.

El «sesgo de supervivencia» ocurre cuando se da más importancia a los datos de los “sobrevivientes” de un proceso, ignorando a aquellos que no lo hicieron. Es una forma de «sesgo de selección» que puede llevarnos a manipular los datos de manera que confirmen nuestras expectativas, otro tipo de tortura de datos.

En culturas donde se celebra únicamente la épica y el éxito, y apenas se presta atención a la oportunidad de aprender de los fracasos, es más fácil olvidar los escenarios fallidos al plantear nuevas soluciones. Esta falta de consideración puede resultar en decisiones mal informadas que no reflejan las realidades completas del producto y su mercado.

Falacia narrativa

En El cisne negro, Nassim Taleb introdujo el concepto de «falacia narrativa» para describir cómo las historias cuestionables sobre el pasado moldean nuestras percepciones del mundo y nuestras expectativas para el futuro. Estas falacias surgen inevitablemente de nuestro constante esfuerzo por darle sentido a la realidad. Las historias que la gente considera persuasivas tienden a ser simples, concretas y a atribuir mayor importancia al talento, la estupidez o las intenciones, en lugar de al azar. Además, se enfocan en unos pocos eventos llamativos que ocurrieron, ignorando muchas otras cosas que no sucedieron. Cualquier acontecimiento reciente y notable puede convertirse en el eje de una explicación causal, influenciado por el «heurístico de disponibilidad». Taleb sugiere que los seres humanos nos engañamos a menudo al construir narrativas frágiles sobre el pasado que asumimos como verdaderas.

La «falacia narrativa» también puede estar influenciada por el «sesgo de supervivencia», donde se destacan los casos de éxito, mientras se ignoran los fracasos o eventos menos visibles. Esto refuerza una visión distorsionada de la realidad que puede llevarnos a crear explicaciones convincentes pero incorrectas sobre por qué un producto tuvo éxito o fracasó, basándonos en anécdotas o en eventos recientes. Estas narrativas simplificadas pueden influir en decisiones futuras, centrándose en factores incorrectos y repitiendo errores pasados. Para evitar esto, es importante combinar las narrativas con un análisis de datos riguroso. Análisis de causa raíz profundos, utilizando prácticas como el slow thinking con el modelo del iceberg, pueden ser mucho más efectivos.

Conclusiones

Cuanto más informadas sean nuestras decisiones, menos bandazos daremos. Esta es solo una pequeña muestra de los sesgos en los que podemos caer al tratar con datos. Con este breve repaso, he intentado resaltar la importancia de ser muy cuidadosos con los análisis cuantitativos. Las personas con perfiles de ingeniería tendemos a ser muy analíticas y apasionadas por los números, pero no debemos perder de vista a los actores de nuestro producto. Es esencial empatizar con sus necesidades y combinar los datos con un análisis cualitativo riguroso.

Como hemos visto, existen peligros en ambos extremos: tanto en manejar una gran cantidad de datos, como ocurre en Amazon, donde se puede encontrar prácticamente cualquier patrón a posteriori, como en trabajar con una muestra pequeña de clientes, donde establecer hipótesis conlleva el riesgo de confundir el azar con causalidad.

Enfoques como continuous discovery y desarrollo lean que permitan ciclos cortos de iteración son herramientas esenciales para experimentar en entornos de alta incertidumbre.

Finalmente, quiero defender el valor de la intuición. No todas las organizaciones cuentan con una cultura «data-driven» bien establecida. En esos casos, pretender que los datos te darán todas las respuestas, ignorando la intuición y la experiencia de quienes mejor entienden el mercado dentro de la organización, puede ser un grave error. La clave está en encontrar un equilibrio entre los datos y la intuición para tomar decisiones de producto más acertadas.

Lecturas recomendadas

• El andar del borracho: Cómo el azar gobierna nuestras vidas — Leonard Mlodinow
• Pensar rápido, pensar despacio — Daniel Kahneman
• The Great Mental Models, Volume 1: General Thinking Concepts — Shane Parrish
• The Great Mental Models, Volume 3: Systems and Mathematics — Shane Parrish
• Por qué creemos en mierdas: Cómo nos engañamos a nosotros mismos — Ramón Nogueras
• El cisne negro: El impacto de lo altamente improbable — Nassim Nicholas Taleb
• La realidad no existe: Cómo entender el mundo cuando entiendes que no entiendes nada — Jaime Rodríguez de Santiago
• Empathy-Driven Development: How Engineers Can Tap into This Critical Skill — Andrea Goulet
• Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value — Teresa Torres
• Racionalidad: Qué es, por qué escasea y cómo promoverla — Steven Pinker
• Spurious patterns and where to find them — Complexity Thoughts

Las trampas del análisis cuantitativo was originally published in Pensando en Sistemas el Desarrollo de Producto on Medium, where people are continuing the conversation by highlighting and responding to this story.