Estimar no es comprometerse

0

Hay una realidad muy clara en nuestro mundo, el de TI: la precisión de nuestras estimaciones es baja. No importa que usemos las técnicas más avanzadas para estimar los costes de un proyecto, no tenemos una bola mágica que nos prediga el futuro. La incertidumbre que hay en nuestras estimaciones es muy alta.

Los motivos son varios. Por un lado tenemos que los programadores tienden a no ver todo lo que hay que realizar, se les escapan cosas y sus estimaciones suelen ser más bajas de lo que luego nos dice la realidad. Así que una y otra vez, se quedan cortos y tienen que luchar con la presión de llegar tarde. Normal que luego los programadores no quieran estimar. Y también es normal que estas estimaciones se acompañen de generosos colchones que las hinchan, para así cubrirse las espaldas.

Asumámoslo, nuestra estimación no es más que eso: una estimación. No es una predicción del futuro. A lo mejor podemos hacer “predicciones” para cosas que pasarán en un par de días, pero no para lo que hay que entregar dentro de dos meses. Pensemos en el hombre del tiempo. Si nos dice el tiempo que hará mañana, nos lo creeremos. Pero a nadie se le ocurre ir a una web de predicción del tiempo para ver el tiempo que hará en una ciudad dentro de dos meses. Sabemos que esa estimación será muy mala y que el poder de predicción es bajísimo.

Así que se ha generado una tendencia a no dar estimaciones. Por un lado en el mundo agile hay una tendencia a no dar plazos más allá de la duración del sprint. Así aparecen técnicas de estimación basadas en puntos, que evitan hablar de plazos de entrega. Así, es normal que en algunos casos negocio se canse de esa falta de visión de futuro, y termine “cargándose” el esquema ágil, volviendo a modelos clásicos (cabreando por supuesto a todo el equipo de desarrollo).

Asúmamoslo, negocio quiere y necesita predicciones. Y negocio es nuestro cliente. No debemos ocultarle información a nuestro cliente, se la tenemos que dar. Pero tampoco debemos mentirle. No podemos decirle “Esto lo tendrás entregado dentro de 2 meses” si no sabemos siquiera el detalle de las funcionalidades que tenemos que montar.

¿Entonces en que quedamos? Pues la conclusión, desde mi punto de vista es simple: No es lo mismo una estimación, que un compromiso. Y eso negocio tiene que tenerlo claro. Y para que lo tenga claro, tenemos que educarlo. Desarrollar software no es como otras ingenierías. La fiabilidad de las predicciones en el mundo de la construcción no es la misma que en el mundo del desarrollo de software. Negocio tiene que aceptar que una estimación de 2 meses se convierta en 4.

¿Y como educarle? Mmm, ese es el quid de la cuestión.

Mi recomendación es que las estimaciones deben incluir dos factores:

  • Esperanza: El valor que creemos que tendrá.
  • Fiabilidad: ¿Cómo de fiable es esa medida?

Pero negocio no entenderá el valor de fiabilidad que le demos. Así que lo mejor es la orquilla. Es decir, decir dos valores:

  • Estimación optimista
  • Estimación pesimista

Y acompañar siempre la estimación pesimista de la coletilla “no es un compromiso”. Si quieren un compromiso, entonces habrá que dejarles claras dos cosas:

  • Establecer un compromiso implica que el valor de esa fecha de entrega es superior a las otras restricciones del producto entregado. Es decir, negocio debe tener claro que al poner una fecha de entrega, estaremos limitando las funcionalidades a entregar. Esto debe quedar cristalino.
  • Establecer unas asunciones y excepciones iniciales, que de incumplirse, rompen el compromiso.

Mi recomendación es que tus clientes entiendan que ese compromiso de fecha de entrega no aparezca como tal. Que sea un item de los que aporta valor. Y a lo largo de cada sprint iremos evaluando como vamos, y si nuestra estimación cumple esa fecha de entrega. En caso de incumplirse, le daremos a elegir en ese momento de lo que se lleva y lo que se pierde. Es decir, convertimos de nuevo el compromiso en estimación.

Mi experiencia es que los primeros meses eso de decirles a negocio “No es un compromiso es una estimación” y meterlo en cualquier mail o documento que se genera, les provoca una reacción de rechazo. Como si quisieses quitarte responsabilidades de encima. Pero llega un día en el que no te aceptan esa frase y te piden un compromiso, ahí es donde de verdad ponemos en marcha la recomendación de hacerles ver lo que les cuesta ese compromiso. Y en ese punto empiezan a entender el concepto de estimación.

Eso sí, las estimaciones no se dan una vez y se abandonan. Las estimaciones se hacen para tener un plan. Luego, ese plan tiene un seguimiento y se va viendo si se sigue el plan o no. Da igual si estimamos coste, horas de trabajo o puntos, se están estimando una fechas de entrega. Según pasa el tiempo pasarán dos cosas: Las estimaciones cambian y la precisión de las mismas aumenta. Mantengamos informados a los interesados.

Al final, negocio lo que necesita es estar correctamente informado. No informarle o darle un compromiso inalcanzable o que merme la calidad de lo entregado es engañarle.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios