Un equipo ya no basta

El punto de partida

Un año después del lanzamiento, New Capital Bank está en la etapa que llamamos tracción: los clientes llegan, el negocio pide una tarjeta y Bizum, y la matriz aprueba contratar. En pocos meses el equipo pasa de seis a unas veinte personas.

Veinte personas no caben en una reunión diaria ni en un mismo tablero. Hay que hacer tres equipos. La forma más natural es juntar a cada uno con los suyos:

• Equipo App: quienes hacen las pantallas.
• Equipo Backend: quienes hacen el motor de remuneración, las operaciones y el alta.
• Equipo Integraciones: los veteranos de la matriz, que conocen el core, los proveedores y los sistemas de pagos.

Tiene sentido: cada equipo comparte tecnología, herramientas y forma de trabajar. Mira qué pasa cuando llegan los cambios que pide el negocio.

Llegan cuatro cambios

En la simulación, las filas son las capas del software (app, servicios, conectores) y los recuadros, los equipos. Cada cambio entra por arriba y recorre sus piezas en orden. Cuando pasa de un equipo a otro hay un traspaso: el siguiente equipo tiene su propio sprint, y el cambio espera a entrar en él. Cuenta una semana de trabajo y dos de espera por cada traspaso.

Qué ha pasado

Casi todos los cambios del negocio cruzan las tres capas: una pantalla, un servicio y un conector. Con un equipo por capa, cada cambio cruza los tres equipos, y cada cruce es una espera. Un cambio de una semana tarda cinco.

Hay algo peor que la espera. Con el tiempo, los equipos acuerdan contratos entre ellos para coordinarse menos: «Backend expone esta API, App la consume». Esos contratos se convierten en la arquitectura. Nadie decidió que el software se partiera en tres capas con interfaces rígidas entre ellas: lo decidió el organigrama.

Esto tiene nombre desde 1968. Melvin Conway lo escribió así: las organizaciones que diseñan sistemas acaban produciendo diseños que copian su estructura de comunicación. Se conoce como ley de Conway.

La maniobra inversa

Si la organización acaba decidiendo la arquitectura, se puede usar al revés: primero se decide qué arquitectura se quiere y después se forman los equipos que la producirán. Es la maniobra inversa de Conway.

New Capital Bank quiere que cada flujo de negocio (la remuneración, los pagos, el alta de clientes) pueda cambiar sin pedir permiso a los demás. Así que corta los equipos por flujo, no por capa: Remuneración, Pagos y Clientes, cada uno con gente de app, de backend y de integraciones. Lanza los mismos cambios con los dos repartos.

No hay corte perfecto

Con el reparto por flujo, tres de los cuatro cambios se quedan dentro de un equipo y tardan una semana. El cuarto, «los intereses en el extracto», necesita una pantalla de Pagos y un dato del motor de Remuneración. Cruza dos equipos con cualquier reparto.

Siempre habrá cambios que crucen equipos. Lo que se elige es cuáles: el reparto bueno es el que deja dentro de un equipo los cambios más frecuentes y deja en la frontera los que llegan poco. Por eso un corte no es para siempre: cuando cambia lo que pide el negocio, hay que revisarlo.

Y cortar por flujo también tiene un coste: la gente de app ya no se sienta junta, y cada equipo puede acabar resolviendo lo mismo a su manera. Los siguientes episodios van de cómo se paga ese coste sin volver a las capas.

Para llevarse

• La ley de Conway: el software acaba copiando cómo se comunican los equipos que lo hacen.
• Repartir por capas técnicas es natural, pero convierte cada cambio de negocio en una cadena de traspasos.
• La maniobra inversa: decide primero la arquitectura que quieres y forma los equipos que la producirán. Corta por donde llegan los cambios.