¿Qué es el bus factor y por qué casi ningún equipo lo mide?

El bus factor (o truck factor) es la cantidad mínima de personas que tendrían que dejar un equipo de un día para el otro —por renuncia, licencia o cualquier imprevisto— antes de que el proyecto se frene por falta de alguien que entienda cómo seguir. Un bus factor de 1 significa que alcanza con que una sola persona se vaya para que nadie más sepa cómo tocar cierto módulo, acceder a producción o explicar por qué se tomó una decisión de arquitectura clave. Cuanto más alto el número, más repartido está ese conocimiento crítico entre el equipo — y menos depende el proyecto de que a nadie en particular le pase nada.

El término nació en la comunidad de desarrollo de software a comienzos de los 2000 como una forma coloquial de nombrar un riesgo que ya existía: la concentración de conocimiento en pocas cabezas. Hoy se usa tanto en auditorías de due diligence técnica —para tasar qué tan frágil es un equipo antes de una adquisición— como en la gestión diaria de cualquier equipo de ingeniería.

¿Cómo se calcula el bus factor de un equipo?

No hay una fórmula única. El enfoque académico más citado —usado en un estudio de Avelino, Passos, Hora y Valente (2016) sobre cientos de repositorios populares de GitHub— estima el bus factor mirando qué porcentaje del código de un proyecto está concentrado en los commits de sus autores principales: si con dos o tres personas ya se cubre la mayor parte del historial, ese es el número. En la práctica, la forma más simple es hacerse una pregunta por cada área crítica del proyecto: si esta persona se va mañana, ¿alguien más puede tomar su lugar sin que todo se frene?

• Decisiones de arquitectura y por qué se tomaron
• Acceso a producción y respuesta ante incidentes
• Los módulos de código más complejos o menos documentados
• Infraestructura, DevOps y contraseñas o accesos de proveedores
• El contexto del cliente: qué se acordó, qué se probó y qué no funcionó antes

¿Por qué el bus factor real de la mayoría de los equipos es más bajo de lo que creen?

El mismo estudio de Avelino y su equipo encontró que el 65% de los repositorios de GitHub que analizaron tenía un bus factor de 2 o menos —es decir, dos personas (o menos) concentraban el conocimiento suficiente para frenar el proyecto si se iban. No es un problema de proyectos chicos o descuidados: son los mismos repositorios populares que cualquiera asumiría bien organizados.

Un estudio posterior, específico sobre cómo lo viven los equipos de la industria (Jabrayilzade et al., ICSE 2022), encontró algo todavía más incómodo: la mayoría de los desarrolladores sabe que el riesgo existe, pero las prácticas para reducirlo —documentar, rotar código crítico, hacer pair programming— se aplican de forma inconsistente hasta que alguien se va y el problema ya es real.

Y la probabilidad de que ese "alguien se va" ocurra no es baja: según datos de LinkedIn, la rotación en el sector tech rondó entre el 20% y el 25% en 2025, muy por encima del 10,9% promedio de todas las industrias. Un bus factor bajo en un sector con alta rotación no es un riesgo teórico — es una apuesta con las probabilidades en contra.

¿Un squad ya armado tiene mejor bus factor que un freelancer o una consultora ad hoc?

Un freelancer que trabaja solo tiene, por definición, un bus factor de 1: no hay nadie más a quien preguntarle. Una consultora que arma un equipo nuevo para cada proyecto tampoco parte mucho mejor —el equipo recién está en la etapa literal de "formación" del modelo de Tuckman, y todavía no construyó el terreno común que hace que el conocimiento se comparta en vez de acumularse en una sola persona.

Un squad que ya trabajó junto en proyectos anteriores parte de otro lugar: las decisiones de arquitectura, el criterio de código y el contexto de cada milestone ya circularon entre varias personas antes de que el proyecto actual empezara. Eso no elimina el riesgo —ningún equipo tiene bus factor infinito— pero lo distribuye desde el día uno, en vez de tener que construirlo sobre la marcha mientras el proyecto ya está en curso.

¿Cómo se reduce el bus factor sin duplicar el costo del equipo?

La forma más cara de resolverlo es la más obvia: poner a dos personas en cada rol, full time. La que realmente escala es hacer visible el conocimiento a medida que se genera, no reconstruirlo después de que alguien se fue. Documentar decisiones en el momento en que se toman —no en un wiki aparte que nadie actualiza—, rotar la revisión de código en los módulos más críticos, y evitar que el acceso a producción dependa de una sola persona son prácticas baratas comparadas con el costo de reconstruir ese conocimiento desde cero.

La evidencia también ayuda a medirlo desde afuera: cuando el avance de un proyecto queda documentado en el repositorio —quién tocó qué, en qué milestone, bajo qué criterio de aceptación— el conocimiento deja de vivir solo en la cabeza de una persona y en las reuniones a las que esa persona fue. Es la misma lógica por la que reemplazar a un squad a mitad de proyecto es mucho más simple cuando el trabajo hecho hasta ese punto es verificable, no una promesa de que "ya casi está".

Antes de que un squad aparezca como opción en un match de Zenit, ya pasó por la verificación de ZenitRank —que mide señales como cumplimiento de milestones y diversidad de clientes, no solo currículum—. Un bus factor bajo tiende a mostrarse ahí antes de convertirse en un problema a mitad de un proyecto real.