Hace años conocí a un emprendedor cuyo responsable técnico era conocido cómo “El Hechicero”. Al parecer todo el mundo en la empresa pensaba que lo que aquel programador hacía era Magia Negra. Por consiguiente, es predecible que el aviso de su baja voluntaria causase cierta ansiedad respecto del futuro. En este post explico cómo paliar los efectos indeseables de la pérdida de conocimiento que acarrea la marcha de un trabajador con conocimientos únicos.
El proceso de transición
Para empezar, nadie es irremplazable. Creo que en treinta años nunca me he encontrado ninguna empresa que quebrase porque se marchó un programador. Si se marcha un equipo entero la situación puede ser más peligrosa, pero sobre eso escribiré más adelante. Es decir, ante todo: calma. Lo cual no implica ignorar el suceso y no hacer nada en absoluto al respecto.
A continuación, yo recomiendo la siguiente secuencia de pasos:
1) Hacer una lista de los conocimientos, competencias y responsabilidades diarias que tiene la persona que se marcha. Estimar cual es la curva de aprendizaje de los conocimientos y cuánto tiempo dedica la persona a cada tarea rutinaria a su cargo.
2) Decidir quién se hará cargo de las funciones asignadas a la pesona que se marcha. Puede que sea otra persona de la empresa, o un departamento, u otro empleado a contratar o un proveedor externo. O una combinación de todo lo anterior.
3) Enumerar y producir la documentación que será necesaria. Esta documentación debe incluir, cómo mínimo:
• Especificaciones funcionales.
• Arquitectura y diseño del sistema.
• Modelos y flujos de datos.
• Manual de operación diaria del sistema.
• Procedimientos de despliegue.
• Procedimientos de pruebas.
• Lista de defectos software conocidos y funcionalidades pendientes de implementar.
4) Recopilar todas las credenciales de las que dispone el causante de la baja. Y acordarse de cambiarlas o cancelarlas inmediatamente en cuanto se haya ido.
5) Diseñar un plan de transferencia de conocimiento. Este plan debe incluir, al menos:
• Producir toda la documentación necesaria.
• Llevar a cabo sesiones de formación con quien vaya a asumir la responsabilidad. Idealmente todas estas sesiones deben ser registradas y grabadas en video.
• Realizar ejercicios prácticos de mantenimiento del sistema con quien vaya a encargarse del mismo.
6) Hacer un inventario del código fuente. Debe haber un hito formal de traspaso del código. Conviene llevar a cabo este paso concienzudamente porque los programadores que llevan mucho tiempo trabajando en solitario tienden a ser nefastos en su sistema de control de versiones.
7) Informar a los compañeros de trabajo, inversores y clientes. Los compañeros necesitan saber que la persona que se marcha debe estar dedicada 100% al plan de transferencia de conocimiento y que, por consiguiente, durante la etapa de transición no puede asumir ninguna otra tarea. Los inversores necesitan saberlo para ajustar sus expectativas. Puede que tengan que poner más dinero debido a la pérdida temporal de eficiencia o que tengan que esperar más tiempo hasta la próxima release. Comunicárselo a los clientes puede ser bastante más peliagudo. Yo he visto clientes amenazar con cancelar un contrato si se iba una determinada persona. Es por eso que conviene notificárselo al cliente sólo cuando esté perfectamente definido el plan de transición.
8) Ofrecer al empleado una referencia profesional justa y equitativa con respecto al trabajo que ha realizado. Algunas empresas se niegan a proporcionar ningún tipo de información acerca del desempeño profesional de ex-empleados incluso a petición de este mismo. Yo no entiendo bien por qué hacen eso. Puede que piensen que así no proporcionan información de valor a la competencia, o que no quieran asumir responsabilidades. En cualquier caso, las referencias profesionales tienen un peso importantísimo en el mercado laboral. Por tanto, negárselas a un ex-empleado es un acto poco ético. Los ex-empleados pueden ser una fantástica fuente de buenos clientes. De hecho, una parte de la estrategia comercial de las consultoras es colocar gente en los clientes para que en el futuro pidan ofertas de servicio a la misma consultora que antaño les empleó.
9) En algunas ocasiones existen cláusulas de no competencia según las cuales un ex-empleado no puede irse a trabajar a una empresa competidora ni crear su propia empresa relacionada con el trabajo que tenía. Aunque algunas empresas son muy agresivas en sus amenzadas, estas cláusulas son difíciles de ejecutar en la práctica a menos que exista un robo muy claro de activos intelectuales o que el ex-empleado reciba una pingüe retribución por no trabajar en absoluto durante un tiempo.
10) Organizar una fiesta y regalarle algo al que se va es una buena idea. Todo fin necesita un funeral, preferiblemente alegre.
Bajas conflictivas
Los conflictos más comunes en las bajas voluntarias son la extorsión y los motines.
La extorsión más habitual es cuando el programador intenta secuestrar una parte del código o del conocimiento y pide un rescate al empleador. Esto simplemente es ilegal. Según la ley, a propiedad intelectual de todos los trabajos realizados por un empleado en horario laboral pertenece al empleador. Por consiguiente, un empleado o proveedor no puede exigir una cantidad de dinero adicional a cambio de entregar el código. Negarse a entregar el conocimiento es igualmente un acto delictivo ya que supone causar un daño económico premeditado a la empresa por el cual esta podría demandar una compensación.
El montín es una forma superlativa de extorsión. Se produce cuando un grupo de empleados amenaza con marcharse en bloque a menos que la empresa modifique sus condiciones laborales. No pretendo defender la explotación laboral. Las huelgas se inventaron por razones perfectamente justificables. Incluso en el sector informático que, teoricamente, debería ofrecer buenas condiciones para los trabajadores, hay empleados en condiciones bastante precarias e injustas. Pero una cosa es una huelga y otra considerar la oferta de un competidor hostil que pretende comprar un equipo entero a golpde talonario para liquidar a la empresa atacada. Este tipo de maniobras suelen terminar mal para todos. Para el atacante porque en definitiva está contratando a una banda de traidores. Y para los amotinados porque es muy común que una vez logrado el objetivo de defenestrar a la empresa atacada, el atacante pretenda reducir costes reemplazando a los amotinados por otros recursos humanos más baratos.
