TL;DR
Estimar con precisión en proyectos de desarrollo de software es imposible. Nunca vas a poder adivinar el futuro. No pierdas tiempo en «aprender a estimar mejor»; inviértelo en enseñar software que funcione a tu cliente cada poco tiempo.
El cliente nos pide una estimación completa
Últimamente me estoy dando de cabezazos con el tema más habitual en mi empresa: «Hola, el cliente nos pide una estimación para este proyecto cerrado. Por favor, necesito el desglose de tareas y horas. Ah, y no os paséis mucho porque el presupuesto debe ser competitivo. Si no, no nos compran». De repente, noto cómo va creciendo un fuego en mi interior y me empiezo a parecer a:
Me enciendo, porque estimar un proyecto tan gordo de una sentada es un suicidio. Perdemos mucho tiempo intentando ser precisos (recuerda, soy scrum master y estoy en búsqueda perpetua del desperdicio), y realmente da igual lo que pongamos; al final hay que poner los números que el cliente quiere ver. La última palabra la tiene nuestro jefe que ve el presupuesto con nuestras estimaciones antes de venderlo: «Uy, si ponemos tanto, no ganaremos el contrato. Hay que quitar 300 horas». Y el Tech Lead se retira cabizbajo, intentando ver de dónde se puede recortar, sabiendo muy bien que será imposible hacer todo lo que el cliente quiere por 300 horas menos. ¿Quién pagará las consecuencias de esta gestión? ¡Lotería!:
- Quizás el equipo de desarrollo al completo, por ser LENTO (¡menos subida salarial en la próxima revisión! ¬¬)
- A lo mejor el Tech Lead, por ser el «responsable» de las estimaciones
- Puede que el jefe si no consigue que el cliente pague los «excesos»
- O el alto cargo, si los «excesos» los cubrimos nosotros y son notorios –> y aquí ya se lía parda porque el problema escala a directivos…
¿Por qué seguimos autoengañándonos?
¡Anda! ¡Parece que de las cuatro opciones, lo menos probable es que salga perdiendo el cliente! Bueno, realmente sale perdiendo porque acaba por obtener un producto obsoleto, que ya no responde a las necesidades de cuando se empezó. ¡Pero eso parece que da igual!
«¿Por qué aceptamos trabajar así?» -me pregunto una y otra vez. Mi jefe me dice que llevan trabajando así 20 años, que la industria funciona de esta manera, que es imposible cambiarlo. Y acto seguido, vuelve a pedirnos al equipo: «Por favor, estimad las horas que cueste hacer este proyecto».
Es cierto que llevan 20 años trabajando así, pero ¿y?. ¿No habéis contratado un scrum master?. ¿No nos hemos metido en un proceso de mejora continua?. ¡Queremos ser más eficientes y aumentar nuestra productividad!. ¿No queremos realmente aportar más valor al usuario?.
Pues para conseguir todo eso hay que mover ficha en varios sentidos (no solo con la vara de la velocidad al equipo de desarrollo). Sobre todo en un mundo que cambia tanto y cada vez demanda más por menos, incluso en industrias «pesadas» (¿conoces las siglas VUCA? ¿te suena el modelo Cynefin de Dave Snowden?). Los proyectos de desarrollo de software forman parte de un sistema complejo, que no complicado. No existen best practices que harán que tengas éxito asegurado; solo consejos que dependerán mucho del contexto en cada momento. Y las necesidades, actualmente, cambian de momento a momento, así que de nada sirve un proyecto cerrado a meses/años vista.
«Estamos vendidos, pero no tenemos otra salida»
Esta industria lleva trabajando 20 años así. No vamos a cambiar ahora nosotros la forma de trabajar del cliente porque nos apetezca. Ellos jamás nos van a escuchar.
Es terrible cuando veo la derrota en los ojos de mi jefe. Llámalo derrota, pereza, desidia o desilusión. El pobre hombre sabe que esta forma de gestionar proyectos no funciona, y a la vez lleva mal-funcionando muchos años (qué incongruencia más incongruente :P).
Perdemos mucho tiempo intentando ser precisos: estimaciones realistas pero a la vez ajustadas, queremos mostrar que somos más rápidos que nuestra competencia. Tenemos debates internos horribles por qué cifra poner en esa celda de Excel. Y tenemos debates aún peores cuando nos juntamos varios y ponemos en común nuestras estimaciones individuales: «donde yo he puesto 10 horas, ¿¡tú has puesto 30!? ¿pero por qué? Espera, analicemos bien qué habrá que hacer dentro de esa funcionalidad». En fin, una serie de despropósitos que no sirven para nada, porque la cifra resultante del debate no será competitiva y el jefe acabará bajándola un poco a ojo.
Pero lo peor de todo viene cuando el proyecto llega a su fin y comparamos las estimaciones del presupuesto con la realidad. «¿Quéee? ¿Estimamos esto en 500 horas y al final han sido 1200? ¡Eso es más del doble! Pero, ¿por qué? Esto no puede ser, hagamos un post-mortem. Así es imposible ser rentable», etc., etc., etc. Así pasan los años en la gran consultora. Unas veces se acuerda con el cliente que ciertas modificaciones corren de su cuenta, otras pringa el equipo de Pepe y otras pringa el equipo de Juan. Y oootro año igual.
¿Y si pudiéramos hacerlo diferente?
Por qué no probar. Por qué no acercarnos a nuestro cliente con una oferta nueva de trabajo. Ideas claras y una bonita presentación. Antes de que empiece el siguiente proyecto, les planteamos con seguridad y profesionalidad que queremos trabajar de otra manera cumpliendo sus deseos. Una manera que realmente consiste en un win-win: gana el cliente (porque verá su software funcionando pronto y a menudo podrá reorientarlo – nos vamos adaptando = clients’ happiness!!! -), por tanto ganamos nosotros.
¿Qué quiere realmente el cliente?
Sabemos que el cliente busca siempre la fórmula perfecta de bueno, bonito y barato. Para ello pide presupuestos a varias empresas y compara, para más tarde tomar una decisión. Podemos ganar a la competencia por ser los reyes de uno de los ejes, pero lo lógico es que ganemos por el conjunto equilibrado, y ese puede ser nuestro punto de partida: nosotros queremos que ellos tengan ese equilibrio constante. ¿Cómo? Comprobando cada poco tiempo que lo siguen teniendo.
Aunque sepamos que llegar a tener las tres B a la vez es imposible y utópico, nuestros clientes no buscan otra cosa. Los contratos de proyectos software a coste fijo (fixed-price) dan esa falsa sensación de tenerlo todo a la hora de la firma, pero jamás acaba siendo así en la realidad.
El triángulo de hierro
El triángulo de hierro de gestión de proyectos está directamente relacionada con la regla anterior:
La manera tradicional de obtener ese valor ha sido con contratos de triángulo de hierro, fixed-price, pero siempre siempre siempre alguno de los lados del triángulo se acaba negociando viendo que es imposible llegar y el deadline se acerca:
- O se retrasa la fecha de entrega
- y/O se cambia el precio
- y/O se renegocia el alcance (pasa menos veces, por querer una solución «completista»)
Estoy convencida de que el cliente no quiere que le mientan ni fantasear con una ilusión, sino quiere pagar por algo que funcione y sea útil; que obtenga un valor. Hasta ahora se le ha prometido algo que no se puede cumplir: ¿por qué no empezar de una manera más honesta?
- ¿Qué necesidades deseas que cubrir (en términos de alcance) y en qué orden? (a alto nivel)
- ¿Qué limitaciones tienes (en términos de fechas, presupuesto u otros)? (y nos vamos adaptando)
Si probamos, quizás ganamos
Estimar a futuro con precisión es intentar adivinarlo, y los seres humanos aún no tenemos ese superpoder. Por tanto, mi consejo:
- No perdáis tiempo de más en ese proceso: que solo estime una persona. No estiméis varias personas para luego hacer una media. Olvidad ser realistas, porque los números siempre serán más elevados que lo que pide el cliente. Liberaos de la necesidad de querer «estimar mejor». Empezad conociendo qué tope competitivo tenemos y usemos ese valor para ganar el contrato. Que se le dedique el mínimo esfuerzo para obtener los números que necesita el cliente, pero solo como primer paso o trámite para comenzar negociaciones.
- Cuando hayas ganado el contrato, procede a la exposición de cómo vas a trabajar: (1) con fechas fijas, (1) con un roadmap (¡que no un gantt!) a muy alto nivel de los deseos del cliente a satisfacer y (1) con una calidad mínima que será respetada (¿queremos una suite de tests que se ejecute automáticamente según se progrese?). Lo que irá variando será el alcance, creando mínimos viables cuando sea lo oportuno y con mentalidad de entregar el máximo valor en el mínimo de tiempo (iteraciones lo más cortas posibles).
Moraleja: estimar con precisión es absurdo
En nuestro mundo de desarrollo de software, estimar es absurdo. No pierdas tiempo en ello e invéntate los números. Si acaso, añade un tanto por cierto de tiempo por aquello de no poder adivinar el futuro y el «por si acaso». Con ese tipo de proyectos, cúbrete, minimiza tu riesgo. Casi es mejor que te inventes los números. Ah, y añade un tanto por ciento para cubrirte. Si el resultado no es una cifra competitiva, cambia los números hasta que lo sea.
Es imposible querer trabajar de manera iterativa adaptativa en el equipo, si el cliente trabaja en cascada con proyecto de precio cerrado. Es imposible no equivocarse estimando. Al cliente siempre le va a llegar el proyecto tarde y no será justo lo que esperaba. Y nosotros como empresa siempre vamos a perder dinero por los penalties. Hay que aprender a vender la filosofía al cliente de querer entregarle software que funcione de forma iterativa e incremental. Pero primero convenzamos a los que tenemos en casa… ¡Ánimo a la hora de enseñar business agility a tu jefe de proyecto!
. . .
Foto de portada: Lines photo created by Racool_studio – www.freepik.com