Alinear equipos sin vivir en reuniones
Cuando dos equipos dependen uno del otro, el reflejo es agregar una reunión de sincronización. Casi siempre el problema no es de comunicación: es que la frontera entre los equipos está mal puesta, y ninguna reunión arregla eso.
Dos equipos que se bloquean entre sí terminan, sin falta, en el mismo lugar: una reunión semanal de coordinación. A veces alcanza. La mayoría de las veces, seis semanas después hay dos reuniones y los mismos bloqueos.
La reunión es un analgésico. La dependencia está en el diseño: alguien tiene que pedirle a otro equipo un cambio para poder terminar su trabajo, y eso no lo arregla hablar más seguido. Lo arregla cambiar quién puede hacer qué sin permiso.
Tres formas de depender, con costos muy distintos
| Forma | Cómo se ve | Costo de coordinación | Cuándo está bien |
|---|---|---|---|
| Por interfaz | El equipo A usa lo que el equipo B publica, sin pedirle nada | Bajo: sólo cuando cambia el contrato | Casi siempre: es a lo que hay que tender |
| Por trabajo | A necesita que B priorice y haga algo para poder avanzar | Alto: entra en las prioridades de otro equipo | Puntualmente, con fecha y acuerdo explícito |
| Por decisión | A no puede avanzar hasta que B decida algo | Altísimo y silencioso: nadie lo ve en ningún tablero | Casi nunca: suele significar que la frontera está mal |
Hacer visible lo invisible
Antes de proponer cualquier cambio conviene tener el inventario, porque casi siempre es más corto de lo que se siente y más caro de lo que se estima.
El inventario de dependencias
- Listá los bloqueos de los últimos dos meses. Qué esperaba cada uno, de quién, cuánto tiempo estuvo frenado.
- Clasificá cada uno en interfaz, trabajo o decisión.
- Sumá el tiempo. Es el número que convierte «nos trabamos seguido» en algo que se puede llevar a una conversación con otro líder.
- Buscá el patrón. Si el 70 % del tiempo perdido viene de una sola frontera, ahí está el problema y no hace falta rediseñar nada más.
Antes de seguir, predecí
Alinear hacia afuera del área técnica
La otra mitad del trabajo es con quienes no escriben código y dependen de lo que hace el equipo. Ahí el error clásico es informar en el idioma equivocado y con la frecuencia equivocada.
| Quién | Qué necesita saber | Con qué frecuencia | Qué NO le sirve |
|---|---|---|---|
| Producto | Qué se puede prometer y qué riesgo hay | Semanal, y ante cualquier cambio de fecha | El detalle de implementación |
| Soporte y ventas | Qué cambia para el cliente y cuándo | Antes de que llegue al cliente, no después | Enterarse por un cliente enojado |
| Dirección | Si el plan sigue en pie y qué decisión necesita de ellos | Mensual, breve, con lo que no está saliendo | Un reporte donde todo siempre está bien |
| Otros equipos técnicos | Qué contratos cambian y cuándo | Con aviso previo suficiente para adaptarse | Un cambio en producción sin aviso |
El bloqueo que vuelve todas las semanas
Escenario · 1 decisión como mínimo
Tu equipo necesita un campo nuevo en una API de otro equipo. Otra vez.
Es la cuarta vez en dos meses que tu equipo queda frenado esperando que el equipo de catálogo agregue un campo a su API. Cada pedido tarda entre dos y tres semanas en su cola. ¿Qué proponés?
Se arma la reunión. Seis semanas después hay dos reuniones semanales y los mismos bloqueos.
DesenlaceLa reunión es un analgésico: mejora la información sobre la espera y no acorta la espera. Cuando una coordinación crece en cantidad de reuniones en vez de bajar en cantidad de bloqueos, es la señal de que se está atendiendo el síntoma.
La jefatura prioriza tu pedido. El equipo de catálogo llega tarde con lo suyo y queda claro por qué.
DesenlaceGanaste tres semanas y perdiste algo más caro. Además, la quinta vez va a pasar lo mismo y ya no vas a poder escalar: escalar funciona una vez, y la dependencia sigue exactamente donde estaba.
Mirás los cuatro pedidos: en tres de ellos el campo que necesitaban ya existía en la base de catálogo y sólo hacía falta exponerlo. ¿Qué hacés con eso?
Catálogo dice que no, y con razón: quedarían atados a no poder renombrar nada nunca más.
DesenlaceUna dependencia se saca dando autonomía, no exigiendo que el otro equipo se congele. Y esa negativa era previsible: lo que estabas pidiendo era que asumieran un costo permanente para resolver tu espera.
Tres meses después, la pantalla muestra precios viejos y nadie entiende por qué.
DesenlaceLa copia sin sincronización resuelve la espera de esta semana y agrega una clase de error nuevo que es difícil de diagnosticar, porque el dato existe y es plausible: sólo está viejo.
Catálogo acepta: tu equipo puede mandar pull requests a su repositorio para agregar campos a la respuesta, y ellos revisan. La primera vez sale en dos días. ¿Qué falta?
Seis meses después cambia la jefatura de catálogo y el acuerdo se cae.
DesenlaceTodo el trabajo de destrabar la dependencia duró lo que duró la relación entre dos personas. Escribir el acuerdo cuesta media hora y es lo que hace que sobreviva a los cambios.
Queda escrito: los campos de respuesta los puede agregar cualquiera, el modelo interno y los nombres existentes no se tocan, y catálogo revisa en 48 horas.
DesenlaceLa cuarta dependencia desapareció y la reunión semanal no hizo falta. Y quedó el criterio para las próximas: cuando dos equipos se bloquean seguido, la pregunta no es cada cuánto hablan, es quién puede hacer qué sin pedir permiso.
Las tres opciones que no funcionan administran mejor la espera. La que funciona la elimina.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica