El Conocimiento es un activo de la organización (1ª parte)

Cuando alguien que hace muy bien su trabajo es promovido a otro puesto o es llamado por otra organización, normalmente deja un hueco, no solo en el lugar físico que dejó, sino en el conocimiento de la organización. Si la organización no “captura” ese conocimiento en algún medio, lo pagará a corto (resolución de problemas inmediatos) y a largo (curva de aprendizaje del nuevo elemento) plazos.
En un departamento de Sistemas o en empresas de consultoría de sistemas hay gente valiosa y creativa que disfruta con lo nuevo, estrena frecuentemente “gadgets” que lo hacen estar a la vanguardia de la tecnología y se entusiasma con los proyectos nuevos en los que participará. Es la misma gente que, en el lado obscuro del ejemplo, no gusta de dar mantenimiento a código que no hicieron ellos ni a aquel sistema que está en una tecnología antigua. Es ese tipo de personas que aborrecen el lado no-creativo o monótono del proyecto como lo es la documentación y que pasan por esa etapa del proyecto entregando el mínimo necesario para que les permitan poner su sistema en producción.

Hubo un tiempo en que en nuestra empresa la rotación de personal era un concepto lejano, pero llegó el momento en el que convirtió en un inconveniente. El problema lo experimentamos de inmediato en lo más evidente, pero conforme ha pasado el tiempo, nos hemos dado cuenta de que en la brecha del conocimiento de los sistemas, se ha ido mucho más de lo que hemos querido.
La mínima documentación y el almacenaje desestructurado dificultan gravemente la búsqueda de respuestas y, en ocasiones, se ha optado por rehacer alguna funcionalidad de los sistemas.
No a manera de conclusión, pero si como una introducción a la segunda parte de este post, permíteme adelantar algunas Lecciones APrendidas.

1. No esperes que sea cierto cuando un trabajador que se retira de la empresa diga “contáctenme para cualquier duda” ni tampoco si dice “cuando contraten a otro, yo vengo los fines de semana a enseñarle”.
2. Haz de la documentación un entregable del proyecto y define métricas de calidad para cada tipo de documento y verifica que se cumplan como en cualquier otro entregable.
3. La documentación debe estar almacenada de una manera consistente y centralizada en un repositorio público al resto del equipo de trabajo.
4. Comunica a todo el equipo cuando se genere un nuevo documento y desarrolla un procedimiento de atención a problemas (si no existe alguno en tu empresa) en el que uno de los procesos sea la revisión de la documentación existente.

En el siguiente post, concluiré con este tema comentando cómo el PMI se refiere a esta información almacenada y cómo sugiere su uso.
Mientras tanto, deja un comentario sobre cómo se maneja la documentación en tu compañía o equipo de trabajo. ¿A qué situaciones te has enfrentado y cómo las resolviste?