Pedro se fue de vacaciones — y los builds dejaron de generarse
Tres semanas en la vida de una empresa donde un proceso crítico se apoyaba en una sola persona, y esa persona se fue a hacer barbacoa con sus padres. Lo que aprendí, y lo que ahora hago con esas situaciones.
Era agosto, calor, temporada de vacaciones. Me llamó un cliente con el que había trabajado seis meses antes. "Estamos en pánico", dijo en ese tono particular que usa la gente cuando el pánico es de la empresa entera, no sólo suyo. "No se nos generan los builds de producción."
— ¿Qué pasó?
— Pedro se fue.
— ¿Adónde?
— Al pueblo. Con sus padres.
— ¿Hay cobertura allí?
— Hay cobertura. Pero Pedro está de vacaciones.
— ¿Y sin él no se puede?
Pausa. No una pausa telefónica. Una pausa existencial.
Pedro en esa empresa era ingeniero de soporte senior, fuerte. En el listado informal de sus funciones estaba "monta los builds de producción los viernes por la tarde". Pedro los montó seis años seguidos. Primero — porque era uno de siete que sabía cómo. Después — porque era el único que sabía dónde están los certificados y en qué orden aplicarlos. Después — porque escribió un script que automatizaba parte del proceso. El resto vivía en su cabeza, en el formato "aquí esperas 30 segundos porque si no la API de Apple no contesta".
Cuando Pedro se fue al pueblo a casa de sus padres, resultó que no tenía documentación. Ni README. Ni vídeo. Ni nota en Jira. Porque no planeaba entregar esta parte. Ni se le había ocurrido que haría falta.
A él, por cierto, hasta hoy le parece excesivo el alboroto. "Yo estaba localizable", dice. "Podíais haber llamado." Sí. Podíamos. Pero Pedro estaba de vacaciones. Y llamar a alguien en casa de sus padres con la barbacoa encendida es mala práctica de gestión, y el precio se paga normalmente en algo no monetario — por ejemplo, Pedro yéndose al competidor seis meses después.
A lo largo de esos tres días de agosto conseguí montar la release — llamé a Pedro dos veces (no se enfadó, le llevamos una botella de coñac en septiembre a modo de disculpa), y dictó los pasos por teléfono. Después le dije al cliente: "Tenemos que arreglar esto antes de que yo salga del proyecto. Si no, en seis meses a un año se repite, y seré yo el culpable de no haberlo arreglado cuando se podía."
El cliente aceptó. Lo arreglamos. Dos semanas.
El hecho de que tu equipo tenga un Pedro es, por regla, el resultado de optimización local, no de una decisión consciente.
Nadie diseña el proceso para depender de una persona. Se acumula de forma natural. Pedro hizo la tarea más rápido que todos. Pedro la hizo otra vez. A la tercera, todos saben que es Pedro. A la cuarta, le resulta más fácil hacerlo que explicarlo. A la quinceava, sólo se puede vía Pedro, porque los pasos no están escritos. No es culpa de Pedro. Es erosión sistémica del proceso.
Los Pedros vienen en distintos formatos. A veces es ingeniero. A veces — el contable que es el único que mete asientos en el sistema local sin recibir una multa. A veces — el comercial senior que es el único que lleva el pipeline en su formato. A veces — el propio founder, que es la única persona en la empresa que entiende por qué la estrategia es esa y no otra.
Si tu empresa tiene un Pedro, se vive. Todo el mundo convive con uno. Tres Pedros es vulnerabilidad estructural. Cinco — no tienes procesos, tienes cinco personas autónomas trabajando al lado y hablando de vez en cuando.
Cuatro métodos que aplico cuando encuentro un Pedro.
Primero — runbook mínimo. No "escribe una wiki de cien páginas". Nadie la lee. Pedro no la escribe, se aburre. Tú no la revisas, estás ocupado.
Funciona una página. Un proceso — una página. Qué hace, entrada, salida, comandos clave, qué hacer si se rompe. Diez minutos para escribirla. Cinco para validarla.
Validar es simple: una semana después de escrita, pásale la página a alguien que nunca ha hecho el proceso y que la siga. Tropezará en tres sitios. Añade esos tres sitios. Ahora el proceso está documentado.
Segundo — pareamiento, dos semanas. Pedro hace la tarea. Al lado (físicamente o en Zoom) se sienta María y observa. No pregunta. Anota decisiones y matices.
A la semana siguiente María hace, Pedro observa. A la tercera — María sola, Pedro en stand-by.
Después de eso Pedro puede ponerse enfermo, casarse o irse al pueblo a casa de sus padres — el negocio no se para. No porque la documentación sea perfecta. Porque hay un segundo portador de contexto.
Tercero — automatiza lo que se automatiza. Si Pedro hace este proceso a mano tres veces por semana — es candidato a script. Incluso un script malo que cubra el 80% de los casos libera el 80% del tiempo de Pedro. El 20% restante realmente necesita al experto.
También al revés: no automatices lo que se hace una vez por trimestre. El coste de escribir y mantener automatización supera al coste de hacerlo a mano. Tuve un cliente exactamente así — un informe financiero que se monta cuatro veces al año. Pasaron medio año construyendo automatización. La automatización no arrancó. Ahora el informe se vuelve a montar a mano, como antes.
Cuarto — rotación. El método más doloroso y el más eficaz. Una vez por trimestre otra persona toma lo que hace Pedro. Pedro va a un área adyacente.
Primero se queja el equipo. Después se queja Pedro, porque su expertise "se diluyó". Después no se queja nadie, porque el conocimiento está distribuido.
Funciona en equipos de cuatro o más. Menor — la rotación no ayuda, no hay a quién pasar.
Lo que no funciona:
"Si se va, ya veremos." La documentación no aparece por arte de magia el día del adiós. Normalmente la dimisión pasa más rápido de lo que puedes reaccionar, y Pedro se lleva seis años de contexto. Tuve un cliente que perdió al equipo de ventas en una semana tras marcharse una persona, porque esa persona guardaba en la cabeza la estructura de relaciones con quince clientes clave. Semana cara.
"Contratemos otro Pedro." Dobla el recurso, pero no cambia la estructura. Dos Pedros siguen siendo Pedros. La fragilidad sistémica se queda. Sólo dividida entre dos.
"El contexto humano importa, no se puede documentar." A veces es verdad. Más a menudo, excusa para no invertir dos horas en un runbook. Prueba a invertirlas. Mira qué sale.
Hay un chiste viejo de ingeniería: "el único servidor sin backup es prod". Para equipos vale lo mismo: el único proceso sin redundancia es el proceso que no estás dispuesto a perder.
"Todo se apoya en Pedro" no es virtud del equipo. Es indicador de inmadurez de proceso. Los Pedros son geniales. La empresa tiene que sobrevivir cuando Pedro se va de vacaciones. O se marcha. O se cansa.
La pregunta no es qué hacer con Pedro. Es cómo crecer para no depender de un Pedro. La respuesta suele ser cuatro horas de trabajo y dos semanas de pareamiento.
Pedro, por cierto, no sale perjudicado. Si Pedro es de los buenos — hasta estará contento de tener unas vacaciones sin llamadas.