Estimando (no practicando la brujería)

Las estimaciones son necesarias, sin duda, para hacer una primera aproximación a la dimensión de la tarea que vamos a realizar. Sea cual sea la indole de esta tarea. Sentada esta base, me interesa comentar cómo se maneja la estimación en el 'mundo real' y que errores tendemos a cometer.

El primer punto a tener en cuenta es que las estimaciones solo son estimaciones. Esto que, a priori, es una perogrullada, se tiende a obviar. Los involucrados en los proyectos, especialmente los roles involucrados en la gestión del proyecto y la relación del cliente, tienden a olvidar esto. Tenemos que entender que cuando un desarrollador da una estimación no conoce muchos de los aspectos que con más fuerza influiran en la duraciona de la tarea, como, por ejemplo, la dificultad técnica. Además estos aspectos son mucho más dificiles de ver cuanto más lejano está el punto de incio de la tarea. Las estimaciones con estimaciones, no contratos. Cuando alguien convierte las estimaciones en contratos esta realizando un acto de brujería no de ingeniería del software. Brujería por que esta confiando en artes adivinatorias y porque esta forzando la voluntad de quien realizo la estimación. Si una estimación no nos gusta solo podemos añadir recursos o recortar características para que se ajuste a nuestras necesidades.

Si bien las estimaciones no son compromisos, solo estimaciones, todos hemos vivido situaciones, en las que se manejan como tales. ¡Hay incluso empresas que miden a sus desarrolladores por como de buenos son cumpliendo sus estimaciones!. Y lo que es peor aun ¡hay empresas que solo valoran este aspecto del trabajo!. No creo que no sea un aspecto relevante, el problema es que cuando solo se valora un aspecto del desarrollo, los desarrolladores tendemos a optimizar ese aspecto olvidandonos de otros y esto es, en mi opinión, extremadamente dañino para el proyecto. Pero eso es algo de los que hablaré en otro post. Siguiendo con lo que nos ocupa, y teniendo claro, que nuestras estimaciones se tratan a menudo como compromisos, que en nuestra imagen como desarrolladores depende de como de buenos seamos estimando, ¿qué podemos hacer?. La situación no es facil, en muchas ocasiones, ¡te van a valorar por cumplir compromisos establecidos sobre información insuficiente!. Pues bien hay ciertas reglas a la hora de comunicar estimaciones que es interesante seguir:

¡Si te piden una estimación, estima!: No des una estimación a la ligera, nunca. Si alguien te pide una estimación tomate un tiempo, directamente proporcional al tamaño de la tarea a estimar y a cuan lejos se encuentra su inicio, para realizar esta estimación. Es necesario hacer el intento consciente de lograr la mayor información posible sobre lo que estás estimando. Recuerda que tu imagen profesional, desgraciadamente, puede estar en en juego. La respuesta adecuada cuanto te pidan una estimación siempre es 'lo estudio y te comento'.

!Defiende con uñas y dientes tus estimaciones!: ¿Cuantas veces al momento de dar una estimación te la intenta cambiar?. ¿Y cuantas veces tienes que ceder?. Recuerda que ceder en una estimación no sería 'tan importante' pero estás cediendo ¡en un compromiso!, aunque no lo parezca. Para poder mantener una estimación tienes que tener argumentos, y si no has tomado tu tiempo en realizar una estimación argumentada dificilmente la vas a poder mantener.

!No olvides las tareas 'menores'¡: A menudo al estimar olvidamos las tareas menores, sin embargo estas suponen un porcentaje alto del trabajo total del proyecto.

!Recuerda que tendemos a ser optimistas¡: Está estadisticamente demostrado (pag. 168 de Rapid Application Development de Steve Mcconnell si quereís la justificación) que tendemos a ser optimistas en nuestras estimaciones. Debemos recordarlo. En el gráfico adjunto tambien se puede observar como nuestra estimaciones tienden a desviarse más hacia el lado optimista. Si X es lo que hemos estimado al principio del proyecto, lo probable es que el proyecto duré o cueste 4 veces más y solo 0,25 veces menos.

!Las estimaciones se refinan¡: Es necesario, ya que las estimaciones inciales se dan con escasa información ir refinandolas a lo largo del tiempo según vamos avanzando y ganado información sobre el problema inicialmente estimado. No es interesante saber como de buenos somo estimando, sino saber como de buenos somos haciendo que nuestras estimaciones converjan (ver el gráfico adjunto). Cuanto antes converjan, mejor estamos obteniendo la información necesaria para resolver el problema estimado y antes lo completaremos.

En un proximo post hablaré sobre como creo que debemos manejar las estimaciones cuando somos quienes las recibimos, no cuando somos quienes las damos.

Para terminar os dejo algunos recursos interesantes sobre estimación:

El Curso de Gestión de Proyecto de la Universidad de Columbia tiene bastante material sobre estimación.

Steve McConnell tiene un libro (en inglés) de obligatoria lectura:
Software Estimation: Demystifying the Black Art

Además tambien tiene una herramienta gratuita para estimación.

Published 1/11/2006 19:10 por Rodrigo Corral
Comparte este post:
http://geeks.ms/blogs/rcorral/archive/2006/11/01/Estimando-_2800_no-practicando-la-brujer_ED00_a_2900_.aspx

Comentarios

# Recibiendo estimaciones

Escribía hace unos días sobre las estimaciones y como se tienden a tratar como compromisos. Pero es evidente

Thursday, November 16, 2006 8:16 PM por La masa, el ladrillo, la bota, el bocadillo...

# re: Estimando (no practicando la brujería)

Recuerdo que en una charla un instructor de ventas de software decia que tampoco se negocia el precio del producto, lo que es lo mismo cuando trabajas frelance, el cliente o el usuario les parece exagerado el tiempo en hacer el proyecto y por lo tanto el costo, sin embargo la leccion es se cobran y se trabajan minutos de 60 segundos no minutos de 30 o 40 segundos

excelente blogs

saludos

Friday, November 17, 2006 5:28 PM por paco

# El difícil problema de la estimación

Este artículo fue publicado anteriormente en dotNetmania . Realizar estimaciones es uno de los más complejos

Sunday, July 22, 2007 6:54 PM por La masa, el ladrillo, la bota, el bocadillo...

# re: Estimando (no practicando la brujería)

Definitivamente la estimación en ocasiones se convierte en un juego de locos, por lo general no se cumplen los tiempos, existen métricas, pero no se usan y menos tenemos la oportunidad de usarlas cuando nos piden a carreras un tiempo x, sin posibilidad de tan siquiera hacer un análisis mínimo y para rematar cuando en pleno desarrollo del proyecto se detecta estimaciones de tiepos para actividades que ni siquiera se ejecutan, perro igual se facturan..definitivamente esto es un caos del día a día

Thursday, October 9, 2008 6:46 AM por Alejandra

# Gestión de proyectos guiada por la intuición, o por qué gestionar proyectos es tan difícil

Tras unos cuantos años participando en la gestión de proyectos de desarrollo de software y ayudando a

Monday, December 13, 2010 8:27 AM por La masa, el ladrillo, la bota, el bocadillo...

# Gestión de proyectos guiada por la intuición, o por qué gestionar proyectos es tan difícil

Tras unos cuantos años participando en la gestión de proyectos de desarrollo de software

Monday, December 13, 2010 10:31 PM por La masa, el ladrillo, la bota, el bocadillo...