¿Qué es el Optimizador de Formación de Equipos y cómo funciona?
Formar equipos a mano es un arte. Lo he hecho muchas veces y siempre acabas con la sensación de que podrías haberlo hecho mejor. Porque al final te dejas llevar por quién se lleva bien con quién, quién está disponible, quién pidió estar con su amigo — cosas humanas, legítimas, pero que no garantizan que el equipo resultante pueda funcionar de forma autónoma. Este optimizador cambia el enfoque: metes las habilidades y niveles de cada persona, le dices cuántos equipos quieres, y el algoritmo evalúa las combinaciones posibles buscando las que maximizan tus criterios. No es magia negra — es optimización combinatoria aplicada a un problema que todo engineering manager ha resuelto mal alguna vez. ¿Te va a dar la respuesta perfecta? No. Pero te da un punto de partida basado en datos en vez de en corazonadas. Y luego tú ajustas por los factores humanos que ningún algoritmo puede capturar.
La ciencia de la formación de equipos: de Conway a Team Topologies
Aquí hay un concepto que flipas: la Ley de Conway dice que la arquitectura de tu software acaba reflejando la estructura de tus equipos. O sea, cómo formes los equipos no es solo un tema de RRHH — es una decisión de arquitectura técnica. Si tu equipo de pagos está separado del equipo de usuarios, tu sistema tendrá una frontera ahí. Team Topologies de Skelton y Pais va más allá y define cuatro tipos de equipo: stream-aligned (entregan valor al cliente), enabling (ayudan a otros equipos), complicated subsystem (gestionan partes técnicamente complejas) y platform (dan servicios internos). ¿Y qué tiene que ver con el optimizador? Pues que el tipo de equipo que estés formando cambia lo que necesitas. Un stream-aligned team necesita cobertura end-to-end — frontend, backend, testing, infra. Un complicated subsystem team necesita profundidad brutal en una cosa. Pero claro, luego está lo que descubrió Google en Project Aristotle: que la seguridad psicológica importa más que la composición individual del talento. Así que sí, usa el algoritmo — pero no ignores cómo se sienten las personas.
Cobertura vs. resiliencia: entendiendo las métricas de optimización
Son dos caras de la misma moneda, pero no son lo mismo. Cobertura al 100% significa que el equipo puede tocar cualquier parte del sistema sin depender de otro equipo. Genial para velocidad, genial para autonomía. Pero — y este pero es importante — puedes tener 100% de cobertura y cero resiliencia. ¿Cómo? Si cada habilidad la cubre exactamente una persona. Si esa persona falta un día, el equipo pierde esa capacidad entera. Resiliencia es la redundancia. ¿Cuántas personas pueden cubrir cada habilidad? Si tres personas saben de backend, puedes perder a una y seguir adelante. ¿Qué priorizar? En mi experiencia, si estás formando un equipo temporal para un proyecto de tres meses, prioriza cobertura — necesitas que arranquen rápido. Si es un equipo que va a estar años, invierte en resiliencia. Porque la gente se va, se enferma, cambia de rol. La rotación es inevitable, y un equipo sin redundancia es un castillo de naipes esperando que sople el viento.
Más allá del algoritmo: factores humanos en la formación de equipos
Voy a decir algo que puede sonar contradictorio después de toda la guía: el algoritmo no lo es todo. Es un punto de partida — buenísimo, basado en datos, objetivo — pero la formación de equipos exitosa necesita algo más. Necesita que las personas quieran estar juntas, o al menos que no se lleven a matar. Necesita diversidad cognitiva — no quieres cinco personas que piensen igual, aunque técnicamente sean complementarias. Necesita tener en cuenta quién ha trabajado bien con quién antes y quién ha tenido conflictos. Heidi Helfand habla de dynamic reteaming: la composición del equipo no debería ser permanente. La gente crece, los proyectos cambian, y aferrarse a una formación 'perfecta' del pasado cuando el contexto ya es otro es un error que he visto cometer muchas veces. Otro consejo: incluye habilidades blandas en tu matriz. Facilitación, comunicación, resolución de conflictos. Un equipo de cinco ninjas técnicos que no saben comunicarse es un equipo disfuncional. Y sobre todo — involucra a las personas en la decisión final. Nada mata más la motivación que enterarte un lunes de que te han cambiado de equipo sin consultarte.
