Cuando trabajamos con clientes, utilizar estimaciones para definir un presupuesto es casi un mandato. Sin embargo, con este método muchas veces podemos tener complicaciones y/o problemas en el proceso del proyecto. En este artículo te contamos, según expertos, por qué las estimaciones no son tan útiles como se piensa.
“Cuando clientes potenciales nos contactan, es probable que quieran saber dos cosas: ¿Cuánto cuesta implementar la aplicación y cuánto tiempo tomará?”, sostiene en su sitio web el desarrollador Petri Kainulainen. Y continúa: “La respuesta honesta ante esto es ‘no tenemos idea’. No hace falta decir que, si le contestamos así a alguien, probablemente no contratará nuestros servicios. Por eso es que usamos estimaciones de trabajo para poder darle algún tipo de respuesta”.
“Nuestros clientes necesitan estimaciones”
Hay muchas variaciones en esto, pero por lo general se reducen a lo mismo: necesitamos clientes y los clientes necesitan estimaciones, por lo tanto las hacemos. Algunos ejemplos de esta idea, tal como indica el programador Woody Zuill en un artículo de su sitio web, son:
- Ningún cliente aceptará contratarnos para programar un software personalizado para ellos a menos que les demos un «presupuesto».
- La realidad de los negocios es que debemos dar estimaciones a nuestros clientes para que podamos trabajar.
- Debemos brindar buenos estimativos porque nuestros competidores están haciendo lo mismo.
- El cliente desea saber si podemos hacer su trabajo a un precio que pueda pagar.
- El cliente necesita saber si puede obtener una ganancia en función de la cantidad que costará su software, por lo que necesita un presupuesto.
Sin embargo, como plantea Petri en su artículo, el problema de dar una estimación radica en que muchas veces no estamos diciendo la verdad.
Los estimativos son suposiciones
Esto puede resultar como una sorpresa para ellos, pero nuestras estimaciones son solo eso: suposiciones. Es bastante fácil descubrir si una tarea específica es pequeña, mediana o grande. Sin embargo, es bastante difícil darse cuenta de cuánto trabajo es requerido realmente para finalizar una sola tarea.
Una razón de esto es que, muchas veces, los estimativos están basados en información insuficiente. El problema es que cuando damos estos indicativos, utilizamos ejemplos de interfaces de usuarios o una lista de historias de usuarios, por lo que no hay ninguna manera de saber cuánto tardaremos en programar este software en particular.
¿Por qué? Porque no podemos estimar sobre algo que desconocemos. Por ejemplo, no sabemos:
- Cómo deberíamos validar los datos
- Cuáles son las reglas de negocio de la aplicación
- Cómo debería implementarse la autorización
Existen muchas preguntas sin respuestas, y aún así deberíamos ser capaces de dar estimativos exactos… lo cual resulta ser algo utópico, según lo indicado por Petri.
Las estimaciones no nos incentivan a maximizar el valor agregado
Los estimativos se usan para dos propósitos diferentes:
- Para que el cliente tenga una idea de cuánto tiempo va a tomar implementar la aplicación y cuánto va a costar.
- Para que la compañía de desarrollo de software se asegure de que el proyecto sea rentable.
Woody comparte algunas consideraciones a tener en cuenta si, de todas maneras, hay que entregar estimativos:
- ¿Estás dispuesto a dar un presupuesto / valor gratis?
- ¿Quién paga las estimaciones de los trabajos que no obtiene?
- ¿Cuánto más necesita para «rellenar» el trabajo para los «desconocidos»?
- ¿Por qué debería pagar su cliente por eso?
- ¿Vas a dar un rango? Por ejemplo: «No te costará menos que esto, pero no más que eso». ¿Puedes garantizarlo?
- Si te cuesta más hacer el software de lo que se estimó, ¿estás dispuesto a asumir la pérdida? ¿Por qué? Si no, ¿cómo lidiarás con eso? ¿Volverás a negociar el contrato?
- ¿Cómo sabes lo suficiente sobre el trabajo para poder ofrecer un precio / presupuesto razonablemente preciso?
- Si un competidor les muestra una mejor propuesta, ¿volverán alguna vez a ustedes?
El camino ágil
Jeff Sutherland, uno de los inventores del proceso de desarrollo de software de Scrum, brindó una charla en la que mencionó la regla del «80/20»: que «el 80 por ciento del valor está en el 20 por ciento de las características» de un proyecto de software. Y sugirió que «deberíamos financiar el 20% y no hacer el resto».
“Yo creo que la regla es más un «95/5», es decir: el 95% del valor está en aproximadamente el 5% de las funciones, y las personas que paguen por el proyecto verán terminado el trabajo una vez que el 5% esté en uso”, explica Woody en su artículo.
Por esto es que algunos eligen el “camino ágil”. En este modelo, se reconoce que «los requisitos surgen». Si podemos ser buenos en permitir que surjan naturalmente los requerimientos más importantes y útiles, esto se amortiza muy bien.
Por eso existe el pedido de estimaciones: un cliente que necesita «saber cuánto costará» antes de decidir contratarte para hacer el proyecto podría no ser del tipo que está dispuesto a dejar que surjan los inconvenientes, porque simplemente no es su forma de pensar.
No todos los clientes requieren un presupuesto
Todo se reduce a esto: se puede elegir con quién hacer negocios. Si eliges atender a los clientes que necesitan estimativos, realiza estimaciones / valores y descubre cómo hacer que eso funcione para ti. Si vas por el camino de atender a los clientes que están dispuestos a dejar que surjan los requisitos, entonces opta por la manera ágil y apuesta por ellos. Es tu elección.