Luego de muchos años de profesión como analista de sistemas , ya no me caben dudas sobre algunas cosas:
- la documentación es sumamente importante para soportar y mantener el trabajo de un proyecto o producto
- documentar absolutamente todo es demasiado y poco probable. En algunos casos inútil.
El reto de cualquier profesional de sistemas es el de encontrar el equilibrio sobre qué documentar, con qué grado de talle y cuándo hacerlo.
La documentación es cultural, si el profesional no documenta su obra, en mi criterio esa persona no es un profesional, es un artista hasta el primer mantenimiento y luego sin lugar a dudas un malabarista con todas las letras.
Es muy importante dejar rastro de la obra, sino la obra termina no existiendo.
Las documentación sirve para facilitar el mantenimiento y reducir las sensaciones, los conflictos y las malas interpretaciones.
Nadie lee todo y nadie sabe todo, pero existe un responsable del producto que debe tener ciertos elementos para hacer evolucionar al producto de software desarrollado e implementado , en nuestra cultura es el analista-diseñador del sistemas.
El programador para bien o para mal tendrá siempre una visión parcial del producto total, excepto que el programador sea analista en el mismo proyecto, pero es algo que va perdiendo fuerza y sostenibilidad con los softwares cada vez más complejos.
La primera premisa básica en cualquier intervención sistémica es que debe existir un mínimo de documentación y no es el código ese mínimo, excepto que sea un prototipo, aún así lo pongo en dudas.
La documentación permite comunicar ideas, conceptos y decisiones. Alguna documentación resulta crítica para el proyecto / producto y otra resulta complementaria.
Como sea, y en cualquier metodología con la que desarrollemos nuestro trabajo profesional, este debe quedar documentado.
Se documenta para los cambios, para la evolución del producto y para tener un punto de partida para el crecimiento del software, del sistema o de la aplicación (o como te guste llamarlo).
Se documenta para conocer el impacto.
No te olvides que los requerimientos, cambian, las reglas cambian, el cliente cambia y los trabajadores de tu organización cambian, incluso cambian los equipos, entonces tenemos buenas razones para documentar, pero no perdamos de vista que debemos documentar lo que merece la pena ser documentado. Por esto, la documentación irá evolucionando en la medida que se necesite.
Los requerimientos funcionales son necesariamente documentables; en definitiva ellos dicen que debe hacer el software.
Las reglas de negocio refieren a las normas y pautas sobre la que el software está limitado a funcionar dentro del marco de, por ejemplo, una organización.
Luego puede aparecer un set de modelos interesantes que serán más relevantes en ciertos proyectos que otros. En mi opinión es visión del profesional expandir la documentación, o bien, retraerla en la medida que así lo vea necesario.
Es importante pensar en un mínimo y en la calidad. Generar documentación que nadie entiende o nadie le resulta de utilidad es una pérdida de dinero.
