Un mal análisis significa, el fracaso de nuestros desarrollos

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.

5 Comments

  1. Posted July 20, 2011 at 9:33 am | Permalink

    Muy bueno tu post. Pareciera como si, al desarrollar sistemas bajo estandares e instrucciones preestablecidas, se estuviera trabajando a ciegas.

  2. Sandra
    Posted July 20, 2011 at 11:07 am | Permalink

    Lamentablemente el que paga el desarrollo se siente el “dueño del sistema” aunque sus alcances no sean una solución real para los verdaderos usuarios.
    Muy buena experiencia al final para aprender…

  3. Posted July 20, 2011 at 11:14 am | Permalink

    @Noe gracias por el comentario, en lo particular me agradan los estandares, mas bien me refería a estipulaciones generadas sin un buen análisis que son entregadas a un equipo desarrollador, y que este, como bien comentas, trabaja a ciegas basándose en estas.

    @Sandra: excelente experiencia, y así es, no por que eres el inversor mayor del proyecto debe acatarse a tus ideas, si no por el contrario, debes enfocar tu esfuerzo en solventar la necesidad de los que verdaderamente usaran la aplicación.

  4. Posted July 20, 2011 at 9:57 pm | Permalink

    Lo que comentas es muy comun, para mitigar estos problemas es recomendable la implementacion de metodologias agiles como Scrum.

  5. Posted July 20, 2011 at 10:59 pm | Permalink

    @itzcoalt creo que el problema va mas allá de una metodología de desarrollo, si hubiésemos trabajado con scrum, el cliente directo siempre fue el mismo, y este nunca considero pertinente mostrar la funcionalidad a los verdaderos usuarios por que el mismo se consideraba un usuario. Aun mas, acatado a estipulaciones, es complicado romperlas, el cliente directo pide tales procesos y tareas, el desarrollador debe entregarlas como lo pide.

Post a Comment

Your email is never shared. Required fields are marked *

*
*