archivo

Archivos diarios: abril 3, 2012

Cuando se está definiendo el alcance de una determinada funcionalidad de un sistema de información (esto es extensible no solo a tareas de desarrollo, se puede aplicar perfectamente al campo de la consultoría) y se despegan los pies del suelo (nos pasa a todos), el usuario puede empezar a pedir que haga cosas que realmente no necesita o que se encuentran demasiado próximas al terreno de la Ciencia Ficción (el famoso botón rojo que automatice todo lo automatizable y más allá) o que seamos nosotros los que añadamos complejidad adicional a dichas especificaciones (o alentamos a los usuarios a ello).

En muchos proyectos se tarda mucho en bajar a un nivel de realidad acorde al mismo, llegándose incluso a necesitar varias iteraciones para alcanzarlo, eso en el mejor de los casos, cuando no implica tirar a la basura todo el trabajo realizado.

Hay una cita de Richard B. Smith que resume de manera muy acertada la pérdida de tiempo (esfuerzo y dinero) que supone no centrarnos en lo relevante y sí en buscar soluciones lo mismo más atractivas técnicamente, pero que complican el desarrollo sin satisfacer las expectativas reales del usuario: “Mis pobres ojos y manos se ponen muy contentas cuando la programación ya se encuentra fuera de la fase ‘Mono con plumas'”.

Los manuales de una aplicación, de una interfaz de comunicación presentan los problemas típicos de cualquier documentación y es que si no se contempla dentro del proceso de desarrollo de software su actualización y/o una correcta gestión de la configuración nos encontraremos con mucha documentación que realmente ha servido mucho menos que el esfuerzo que ha sido necesario para generarla y otra que probablemente haya quedado desfasada.

Ya sabéis mi opinión sobre la documentación: cada proyecto debería tener solo aquella que sea estrictamente necesaria para el mismo respetando las directrices de calidad del proceso de desarrollo de nuestra propia organización y de la organización para la que se desarrolla debiendo tenerse en cuenta en los costes del proyecto el necesario para gestionar la documentación como parte del propio proceso de desarrollo.

Si la documentación se entiende como un elemento aparte, sucede lo que en la mayoría de los proyectos, algo que Ray Simard resume de manera muy acertada cuando define de manera irónica lo que es un manual: “Unidad de documentación en la que hay siempre tres o más unidades y/o versiones. Una está accesible y alguien tiene las otras. La información que necesitas se encuentra en las otras”.