¿Cómo «facturar» un «proyecto» Ágil en el mundo real?

En el mundo ideal, y pocas veces real, la colaboración con el cliente es maravillosa, incluso no hay presión de los clientes (incluso tenemos más bien usuarios que descargan apps y no legacy viejuno), hacemos productos, productos web en los que una vez terminada una historia de usuario se puede pasar inmediatamente a producción, nuestros backlog sólo tienen historias todas ellas relacionadas que nos dejan súper limpio tener bonitos objetivos para nuestros Sprints (te dejo post) y nos reducen los cambios de contexto.

Pero en el mundo real lo que pasa es que hay infinidad de sitios que tienen clientes que condicionan el roadmaps de sus productos, condicionan qué tienen que hacer sus equipos, hay clientes que solo entienden la peligrosa palabra proyecto y hay que ingeniárselas para encajar esa cultura de proyecto (fecha inicio, fecha fin y alcance cerrado) en una cultura ágil, en el Product Backlog entran historias de diferentes PROYECTOS por necesidades de negocio, incluso historias de diferentes clientes, etc.

Te dejo vídeo relacionado sobre los Roadmaps Ágiles (recuerda que puedes ayudarnos con el canal de YouTube con algo tan simple como suscribirte aquí y darle me gusta al vídeo)

En el post de hoy, que viene de:

  • Una conversación hace unas semanas con nuestro Mr. NoBody de hoy, que trabaja con clientes que sólo ven proyectos, que por las necesidades de la vida sus equipos no pueden centrar un Sprint sólo en un cliente, etc.
  • Que además estoy actualizando toda la información que tengo de contratos Ágiles, etc., para la formación Agile Transformation Program, que empieza en 15 días

Y, por gestionar expectativas, no hay una solución mágica a este problema y si diferentes alternativas (que tristemente no son happy ágiles, pero es que la realidad es dura y el trabajo duro es «hacer ágil» lo que no es fácil).

Así que vamos a repasar opciones (y si alguna se nos ha escapado… déjanosla en un comentario, que se agradece), que van a ir de lo que en mi opinión es más «puro» a lo que es más complicado (no digo Oscuro).

1 – Facturar por Sprint

Esto sería bastante fácil de gestionar, si tenemos mínimamente montado un modelo de gestión Ágil, en el que debería haber equipos estables y multifuncionales, por lo que sabemos con exactitud lo que nos cuesta un Sprint.

Esta sería versión más pura de lo que se conoce como «time and materials» y que sería la más Ágil

El problema aquí es que hemos metido sólo tiempo transcurrido y no trabajo completado (y mucho menos aún valor aportado, pero eso es otra historia), es decir, que no influye en la facturación al cliente terminar más o menos historias de usuario, lo cual para algunos clientes puede sonarles raro y, además, sólo funciona si trabajamos el 100% del Sprint con el mismo cliente, si no ya hay que hacer cosas raras que a mí no me gustan nada, como llevar exaustivos controles de horas.

Así que, si esto no nos encaja, podemos pasar a…

2 – Facturar por HU terminada

Podemos acordar un precio por Historia… si son todas de un tamaño similar (que sería lo mejor del mundo, por lo que nos ayuda, no sólo con el tema de facturar, sino con otros como el noestimates, etc., más info de esto aquí).

Así que, si esto tampoco nos encaja, tendremos que ir al Lado Oscuro de los Puntos Historia o las ponderaciones por Historias de Usuario…

3 – Facturar por tiempo estimado (ideal) de cada historia de usuario terminada

En otras ocasiones te he comentado:

  • Hace años, como comunidad (no sólo yo) no mirábamos con tan malos ojos a los Puntos Historia, ahora sabemos más cosas y no nos gustan tanto
  • Si no tienes Historias similares vas a tener que usarlos
  • No confundas velocidad o eficiencia con número de Puntos Historia (usa los Puntos Historia sólo para estimar, no para mirar velocidad)
  • Si tienes que usar puntos historia no le des significado de «complejidad», haz que su significado sea «tiempo ideal».

Dicho lo anterior, una nueva opción  sería poner precio al punto historia (que viene a ser poner precio a la hora, o unidad de tiempo, que asociamos a la historia), es decir facturar por tiempo estimado o tiempo ideal.

4 – Facturar por tiempo real de cada historia de usuario terminada

Claro que, frente a la anterior opción, alguien podría decir… «¿y si estimamos en 3 horas y luego son 20 horas?». Si eso es así… también está claro que os queda mucho que mejorar ya que a) estáis usando los problemáticos Puntos Historia y b) encima no acertáis, dentro de un error controlado.

En este caso, queda la, en mi opinión oscura opción, de que le cargues los errores de estimación, los tiempos reales al cliente. A mí eso me parece oscuro, suena raro.

Yo trabajaría por ser fiable en las estimaciones, mejorar nuestro modelo de trabajo y, si todo es un desastre llegar a algún acuerdo con el cliente (del tipo, si nos vamos mucho de la estimación lo comentamos) o trabajar la confianza (recordar aquello de, y necesitaba acabar este post con esta frase, Customer collaboration over contract negotiation) y volver a la opción 1 y facturar por Sprint.

Terminando

Han quedado fuera del post cosas como por qué es oscura la palabra proyecto en sí o el papel del valor en todo esto, para otro post.

También te dejo otros post relacionados con este…

The post ¿Cómo «facturar» un «proyecto» Ágil en el mundo real? appeared first on Javier Garzas.



Fuente: Javier Garzás (¿Cómo «facturar» un «proyecto» Ágil en el mundo real?).