Systems Thinking Radar es un formato más ligero donde poder compartir notas más en crudo sobre el contenido que voy consumiendo, a la vez que me permita revisitar algunos conceptos ya tratados, pero en un formato más resumido.

🔄 Un bucle

El círculo virtuoso de la documentación

Luca Rossi y su comunidad de Refactoring.fm son grandes pensadores sistémicos, por lo que preveo que aparecerán en muchas ediciones de este radar. En la última sesión de mastermind de la comunidad, surgió el tema de los engineering handbooks y cómo la documentación tiende a crear ciclos de refuerzo continuo, ya sean positivos o negativos.

Cuando un equipo pierde el hábito de documentar, la información se vuelve rápidamente obsoleta, lo cual reduce la confianza en la documentación. Al desvanecerse esta confianza, el uso de la documentación disminuye, y eso, a su vez, desincentiva aún más el esfuerzo de mantenerla actualizada, atrapándonos en un círculo vicioso de desactualización y desuso.

En su ensayo de esta semana (de pago), Rossi ofrece una guía detallada sobre cómo crear un Engineering Handbook donde presenta principios clave para romper el círculo vicioso que afecta a la documentación de los equipos de ingeniería. Todos estos principios se orientan a «encender la llama de la documentación» y facilitar el giro hacia un ciclo de auto-refuerzo positivo.

Para ello, propone que la documentación sea reusable, creando notas pequeñas y cohesivas que aborden un único concepto y se enlacen con otras notas relacionadas; descubrible, facilitando que el contenido sea fácil de encontrar; y contextual, organizando la información en función de su utilidad y el contexto en el que se usará.

Si logramos que la documentación que creamos sea útil y accesible, incentivaremos su uso, lo cual, a su vez, motivará a mantenerla actualizada, cerrando un ciclo virtuoso que aumente la confianza en su vigencia y promueva su uso constante.

🧠 Un modelo mental

El cubo

Como programador mi cerebro cortocircuita cada vez que menciono conceptos que no he tratado, quizás como reflejo de un trauma de los errores de compilación en la era sin linters. Así que la semana pasada escribí una brevísima introducción a las piezas clave de la dinámica de sistemas. Si estos conceptos son nuevos para ti, puedes consultarlos en este artículo.

En dinámica de sistemas, una reserva puede cambiar su estado tanto por el flujo de entrada (incrementándolo o reduciéndolo) como por el de salida. Aunque parece trivial, muchas veces lo pasamos por alto. Por ejemplo, al ver un coche en movimiento, solemos pensar en el acelerador, sin considerar que, en una pendiente, el conductor probablemente también esté usando el freno.

También solemos olvidar que podemos cambiar la estructura del sistema, como por ejemplo aumentar la capacidad de la reserva.

En una entrevista en Radio Fitness Revolucionario con Carlos Cenalmor, Marcos Vasquez usa la analogía de un cubo de agua para explicar la carga alostática o acumulación de estresores en la vida.

Burnout o Estrés Laboral, con Carlos Cenalmor (Ep. 417) Marcos Vázquez Episode

Imagina un cubo que se llena con factores de estrés (como falta de sueño o problemas laborales). Cada persona tiene un tamaño de cubo distinto, y algunas actividades, como el ejercicio o el descanso, funcionan como «agujeros» que liberan parte de la carga acumulada. Para evitar que el cubo rebose, podemos reducir los estresores, aumentar la capacidad del cubo, o añadir más «agujeros» con actividades que alivien la tensión.

Esta misma lógica aplica en los equipos de producto: cuando no logran los resultados esperados, la primera reacción suele ser añadir más personas, desarrollar más funcionalidades, o aumentar el trabajo, en vez de identificar y reducir el desperdicio, como propone el desarrollo lean.

La próxima vez que necesites intervenir en un sistema, recuerda que hay más opciones más allá de incrementar los flujos de entrada.

📖 Una cita

—¿Qué libro es ese tan grande? —preguntó a su vez el principito—. ¿Qué hace usted aquí?

—Soy geógrafo —dijo el anciano.

—¿Y qué es un geógrafo?

—Es un sabio que sabe dónde están los mares, los ríos, las ciudades, las montañas y los desiertos.

—Eso es muy interesante —dijo el principito—. ¡Y es un verdadero oficio!

Dirigió una mirada a su alrededor sobre el planeta del geógrafo; nunca había visto un planeta tan majestuoso.

—Es muy hermoso su planeta. ¿Hay océanos aquí?

—No puedo saberlo —dijo el geógrafo.

—¡Ah! —el principito se sintió decepcionado—. ¿Y montañas?

—No puedo saberlo —repitió el geógrafo.

—¿Y ciudades, ríos y desiertos?

—Tampoco puedo saberlo.

—¡Pero usted es geógrafo!

—Exactamente —dijo el geógrafo—, pero no soy explorador, ni tengo exploradores que me informen. El geógrafo no puede estar de acá para allá contando las ciudades, los ríos, las montañas, los océanos y los desiertos; es demasiado importante para deambular por ahí. Se queda en su despacho y allí recibe a los exploradores. Les interroga y toma nota de sus informes. Si los informes de alguno de ellos le parecen interesantes, manda hacer una investigación sobre la moralidad del explorador.

— Antoine de Saint-Exupéry. El Principito

Mientras leía por enésima vez este capítulo de El Principito a mi hijo, no pude evitar pensar en los muchos «smells» de geógrafos y exploradores de los que he intentado huir en mis equipos de producto.

Equipos de frontend y backend, cada uno con su propio backlog, creando silos innecesarios; arquitectos que entregan diagramas a los programadores sin involucrarse en su implementación; product managers que solo dictan soluciones sin abrir el espacio para el descubrimiento y comprensión del problema; y equipos de producto que tratan la infraestructura como una caja negra, sin comprender su impacto en el sistema.

También pienso en QA testers que solo se integran al final del desarrollo para «atrapar errores»; diseñadores que entregan maquetas finales sin iterar con el equipo de desarrollo; y equipos de DevOps que se limitan a «mantener las luces encendidas» sin colaborar activamente en la optimización de la infraestructura junto a los desarrolladores. Y como no, líderes de equipo que centralizan toda la toma de decisiones técnicas sin consultar a los desarrolladores, limitando así la innovación y la colaboración.

Estos «smells» violan dos principios fundamentales de la Teoría de las Restricciones (Theory of Constraints o TOC) desarrollada por Eliyahu M. Goldratt: mejorar el rendimiento global del sistema y enfocarse en la «meta» del sistema. La TOC propone que optimizar partes individuales sin considerar la totalidad y el objetivo del sistema genera ineficiencias y desperdicio, desviando los esfuerzos del equipo y reduciendo su impacto en el valor real.

Aunque me inclino hacia la creación de equipos de generalistas, reconozco que los especialistas tienen un papel crucial cuando se trata de innovar en su área de expertise. Sin embargo, para que realmente contribuyan al equipo, los especialistas necesitan una mentalidad T-shaped: deben contar con un enfoque profundo en su especialidad, pero también con habilidades transversales que les permitan colaborar eficazmente con otras áreas y adaptarse sin problema cuando el trabajo más urgente para el equipo no sea el de su especialidad.

Yo suelo decir «si traer café al que está picando código es lo que más puede contribuir al objetivo del equipo, entonces ese es el trabajo más importante que puedo hacer en ese momento».

Si te encuentras en un equipo donde se rellenan los backlogs solo para mantener a un especialista entretenido o «bien aprovechado», ese equipo ha perdido el enfoque en su verdadera meta.

Lecturas relacionadas

• La Meta — Eliyahu M. Goldratt

• Amplitud (Range): Por qué los generalistas triunfan en un mundo especializado — David Epstein

• The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations — Gene Kim, Patrick Debois, John Willis, Jez Humble

• The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win — Gene Kim, Kevin Behr, George Spafford

• Interesante paralelismo entre «code smells» y disfunciones en organizaciones «corp smells» propuesto por Emmanuel Valverde en este hilo en Twitter.

Ralentizar, simplificar y amplificar para ganar Alfredo Artiles · Jun 7 Read full story

Esto es todo por hoy. Si te gusta este nuevo formato, házmelo saber, así como cualquier sugerencia sobre otra categoría de píldoras que sería interesante añadir.