Es extraña la forma en que como desarrolladores/programadores pensamos las soluciones, incluso, me atrevo a decir que dentro de la gamma de desarrolladores existen aun mas ramificaciones que podríamos agruparlas según su tipo, desde el desarrollador con tendencia a simplificar y optimizar (me considero dentro de este grupo), pasando a través de los clásicos suiteros (aquí los que nunca dejan las tecnologías de Microsoft), los innovadores que eligen tecnologías a la vanguardia, los extremistas desarrolladores de emac's (a estos los suelo admirar de vez en cuando), hasta los que programan en lenguajes no muy conocidos y muy subterraneos.

Cada uno de estos tipos suele arrastrar detalles que al otro le molestan, pero, no suelen afectar tanto el desarrollo en sí como lo pudiera ser un error arrastrado desde los simientos.

Actualmente me encuentro terminando un proyecto muy importante para la empresa donde laboro . Proyecto en el cual fungí como coordinador y arquitecto de gran parte de él, pero que debo admitir, aun veo fallos y detalles que pueden mejorar con un poco mas de trabajo .

Cuando se comenzó el proyecto, el cliente directo entrego una completa documentación que brindaba detalles desde lo general hasta lo particular y que describía ciertos procesos que el sistema debería automatizar, módulos con los que debía contar, tecnologías a usar (como recomendaciones), así como tiempos de análisis, desarrollo, pruebas, implementación y capacitación medidos.

Sin lugar a dudas sorprendía la cantidad de información agrupada y entregada para el desarrollo.

El desarrollo tenía la finalidad de solventar la necesidad del cliente, que básicamente era tener un conjunto de información que pueda consultar para obtener detalles específicos. En particular, cuestiones agrícolas en Jalísco .

El sistema debería ser alimentado constantemente por alguien, despachos contratados con esta única finalidad, brindar información. Así que, gran parte de la funcionalidad debería ser tomada en cuenta para estos despachos que resultarían usuarios de la aplicación.

La documentación especificaba como debía ser la funcionalidad , así que, se trabajó en el desarrollo basándose en estas estipulaciones durante 6 meses aproximadamente.

Tiempo en el cual, el grupo desarrollador no tuvo contacto con los verdaderos usuarios, los despachos (según las especificaciones no hacía falta).

No fue si no hasta la semana pasada, cuando, el grupo desarrollador tuvo contacto directo con estos usuarios, 2 despachos que hasta el momento no habían visto/probado la funcionalidad del sistema (el contacto siempre fue con el cliente directo, asumiendo que este había analizado todos los pormenores por contar con un departamento de TI ).

Estos 2 despachos, aun laborando en rubros comunes, su alcance y necesidad eran distintos, y mientras el sistema se adaptaba muy bien a un despacho, al otro le era completamente inservible. El primer despacho canalizo perfectamente la idea del proceso automatizado para sus fines propios, el objetivo aquí se había cumplido.

El segundo despacho ya había solventado la misma necesidad por sus propias manos, de forma mucho mas primitiva, pero que, resolvía su problemática de forma eficaz , incluso, explotando el alcance que este medio le daba recolectando un 90% mas de información que la especificada en la documentación. Así que el objetivo se habría truncado para este usuario. El error mas grande cometido entonces, había sido un mal análisis de requerimientos con los usuarios, cuestión que estaba fuera de nuestro alcance.
Esto muestra la gran importancia que sustenta un buen análisis, de ello depende el éxito final de nuestros desarrollos.
No puedo decir que fue un fracaso total por que se cumplió con estipulaciones, y lamentablemente en muchas de las ocasiones no esta en las manos del desarrollador generar el sistema ideal para todos los usuarios.

Jorge Hernandez :: http://jorgeluis.com.mx

    Aprendiendo Django [III] :: El proyectoSonidos de π y Ταυ