Uno de los problemas principales de que la informática no sea considerada como una ingeniería es la falta de generación de documentos. No se crean porque no se sepa qué hay que hacer, sino porque no hay una conciencia de que se tienen que generar. Es evidente que es necesario generar informes sobre la arquitectura del proyecto y su estado, pero debemos ir más allá. ¿Cuáles son los límites de un proyecto? ¿Qué nos pidió el cliente? ¿Qué es importante y qué no lo es?

Es necesario, en cualquier proyecto serio, establecer una línea que separe claramente qué es lo que se va a hacer y qué no. Esta línea debe ser aceptada explícitamente por ambas partes, de forma que cualquiera de las dos puedan presentar una prueba en caso de error o problema. Tendemos a pensar de forma positiva, minimizando el impacto de futuros problemas: “ya haré la copia de seguridad mañana, ya le enviaré el acta de reunión después”.

Debemos evitar “acordarnos de Santa Bárbara cuando truena”. Debemos establecer un plan estricto de gestión que nos ayude en nuestro trabajo diario, evitar el tener que pensar en “qué viene ahora” o “¿Qué había que hacer para …?”. En resumen, nuestro título de ingeniero no debe servir sólo para decorar una pared.

Artículos relacionados

• 31/Dic/2008 -- Caída y auge del sector software (y VII)
• 30/Dic/2008 -- Caída y auge del sector software (VI)
• 29/Dic/2008 -- Caída y auge del sector software (V)
• 28/Dic/2008 -- Caída y auge del sector software (IV)
• 27/Dic/2008 -- Caída y auge del sector software (III)
• 26/Dic/2008 -- Caída y auge del sector software (II)
• 25/Dic/2008 -- Caída y auge del sector software (I)
• 24/Nov/2008 -- Marketing democrático
• 14/Nov/2008 -- Sobre software, apagones y responsabilidades
• 7/Nov/2008 -- La importancia del software

1. makj dice:
   03 de Diciembre de 2008 a las 10:05

   totalmente de acuerdo, quizá la solución sería generar toda la documentación ANTES, como un elemento más del propio proyecto sin el cual no se puede siquiera plantear el hacer nada precisamente para como tu bien dices llegar a un acuerdo con el cliente mediante su aprobación, y no como un añadido a modo de explicación de lo que se ha hecho (porque además asi es increiblemente fácil olvidar “lo que hice aquel dia que tuve la brillante idea para resolver el problema que tuvimos durante dos semanas y que una vez hecho nadie más supo de aquello salvo por el hecho de que todo funcionaba por fin”)
   creo que los planes de estudios universitarios deberian poner más enfasis en este aspecto, y también que los colegios informáticos que hay por el momento también podrian aportar su granito definiendo unos modelos de documentación estándar por proyecto (sino seguirá pasando como hasta ahora y cada uno hará la suya a su manera)