La importancia de la transmisión de conocimiento en proyectos de IT

Por Javier Sotomayor Aramburu
COO de OpenSistemas

Uno de los grandes problemas a los que se enfrentan los equipos de trabajo en proyectos de tecnología es el de la transmisión de la información relativa al proyecto entre los distintos integrantes del mismo, tanto en proyectos pequeños que se quedan parados durante meses y se evolucionan más adelante, muchas veces con personas distintas a las originales, como en proyectos grandes de larga duración en los que puede haber rotación de recursos y cada nuevo miembro tiene que absorber mucha información antes de ser operativo.target=”_blank”

Es muy importante en los proyectos el realizar una gestión correcta de la información asociada al mismo para que cuando se incorporan personas nuevas puedan ser autónomos en el menor tiempo posible. Y en este tipo de proyectos entendemos como información la asociada sobre todo al ámbito técnico: documentación sobre arquitecturas, modelos de datos, definiciones técnicas y comentarios en el código que ayuden a los nuevos incorporados a ejecutar sus tareas sin tener que analizar durante días la arquitectura y código del proyecto.

Equipo de OpenSistemas durante una transferencia de información sobre WordPress

Equipo de OpenSistemas durante una transferencia de información sobre WordPress

No me refiero a aquella documentación que metodologías como Metrica 3 requiere que se realice, ya que cada una implica unos pasos distintos en cuanto a documentación se refiere, si no a que hay distintas fuentes de información que son básicas en cualquier proyecto informático y que es necesario tener en cuenta para que las rotaciones de recursos no afecten a su ejecución, y que se pueden agrupar así:

· Arquitectura técnica: Es un documento que recoge la estructura de servidores, bases de datos, canales de comunicación, etc. del sistema que se está implementando. Da una visión a alto nivel del sistema y ayuda a la persona que se incorpora a entender las piezas del sistema a nivel global. Normalmente es una única página pero da una visión muy clara de dónde estamos.

· Modelo de datos: En el caso de que existan bases de datos, esta documentación incluye un diagrama del modelo de datos con explicaciones de las tablas y elementos que interaccionan en el sistema, o al menos las más importantes, dando una visión de dónde están los datos y como están organizados.

· Documentación de gestión: incluye toda aquella documentación relativa a la gestión del proyecto, listado de stakeholders, informa de riesgos, equipos de trabajo, planificación del proyecto, tareas a ejecutar, etc. Esta información es de control del proyecto y se usa en la capa más alta del equipo de trabajo y es la que se suele exigir al aplicar metodologías de desarrollo.

· Documentación de código: Documentación relativa al código del sistema, en cuanto a cómo está estructurado, carpetas en las que está el código, clases y objetos usados, nomenclaturas utilizadas, etc. Le permite a la persona que va a modificar el código entender como está estructurado. Aquí son clave los comentarios en el código, que expliquen con palabras claras lo que hace cada función para que se entienda perfectamente sin tener que analizar líneas de código.

· Traspaso a través de formación: Es muy frecuente en este tipo de proyectos que los que conocen la plataforma hagan el traspaso a los que se incorporan al proyecto a través de una reunión-formación en la que se explica lo que se ha hecho hasta ahora para facilitar la incorporación de nuevos recursos, evitando que tengan que autoformarse leyendo documentación y facilitando el arranque en el nuevo proyecto.

Por desgracia el mantener una documentación de calidad en algunos proyectos es complicado porque se suelen manejar fechas muy ajustadas. Muchas veces se deja para el final, pensando que habrá tiempo de hacerla cuando estemos finalizando. Esto es siempre un error. Documentar técnicamente un proyecto es un proceso vivo que tiene que avanzar a lo largo del desarrollo, y si no se hace así tarde o temprano pagaremos el precio de no hacerlo.