Chess - antoniomartel.com

Archivos de Autor: antoniomartel

Errores comunes en las estimaciones (II): La trampa del ancla

Hablaba hace unas semanas sobre uno de los errores más comunes al hacer estimaciones en un proyecto, el exceso de confianza. Les voy a hablar esta semana sobre otro error muy frecuente: la trampa del ancla.

Al tomar una decisión, como la que hacemos al dar una estimación, le damos un peso desproporcionado a la primera información que recibimos. El comentario de un cliente o algo que hemos oído sobre otro proyecto similar puede hacernos anclar nuestra propuesta a ese dato inicial aunque otra información más objetiva nos habría llevado a otra cifra.

Cierto profesor universitario suele hacer una prueba para mostrar a sus alumnos el efecto del anclaje en sus predicciones. Les pide a cada uno que hagan lo siguiente:

  • Anote en un papel las últimas tres cifras de su número de teléfono. Súmele 400 a esa cifra y anótelo en el mismo papel.
  • Atila el Huno fue uno de los conquistadores más terribles de nuestra era hasta que fue derrotado por los romanos ¿Fue derrotado antes o después de la fecha que anotó en el papel? Escriba en el papel la palabra ‘Antes’ o ‘Después’.
  • Escriba ahora el año en el que cree que Atila el Huno fue derrotado.
Curiosamente a aquellos cuyo número de teléfono más 400 estaba entre 400 y 599 predecían de media que Atila fue derrotado sobre el año 580 pero para aquellos cuyo número estaba entre 1200 y 1399 se inclinaban de media por la cifra de 1340. Habían relacionado ambas cosas pero ¿Qué tiene que ver el año en que Atila fue derrotado con nuestro número de teléfono? Nada, pero todos tendemos de forma natural a caer influenciados por esas primeras informaciones que recibimos.
Esto es lo que nos pasa cuando nuestro cliente nos pide un presupuesto pero nos dice que sólo cuenta con 20000 euros. Hacemos nuestros cálculos sobre el coste del proyecto influenciados por esta cifra como cuando lo hacemos por el número de teléfono del ejemplo anterior. Si las cifras reales al finalizar el proyecto muestran un número muy superior ¿Ejecutamos mal el proyecto o estimamos mal debido al ancla a los 20000 euros?
No confíe demasiado en su experiencia en proyectos del mismo tipo. Los expertos también fallan en sus estimaciones. Dos investigadores preguntaron a cirujanos especializados en enfermedades del pulmón por las posibilidades de que cierto paciente desarrollase una enfermedad pulmonar. A un primer grupo les preguntaron si la posibilidad era mayor o menor que un número aleatorio sacado de una tarjeta, digamos el 20%, y que escribieran luego su propia estimación. A un segundo grupo les hicieron la misma pregunta pero sobre una tarjeta aleatoria distinta, pongamos 50%
Ya puede imaginarse los resultados. Los cálculos de la mayoría de miembros del primer grupo rondaban el el número mostrado en la primera tarjeta y en el segundo grupo las predicciones se acercaban al 50% de la segunda. El número aleatorio que se les mostró influyó mucho más en su predicción que todo su conocimiento previo en el área. 
Tenga cuidado con toda información que pueda anclar sus estimaciones. Le podría salir muy caro.

Si quieres saber más sobre estimaciones aquí te dejo algunos de los post más populares:

Fuentes:

  • Curso Successful Negotiation de George Siedel en Coursera.

Errores comunes en las estimaciones (I): El exceso de confianza

Quién no se ha equivocado alguna vez estimando el coste de sus proyectos. Dividimos cuidadosamente el trabajo a hacer en una lista detallada de pequeñas tareas, consultamos a los compañeros que más experiencia tienen en las tareas más complejas, tenemos en cuenta los tiempos para preparar el entorno y un montón de cosas más pero aún así nos equivocamos y, con frecuencia, nos equivocamos por mucho. ¿Qué sucede? ¿No sabemos estimar? No podemos perder dinero en cada proyecto pero tampoco podemos aumentar las cifras ‘por si acaso’ porque lo que comenzaremos a perder son clientes.

Las razones por las que nos equivocamos una y otras vez cuando estimamos son muchas. Te explico aquí una de las más importantes:

El exceso de confianza en las estimaciones

El ser humano es optimista por naturaleza. Confía en exceso en sus propias posibilidades y olvida que los pequeños desastres del día a día le suceden a uno también no sólo a los demás. Cuando calculamos mentalmente lo que tardaremos en hacer una determinada tarea sólo tenemos en cuenta los pocos minutos que nos llevará teclear el código pero con frecuencia olvidamos el tiempo para testear, para desplegar, para documentar y comentar el código, para solucionar ese bug en el navegador, para escribir el manual de usuario y un sin fin de cosas más.

Tengo malas noticias: Usted también es demasiado optimista ¿no lo cree? Haga esta prueba conmigo:

Si le pido que me indique el año en el que nació Mozart probablemente no podrá darme un valor exacto pero si le facilito un poco las cosas y le pido que me indique un rango de años en el que con un 90% de probabilidad usted cree que Mozart nació posiblemente sí se atreva a darme una respuesta.

Ampliemos un poco esta prueba. Le planteo ahora diez preguntas. Anote por favor el rango de números entre los que cree con un 90% de probabilidad que acertará la respuesta correcta.

  1. Año en el que Mozart nació. Límite inferior: ____ Límite superior: ____
  2. Longitud del río Nilo. Límite inferior: ____ Límite superior: ____
  3. Número rayos que golpean la tierra por minuto. Límite inferior: ____ Límite superior: ____
  4. Tiempo que tarda la luz del sol en llegar a la Tierra (en segundos). Límite inferior: ____ Límite superior: ____
  5. Diámetro de la Luna. Límite inferior: ____ Límite superior: ____
  6. Número de cuchillos, tenedores y cucharas en la Casa Blanca. Límite inferior: ____ Límite superior: ____
  7. Número de lenguas vivas que se hablan actualmente en el mundo. Límite inferior: ____ Límite superior: ____
  8. Periodo de gestación (en días) de una elefante asiático. Límite inferior: ____ Límite superior: ____
  9. Número de nacimientos que tienen lugar diariamente en el mundo. Límite inferior: ____ Límite superior: ____
  10. Número de días en los que un caracol puede dormir si no es molestado. Límite inferior: ____ Límite superior: ____
Al final de este post tiene las respuestas correctas. Si sus estimaciones fueron correctas debería haber acertado 9 de las 10 preguntas ¿no fue así? No se preocupe, la mayoría de gente solo acierta unas pocas. Tendemos a ser demasiado optimistas y elegimos un rango demasiado pequeño para acertar. Nos pasa a todos, de hecho, las personas que no tienen este sesgo optimista se consideran clínicamente deprimidas.
Ahora que conoces un poco más tu propia forma de pensar quizás decidas ser un poco más precavido en su próxima estimación. Aún así no se confíe, las personas que fueron advertidas de este sesgo optimista antes de hacer pruebas como ésta también pecaron de exceso de confianza en sus predicciones.
Las próximas semanas iré publicando nuevas entradas sobre los errores más comunes que cometemos al estimar. Atento a las nuevas entradas. 
Si quieres saber más sobre estimaciones aquí te dejo algunos de los post más populares:

  1. Año en el que Mozart nació. 1756.
  2. Longitud del río Nilo. 6,738 kilómetros
  3. Número de veces que un rayo golpea la tierra por minuto. 6,000
  4. Tiempo que tarda la luz del sol en llegar a la Tierra. 492 segundos
  5. Diámetro de la Luna. 3,476 kilómetros
  6. Número de cuchillos, tenedores y cucharas en la Casa Blanca. 13,092
  7. Número de lenguas vivas que se hablan actualmente en el mundo. 6000
  8. Periodo de gestación de una elefante asiático. 645 días
  9. Número de nacimientos que tienen lugar diariamente en el mundo. 365,000
  10. Número de días en los que un caracol puede dormir si no es molestado. 1,095 días

Fuentes:

  • Statistic Brain and Odd Trivia Facts de Russo y Schoemaker publicado a su vez en el curso Successful Negotiation de George Siedel en Coursera.

Nueva edición del libro Gestión práctica de proyectos con Scrum

Esta semana he lanzado en Amazon una nueva edición del libro Gestión práctica de proyectos con Scrum. Nueva portada, nuevos capítulos, revisión de contenidos, en definitiva, un montón de cosas en esta segunda edición del libro ¿Aún no lo has leído? Échale un vistazo en Amazon.com. Aquí tienes el enlace: Gestión práctica de proyectos con Scrum.

Con estos cambios el libro se ha colocado como número 1 en tres categorías al mismo tiempo (Programación y desarrollo software de la Tienda Kindle y Programación y desarrollo de software e Internet y web dentro de todos los libros de Amazon.es). En el momento en que escribo esto el libro se ha colocado en la posición nº 166 en ventas de todos los libros Amazon España ¿Llegará al top 100?

El rol de Product Owner en Scrum

Hay muchas formas de denominar a la persona que cumple las funciones de Director del Proyecto en la organización que nos contrata. Aquel que tiene la visión del producto que necesita su compañía y que la representa ante el equipo de trabajo. Si pertenece a la organización externa que nos ha encargado el trabajo, el nombre que mejor se le ajusta es el de Dueño del Producto, como hace Scrum, porque es eso literalmente, el ‘Dueño’ de lo que se ha contratado. Si en cambio es una persona de nuestra propia organización la que va a representar al ‘negocio’ en el proyecto suele denominársele Product Manager o incluso Business Analyst según la empresa que le haya dado el cargo. Personalmente, quizás por el tipo de proyecto que habitualmente gestiono, me siento más cómodo llamándolo simplemente Director del Proyecto en el Cliente.

Lo llamemos como lo llamemos, cumple una función muy importante para el éxito de un proyecto. Es el encargado de decidir qué funcionalidades tendrá el producto que se está construyendo, cuáles son importantes y cuáles son prescindibles. Es posible que sea un usuario final del producto por lo que tendrá muy claro qué se necesita para obtener una herramienta útil en su trabajo diario, pero no debe ser útil solo para si mismo o su departamento, sino que deberá tener en cuenta los requisitos de toda su empresa.

Cuando comenzamos un nuevo proyecto, el Director del Proyecto en el cliente y todos los usuarios interesados en el producto final tienen un montón de ideas y grandes expectativas para el nuevo sistema. Lamentablemente, ningún proyecto, por grande que sea, puede contemplar todas y cada una de las sugerencias de sus usuarios. Algunas ideas serían irrelevantes para la mayoría, otras funcionalidades serán demasiado costosas de implementar o llevaría tanto tiempo desarrollarlas que retrasarían la puesta en marcha del producto. Es aquí donde el Director del Proyecto en el Cliente, que conoce bien el mercado y tiene una clara visión del producto, tendrá que priorizar las características más importantes y descartar aquellas que aportan menos valor al resultado final.

Para explicar hasta dónde llegan sus responsabilidades imaginemos que nuestra empresa decide contratar el desarrollo de un nuevo sistema de reserva de billetes de avión. En esta empresa han nombrado a Raúl como Dueño del Producto o Director del Proyecto y tendrá que trasladar a la empresa contratada todos los requisitos y necesidades que el nuevo sistema deberá cubrir.

Raúl tiene una visión muy clara de lo que quiere y está muy ilusionado con el proyecto. También lo están los responsables de IT, marketing y ventas que han elaborado una exhaustiva lista de funcionalidades a incluir en el nuevo producto. Incluso en conversaciones informales, los que serán nuevos usuarios del sistema, le trasladan a diario peticiones de nuevas funcionalidades. Raúl no quiere que se le escape nada importante y anota cuidadosamente todos estos requisitos en un cuaderno.

Al segundo mes de comenzado el proyecto Raúl se da cuenta que el Equipo de Trabajo en la empresa desarrolladora está entregando de 4 a 6 nuevas funcionalidades a la semana y que esta parece su capacidad máxima de trabajo. Está contento con el trabajo que están haciendo pero tiene un problema: en su libreta anota una media de 10 nuevos requisitos a la semana. La lista está creciendo y pronto necesitará un nuevo cuaderno.

Primero solicitó al Equipo de Trabajo que hiciera un esfuerzo para entregar estas diez funcionalidades cada semana. Lamentablemente, no muchas más funcionalidades eran entregadas y, lo que es peor, se comenzaba a percibir que la calidad de las mismas había bajado. En ocasiones incluso había que parar todo para corregir defectos en entregas previas. Si seguían así, la desmoralización y el estrés iban a dominar el proyecto.

Raúl iba a decidir a partir de ahora qué se hacía y qué no. Todas las funcionalidades no iban a poder se desarrolladas, por lo menos no ahora. Algunas tendrían que esperar a una futura versión. Desde luego, la funcionalidad similar al Clippy de Windows para asistir en la compra de los billetes de avión era un claro ‘No’.

 

Pero ¿cuáles desarrollar primero? ¿qué criterio seguir? Raúl se dio cuenta de que no había relación directa entre el coste de las funcionalidades y su valor para el producto final. Algunas funcionalidades eran fáciles de construir pero otras, en cambio, llevaban mucho tiempo de desarrollo pero no por ello eran las que más valor aportaban. Si preguntaba directamente al Equipo de Trabajo en cuantos días podría estar hecha cada una de las funcionalidades sabría su coste aproximado y si preguntaba a los usuarios por una valoración del 1 al 5 para cada funcionalidad sabría calcular el valor para su empresa.

Si había dos funcionalidades que tienen el mismo coste aproximado pero una tiene valor 1 y la segunda valor 3 estaba claro que se construiría la segunda funcionalidad. Si en cambio, había dos funcionalidades de aproximadamente el mismo valor para la empresa pero tardaríamos 5 días en desarrollar una de ellas cuando la segunda podría estar desarrollada en una horas, también estaba claro en cuál se trabajaría primero.

Raúl sabía que el coste y el valor de cada funcionalidad no eran números absolutos sino solo una aproximación. No sabemos cuánto pesa una manzana pero sí sabemos que es aproximadamente 5 veces más grande que una fresa y que la fresa gusta más (para los que van a pagar por ella al menos) por lo que la fresa se construiría primero. Es un modo fácil de decidir qué aporta más valor y más rápido a nuestro proyecto.

La comunicación es una parte importante de las responsabilidades de Raúl. Deberá estar en contacto directo con el Equipo de Trabajo pero también con las personas de su empresa que tienen algo que decir sobre el producto que se va a construir. Debe ser hábil para saber decir ‘no’ cuando sea necesario. Debe ser práctico también para tomar esta decisión de forma rápida y directa y, además, conocer muy bien su negocio para asegurarse de que se construye lo que realmente aportará valor a su empresa. Todo un papel para Raúl ¿no creen?

Este artículo se publicó por primera vez en el número 3 de la revista IT Proiectus. Puedes encontrar este artículo y muchos otros en la web de Proiectus, consultoría y formación en dirección de proyectos.

Nuevo número de la revista Proiectus

Ya ha salido el nuevo número de la revista de gestión de proyectos Proiectus editada por Iván Tejera. Ya va por el número 3 y en esta edición alcanza las 80 páginas de artículos sobre la dirección de proyectos en Canarias escrita por jefes de proyecto como Javier Zaya, Fernando Manero, Toni Dorta, Pilar Tarriño, José Barato o Mike Griffiths.

Yo también tengo un artículo en este número titulado ‘El rol del director del proyecto en el cliente‘ en el que hablo de la importancia que tiene el papel del Product Owner en todos los proyectos.

No te lo pierdas. Échale un vistazo en este enlace a la revista Proiectus en Issuu: