Analizador de Brechas de Capacidad

Voy a ser directo: si no sabes qué habilidades tiene tu equipo y cuáles le faltan, estás gestionando a ciegas. Y no me refiero a tener una idea vaga de que 'María sabe de React y Pedro de DevOps'. Me refiero a saber exactamente a qué nivel, quién puede enseñar a quién, y dónde hay huecos que podrían reventarte un proyecto. Este analizador hace eso — mapeas a cada persona, sus niveles en cada habilidad, y defines lo que vas a necesitar a futuro. La herramienta cruza las dos cosas y te dice: aquí tienes un problema gordo, y aquí estás bien. En mi experiencia, la mayoría de líderes técnicos creen que conocen las capacidades de su equipo, pero cuando lo ponen por escrito se llevan sorpresas. A veces agradables — descubres que alguien tiene un talento oculto. Pero generalmente descubres agujeros que preferirías no ver. Mejor verlos ahora que cuando te estalle un incidente a las 3 de la mañana y nadie sepa cómo arreglarlo.

El bus factor. O como yo lo llamó, el 'qué pasa si Javi se va de vacaciones y se rompe producción'. Es el número de personas cuya ausencia haría que el equipo no pudiera operar en una habilidad crítica. ¿Solo una persona sabe cómo funciona el sistema de pagos? Bus factor de 1. Una renuncia, una baja médica, y tienes un problema serio. Pero el bus factor es solo la punta del iceberg. El análisis también te revela riesgos de obsolescencia — ¿nadie en el equipo sabe Kubernetes y el año que viene migráis a containers? Riesgos de calidad — ¿cuánta gente puede hacer code review con criterio, o escribir tests decentes? Y cuellos de botella de conocimiento, que es cuando una persona se convierte en el oráculo al que todo el mundo consulta para todo, y acaba siendo el cuello de botella más lento del equipo. He visto equipos donde el 'experto' estaba tan quemado de ser el único que sabía que al final se fue. Con el análisis delante, habrían visto venir eso meses antes.

Los cuatro niveles que usa la herramienta — Ninguno, Novato, Ejecutor, Experto — están basados en el modelo Dreyfus, pero adaptados para que sean prácticos y no académicos. Un Novato sabe que la tecnología existe, ha hecho algún tutorial, pero necesita supervisión constante. Un Ejecutor puede resolver tickets solo, tomar decisiones técnicas razonables y no la lía. Un Experto, además de todo eso, diseña soluciones para problemas que nadie ha resuelto antes y puede enseñar a otros. ¿Y qué pinta aquí el perfil T-shaped? Mucho. Es la idea de que cada persona tenga profundidad en una o dos cosas y amplitud básica en varias más. Los equipos más resilientes que he visto están compuestos por perfiles T cuyas barras verticales se solapan — si Ana y Carlos los dos saben de backend aunque su especialidad sea otra, cuando uno falta el otro puede cubrir. La matriz de capacidad que genera la herramienta es exactamente eso: un mapa de calor donde las zonas frías te gritan 'aquí hay un hueco' y las calientes te dicen 'aquí sobran manos'.

Vale, ya sabes dónde están los agujeros. ¿Y ahora qué? Depende del agujero. Si es una habilidad que varias personas necesitan aprender desde cero — por ejemplo, el equipo no sabe nada de observabilidad y la vais a necesitar ya — un curso externo o un workshop intensivo puede ser la mejor inversión. Rápido y para todos a la vez. Pero si lo que necesitas es transferir conocimiento que ya existe dentro del equipo — que Pablo le enseñe a dos personas cómo funciona el pipeline — la mentoría interna es imbatible. Es más barata, se adapta al contexto real, y genera vínculos en el equipo. Ahora bien, hay brechas que no puedes cerrar internamente. Si necesitas un especialista en seguridad y nadie tiene experiencia, no vas a convertir a un junior en experto en tres meses. Ahí toca contratar. Y luego está la reorganización, que a veces es lo más fácil: si un equipo tiene exceso de frontend y el de al lado tiene déficit, mover a una persona resuelve dos problemas a la vez. Lo clave es priorizar. No puedes cerrar todas las brechas a la vez — empieza por las que tienen mayor riesgo y mayor necesidad futura.