Es un error muy común pensar que la documentación es poco importante o directamente prescindible, hoy vamos a ver algunas de las posibles consecuencias de no ir generando una documentación adecuada a lo largo del ciclo de vida de un proyecto.
¿Cuántas veces en un proyecto que va retrasado se ha sacrificado una correcta documentación en favor de más tiempo de desarrollo?. Se tiende a pensar que la documentación no es más que un “mal necesario” y en la tabla de tareas suele estar en el último lugar, dejándose siempre para el último momento “si hay tiempo”.
La documentación es una parte muy importante del desarrollo de un proyecto, nos facilita su seguimiento, ayudándonos a encontrar con mayor facilidad posibles fallos que en su momento hubiesen podido pasar desapercibidos, por no hablar de ser un apoyo imprescindible en caso de que haya un cambio en el personal del proyecto. Asimismo permite una vez finalizados los proyectos, tener un repositorio de consulta sobre cómo se realizó el desarrollo de los mismos y los cambios y mejoras que se han dado desde entonces.
Pongamos un par de ejemplos ilustrativos.
1 – Durante el desarrollo de un proyecto, en una fase ya avanzada del mismo, uno de los programadores sufre un percance y coge una baja que le impedirá continuar desarrollando sus funciones. Como ha sido un percance, no estaba planificado y por tanto no se ha podido realizar un traspaso de conocimientos, de un día para otro uno de los puestos ha cambiado y se ha tenido que asignar a toda prisa a otro programador al proyecto para cubrir el puesto. En este escenario se pueden plantear dos opciones, la primera es que se haya ido realizando una correcta documentación del trabajo realizado, en este caso el nuevo programador podrá apoyarse en ella para comprender el trabajo de su predecesor y en un corto espacio de tiempo podrá continuar con su trabajo manteniendo una coherencia con el mismo al seguir los mismos patrones de desarrollo establecidos. La segunda opción es que el nuevo programador se siente frente al ordenador y desgrane toda la tarea de programación de su predecesor, teniendo que revisar línea a línea todas las funciones que se hayan implementado hasta la fecha para después empalmar su propio trabajo sin seguir una pauta concreta. En el primer escenario el trabajo sufre muy poco retraso y el desarrollo final no se ve apenas afectado, en el segundo, el tiempo necesario para continuar trabajando se multiplica exponencialmente al trabajo ya realizado y el cambio de patrones entre ambos programadores puede suponer nuevos retrasos al final del proyecto.
2 – Una empresa contrata a un equipo de consultores para añadir nuevas funcionalidades a su sistema “de toda la vida”, básicamente se busca añadir valor a una serie de funciones que llevan en uso 20 años o más, de hecho, nadie en el cliente recuerda exactamente quien las desarrolló y mucho menos como lo hicieron, además desde entonces se han producido numerosas “intervenciones” sobre dichas funciones para ir adaptándolas a las necesidades puntuales que iban surgiendo en su negocio. Nuevamente tenemos dos posibles escenarios, si hay una buena documentación guardada, en la que se detalla no solo como se realizaron las funciones originalmente, sino también un registro de quien, cuando y como se realizaron las “intervenciones” de mejora, el equipo de consultores tendrá una base sólida para comprender lo que hay y podrá realizar su labor rápida y eficientemente sin demasiado riesgo de alterar nada que no deba ser tocado. En el segundo escenario los consultores no tienen nada a lo que recurrir como apoyo a su trabajo, por lo que tendrán que investigar con minuciosidad todo el contenido del sistema, validando una a una sus funciones para garantizar que siguen en uso y que funcionan acorde a lo esperado. En este escenario las labores de consultoría se dilatan enormemente en el tiempo y se corre el riesgo de que alguna función cuyo contenido no está claro, sea alterada provocando errores y más retrasos.
Como podéis ver, ya seáis una empresa de servicios externos o un cliente final, es primordial planificar adecuadamente los tiempos de ejecución contando con márgenes prudenciales para que se pueda ir desarrollando una correcta documentación del proyecto en paralelo a los avances del mismo y nunca dejar de hacerla ya que no podéis preveer cuando la vais a poder necesitar.
Espero que os haya resultado interesante y que en adelante no volváis a dudar de la importancia de una buena documentación.
¡Nos vemos en próximas entradas!
yo anadiría, que la mala imagen que daría el departamento hacia el cliente, o simplemente hacia los otros departamentos, cuando llaman a preguntar por el status y se responde: «no se, el encargado de ese proyecto está enfermo» se deterioraría mucho.
tambien cabe decir que a la larga se ahorra tiempo de reacción con una buena documentación, ya que en futuras incidencias, solo habría que mirar como se solucionó en el pasado.
como siempre, muy interesante lo que encuentro por aquí!
Me gustaMe gusta