Tu mejor ingeniero acaba de renunciar. ¿Y ahora qué?

Cada equipo de ingeniería tiene a una persona que sabe por qué el pipeline de despliegue funciona de la manera en que lo hace, por qué el esquema de la base de datos tiene esa convención de nomenclatura tan extraña, qué pasó durante la caída de servicio en 2023 que dio forma a la configuración de monitorización actual y qué partes del código heredado son muros de carga que no se deben tocar bajo ningún concepto.

Cuando esa persona se marcha, y tarde o temprano lo hará, todo ese contexto se va con ella. El equipo descubre los vacíos de información durante las semanas y meses siguientes, un doloroso incidente a la vez: un despliegue que falla porque nadie sabía de ese paso manual que no estaba documentado, una refactorización que elimina sin querer un parche que existía por una razón que ahora nadie recuerda, o una nueva incorporación que pasa tres semanas intentando entender un sistema que el ingeniero que se marchó podría haber explicado en veinte minutos.

Este es el problema del factor autobús (bus factor), llamado así por la morbosa pregunta "¿a cuántos miembros del equipo tendría que atropellar un autobús antes de que el proyecto no pudiera continuar?". La mayoría de los equipos de ingeniería tienen un factor autobús de uno o dos para partes significativas de su sistema, lo que significa que una o dos salidas podrían causar semanas o meses de interrupción.

Lo que realmente se va

Cuando un ingeniero con experiencia se marcha, el código se queda. Las relaciones públicas (PR) se quedan. Los mensajes de Slack se quedan, al menos hasta que desaparecen de la ventana de retención. Lo que se va es la capa interpretativa: la comprensión de por qué las cosas son como son, qué decisiones fueron concesiones conscientes y cuáles fueron accidentes, dónde están ocultos los problemas y qué se romperá si se toca lo que no se debe.

Este es el conocimiento tribal en su forma más concentrada, y es el tipo de conocimiento más difícil de transferir porque la persona que lo posee a menudo no se da cuenta de cuánto sabe. Lo ha acumulado a lo largo de meses o años trabajando estrechamente con el sistema, y gran parte de ello se ha vuelto tan automático que no podría elaborar un documento exhaustivo al respecto incluso si lo intentara.

Las entrevistas de salida y las sesiones de transferencia de conocimientos ayudan, pero solo capturan una fracción de lo que sabe la persona que se va. No se pueden transferir dos años de contexto acumulado en un periodo de preaviso de dos semanas.

La alternativa de la captura continua

La respuesta al problema del factor autobús es capturar el conocimiento de forma continua, en lugar de apresurarse a extraerlo en el momento de la partida.

La documentación que se redacta sola hace esto al convertir la actividad de ingeniería que ya se está realizando en documentación estructurada y en la que se pueden realizar búsquedas a medida que ocurre. Cuando un ingeniero explica una decisión de diseño en un hilo de Slack, esa explicación se captura y se integra en la documentación del sistema. Cuando una PR incluye una descripción de por qué se eligió un enfoque concreto, ese razonamiento se conserva junto al código. Cuando en una reunión se debaten los pros y contras de un plan de migración, el debate se documenta y se vincula al sistema correspondiente.

El conocimiento no se extrae del ingeniero en una sesión especial. Se captura como un subproducto del trabajo que ya está haciendo, lo que significa que se acumula continuamente y se mantiene actualizado a medida que el sistema evoluciona.

Cuando ese ingeniero finalmente se va, la documentación que generó durante su permanencia permanece. La siguiente persona que necesite entender por qué el pipeline de despliegue funciona de la manera en que lo hace puede buscar en la documentación en lugar de descubrir la respuesta mediante ensayo y error.

El coste de no resolver esto

El coste de una partida clave sin la documentación adecuada es difícil de medir con precisión, pero fácil de sentir. Los equipos suelen registrar de dos a seis meses de velocidad reducida tras perder a un depositario de conocimientos críticos, dependiendo de qué parte del sistema entendía esa persona y de lo bien documentado que estuviera ese conocimiento.

Con un salario de ingeniero sénior de 180.000 a 220.000 dólares, incluso dos meses de productividad significativamente reducida en un equipo representan decenas de miles de dólares en pérdida de rendimiento. Para sistemas críticos donde el ingeniero saliente era el único depositario del conocimiento, el coste puede ser mucho mayor: incidentes de producción que tardan más en resolverse, funciones que se posponen porque nadie entiende el sistema lo suficientemente bien como para modificarlo de forma segura, y una incorporación (onboarding) que lleva meses en lugar de semanas porque no hay nada que los nuevos empleados puedan leer.

El problema del factor autobús es uno de los pocos riesgos de ingeniería en los que la solución (documentación que captura el conocimiento de forma continua) es más barata que el problema que evita.

Preguntas frecuentes

¿No podemos hacer simplemente sesiones de transferencia de conocimientos? Se puede y se debe, pero solo capturan lo que el ingeniero saliente se acuerda de mencionar, que es una fracción de lo que sabe. Gran parte de los conocimientos más valiosos son contextuales y solo surgen en respuesta a situaciones específicas que no se presentan durante una sesión de transferencia.

¿Cuánta documentación es suficiente para reducir el factor autobús? Concéntrese en las decisiones y el razonamiento más que en los detalles de implementación (el código se documenta a sí mismo a nivel de implementación). Si un nuevo ingeniero puede entender por qué el sistema está estructurado de la manera en que lo está leyendo la documentación, el riesgo del factor autobús se reduce sustancialmente.

¿Se aplica esto a equipos pequeños? Los equipos pequeños son en realidad más vulnerables, porque cada persona posee una proporción mayor del conocimiento total. Un equipo de cinco personas que pierde a un ingeniero pierde el 20 % de su contexto colectivo. Un equipo de cincuenta personas que pierde a un ingeniero pierde el 2 %.

Lecturas relacionadas: El coste oculto del conocimiento tribal, La deuda de documentación, Su base de código está documentada, sus decisiones no. Páginas relacionadas: Documentación que se redacta sola, Retención del conocimiento, Para equipos de ingeniería.