Pensamiento de Sistemas

Un sistema es más que una colección de partes. Son las partes más sus interacciones. Y a menudo, las interacciones importan más que las partes mismas.

Considera un equipo de software. Tienes desarrolladores, diseñadores, ingenieros de QA, un gerente de producto. Cada individuo puede ser excelente. Pero si no se comunican bien, si las transferencias son torpes, si los incentivos están desalineados—el equipo tiene un rendimiento inferior a pesar del talento.

El pensamiento de sistemas significa entender el sistema completo antes de intentar mejorar las partes. Significa preguntar: ¿Cómo interactúan las piezas? ¿Qué ciclos de retroalimentación existen? ¿Qué comportamientos emergentes surgen?

La mayoría de las disfunciones organizacionales provienen de ignorar el pensamiento de sistemas. Cada departamento optimiza sus propias métricas mientras el resultado general sufre. Ventas cierra tratos que el producto no puede entregar. Ingeniería construye funciones que marketing no puede vender. Todos alcanzan sus KPIs mientras la empresa lucha.

Aquí hay un escenario común: El equipo de desarrollo es el cuello de botella. Entonces la gerencia decide hacer a los desarrolladores más eficientes. Rastrean puntos de historia, miden la velocidad, reducen reuniones. La productividad del desarrollador aumenta.

Pero la entrega no mejora. ¿Por qué?

Porque el cuello de botella nunca estuvo realmente en el desarrollo. Estaba en el despliegue—un proceso manual propenso a errores que solo una persona entendía. Al acelerar el desarrollo, solo creaste un embotellamiento más grande en el despliegue. El tiempo de entrega aumentó aunque los desarrolladores trabajaron más rápido.

La optimización local mejora una parte del sistema. La optimización global mejora el sistema completo. No son lo mismo—y la optimización local a menudo perjudica el rendimiento global.

Esta es la perspectiva de Goldratt de la Teoría de Restricciones: mejorar cualquier cosa que no sea la restricción es desperdicio. Si el despliegue es tu restricción, hacer el desarrollo más rápido es teatro. Arregla el despliegue primero.

En organizaciones de software, optimizaciones locales comunes que perjudican globalmente:

• Maximizar la utilización del desarrollador (destruye el margen, aumenta los tiempos de espera)
• Medir la velocidad individual (incentiva el juego, perjudica la colaboración)
• Optimizar el tiempo de compilación (irrelevante si los despliegues solo ocurren mensualmente)

Los sistemas contienen ciclos de retroalimentación—la salida de una parte se convierte en entrada de otra. Algunos ciclos son de refuerzo (amplificación), otros son de equilibrio (estabilización).

Ejemplo de ciclo de refuerzo: Los desarrolladores toman atajos para cumplir plazos. Esto crea deuda técnica. La deuda técnica ralentiza el desarrollo futuro. Los equipos toman más atajos para cumplir el siguiente plazo. La espiral de muerte se acelera.

Ejemplo de ciclo de equilibrio: Un equipo adopta límites de WIP. El trabajo se acumula. Las personas se agrupan para ayudar a despejar la acumulación. El WIP disminuye. El sistema se autoestabiliza.

El comportamiento emergente es un comportamiento a nivel de sistema que no puede predecirse solo a partir de las partes. Un embotellamiento de tráfico no es causado por ningún auto individual—emerge de miles de pequeñas interacciones. De manera similar, una organización disfuncional puede tener todos individuos excelentes pero el sistema produce disfunción.

El pensamiento Lean requiere dar un paso atrás para ver estos patrones. No puedes arreglar una espiral de muerte de refuerzo capacitando individuos. Tienes que cambiar la dinámica del sistema—usualmente cambiando incentivos, restricciones o mecanismos de retroalimentación.