La mejor y más rápida solución inventada para cambiar de proveedor software (sin verse afectado por la dependencia de personas)

Manu (un pseudónimo) ejercida ese rol que solemos llamar “cliente”, mas concretamente, y según decía en su tarjeta, ejercía de lo que ahora se llama CIO, y su principal responsabilidad era gestionar los llamados “recursos externos”, es decir, un grupo de personas al modo “body shopping”, que pertenecían al llamado proveedor, pero trabajan “físicamente” en la empresa de Manu, mas concretamente, en el desarrollo del  producto estrella de la empresa del “cliente”.
Todo se “desarrolló” de en paz y trnquilidad durante 2 años, de manera normal, con sus más y sus menos, pero normal, era hasta incluso aburrido en ocasiones… hasta que Manu recibió una llamada de su Jefe.
Saltando los detalles, el jefe pidió a Manú que fuera gestionando la sustitución de la empresa “proveedora de recursos”, en un mes sería sustituida por otra empresa proveedora. Las razones no se las comunicó, aunque Manu  intuyó algún tema político, nunca técnico, detrás de la sustitución.
Al principio, el tema no le pareció excesivamente crítico, más allá del cariño que podía haberle tomado a las personas del proveedor, que trabajaban como si fueran personal propio. Pero según pasaban los minutos, Manu fue sopesando algunos problemas de la sustitución.
Hasta la fecha, como todo había funcionado razonablemente bien durante esos 2 años, pues nadie se había preocupado por aquello llamado “software” o “código” o simplemente “el cómo estaba eso hecho por dentro”. Eso eran cosas “de los técnicos” y Manu nunca fue técnico, él había estudiado un MBA.
Pero después de hablar con otros colegas que habían pasado por una situación similar, empezó a entrarle la duda de si, una vez que las personas de la empresa proveedora actual fueran sustituidas por las personas de la nueva empresa proveedora, habría algún problema en aquello que la gente llamaba “traspaso de conocimiento”.
La preocupación fue mayor cuando Manu le preguntó a los actuales desarrolladores si estaba todo “documentado”, le bastó con ver la cara de los mismos como respuesta a la pregunta, más ahora que sabían que se iban y que no tenían porque ocultar nada.
Y la preocupación creció aún más al saber que a los jefes del actual proveedor no les había sentado nada bien la sustitución y que por ello no parecían muy abiertos a futuras consultas sobre cómo todo aquello había sido desarrollado.
Al final Manu llamó a un “consultor externo”, uno que si sabia del tema técnico. Que aún le preocupó mucho más, si aún era posible, cuando después de revisar la situación le soltó un montón de palabras técnicas que faltaban, que le sonaban a chino, pero que al parecer eran muy importantes, cosas del tipo a “no hay control de versiones”, “la calidad del código hace que sea inmantenible”, “hay partes, algoritmos, consultas SQL, etc., tan complejas que solo el que las hizo va a saber mantenerlas, a menos que se empiecen a refactorizar”, etc.
Y le propuso un plan de medidas para mejorar los procesos, la metodología, la calidad, la mantenibilidad, la formación del personal, etc., con el objetivo de minimizar la dependencia de las personas. Pero entre que todo eso a Manu le sonaba a chino, entre que le iba a costar dinero, que estaba harto de los técnicos y, principalmente, que él era economista, Manú tomo una solución mucho más rápida y práctica: obligó a la nueva empresa proveedora a contratar a las personas clave que antes trabajaban contratadas por el ahora antiguo proveedor.
Todos felices.