Presupuestos ágiles: nuestra desastrosa experiencia

Hace unos días llegó a mis manos este Hangout sobre presupuestos ágiles en el que participaban responsables de diferentes empresas del sector, como son RunRoom, Becode... Aquí podéis ver el vídeo.

Después de ver dicho vídeo, he considerado que quizás sería interesante explicar nuestras experiencia con los presupuestos ágiles.

La historia empieza el verano pasado -hemos preferido dejar un tiempo prudencial para madurar lo sucedido-, momento en el que realizamos nuestro primer 'presupuesto ágil'. ¿Pero qué es un presupuesto ágil? Como habéis podido observar, he puesto comillas para curarme en salud, ya que quizás muchos de los que lean esto no lo considerarían un presupuesto ágil. En todo caso, lo mejor es describir lo que hicimos y después que cada uno juzgue según su criterio.

El caso es que, después de un tiempo pensando en el agilismo -el bichito nos picó en el Drupal Day Valencia, en la charla de Emma López de beCode-, empezamos a implementar cambios a nivel interno. Había muchas cosas que ya realizábamos de forma ágil y que surgieron de manera natural en nuestro día a día, y otras que fuimos aprendiendo y aplicando a nuestra forma de trabajar. Ahora, el reto era sacar este supuesto 'agilismo' de nuestros mecanismos internos, e intentar implicar al cliente en el mismo. La ocasión se nos presentó con un cliente que conocía estas metodologías, tenía un proyecto que duraba unos tres meses y estaba dispuesto a firmar un contrato en el que el objetivo final no estaba plenamente concretado.

La propuesta

Después de hacer un análisis del proyecto a realizar y una aproximación en tiempo y personal dedicado, la propuesta definía tres sprints de tres semanas cada uno. Para cada sprint, una explicación del resultado final, sin entrar en detalle. Al final de cada uno de los sprints, una semana para que el cliente revisara el proyecto y diera el visto bueno al mismo.

La idea era, antes de iniciar cada uno de los sprints, definir un listado de historias de usuario, ordenarlas por prioridad, y ir trabajando en cada una de las historias hasta la finalización del Sprint. Por su lado, el cliente podía negociar en todo momento la prioridad de las tareas, y podría ir observando día a día los avances del proyecto.

La realidad

Teóricamente todo funcionaba a la perfección, y ahora era el momento de poner en marcha el proyecto. Lo primero que notamos es que la respuesta del cliente era bastante lenta. Es decir, no iba revisando el desarrollo frecuentemente, y su capacidad de respuesta era bastante limitada. A la finalización del primer Sprint, el trabajo realizado ya parecía insuficiente para el cliente. Se habían realizado cosas que quizás no eran tan importantes, y otras que eran esenciales no estaban listas. De todas formas, se firmó la finalización de dicho Sprint y se empezó con el segundo.

En el segundo sprint las cosas siguieron más o menos el mismo camino. Muchas dificultades para reunirnos con el cliente, poco seguimiento, y mucha “inventiva” por nuestra parte. Intentando entender el producto final, aplicábamos el sentido común, pero hay cosas que funcionan de una manera en nuestra cabeza, y de forma diferente en la cabeza del cliente.

Cerrado el segundo Sprint, de forma parecida al primero, se empezó con el tercer Sprint, y dicho inicio fue bastante desastroso, ya que el mismo se retrasó en el tiempo, y finalmente cuando empezamos a trabajar no teníamos el material necesario para realizar nuestro trabajo. Finalmente, la mitad del sprint se gastó en corregir cosas del segundo sprint, y tuvimos sólo la mitad de tiempo para realizar las tareas que realmente se tenían que realizar en el tercer sprint.

El resultado final no fue bueno, y tuvimos que hacer más horas de las estipuladas para finalizar de manera “digna” el proyecto.

¿Final feliz?

No, el final no se puede decir que haya sido demasiado feliz. El resultado ha sido un cliente insatisfecho y nosotros hemos trabajado más tiempo del que estaba estipulado en el contrato. Además, la finalización del proyecto trajo consigo una “quita” importante del importe del tercer y último Sprint porque el cliente consideró que los objetivos no se habían conseguido.

¿En qué hemos fallado?

Hemos fallado en muchas cosas, pero principalmente las podríamos resumir en tres puntos:

• El cliente no es ágil: Por mucho que a nosotros nos guste el agilismo, si no tenemos un cliente realmente implicado, es muy difícil realizar un proyecto de forma ágil.
• Compromiso: Falló el compromiso en muchos momentos, y no tuvimos el coraje de parar el Sprint si no teníamos el material necesario para realizar el mismo.
• Reaccionar antes: Nada más empezar el proyecto, deberíamos haber observado la deriva que iba tomando el mismo, y haber cambiado el criterio. Confiamos en que todo se solucionaría más adelante, y no fue así. Lo que mal empieza..

Conclusiones

Si tenemos que sacar alguna conclusión de todo esto, es que hay que seleccionar muy bien al cliente antes de hacerle una propuesta como esta. Si no se está dispuesto a actuar de una manera diferente a la que suele ser la habitual en este tipo de proyectos -te entrego la documentación, me olvido del proyecto y mágicamente, tres meses más tarde está todo perfectamente implementado-, no es aconsejable realizar dicho proceso.

Por nuestra parte, y pese al primer fracaso, seguiremos insistiendo. Creemos que una fuerte implicación del cliente en el proceso de desarrollo de su proyecto es fundamental -parece lógico, verdad?-.

Foto de Geomangio