Sunday, 3 January 2016

Requisitos que pueden cambiar

Hace ya unos cuantos años, antes de aplicar por completo todo esto de agile, trabajé en el desarrollo de una aplicación web que debía gestionar las fichas de trabajo del cliente mediante una serie de pasos o wizard que guiase al usuario sobre la fase en la que estaba.

Realizamos un análisis completo, recopilamos todas las necesidades que el cliente tenía y de ahí salieron una lista de funcionalidades a implementar. Todo normal. Funcionalidades correctas y coherentes que solucionaban problemas concretos. Con el grueso documento de requisitos y su correspondiente diseño nos pusimos a implementar, una tras otra, cada una de estas funcionalidades.

En aquel momento ya intentamos ser algo ágiles (some way) e íbamos enseñando en pre-producción cada dos semanas lo que íbamos haciendo. No tenía mala pinta. Era fácil de usar e incluso nos dieron la enhorabuena por el trabajo que iban viendo. Estábamos contentos por lo que continuamos así hasta desarrollar con no poco esfuerzo hasta la última de las funcionalidades que estaban en el documento de análisis aprobado. Y subimos a producción...

En cuanto los administrativos estuvieron unos días usando la aplicación se dieron cuenta que habrían venido bien algunos cambios: incluir una tabla en cada pantalla con los documentos originales para no perderlos de vista, evitar salir a otro menú cuando se quiere crear una entidad, añadir más controles para evitar errores al finalizar una ficha, etc. La mayoría eran pequeños cambios que no llevarían más de 2 o 3 días de desarrollo pero nosotros ya habíamos acabado el presupuesto (y más).

Entre las funcionalidades que habíamos desarrollado al principio, había algunas de bastante complejidad que te permitían complicados cambios entre procesos, y que costó bastante desarrollar (y testear para tener en cuenta todos los posibles casos). Pregunté por ellas meses después pero nadie sabía de su existencia ni en qué menú estaban. Tampoco le dieron importancia. Cuando habían necesitado algo parecido cancelaron el proceso y empezaron uno nuevo.

Cuando empezamos el proyecto, ni yo, ni el cliente, ni los usuarios teníamos una idea exacta de lo que iba a funcionar bien. Simplemente no podíamos saberlo a ciencia exacta. ¿Qué podíamos haber hecho para evitar esto? Pues subir a producción en cuanto tuviésemos las funcionalidades básicas para los primeros procesos. Ahí habríamos visto con facilidad todos estos pequeños cambios que habrían hecho la aplicación más práctica y fácil de usar.

Desde entonces, en nuevos proyectos, cuando los usuarios ven la necesidad de cambios como éstos, me preguntan por la posibilidad de incluirlos. No tienen ningún problema en descartar otras funcionalidades de las que ya ni se acuerdan porqué las pusieron en los pliegos de contratación o a las que ahora no le ven tanto sentido.

La lista de funcionalidades está estimada desde el inicio en el product backlog y el cliente conoce esta estimación. Simplemente nos dice 'Quítame la funcionalidad número 18 que llevaría 8 días de trabajo y cámbiamelas por estas dos nuevas que suman 6. Guardamos estos dos días por si solicitásemos algún cambio más'.

Éste es otro de los principios ágiles:
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
En general supone una ventaja para el cliente que obtiene un producto que le funciona y que no queda cojo hasta que se realice una nueva contratación para un mantenimiento evolutivo (a pagar con dinero extra), pero también es una ventaja para nosotros como proveedores que sumamos un proyecto que nos sirve referencia, en el que controlamos bien cada hora invertida y evitamos entregar un producto, en el que gastamos todo el presupuesto y al que le faltan cosas importantes.


No comments:

Post a Comment