¡Necesito evitar la dependencia de las personas!

Dependencia de las personas… el gran terror de miles de responsables de proyecto, de gerentes, socios, directores, etc. Más aún si cuenta con personal externo ¿Qué hacer? ¿Cómo hacer para no depender de ciertas personas? ¿Y si Pepe se va de la empresa? ¿Y si no queremos seguir contando él?
Lo primero que a cualquiera le viene a la cabeza es que, para no depender de Pepe, hay que, valga la redundancia, sacarle a Pepe las cosas de la cabeza. ¡Que alguien escriba lo que Pepe hace en un documento! ¡Documentación! De echo, en parte, este motivo dio origen a la inconclusa era de la “sobre documentación”.
Todo en papel. No se da el siguiente paso en el ciclo de desarrollo… si antes alguien no escribe el paso previo en un papel.
Hasta este punto, mucha gente se cree segura, muchas veces viviendo en una falsa seguridad. Tengo documentado todo lo que se ha implementado y además cómo se ha llegado a ello, y todo ello en un papel.
Pero como comentábamos en la verdadera calidad software la tienes que ver en los fuentes, en el código, no te fíes de nada más… ¿De verdad crees que lo que hay en un papel vale para algo? ¿De verdad crees que lo que hay en un papel se parece en algo a lo que de verdad se ha programado? ¿De verdad?
Yo que tu… mmm no me fiaría. Yo hay veces que ni me fío ni de los fuentes que hay en control de versiones, porque muchas veces ni coinciden con el software que hay en producción.
La historia de la ingeniería del software está llena de “inventos” ingeniados para asegurar que los documentos reflejan la realidad del software implementado, desde las auditorías, pasando por las matrices de trazabilidad, el “round trip” (actualizar los UML cuando se toca el código), etc. Pero realmente… no han terminado de funcionar.
Mientras, ingentes cantidades de documentos se han ido generando. Horas. Meses. Personas y personas dedicadas a documentar. Desperdicio y desperdicio en terminología Lean.
¿Quieres un consejo? ¿Sabes cuál es la mayor garantía de no dependencia de personas? Cómo no depender de aquel que programó algo…. Tener buen código. Código limpio. Buenos diseños. Buenas Pruebas. Buen control de versiones. Métricas de calidad software en valores razonables. No tener exceso de líneas de código. No tener aberraciones en el diseño. Etc.
Ya, si lo sé. Que esto es mucho más difícil de entender y de explicar a muchos gerentes y responsables de proyecto. Es más fácil entender “lo importante de documentar” que entender lo que son “aberraciones en diseño y código”.
Pero nadie dijo que esto era fácil, el software, eso que revoluciona negocios, que cambia el mundo, no podía ser tan fácil. Y para entenderlo necesitas profesionales cualificados.
¿Qué? ¿qué pasa con los documentos? ¿qué si no hay entonces que documentar? Sí, claro. Yo no dije que no documentases, yo digo que hagas documentación inteligente, documentación útil. No documentación tan difícil de mantener que nadie la mantiene y nadie se fía de ella.
Documentación cuyo propósito no sea poner el código en un papel. Documentación que sirva de guía, al igual que un esbozo de un mapa no pretende representar todos los detalles de la realidad.
Pero por muy buena documentación que tengas, recuerda, no serás tan libre como teniendo buen código.