Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

Estimando que es gerundio.

4 comments
Estimando que es gerundio.

Es bastante frecuente que cuando nuestros clientes o Jefes nos piden estimar un proyecto, sientas “su aliento en el cogote” porque es urgentísimo tener una estimación de algo que se necesita automatizar.

Yo mismo, he sido el “inductor” en más de alguna ocasión de la famosa frase de “Lo necesito para ayer” cuando de dar una estimación de un proyecto se trata. Sé los riesgos que tienen las “estimaciones tempranas” , pero muchas más veces de las que me gustaría no hay más remedio que hacerlo así.

Por mucho que nos empeñemos , y llevo ya unos cuantos años en esto, siempre nos vamos a encontrar con este tipo de situaciones. Si eres proveedor que concursas por un proyecto en el cliente, te pedirán bastantes veces  que estimes con prisas, y con datos escasos para poder hacer tu trabajo adecuadamente.

Si eres de un departamento interno de desarrollo de Sw, te pedirán bastantes veces que estimes con prisas  y con datos escasos para poder hacer tu trabajo adecuadamente. No, no  he repetido una frase de este post por error. Está intencionadamente puesta así.  Esto demuestra que da igual que rol desempeñes, las estimaciones que te tocará realizar van a ser en muchas ocasiones dadas en poco tiempo y con pocos datos.

También es bastante común, que aquellos que no van a trabajar en el proyecto creen saber más que tú sobre lo que se va a tardar en hacer el proyecto. Este tipo de cosas ocurren en la Gestión de Proyectos , y debes convivir con ellas.

Y como no, todos esperan de ti que además de seguir con todas las tareas y proyectos que manejas y gestionas , le dediques tiempo a hacer la estimación con la máxima profundidad ( y  hay de ti como no sea así , porque si tienes la suerte de que te den el proyecto : o has estimado con unos mínimos de confiabilidad o estás literalmente perdido; vas a empezar ya torcido y luego enderezarlo será difícil).

He aquí algunos consejos para que tus estimaciones sean más confiables.

1-    Pregunta.

Tu cliente o jefe, te ha explicado lo que se requiere, con toda la información que puede/tiene  bajo su control ( aquí descargo una pica a favor de ellos porque muchas veces, tampoco  tienen toda la información para que puedas estimar, puede haber muchos factores tanto internos como externos que pueden estar en el momento en que surge la necesidad poco o nada definidos y se deben descubrir con el tiempo.)

Pregúntale primero cual es su prioridad principal.  ¿ La entrega de la Release /Proyecto en una fecha? – ¿ El presupuesto?. Algunas veces es la fecha y otras veces es el presupuesto. Y las que más son la fecha y el presupuesto. Así de dura es la vida amigos, pero por lo menos pregunta. No des nada por sentado. Solamente porque tu Jefe / cliente te pregunte por la Fecha de entrega, no tiene porqué querer decir que esa será su principal prioridad.

2-    Divide y vencerás.

Cuando las características que tienes que desarrollar son poco definidas y te da en el olfato ( que es algo que también se usa para estimar ) que pueden ser descompuestas en funciones más pequeñas , procura hacer esa descomposición en tareas tan granularmente como te sea posible pues de esa manera te será más fácil obtener una estimación y al mismo tiempo te ayudará a descomponer el trabajo, lo cual es algo que ya tienes ganado.

Haz estimaciones de cada función descompuesta con tiempos optimistas, probables y pesimistas y obtén la estimación por cálculo de tiempos medios.

3-    No discutas

Cuando te imponen una fecha y un conjunto de características. ¿Para qué te vas a poner a discutir?. No te va a servir de nada. ¿ Para qué te vas a poner a estimar? – Ponte a trabajar!!! . Ya!!!

Aplica una técnica mucho más inteligente y menos dolorosa para ti que la discusión que no te va a llevar a nada, porque no te van a cambiar la fecha ni lo que tienes que entregar.  Comunica a la dirección que vas a hacer todos los esfuerzos para tener lo que te han pedido en el tiempo que te han pedido, pues no puedes pararte a estimar si es o no posible cumplirlo y explica que vas a realizar una revisión del trabajo que llevas realizado cuando se haya cumplido entre el  35% – 50 % del tiempo estipulado para ver como va el avance ( % que dependerá del nivel de complejidad del proyecto) . Haz que la dirección se comprometa a que como resultado de esa revisión,  si el avance acumulado presenta un riesgo de incumplimiento , tome medidas para que tu equipo pueda llegar al objetivo ( ampliar equipo, negociar alcance o gestionar prioridades ).

En estos casos, tienes que ser capaz de sacar al equipo de la multitarea , no puede haber interrupciones y como Jefe de Proyecto debes ser un muro que pare cualquier otra petición que afecte al objetivo.

4. Comparte con el equipo.

No siempre será posible ya que en bastantes ocasiones, se le piden  estimaciones al proveedor o Jefe de Proyecto sin que éste sepa quien va a ser el equipo que desarrollará .  Si tienes la suerte de contar con un equipo fijo , para estimar debes tener en cuenta la “velocidad” de tu equipo y basándote en las métricas de otros proyectos ajustar la confiabilidad de la estimación a las personas que van a realizar el trabajo.

Si no es así, y el equipo te lo van a asignar una vez que te adjudiquen el proyecto, tendrás que considerar un % de confiabilidad más bajo en lo que hayas estimado , y ajustarlo más tarde cuando te hayan asignado ya el equipo.

Ahora bien, con estos cuatro consejos encima de la mesa, si eres un proveedor que está ofertando para un cliente y se te exige precio cerrado , tienes que hacerlo muy , pero que muy bien al estimar. Y tienes que ser capaz de demostrar tu estimación y justificar los % de confiabilidad que estás dando y porqué.

Todo sería mucho más fácil si puedes formalizar un Contrato ÁGIL. Un contrato en el cual en base a una lista de funcionalidades ordenadas  y valoradas (Product Backlog) , y   a unas entregas pactadas (Sprint Planning) , defines las estimaciones y por tanto los presupuestos de cada una de las entregas en vez del proyecto completo . Tanto tú como tus clientes os comprometéis a una relación Win-Win , en la que se estipulen unos importes máximos por el proyecto completo y un importe mínimo comprometido , que luego se va a ir  ajustando en base a como vayan avanzando cada una de las entregas pactadas , siendo menos perjudicial para todos cualquier alteración del proyecto tanto en alcance (modificamos el Product Backlog para el siguiente Sprint siempre que lo nuevo sea razonablemente parecido a lo que existía ) como en terminación anticipada del proyecto caso de que suceda algún evento que así lo obligue.

Las organizaciones que ya han adoptado el Modelo Ágil para el desarrollo de SW son consumidores de estos “Contratos Ágiles”, sobre los cuales escribiré algo por estas páginas, puesto que el párrafo anterior no es más que una mera introducción a este tipo de contratos, muy básica, pero que me sirve para ilustrar como estos contratos influyen en las estimaciones de los proyectos.

Lo más habitual, sin embargo, es contar con contratos de “Precio cerrado” , en los que un buen ejercicio de estimación es fundamental. Espero que con los consejos que te he mencionado en este artículo te ayude para realizar próximas estimaciones.

  1. Pues anda que no he discutido veces por el timming. De todas maneras, en empresas anteriores que he trabajado me he encontrado muchas veces que consigues acotar un timming y te encuentras con muros que provocan dialogos del tipo combate con florete:

    Tu le das tu timming con ciertas reservas debido a que lo has ajustado mas o menos al máximo, y te dicen:

    JEFE: “imposible ha de estar antes” o bien un (coloquialmente) “se te ha ido la pinza”

    con lo que alguna vez optas por decir:

    “bueno, dame tu el timming y lo que esté estará y lo que no pues faltará”.

    A lo que responde:

    JEFE: “Imposible, ha de estar todo y en ese tiempo y funcionando perfectamente”.

    Ante eso contraatacas con:

    “Con mi equipo actual no llegamos porque tenemos tal y tal proyecto a la vez que tendremos que aparcar….” (aquí habitualmente hay una interrupcion brusca)

    JEFE: “Imposible (será que aprendió la palabra, le gustó y la utiliza cada pocos segundos??), no podeis dejar nada porque vamos justos de tiempos!!!”

    Ya desesperado propones (iluso):

    “Pues necesitaria que me asignarais mas personal para redistribuir”.

    JEFE: “Imposible (again) ya sabeis que tenemos el presupuesto acotado, haced mas horas o suprimid el café (como si nos diera tiempo de tomarlo gracias a los ultimos marrones)” .

    Finalmente, ante esto optas por decir:

    “Bueno se hará lo que se pueda, decide que quieres que hagamos primero.”

    A lo que te lanza un:

    JEFE- “Dímelo tu que eres el responsable y conoces como va el equipo, dame el timming”

    Y se produce un reseteo de la conversación. Vuelta a empezar hasta que uno de los dos se rinde o se cansa de dar vueltas.

    :)

    De todas maneras, si no pasarán cosas así no sería divertido! :)

    • Pepe Vázquez says:

      Asi es David, en nuestra profesión estos casos que comentas, son más habituales de lo que pensamos. Por mucho que te empeñes en demostrar que el Timming es el que es, los directivos quieren otra cosa. Hay veces que saben que las fechas y la valoración que tú das son más que razonables , pero juegan otro rol distinto . Ellos son los que en el mundo de la empresa actual, se la juegan en primera instancia y presionan incluso para que adelantes las fechas en la convicción de que si aprietan aún más , conseguiran mejores resultados, o al menos, una mayor cantidad de trabajo realizado cuando llegue la fecha y por tanto un menor retraso global. Creo que eso es un error !! . Esto se tiene que basar en la confianza y en la transparencia. Es verdad que desde su rol ven que de manera sistemática muchisimos proyectos ( las cifras lo demuestran) se retrasan y se van de presupuesto (¿ eso es culpa nuestra? en parte si) , pero creo que es consecuencia de muchas otras cosas : de las presiones innecesarias que no motivan al equipo (sino todo lo contrario) de la manera de hacer las cosas ( en Waterfall esto es un claro ejemplo que se ve a menudo) y de los recortes presupuestarios que hacen que las personas, sus conocimientos habilidades y competencias, se reduzcan minando la productividad. Es un cúmulo de cosas, pero también creo que podemos cambiarlo y a los Jefes que ven asi las cosas deberíamos tratar de enseñarles, y no cejar en el empeño de que entiendan porqué hemos dado esta u otra estimación e incluso invitarles a que asistan a las reuniones de estimación en las que con tu equipo haces esta tarea. Muchas gracias por tu comentario y como dices bien : si todo fuera una balsa de aceite no aburriríamos.

  2. Que buen articulo y que útil. Deberían leerlo algunos que me se. Por lo menos se lo mandare a los que me sigan. Seguro que les vale de mucha ayuda!! Me encanta tu blog!! Felicidades y gracias.

    • Pepe Vázquez says:

      Muchas gracias por el comentario Elia. Esto de las estimaciones es una “ciencia” que requiere de bastante sentido comun a la par que algo de “brujería” porque hay veces que nos piden estimar unas cosas en las que tienes que mirar la bola de cristal para poder calcular lo que va a costar algo.
      Gracias de nuevo y me alegro que te guste el blog.

Trackbacks/Pingbacks

  1. WaterScrumFall. | GestiondeProyectosIT - [...] El precio está cerrado, así que poco puedes hacer ya en ese sentido.  Las estimaciones iniciales que se dieron…

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *


*