archivo

Archivos diarios: septiembre 28, 2011

Muchas veces se solicitan funcionalidades manifiestamente innecesarias o cuya complejidad (y posterior utilidad) no la hace rentable.

Como sabéis, soy partidario de dejar la imaginación al área usuaria, si bien, es conveniente advertirles de los pros y contras que podría tener el desarrollo de una determinada funcionalidad.

Es cierto que en muchos casos, el área usuaria por mucho que le digas, por mucho que le adviertas, termina tomando la decisión de que la evolución se realice y no quedará otra que ejecutar el trabajo, no obstante, si pasa el tiempo suficiente (y se le vuelve a insistir), lo mismo terminan reconsiderando su decisión inicial.

Sobre el tema del desarrollo de funcionalidades que pueden ser prescindibles, en ocasiones sería conveniente recordarle a los usuarios las reglas de optimización de Michael Anthony Jackson (que si bien las enunció para la optimización de código, son perfectamente válidas para el ámbito que nos ocupa en este artículo y en otros muchos):

“Regla 1: No lo hagas.

Regla 2 (solo para expertos): No lo hagas, todavía”

En ocasiones, ante la ausencia de un gobierno funcional en el proyecto se le encarga al equipo técnico explorar los diversos departamentos afectados por el mismo, ya sea para obtener los requisitos funcionales o para intentar que utilicen el sistema.

Esto es un error, ocasionará mucho trabajo, desgaste y probablemente los resultados estén por debajo de ese esfuerzo y de la inversión realizada en el desarrollo.

Motivos:

1) En el caso de que desde etapas iniciales del proyecto no haya colaboración por parte del área usuaria en la coordinación de la selección de las funcionalidades es un síntoma de que se está desarrollando un sistema que entienden que no necesitan. Lo mismo, a nivel de organización, sí interesa su implementación, pero ese mensaje no ha llegado al área usuaria o no ha sido suficientemente convincente.

2) El problema anterior se seguirá produciendo, si no se soluciona, en las diferentes etapas del proyecto y por supuesto en su puesta en marcha: habrá usuarios que utilicen el sistema, otros que lo usen a su manera y otros que se nieguen a abandonar las herramientas (aplicaciones, soluciones ofimáticas, etc…) que venían utilizando hasta ahora.

Después, entre quienes usen el sistema habrá quienes pidan unas funcionalidades, quienes pidan otras o quienes pidan lo contrario que ha solicitado otro y nos encontraremos con el problema de definir las prioridades, de elegir una opción sobre otra, etc…

Es un mal síntoma para un proyecto de desarrollo de software cuando el personal técnico tiene que ponerse el salacot y utilizar el cazamariposas.