Muchas personas en el área TI están en la búsqueda del “Santo Grial de la estimación”.
Un objeto con una habilidad particular: es capaz de estimar exactamente cuánto tiempo un proyecto de software va a tardar en ejecutarse.
“Amado Santo Grial de la estimación, dado que tengo a Juan y a Diego, quieres pueden trabajar 45 horas semanales y que necesito hacer un software que nos permite hacer café al pensarlo… ¿cuánto tiempo nos tomará?” ― Martin, Project Manager
“Esto tomará 3 semanas, con 2 días y 4 horas” ― Santo Grial de la estimación
Cool, ¿verdad? Nos ahorraríamos las vergüenzas y problemas asociados a malas estimaciones.
Lamentablemente este dios de la estimación no existe, y no puede existir 😨
J.P. Lewis, académico de la universidad de Stanford, en el paper “Mathematical Limits to Software Estimation” demostró que no existe una metodología que sea capaz de estimar objetivamente cualquier tipo de proyecto.
OJO, esto no quiere decir que estimar sea imposible.
Las conclusiones del artículo son claras:
- La construcción de software es inherentemente creativa y subjetiva, teniendo más en común con la física que la industria de fabricación.
- Debido a que el software se utiliza en el gobierno, en los vehículos y en otros lugares donde potencialmente puede tener un impacto negativo en la vida de las personas, nosotros (los creadores de software) tenemos la responsabilidad ética de no sobrevalorar nuestra capacidad de estimar (especialmente cuando se trata de la calidad de software).
Sin embargo, SIEMPRE tendremos que estimar. ¿Qué hacemos?
A continuación hay 3 situaciones en las que se usa la estimación y los problemas que nos genera cuando nos equivocamos.
Problemas asociados a malas estimaciones
Situación #1: Cobrar en base a tu estimación
Si te equivocas, tus costos pueden superar tus ingresos, y esto sostenidamente desencadena en el quiebre de las empresas.
En el caso de freelancers o independientes, en trabajar horas extras no previstas (ejemplo: trabajar fin de semanas).
Situación #2: Fechas de entregas
Si fijas una fecha de entrega basada en la estimación y esta no se cumple, podría atrasar una fecha de lanzamiento, una campaña de marketing, etc. y la confianza que tienen en ti se verá perjudicada. A veces incluso hay multas asociadas con atrasos…
Situación #3: Presupuesto fijo y la planificación se basó en los costos de desarrollo
Aquí si te equivocas, el costo real puede superar el presupuesto, e incluso puede agotarse todos los recursos antes de terminar el software. Es decir, el dinero a la basura.
¿Y si haces las 3 cosas juntas?
BOOM! 💥
Espero que no te pase… y si ya te pasó, te entiendo! Lamentablemente estuve ahí.
Imagina que mejoras tus estimaciones. Esto solucionaría varios de los problemas, ¿cierto?
- Podríamos cobrar exactamente en base a nuestra estimación sin salir perdiendo.
- Podríamos colocar fechas de entregas y cumplirlas siempre
- Podríamos planificar bien costos de desarrollo sin pasarnos del presupuesto.
Happy World!! 🌈
La verdad es que la exactitud de la estimación NO es el problema.
El verdadero problema es el CÓMO trabajamos con ella.
De hecho, los problemas de arriba por lo general son síntomas de una enfermedad, pero no de la enfermedad de estimar mal.
A continuación se analizará cada problema con una causa posible, y además irá acompañado de consejos como solucionarlo. Siguiendo esos consejos te ayudará a:
- Quitarle la importancia a la exactitud de la estimación.
- Buscar otras formas de cobrar proyectos.
- Idear soluciones que consideren las fechas de entrega.
Mejorando como trabajamos con nuestras estimaciones
Solución a #1: ¿Cobras en base a tu estimación?
No deberías. Una de las razones de porque las personas lo hacen porque piensan que es lo más “justo” o lo más “objetivo”.
Ya sabemos gracias a las ciencias matemáticas que estimar es subjetivo y que por ende este precio también lo será.
¿Por qué no asumir que el precio es subjetivo y punto? Y así utilizar otros métodos (por ejemplo, cobrar en base al valor).
Además, también sabemos gracias a la biología (neurociencia) que las personas no compran en base al precio. El 85% de la decisión de compra es inconsciente.
Así que es mejor sacarle provecho al conocimiento que nos da la ciencia y utilizar otras formas de cobrar. Te recomiendo ver el artículo Cómo cobrar más haciendo lo mismo.
Solución a #2: ¿Fechas de entrega en base a la estimación?
Siempre habrá una fecha de entrega, ya que por lo general tu cliente depende del trabajo para poder seguir con su empresa. Incluso hay casos en los que la fecha límite es imposible de cambiar, como pasa con los “Black Fridays” o eventos deportivos importantes.
Si llega la fecha de entrega y no hay nada funcional, no hay nada de valor construido… déjame decirte que hubo un problema en la gestión del proyecto, no con la estimación.
Para dicha fecha, debe haber software funcional, con funcionalidades implementadas, disponibles, corriendo y probadas (testeadas). Puede que el 100% del software no esté listo, pero al menos está hecho ese 20% que genera el 80% de resultados para tu cliente (Principio de Pareto). Lo que queda por hacer deben ser cosas pequeñas.
Aquí entra en juego algo que Ron Jeffries, uno de los autores de Xtremme Programming (XP) en su articulo Making the Date:
“Making the date is not a development responsibility, it’s primarily a management and customer responsibility. Let’s treat it that way.”
Así que yo no me calentaría mucho la cabeza estimando las tareas (lo cual es responsabilidad de los desarrolladores) para fijar una fecha.
Si tu cliente no tiene una fecha en mente, ayúdale a llegar y en el peor caso que sea lo que tu estómago de diga (intuición).
Aunque OJO, el hecho de no tener fecha de entrega puede ser indicio de que el proyecto no sea tan importante…
Como puedes esperar, la solución en este caso es mejorar las habilidades de gestión del proyecto. Sé que es un consejo similar a “para adelgazar debes dejar de comer”. Lo más accionable que puedo darte sin extenderme mucho:
- Definir muy bien los objetivos del proyecto.
- Que estos objetivos estén alineados con la problemática que el cliente quiere solucionar.
- Cada cambio solicitado se mida de acuerdo a dichos objetivos (“¿en qué ayuda que el botón sea azul y no verde?” es mejor que “ok cambiar el color es fácil así que lo hago porque sí”)
Leer sobre ingeniería de software o metodologías de desarrollo también irán ayudando a desarrollar el músculo de la gestión.
Solución a #3: ¿Presupuesto fijo para desarrollar algo?
Presupuesto fijo para un proyecto + lanzarse a desarrollarlo inmediatamente = 😱
Mejor invertir un poco de ese presupuesto en una prueba de factibilidad, lo que a su vez va ayudar a llegar a un mejor estimado.
Invertir tiempo ideando una solución dada las restricciones es mucho mejor que lanzarse y hacer lo que se supone que hay que hacer.
Cuenta la leyenda que Albert Einstein alguna vez dijo:
“Si me dan una hora para resolver un problema, gastaría los primeros 55 minutos en plantearlo bien, y los 5 minutos restantes en solucionarlo”.
Sí, es más importante el trabajo previo, y lo mejor es que suele ser más barato también (al menos medido en horas hombres).
Conclusiones
¡Deja de sufrir con las estimaciones!
No quiero que te quedes con la idea de que estimar no es importante o que no hay que hacerlo…
De hecho estimar es MUY importante, te permite planificar y reaccionar ante eventualidades de manera de asegurar una correcta ejecución de los proyectos.
Lo importante es no delegarle a las estimaciones decisiones importantes como cuánto cobrar, cuándo entregar el software o definición de presupuestos (que por lo general dependen de la exactitud de la estimación, lo cual tiende a ser subjetiva).
Más bien estos usos son en realidad son causas de otros problemas:
- Si cobras en base al estimado, no deberías. Busca otras formas de cobrar.
- ¿Problemas con cumplir fechas de entregas? Revisa bien metodología de trabajo. Intenta usar alguna metodología ágil al menos parcialmente. Divide tu software en multiples “entregables” y asegúrate de siempre tener algo funcional.
- ¿Presupuesto fijo? Define bien el problema a solucionar, y piensa luego en una solución que se ajuste al presupuesto, tiempo y recursos.
P.D: Algunos datos freak (fuente: Chaos Report 2015)
- 38% de proyectos ágiles es exitoso, vs un 11% de cascada.
- De los proyectos exitosos, el 68% es de tamaño “pequeño”
Así que… al parecer que hacer proyectos pequeños y ágiles es como comenzar el día con el pie derecho (considera que sólo el 29% de proyectos se considera exitoso).
