“No puedo ser ágil. En mi negocio eso es imposible. Antes de empezar un proyecto de desarrollo para mis clientes… me piden siempre un presupuesto en horas. Tú imagínate que vas a pedir una reforma en tu casa y hablas con los albañiles… ¿Te imaginas decirles que empiecen a trabajar sin que te den antes un presupuesto cerrado? ¿A qué no? ¿Les vas a pagar por tiempo sin saber cuánto tiempo van a tardar? Imposible ¿no? Pues lo mismo nos pasa a nosotros, nuestro cliente, antes de empezar, necesita un presupuesto”.
¿Te suena lo anterior? Seguro lo habrás escuchado muchas veces, quizá hasta lo pienses. Yo te puedo asegurar que raro es que no tenga que ir a alguna empresa por algún tema relacionado con agilidad y que alguien no diga algo similar. Debo haberlo escuchado más de 30 veces sólo este año.
Y, además, curiosamente, los ejemplos siempre suelen ser comparándonos con un albañil que va a casa a hacer una reformilla, con todos mis respetos a los albañiles, ya podíamos compararnos con la NASA… “Imagina que la NASA va a mandar una nave a Marte… ¿lo haría sin presupuesto?”
El tema de los albañiles suele salir cuando toca hablar de contratos y estimaciones en un proyecto ágil. La agilidad, entre otros, asume que los requisitos pueden cambiar, incluso puede que apenas se conozcan los requisitos (ni requisitos sería la palabra apropiada, pero no liemos el post) al comenzar, sólo unos cuantos, y que se iran descubriendo al ir construyendo prototipos y productos mínimos viables, viendo las sensaciones de los usuarios, puede que por lo innovador de aquello, de aquel modelo de negocio basado en tecnología que se quiere construir.
Todo ello, se diferencia bastante del mundo clásico, que a diferencia de lo anterior busca cerrar el 100% de los requisitos antes de empezar, contractualizarlos entre las partes, estimar los tiempos y costes antes de empezar y de ahí hacer inamovible el modelo. Si durante el desarrollo del proyecto detectamos que no eran esos los requisitos, que había que cambiar unos por otros, etc… mala suerte.
Si los requisitos no son precisos… las estimaciones no son precisas. Incluso teniendo requisitos cerrados, por definición, y sentido común, las estimaciones no son exactas, recuerda aquello de tienes pocas probabilidades de estimar un proyecto software con una fecha… y acertar al 100%.
Sucede entonces que más que los requisitos premiamos tener un presupuesto, si hay que elegir parece que nos importa más saber cuánto me va a costar, durar, que acertar con lo que realmente necesitamos. Por ello, pedimos estimaciones y ello nos lleva a cerrar requisitos. Y esto termina demasiadas veces con proyectos que en lo que refiere a requisitos no cumplen las expectativas (muchas veces tampoco las cumplen en las estimaciones).
¿Cómo romper el modelo? Permitiendo requisitos cambiantes, lo que implica estimaciones no cerradas. Una primera estimación y un primer conjunto de requisitos que pueden variar sin que nadie se ponga nervioso. ¿Como saber que así “el albañil” no me va a engañar? Trabajando con él en equipo y con confianza. Y dejando de pensar que desarrollo es un albañil.
El caso del albañil, aunque queramos simplificar un desarrollo tecnológico hasta parecer un trabajo del albañilería, por mucho que queramos… no lo es. No es válido y la simplificación es peligrosa.
Muchas de las razones de porqué el ejemplo albañil no es válido te las dejé en dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas. si bien me voy centrar aquí en que, cuando le dices a un albañil «dame un presupuesto para arreglar el baño», y quieres comparar eso con un desarrollo de un modelo de negocio basado en un desarrollo software, hay dos cosas que NO puedes pasar por alto y que son enormemente importantes:
a) Está clarísimo lo que hay que hacer, cambiar el baño, concretamente este baño, con estas dimensiones y poniendo exactamente estos materiales.
b) La humanidad, y los albañiles, llevan cambiando baños desde tiempos inmemoriales, un mismo albañil habrá reformado más de 30 baños en su vida.
La suma de a) + b) reduce drásticamente la incertidumbre y ello le permite dar un alcance, tiempo y coste que poco varía (y ojo, aun así varía).
Pero en un desarrollo de un negocio basado en tecnología muchas veces, que no siempre, no existen ni la a), porque vamos aprendiendo en el camino qué debe hacer ese negocio basado en tecnología, ni la b) la mayor parte no se había hecho nunca antes.
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.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Yo creo que cuando hablamos de albañiles (o la típica analogía de la construcción de edificios y de software), se parte de un supuesto falso (o dos supuestos falsos).
1) que saben exactamente cuales son las tareas a realizar y los pasos a seguir. Eso nunca es así, a medida que se rompe, se avanza, se construye aparecen cosas que no eran como parecían, y se hace lo que en Argentina llamamos «replanteo en obra».
2) he sido cliente contratando un arquitecto para construir una casa, luego reformarla. Y los arquitectos no tienen forma de lidiar con los requerimientos del usuario (y sus cambios). Lo que yo vi en un plano me parecía bien, en el plano, pero cuando tuve el primer release, no me gustó. Ya era tarde para cambiarlo.
Entonces, como docente en Ingeniería en Sistemas, lo primero que me gustaría es que dejemos de trazar la analogía de la construcción.
Uno estima, repito ESTIMA (elabora una medida aproximada del esfuerzo, para poder decirle al cliente cual es el costo de un proyecto), en función a la experiencia, y lo que entendemos que es la complejidad del proyecto. LUEGO, necesitamos herramientas de gestión para poder alcanzar las funcionalidades solicitadas en el tiempo previsto (para no salirnos de presupuesto o minimizar los desvíos).
Yo compararía la estimación más con un viaje. No es lo mismo estimar el costo y la duración de un viaje de 40 km de una ciudad a otra por una ruta conocida, con un vehículo conocido, que a 400 km, que a 2000 km. Es mucho más fácil que dependiendo del tamaño del proyecto no se necesitan los mismos elementos de gestión, ni es tán sencillo estimar el tiempo, el esfuerzo, los riesgos posibles cambian, y sobre todo el impacto de estos riesgos. Tener problemas con un neumático es un riesgo siempre. En un viaje de 40km es poco probable pero de altísimo impacto en la demora. En un viaje de 2000km es más probable, pero el impacto se puede diluir (la demora de cambiar el neumático, la puedo recuperar haciendo una parada menos a descansar, o andando más rápido).
Y el otro problema clave, es pensar que hay una herramienta que aplique para todos los proyectos. Y cada proyecto, tiene su tamaño, sus características y sus necesidades de gestión. No siempre es necesario para gestionar un proyecto adoptar todas las prácticas que dice un libro, solo aquellas que resuelven problemas de gestión reales que tenemos en un proyecto, que en definitiva son las que agregan valor.
Saludos.
Se me ocurre que una buena analogía sería comparar nuestro trabajo con el de un taxista.
Al taxista le entra un cliente que quiere ir a una ciudad vecina, pero no sabe el nombre de la calle, así que ya le dirá cuándo está donde quiere. Automáticamente el taxista debería de activar el taxímetro. Pero entonces, el cliente le interrumpe y le dice que no, que le hagas un presupuesto y que tienes que estar en ese lugar, que él mismo desconoce, en 1 hora exacta. Si no puedes, que se busca otro taxista.
Es evidente que un taxista no podría cumplir esas condiciones. No sabe lo que va a tardar, porque durante el trayecto pueden surgir muchos imprevistos y porque el cliente le puede estar dando vueltas hasta llegar al destino. Lo lógico es, en efecto, activar el taxímetro, y que el cliente vea, porque va dentro del taxi, que el taxista está siendo legal y no le hace perder el tiempo.
este comentario es anterior a Uber, por ejemplo 🙂 Precio fijado antes de subir.
Javier ¿Cuando estarás por Colombia nuevamente? la verdad es que en la fábrica de software para la que trabajo se han empezado a interesar mucho por «Ágil» y quiero proponer una charla impartida por un experto en la materia como lo eres tu, y muchas gracias porque gracias a estos post tengo argumentos a diario para inducir hacia un pensamiento mas ágil por donde quiera voy.
Hola
Por ahora no tengo viaje previsto 🙁
Saludos