Este verano he podido comprobar su facilidad de aplicación en un entorno muy diferente al desarrollo del software con mi hijo de 9 años. Os resumo la experiencia:
Al aproximarse el cumpleaños de su madre se encontraba con un dilema: se veía demasiado mayor para regalarle un dibujo (recurso clásico utilizado hasta el momento) pero muy pequeño para ganar dinero con que comprarle algo. Tampoco le hacía ilusión unirse a mi regalo puesto que él (y su madre) sabían que en realidad no habría participado. Como solución le propuse que podría ganar dinero barriendo las hojas del patio. Me pareció un ejercicio doblemente didáctico porque este año ha comenzado a estudiar el valor del dinero en el colegio (diferentes monedas y billetes de euro) y además aprendería a valorar las cosas (que ya va teniendo edad). Acordamos 0,50€ cada vez que limpiase el patio.
Durante todo el mes de julio se ha encargado de la limpieza (de hecho algunas veces le tuve que quitar la idea de limpiar a pleno sol) y a primeros de agosto se había hecho con la considerable cifra de 10€. Gracias a su esfuerzo consiguió hacerse con un par de pendientes en los puestos de la playa y hacer su primer regalo real (su cara no tenía precio cuando se los entregó a su madre).
Imagen cortesía de David Castillo Dominici / FreeDigitalPhotos.net
Lo curioso del tema es que a partir de ese momento veía el mundo con unas gafas totalmente distintas. Como en el colegio le habían introducido el concepto del dinero llevábamos todo el año de innumerables preguntas (está en edad) sobre el valor de esto o aquello: ¿Vale más el coche o la casa? ¿Es muy cara una Nintendo? ¿y mi bici?... Aunque le respondía con el precio de cada cosa mi percepción es que se quedaba tal cual... 160€, 240€... estas cantidades que no le decían nada. En el colegio le habían enseñado a elegir los billetes y monedas adecuados para pagar algo pero no tenía percepción de su valor real.
Durante las vacaciones de forma automática comenzó a traducir el valor monetario en esfuerzo, y así comenzó a valorar mejor lo que tenía (o lo que no...).
Cinco minutos de vueltas en un Kart con su hermano 20€.
- ¡Caray, me habría costado dos meses limpiando el patio! Pues sí que salen caros los cinco minutos (eso mismo pensé yo...).
Pagando un carro de comida en el supermercado:
- ¿60€ en comida? ¡Pero si es sólo comida! 6 meses de limpieza de patio...
Paseando por el supermercado:
- Papá, están locos, mira dice Oferta Jamón Ibérico 119€... ¿Cómo va a ser tan caro un jamón? ¿Un año limpiando el patio?
Y así durante todo el mes... él sólo, sin necesidad de explicación, estaba traduciendo el esfuerzo necesario para comprar el regalo a su madre con el valor real del resto de cosas. Podía estimar el esfuerzo que le llevaría comprar algo o incluso darse cuenta que necesitaría varias vidas para comprar un coche con ese nivel de ingresos. Me llevó todo un año de explicaciones fallidas del concepto abstracto del valor del dinero (para que pudiera valorar lo afortunado que era al poder disfrutar de determinadas cosas) y gracias a la comparación relativa con el regalo de su madre él sólo lo ha resuelto.
En cualquier proyecto en general, y en el desarrollo de software en particular, nos ocurre lo mismo. Todos hemos cambiado el gesto cuando nos han preguntado el número de horas que llevará realizar determinado trabajo o el número de meses/hombre necesario para completar un proyecto. Sin embargo si lo comparamos con otras tareas/proyectos nos puede resultar mucho más sencillo, de hecho casi automático. Obviamente esto no elimina la incertidumbre asociada a la estimación, pero facilita en mucho esta "desagradable" mirada al futuro.
Como con tantas otras prácticas, debemos tener claro que no en todos los entornos, proyectos o fases de un mismo proyecto podremos utilizar este tipo de estimación. En la guía PMBOK®, por ejemplo, recomiendan la estimación análoga en fases iniciales del proyecto, cuando existe una cantidad limitada de información (mayor incertidumbre). Hay que recordar que este tipo de estimación requiere menos tiempo que otras técnicas pero también es menos exacta. Atendiendo a esto debes decidir cuándo es adecuado su uso o cuándo es preferible dedicarle más tiempo a la estimación. Obviamente a mi hijo le sirve perfectamente para situarse en su entorno cercano y valorar el esfuerzo realizado por los Reyes Magos en sus regalos ;-) pero tal vez no sea suficiente para aceptar la viabilidad de un proyecto de desarrollo.
Nosotros utilizamos la técnica de Planning Poker® para la estimación de la mayor parte de nuestros esfuerzos de desarrollo, lo que además de permitirnos de una forma rápida clasificar nuestras tareas por sus tamaños relativos tiene una ventaja extra asociada, y es que al ser una estimación grupal, puede existir un rango de valores, que de ser amplio, al igual que ocurre con los tiempos PERT, deja al descubierto de inmediato la incertidumbre o riesgos asociados a esos trabajos.
Otra derivada de todo este asunto me hizo pensar y sonrojarme al recordarme a mi mismo poniendo vídeos de motivación en cursos de gestión de proyectos cuando no había conseguido motivar a un niño de 9 años a involucrarse en las tareas del hogar... hasta que él encontró su propia motivación...
PMBOK® es una marca registrada del Project Management Institute (PMI).
Planning Poker® es una marca registrada por Mountain Goat Software, LLC.
No hay comentarios:
Publicar un comentario