En ocasiones trabajo con clientes que tienen un problema importante para entregar en los plazos y calidad acordadas. Cuando empiezo a investigar las causas me encuentro que cuando hablo con el equipo de producto dicen que el problema es que ingeniería no es suficientemente rápido y/o producen demasiados defectos, y cuando hablo con ingeniería me dicen que les llegan especificaciones incompletas desde producto, lo cual hace que tengan que emplear más tiempo en desarrollar, y que a veces tengan que deshacer cambios porque no eran lo que el cliente quería. Es común que estás organizaciones se vean como un conjunto de silos, y crean que la solución pasa por “arreglar” uno de esos silos (p.ej: ingeniería). Pero esta es una visión reduccionista del problema, y que pocas veces ayuda a solucionarlo. Para tratar el problema de raíz se necesita re-pensar como entendemos la organización, y es aquí donde el Systems thinking nos puede ayudar. Como decía Einstein: “No podemos resolver problemas pensand o de la misma manera que cuando los creamos”.
Hace un par de años cayó en mis manos el libro de Team Topologies (de Mathew Skelton y Manuel Pais), en el que se habla de las organizaciones como sistemas de software. El libro introduce la ley de Conway, que reza que las organizaciones producen sistemas que imitan sus estructuras de comunicación. Ejemplos de esta ley en práctica, los podemos ver cuando separamos un equipo que trabajaba en un mismo componente o microservicio, lo común es que este componente se acabe dividiendo, puesto que la estructura de comunicación entre los equipos se parte, haciendo más complicada la colaboración cercana que requiere trabajar en un mismo componente. El libro habla de la maniobra inversa de Conway, que nos invita a que diseñemos nuestra organización de acuerdo a la arquitectura que deseamos obtener. Esto desafía muchas de las decisiones organizativas que se toman en las empresas, donde la arquitectura no se tiene en cuenta o tiene un papel secundario a la hora de diseñar la organización. Y nos invita a pensar en las personas y el software, que estas producen, como partes de un mismo sistema.
Las empresas son sistemas, sin embargo, en multitud de ocasiones no se ven como tal. Y aunque no seamos conscientes del sistema que conforma nuestra organización, ese sistema es real y está ahí. En ocasiones la única representación visual del sistema de una empresa, es un organigrama tradicional, sin embargo esta es una visión muy limitada, que solo recoge las personas, equipos y las líneas de reporte. No refleja ni el flujo de la información, ni las conexiones dinámicas, ni la cultura, ni las relaciones reales y complejas que se producen a lo largo del organigrama.
Linealidad y no linealidad
Estamos acostumbrados a pensar de forma lineal: si X entonces Y. Sin embargo, los sistemas no se pueden entender de esta forma. El número de componentes y relaciones entre ellos, crece de forma exponencial, y los sistemas se convierten en no lineales. Continuamente tengo conversaciones en las que se intentan abordar los problemas de forma demasiado simplificada. Ej: hablando con un manager hace unos meses sobre la necesidad de invertir en actualizar su infraestructura cloud, Él me preguntaba cual era el ROI esperado, en términos de cuántas horas por semana iba a ahorrarse cada desarrollador con respecto al coste de actualizar la infraestructura. Queria saber esto de cara a sabes si aprobaba la inversión o no. Si bien podemos estimar el ahorro en horas de desarrollador, calcular el ROI de ese modo y tomar una decisión de go o no-go, deja fuera muchos otros aspectos importantes. Si pensamos en sistemas y trabajamos en identificar las implicaciones de tener una infraestructura desactualizada, se abren nuevas perspectivas donde podemos ver que esto no solo nos afecta a la productividad, sino que también afecta a las personas, las operaciones y los clientes. En este diagrama, de ejemplo, se puede ver claramente:
Cuando pensamos en sistemas, empezamos a ser conscientes de las diferentes partes y cómo se relacionan e influyen en los resultados del mismo. Pero cuanto más profundizamos en el sistema, más nos hacemos conscientes de la cantidad de variables que existen y de cómo la búsqueda de la decisión correcta, se aleja. El paradigma cambia, y en lugar de buscar la decisión definitiva, lo que hacemos es experimentar, recoger el feedback y re-ajustar la dirección. Aprendemos. Las metodologías ágiles funcionan así, reconocen la imposibilidad de desarrollar un proyecto que se idea y planifica de una vez al comienzo, para responder a las necesidades complejas de un cliente de forma adecuada. Las startups funcionan así, en lugar de fábricas, se conciben como motores de experimentación y aprendizaje. El lema de Facebook era “Move fast and break things”, el cual puede verse como un reconocimiento de que el mundo es un sistema complejo, y para encontrar la solución adecuada lo mejor es experimentar, no tener miedo a fallar y aprender de forma empírica.
Pensar en sistemas require un cambio de mentalidad, requiere dejar atrás un enfoque reduccionista, donde si hacemos X entonces obtenemos Y. Requiere identificar las diferentes piezas que influyen en un problema y las relaciones entre ellas. Requiere hacer un análisis de las causas raíces, no quedarse en el síntoma, aceptar que muchas veces no tenemos suficiente información para tomar una decisión, y entonces debemos experimentar, aprender y re-evaluar la decisión. La herramienta para pensar en sistemas es el modelaje, representar las partes, las relaciones, el todo y los resultados. Esto se puede hacer con una una pizarra offline u online (p.ej. miro), como se muestra en el diagrama anterior.
Aunque todavía no se ha extendido mucho el uso de Systems thinking en la industria del software, creo que es cuestión de tiempo que esto ocurra. Continuamente estamos viendo como la mentalidad y visión más clásica para abordar los problemas se da de bruces con la realidad. Empezar a utilizar Systems thinking no es complicado, quizás hay un problema que te da vueltas en la cabeza, y para el que pensar en sistemas te puede ayudar a hacer avances.
Referencias
Actualmente trabajo ayudando a las empresas y los equipos de tecnología a hacer un mejor uso de su potencial. Para ello les ayudo a ser conscientes de dónde están sus ineficiencias y cómo pueden trabajar en acciones concretas para mejorar dentro de su contexto, y hacerlo de forma continua. Si sientes que en tu empresa tenéis margen de mejora, pero el día a día os come, podemos hablar para explorar soluciones juntos. Puedes reservar una llamada aquí.