Masa y energía

Algunas compañías de producto digital logran resultados enormes con equipos mínimos. Por qué añadir masa a una organización de software suele restar energía.

20 de noviembre de 2024
Masa y energía

Algunas compañías de producto digital consiguen estupendas relaciones entre tamaño de equipos y resultados. En economía dirías que tienen una ENORME productividad.

Publicación de Jay en Bluesky: el equipo de Bluesky lo forman unos 20 empleados a tiempo completo, un millón de usuarios por empleado

Un millón de usuarios por empleado. La relación entre masa y resultado no es la que uno esperaría.

Mario compartía este otro ejemplo clásico.

Recorte de una entrevista: cinco personas participaron en la planificación preliminar de Super Mario 64 y entre 20 y 25 en las fases finales, con una media de 15 a 20 personas durante unos dos años

Super Mario 64: entre 15 y 20 personas de media durante unos dos años.

Sabemos que hay una relación inversa entre la masa y la energía. Sin embargo, a menudo los equipos de producto digital crecen abruptamente, sobre todo cuando se encuentran en fases de hipercrecimiento, exactamente en el momento en el que la tentación es mayor y el coste más alto.

La naturaleza de la creación digital hace que los desequilibrios entre la masa y la energía suelan tener efectos muy negativos.

El trabajo no se divide

Por su naturaleza no lineal —un problema no es una lista de tareas— al software rara vez le sienta bien la incorporación de más gente con la intención de acelerar las cosas. Todo se retrasa y lo que podría ser atómico acaba siendo sistémico.

The Mythical Man-Month sigue siendo la formulación clásica de esto, y merece la pena precisar el mecanismo, porque el libro se cita más de lo que se lee. La tesis de Brooks no es que la gente sea inútil. Es que el coste de una persona nueva se paga de inmediato y la capacidad llega después, si llega. La incorporación consume el tiempo de exactamente las personas que ya eran el cuello de botella. Mientras tanto el número de caminos de comunicación crece de forma cuadrática y el trabajo no.

El trabajo de Herbert Simon sobre la arquitectura de la complejidad da la versión más general. Los sistemas se vuelven tratables cuando se descomponen en partes casi independientes. Cuando no se descomponen —cuando todo toca todo— añadir capacidad en paralelo te compra coordinación, no rendimiento.

Divide y vencerás también sirve para los equipos

El enfoque habitual de la ingeniería funciona aquí igual. Cuando las organizaciones crecen, la tendencia sana es hacia verticales o equipos temáticos de producto, con un conocimiento propio del dominio y estructuras con poca gente —dos a cuatro personas— con capacidad para ir ajustando el alcance.

El tamaño importa menos que esa última cláusula. Un equipo de tres que tiene que negociar cada cambio de alcance carga con el coste de coordinación de un equipo de treinta sin la capacidad. Skelton y Pais hicieron el movimiento útil de tratar los límites de equipo como una decisión de arquitectura y no de recursos humanos, que es la consecuencia práctica de la ley de Conway: el sistema que entregas se parecerá a la estructura de comunicación que lo construyó, lo pretendiera alguien o no. Si quieres un producto modular, necesitas equipos modulares, y los necesitas antes de que exista el código.

El modelo de propiedad single-threaded de Amazon es la misma intuición llegada por vía comercial: una persona, un problema, sin atención compartida. Lo que lo hace funcionar no es la plantilla, sino la ausencia de división en la cabeza de quien responde.

La masa genera incertidumbre

Por la propia naturaleza del software y la incertidumbre que le acompaña, tener que manejar más masa incrementa la probabilidad de mayor incertidumbre. Esto suele convertirse en un círculo vicioso, y es la parte que menos atención recibe.

Más gente significa más código, más servicios, más puntos de integración, más superficie de despliegue, más lugares donde un cambio tiene consecuencias que nadie predijo. Las razones por las que los productos basados en software son tan difíciles no escalan linealmente con la organización. Se componen. La cualidad de mancha de aceite del software hace que la masa añadida en el borde aparezca como opacidad en el centro.

Los argumentos de colas de Reinertsen explican el síntoma visible. Cargar un sistema hacia la utilización plena destruye su capacidad de respuesta mucho antes de destruir su capacidad, así que una organización puede parecer más ocupada cada trimestre mientras entrega menos. Se siente como un problema de disciplina. Es un problema de física.

Ohno llegó a la misma conclusión desde la planta y sin nada de matemáticas: el exceso de capacidad esconde problemas, y los problemas escondidos son los caros. El instinto de Toyota era reducir hasta que el sistema empezara a quejarse, porque un sistema que se queja es un sistema que te está diciendo dónde le duele de verdad.

Nada de esto es un argumento para quedarse pequeño como virtud. Es un argumento para saber qué estás comprando. La masa se adquiere en una moneda y se paga en otra, y la factura llega en forma de una reunión de coordinación que nadie recuerda haber convocado.