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…
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
Es un tema complejo y bastante controversial, plantear facturar por Hus, o tiempo estimado es ir en contra de principios agile, ya que las estimaciones son eso estimaciones, no compromisos de tiempos de trabajo real, recordad que en agile de hecho cuando se plantean «proyectos» hablamos de tiempo y coste mas no de alcance, ademas que las empresas estan acostumbradas a proyectos «llave en mano» muy waterfall, considero que se deberian tener mas Project managers tecnicos que puedan crear proyectos gestionandolo con «Time and Materials» un concepto que parece mas agile donde puedes crear squads para un producto en concreto y facturas en base a las jornadas por perfil requeridos, y siendo parte activa del los objetivos del sprint
Buena y realista aportación.
Facturar por Sprint Goal, En terminos practicos es facturar por Sprint, pero con el condicionante que se asume el compromiso de cumprir con el objetivo del sprint, el cual es establecido con el cliente, si no se cumple con el objetivo del sprint se revisara en conjunto con el cliente para evaluar el contexto y evaluar la naturaleza del impedimiento, 1. SE EVIDENCIA una mala estimación por las caracteristicas del incremento prometido, se puede definir una penalización acordada ejem 10% o no, 2. SE EVIDENCIA negligencia del Scrum Team no se paga nada, un porcentaje representativo del avance obtenido, o un porcentaje definido previamente 40%, 3. SE EVIDENCIA negligencia por parte del cliente (casos donde esta involucrado en la gestión del proyecto) se debe pagar el 100%, un porcentaje representativo del avance obtenido, o un porcentaje definido previamente 70%.