Documentación Util

Este es un punto donde hay mucha discusión ya que tenemos en el enfoque básico que indica que cuanto mas documentación se haga y cuanto mas detalle tenga esa documentación mejor. Pero este planteamiento es el claro ejemplo de cosas que suenan bien pero en la practica son un fracaso. Por que? vamos a ver los factores que SI hay que tener en cuenta:

• Tiempo de elaboración: Cuanto mas extensa y mas en detalle sea la documentación mas va a costar redactarla.
• Mantenimiento: No existe (al menos en el mundo del software) documentación que este bien desde el principio. Ni los pliegos. Cuanto mas extensa y mas en detalle sea la documentación mas va a costar las modificaciones y las ampliaciones.
• Capacidad de comprensión: la documentación tiene que ser un punto de referencia, debe ser la "CONSTITUCIÓN" del reino del proyecto. Cuanto mas extensa y mas en detalle sea sera mas posibilidad exista de que en algún punto diga una cosa y en otro diga completamente lo contrario (que existan contradicciones).

La documentación de software debe seguir la siguientes reglas:

• Del axioma "Cuanto mas extensa y mas en detalle sea ..." del punto anterior tampoco saquemos la conclusión de que la documentación debe ser escasa. La documentación en un proyecto de desarrollo de software debe ser precisa y completamente determinista.
• Debe tener el mayor número de dibujos que expliquen gráficamente lo que se esta explicando con palabras.  
•  Debe tener un formato fácilmente accesible por todo el mundo. Sea técnico, gestión, cliente, etc.. Olvida los words, excel, etc... Tiene que ser un formato web tipo wiki, blog, etc..

La clave es que cuando algún miembro del equipo pregunte por cualquier cosa se le pueda solucionar "enviandolo" a una url donde esta la documentación precisa que le solucione el problema.