El “bus factor” mide algo muy concreto: cuántas personas de un equipo pueden faltar de golpe antes de que el proyecto se quede parado por no saber cómo seguir. Cuanto más bajo es ese número, más frágil es el proyecto, y es una fragilidad que no se nota mientras todo el mundo sigue en su sitio.
Y entre entrega y entrega, el conocimiento del proyecto se va quedando en la cabeza de quien lo ha ido resolviendo, sin pasar al resto. No porque nadie quiera guardárselo, sino porque documentar nunca es lo urgente: siempre hay una entrega encima, o una corrección de esa entrega, y explicar el porqué de una decisión se queda para "luego".
Hay un proyecto en el que estoy trabajando ahora donde el equipo lo formamos cuatro personas, y en algún momento nos dimos cuenta de que dos de ellas concentraban la mayor parte del conocimiento. Tiene su lógica: son quienes tienen más experiencia en ese campo, y marcan buena parte del criterio mientras el resto vamos ejecutando tareas. Pero ahí está el problema, un proyecto no puede depender de que esas dos personas estén siempre disponibles para que el resto sepa por dónde seguir.
Lo que hicimos fue bastante sencillo, aunque no inmediato. Empezamos a documentar los procesos y el código a medida que se iban tocando, no al terminar. Metimos reuniones cortas para poner en común lo que sabía cada persona, y ratos de trabajo compartido (en pareja o en grupo, según el caso) para que el conocimiento pasara de una cabeza a otra sin depender de una sola persona. La rotación de tareas la tenemos todavía en pañales, pero ya la estamos probando.
Al final, lo que de verdad marca la diferencia es tener un documento de trazabilidad que sea útil de verdad: uno de consulta, no un archivo que se escribe una vez y se olvida. Un documento vivo, que se va alimentando según avanza el proyecto, para que cualquiera que lo abra (incluidas las personas con más experiencia) meses después, pueda seguir el hilo sin depender de que alguien se acuerde.