La fórmula mágica

Aitor me ha pedido en un comentario en el blog de Fernando que explique los detalles de mi “fórmula mágica”. Esto de “fórmula mágica” lo digo un poco con retranca gallega, porque de mágica tiene poco. En resumen, se trata de un conjunto de técnicas y reglas sencillas que llevo usando bastante tiempo para gestionar proyectos de ingeniería, investigación, desarrollo y producción, siempre en el área del trabajo con el conocimiento.

Estoy contento con mi “fórmula mágica”. Llevo unos 12 años usándola y, en general, funciona bien. En mi experiencia, funciona mejor que los enfoques más tradicionales, que describo a continuación. No quiero decir con esto que mi fórmula funcione siempre o con cualquier persona; no. He conocido personas que no supieron, pudieron o quisieron adaptarse a mi forma de ver las cosas, y organizaciones que no superion, pudieron o quisieron ver las ventajas, con lo cual mi fórmula no pudo funcionar. Sin embargo, y tras más de una década aplicando mi enfoque de forma sistemática, creo que los resultados son claros: mi “fórmula mágica” es superior.

Tradicionalmente, la gestión de proyectos se basa en principios tayloristas, tomados de los procesos de producción industrial, que asumen que las personas son piezas intercambiables en una gran maquinaria, y que es posible optimizar el throughput de dicha maquinaria optimizando el caso nominal, es decir, el modo de funcionamiento considerado “normal”, sin prestar demasiada atención a los modos transitorios de puesta en marcha y parada de dicha maquinaria. Estos principios, y otros más, son elegantemente explicados por (quién si no) DeMarco y Lister en el capítulo 2 de Peopleware.

Utilizar un enfoque taylorista significa planficar los procesos de antemano, para poder predecir costes, tiempos y necesidades de recursos. Esto encaja bien con las premisas de que las personas son todas iguales (piezas intercambiables en una gran máquina de producción) y el caso nominal es lo que cuenta. Si podemos saber de antemano cuánto vamos a tardar en realizar una tarea, cuántas personas van a hacer falta, y cuántos recursos va a consumir, entonces podemos tomar decisiones de forma correcta. Dado que el negocio necesita tomar decisiones, los enfoques tayloristas prefieren pensar que es posible predecir estos tiempos, esfuerzos y recursos necesarios. En otras palabras, los enfoques tayloristas basan su efectividad en la adivinación del futuro.

La mala noticia es que las predicciones son siempre difíciles, sobre todo sin son acerca del futuro, como ya dijo Yogi Berra. Por mucho que les fastidie a los managers clásicos, y por muchas hojas de cálculo que rellenen y muchos planes de Project que hagan, el futuro sigue siendo caprichoso. La gente se pone enferma. Se cae la red. Tienes un día malo. O dos buenos seguidos y rompes una dependencia. Alguien se va de la empresa. Una impresora se estropea y te colapsa un proyecto de un millón de euros (lo he visto suceder). Una actualización del sistema operativo hace que tu compilador comience a comportarse de un modo ligeramente distinto a como la hacía antes y 6.000 de tus tests automatizados han de ser reescritos. Cositas, vaya. Luego viene el jefe echándose las manos a la cabeza “¡pero eso no estaba en mis planes!”

Desde que tengo uso de razón (desde hace 12 años, vaya) siempre he tenido la modestia de admitir abiertamente que no puedo adivinar el futuro. Ni si quiera de cerca. Creo que era Steve McConnell quien decía que si un desarrollador de software te da una estimación acerca del futuro y acierta, es de casualidad. Bromas aparte: seamos honestos y admitamos que adivinar el futuro es solo para personas con las gafas al revés, y no para los meros mortales como nosotros. Y si quieres pruebas, léete Software Estimation y hazte el test de estimación que viene en uno de los primeros capítulos.

Conceptos básicos

Una de las cosas que no debes olvidar como gestor de proyectos (o como trabajador gestionado) es la diferencia que hay entre tres conceptos relacionados pero muy distintos: estimación, objetivo y deseo.

  • Una estimación es una probabilidad y, por lo tanto, tiene valor estadístico. Por ejemplo, si me pides que te dé una estimación de cuánto tiempo me va a llevar completar la documentación de requisitos para el producto MegaPlus y yo te digo que 20 días, eso significa que hay un 90% (o 95%, o la certeza que yo haya decidido usar) de probabilidad de que en 20 días yo haya completado la tarea en cuestión.
  • Un objetivo es una intención que decidimos perseguir y que consideramos posible, pero quizá poco probable. Por ejemplo, después de que yo te diga que voy a tardar 20 días en terminar de documentar los requisitos, tú me puedes decir “ummm… me gustaría que los tuvieses listos en dos semanas; ¿cómo lo ves?”, y yo podría decirte “pues es poco probable, pero me lo tomo como un objetivo”. Esto quiere decir que voy a hacer lo posible para alcanzar mi objetivo, a sabiendas de que tengo pocas probabilidades.
  • Un deseo, por último, es algo que nos gustaría tener y que, a veces, es difícil de alcanzar. Por ejemplo, me gustaría tener un millón de euros. Eso es un deseo. O tú podrías decirme “eso de 20 días para los requisitos es inaceptable; los quiero en una semana”; yo te respondería “entiendo que deseas tenerlos en una semana; a mí también me gustaría tenerlos tan pronto, pero es imposible”.

En resumidas cuentas: una estimación es el resultado de un cálculo matemático y por lo tanto no es negociable. No dejes que nadie te discuta el resultado de una estimación. Es como si alguien tratase de discutirte el valor de π. Los objetivos sí son discutibles y negociables.

Dos reglas fundamentales

Dicho todo esto, podemos pasar a mi “fórmula mágica”. Mi primera regla de oro para gestionar proyectos es esta:

Regla 1

El responsable de realizar estimaciones y establecer objetivos iniciales es la persona que vaya a realizar cada tarea.

Por ejemplo, si yo te pido que documentes los requisitos del producto MegaPlus y tú accedes a hacerlo, solamente tú puedes estimar el esfuerzo, tiempo y recursos que van a ser necesarios para la tarea, y solamente tú puedes establecer tu objetivo inicial. Por supuesto, yo, como director del proyecto, comprobaré que tu estimación y objetivo tienen sentido. Si no lo tienen, hablaré contigo. Este es un ejemplo de una conversación posible:

Bob: Creo que Alice se va a encargar de documentar los requisitos, ¿no?

Alice: Sí, vale.

Bob: ¿Cuándo crees que los tendrás listos?

Alice: Ummm… no sé… quizá en tres o cuatro días… No parecen muy complicados.

Bob: Echa tus cuentas y dímelo esta tarde, por favor. Prefiero que te tomes tiempo de sobra y entregues a tiempo que que tomes menos tiempo y luego tengas que retrasar la entrega.

Alice: Vale. Pero no creo que me haga falta más de una semana.

Bob: Lo dicho. Dímelo esta tarde.

La segunda regla es evidente:

Regla 2

Cuando das una estimación estás realizando un compromiso. Respetar ese compromiso es mucho más importante que el valor de la estimación en sí.

Lo que quiero decir es que, como se ejemplifica en la conversación anterior entre Alice y Bob, la fecha concreta a la que te comprometas, o el esfuerzo al que te comprometas, o los recursos que solicites, son solamente de una importancia relativa. Lo que es de una importancia crucial es que, una vez que te comprometes a un objetivo concreto, respetes dicho compromiso y trates por todos los medios de no fallar. Las personas acostumbradas a trabajar en entornos muy tayloristas suelen tender a dar objetivos muy ajustados (plazos cortos, escasos recursos, poco esfuerzo), porque creen que eso está bien visto por parte de sus jefes. Es cierto que muchos jefes reciben estos objetivos con una sonrisa, pero esto no significa que constituyan estimaciones correctas. Personalmente, prefiero un objetivo que corresponda a una estimación correcta aunque la fecha o esfuerzo que representa sea mucho mayor de lo que idealmente me gustaría. ¿Por qué? Pues porque mi planificación se basa en asumir que la gente va a cumplir sus propios compromisos. Fíjate en la siguiente conversación:

Alice: He estado pensando en los requisitos.

Bob: Bien. ¿Ya tienes una idea de cuánto tiempo vas a necesitar para completarlos?

Alice: Sí. Creo que una semana es suficiente.

Bob: ¿Qué quieres decir con “creo”? ¿No estás segura?

Alice: Ummm… Estoy bastante segura… Una semana debería llegar si todo va bien, aunque siempre puede haber imprevistos.

Bob: Bueno, pues cúbrete las espaldas. Convierte los imprevistos en “previstos” o, al menos, parte de ellos. Si crees que una semana te llegaría si todo va bien, pídeme dos semanas.

Alice: ¡Pero eso es mucho tiempo! ¿Vas a darme dos semanas?

Bob: Yo no te doy dos semanas. Eres tú la que me dice cuánto tiempo necesitas. ¿Ves la diferencia?

Alice: Creo que sí.

Bob: ¿Dos semanas son suficientes?

Alice: Seguro. En dos semanas estarán listos los requisitos.

Bob: ¿Incluso si las cosas no van bien?

Alice: Pues… casi seguro. ¡A no ser que se hunda el edificio!

Bob: Ja ja ja. Pero no vamos a ser tan pesimistas. La probabilidad de eso es tan pequeña que no la vamos a incorporar.

Alice: De acuerdo. Creo que dos semanas cubren todos los imprevistos que son relativamente probables. ¿Qué pasa si todo va bien y termino mucho antes de las dos semanas?

Bob: Pues estupendo. Puedes aprovechar para leer algo, o para comenzar a instalar el laboratorio de virtualización.

Alice: Muy bien.

Creo que queda claro, ¿no? Mejor un plazo más largo pero más cierto que un plazo más cercano pero más incierto.

Incertidumbre

Esto nos lleva al tema de la incertidumbre. Sobre todo al comienzo de un proyecto no trivial, el grado de incertidumbre respecto a plazos, esfuerzos y recursos puede ser tan enorme que incluso las estimaciones más vagas carecen de sentido. En estos casos, yo siempre he utilizado conos de incertidumbre. Un cono de incertidumbre es, básicamente, un gráfico que muestra la evolución de un rango de valores a lo largo del tiempo, y te permite visualizar fácilmente si este rango tiende a converger hacia un valor final o si, por el contrario, está fuera de control. Te lo explico con un ejemplo.

Imagina que estás a cargo de un proyecto pequeño-mediano y, grosso modo, calculas que necesitarás entre seis meses y un año para terminarlo. Hoy es el día cero, es decir, estás comenzando el proyecto. A fecha de hoy es muy difícil saber cuándo podrás tener el producto final terminado. Un manager clásico se pondría a hacer diagramas de Gantt con el Project y al final obtendría la fecha de final que quisiese obtener, independientemente de la viabilidad de los plazos y esfuerzos. Todo parecido con la realidad, como decía McConnell, sería pura coincidencia. Yo, sin embargo, trataría de estimar le fecha de final del proyecto mediante un rango de fechas. Por ejemplo, a fecha de hoy, es decir, en Agosto de 2008, estimo con casi total seguridad que el proyecto estará terminado entre Enero y Julio de 2009. Esto es un rango muy amplio, ya lo sé, pero no puedo decir más. Comencemos a trabajar, y según avancemos y las cosas se vayan aclarando y concretando, refinemos nuestra estimación. Yo suelo hacer estimaciones mensuales para proyectos medianos. En Septiembre volvemos a estimar y resulta que no podemos decir mucho más: seguimos creyendo que terminaremos en algún momento entre Enero y Julio de 2009. Seguimos trabajando, y cuando llega Octubre, hemos concretado lo suficiente como para saber que no será necesario llegar tan lejos como Julio, y dejamos nuestra estimación en Enero-Junio 2009. En Noviembre, con datos nuevos, repetimos nuestra estimación y vemos que Enero está demasiado cerca, con lo cual estimamos Febrero como fecha optimista más probable. Y de este modo, poco a poco, vamos cerrando el cono:

Cono ideal

Cono ideal

En la figura, el eje horizontal muestra el tiempo que va transcurriendo. El eje vertical muestra el tiempo de nuestras estimaciones. Nuestras estimaciones se representan como círculos rosas. Por ejemplo, fíjate que la columna de Agosto de 2008, a la izquierda de todo, muestra dos estimaciones (dos círculos), uno para Enero de 2009 y otro para Julio de 2009. Esto corresponde con el rango de estimaciones que propusimos. Según nos movemos hacia la derecha (es decir, según avanzamos en el proyecto), vamos realizando estimaciones nuevas. He unido las estimaciones optimistas y pesimistas con sendas líneas, que comienzan muy separadas al principio del proyecto y se juntan al final. Fíjate que el proyecto finaliza en Abril de 2009, cuando el “cono” se cierra y las estimaciones, evidentemente, coinciden con el tiempo “real”.

<frikada>Si hay algún físico relativista leyendo esto, se habrá dado cuenta de que la línea azul de rayitas que cruza el gráfico en diagonal corresponde a un horizonte de sucesos que no puede ser “atravesado” por el cono. Además, un cono siempre “termina” o se cierra sobre este horizonte, porque este horizonte represente el presente en cualquier momento dado. La superficie por encima del horizonta represente el futuro (y por eso podemos hacer estimaciones acerca de él) y la superficie por debajo de él representa el pasado.</frikada>

El cono que dibujé arriba es un cono muy chulo, que se comporta muy bien. Es decir, es el sueño de todo gestor de proyectos. No se curva hacia arriba (lo que indicaría retrasos), ni sus líneas divergen (lo que indicaría estimaciones fuera de control). Imagina algo así:

Cono indeseable

Cono indeseable

Mirando esta figura, ¿eres capaz de imaginarte dónde se juntarán las líneas del cono? Yo no. Podría nivelarse al mes siguiente y cerrarse en un par de meses más, o podría seguir ascendiendo, ambas ramas en paralelo, para siempre jamás. Es un proyecto fuera de control. Brrrr.

Enunciemos la tercera regla:

Regla 3

Utiliza conos de incertidumbre para visualizar y estimar el progreso del proyecto y otras actividades.

Por cierto, los conos de incertidumbre se pueden aplicar a tareas más pequeñas, y no solamente a proyectos.

Estas tres reglas resumen mi filosofía general de gestión de proyectos. Me dejo mucho en el tintero, pero un post no debe ser más largo. Hay temas conectados, como el tema de los horarios o el de la organización del espacio, pero los trataré en posts separados.

¿Qué opinas?

8 respuestas a La fórmula mágica

  1. Una fórmula muy interesante!!! La verdad es que eso es confiar en las personas y no tanto en los planes. Además, creo que esta visión de la planificación de proyectos es más realista que la visión tradicional tayloristo. Acaso un plan de proyecto no es algo vivo que debe actualizarse durante todo el proyecto, reflejando las actualizaciones para aprender a “predecir” esos cambios en futuros proyectos? Repito. Muy interesante. Ya te comentaré si me funciona o no dentro de algún tiempo.

    Saludos.

    PD: Veo que no has dejado de ser tan certero en tus opiniones…

  2. cesargon dice:

    Aitor, en efecto, la clave reside en confiar en las personas. En un post posterior comentaré una conversación que tuve una vez con un colega australiano acerca de la confianza en las personas, y de si debemos “vigilar” a nuestro equipo o dejarlo a su aire.
    Ah, y espero tu feedback acerca de la “fórmula”.🙂

  3. […] de Alice (”¿Puedes tenerlo para esta tarde?”), lo cual contraviene nuestra Regla 1. En segundo lugar, Bob está apresurando a Alice a hacer su trabajo, y quitándole importancia […]

  4. Morgan dice:

    si si .. .claro ….
    me parecen muy buenas reglas y es evidente la confianza que depositas en la gente. Para algunos afortunados que hemos trabajado contigo lo hemos disfrutado y tu lo has sufrido.
    Lo que no dejas claro es cómo vas a luchar contra el choque cultural y la picaresca latina. Yo me he encontrado en muchas situaciones en el pasado y actualmente donde la gente no quiere trabajar y estima de manera exacerbada sus tareas. Segun el libro que citas de Software Estimations hicimos el test y la tecnica a utilizar para que seas un buen “estimator” es sobre-estimar por muchisisisisisismo. Y eso no esta bien. Si utilizamos control charts para el control estadistico de los procesos nos damos cuenta que lo que queremos hacer es reducir la distancia entre LCL y UCL (Low and Upper Control Limit) es decir los limites superior e inferior. Sin embargo en Software Estimations eso no importaba.(lo comprobare—- another bold statement)

  5. cesargon dice:

    La forma de luchar contra la picaresca latina es un caso concreto de un problema más general: la forma de luchar contra las personas que no hacen bien su trabajo. He visto de todo: desde personas que simplemente “pasman” delante del ordenador horas y horas, sin hacer nada, hasta personas que usaban los recursos de la empresa para dedicarse en cuerpo y alma a proyectos personales o incluso pagados por otras empresas (como lo oyes). La forma de luchar contra esto es siempre la misma: tú, como líder del grupo, no aceptas cualquier estimación que te den: si la consideras demasiado optimista, ayudas a la persona a que la haga un poco más realista (como hacía Bob con Alice en algún ejemplo mío reciente); si la consideras demasiado poco ambiciosa, por usar un eufemismo, tomarás nota las primeras veces, y tras unas cuantas, hablarás con el individuo en cuestión. Daré los detalles en un post próximo.

  6. Juan Carlos Restrepo Montoya dice:

    Hola Aitor
    La verdad me ha sorprendido que conclui yo en mi trabajo de grado y es muy similar a lo tuyo. Basicamente lo que enuncias son reglas basicas que todos deberiamos ser concientes de ellas. Algo en lo que no estoy totalmente deacuerdo es en tu primera regla, puede que si sea mejor que la persona que realice el trabajo estime(aunque muy dificil en algunos tipos de trabajos), pero debería de ayudarse con variada tecnica de estimación y no solo en el juicio de expertos(algo muy oscuro). En la tercera regla estoy totalmente deacuerdo, y es lo que se enfatizo mi trabajo de grado, y es que deberían haber varias estimaciones durante el proyecto. Mi compañero y yo sugerimos que dependiendo de una seria de variables se utilizarán tecnicas diferentes para dar una mejor aproximación. Lo que nosotros consideramos importante es el no usar una sola TECNICA, es usar varias y encontrar un punto de convergencia. Creo que entre las diferentes reglas que mencionas deberias tener presente en la tener varios puntos de vista de la estimación y asi será menos sesgada y posiblemente mas efectiva pero mucho mas “costosa” de implementar pero seguramente mas barata que pagar un retraso de un proyecto.
    Si me das tu correo te comparto mi proyecto de grado(algo ladrilludo), pero intersante.
    Cuidate

  7. cesargon dice:

    Juan Carlos,
    Gracias por tu contribución. Mi nombre es César; Aitor es un amigo y comentador habitual de este blog.🙂
    Dices que no estás totalmente de acuerdo con la primera regla (“el responsable de realizar estimaciones y establecer objetivos iniciales es la persona que vaya a realizar cada tarea”). El motivo de esta regla es que la variabilidad de rendimiento y productividad entre diferentes personas es inmensa, a veces de hasta dos órdenes de magnitud, por lo que una estimación hecha por una persona persona diferente a las que va a hacer el trabajo difícilmente tendrá en cuenta el componente subjetivo, tan importante. De hecho, una de las críticas más sólidas que se les suele hacer a los sistemas de gestión estadísticos como Six Sigma y similares es que solo tienen en cuenta las medias y no las enormes dispersiones tan típicas de la variable productividad en el trabajo con conocimiento.
    En cuanto a las técnicas a usar para realizar estimaciones, este es un tema muy importante, pero ortogonal al anterior. El juicio de expertos es “oscuro”, como dices, y recurrir a datos históricos y otras técnicas es útil. El libro que suelo citar, “Software Estimation”, contiene consejos interesantes al respecto. En todo caso, y como bien dice su autor (McConnell): si puedes, cuenta; si no puedes, calcula; y si tampoco puedes, entonces, estima. Es decir: la estimación es un último recurso.
    Un último comentario: no estoy seguro de qué quieres decir cuando hablas de considerar diferentes puntos de vista a la hora de realizar estimaciones. Si lo que quieres decir es promediar las opiniones de diferentes personas, creo que esto no es necesariamente una buena cosa. Es muy políticamente correcto, muy “democrático”, pero cuando estamos hablando del trabajo de una persona, su estimación, si está bien hecha, pesa muchísimo más que las opiniones de cualquier otro individuo. Incluso en un mundo libre de malas intenciones, este no es lugar para los promedios.

  8. […] Creo que hay un detalle de mis posts más recientes que no ha quedado muy claro. He explicado (aquí, aquí y aquí) que cada persona debe de ser la responsable única de establecer los objetivos que […]

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: