Archivos Mensuales: febrero 2016

Estimaciones de un proyecto

Cuando nos enfrentamos a un nuevo proyecto, parece de sentido común que lo primero que tenemos que hacer es “sentarnos a pensar”… qué hacer y cómo hacerlo y hacer una estimación de los costes, ya sea en horas o en euros, pero, ¿y si no tenemos la más remota idea? ¿Y si es la primera vez que nos enfrentamos a un reto parecido? ¿Y si se trata de un proyecto innovador donde sólo sabemos lo que nos gustaría obtener, lo que el cliente querría tener, pero no tenemos una idea clara de cuál va a ser el resultado final?

Seguro que todos nos hemos enfrentado alguna vez a situaciones parecidas. Viene nuestro responsable, el director de la compañía o el responsable comercial y nos dice: “Necesito que estimes el coste de este proyecto para mañana”… Hemos tenido suerte, a veces lo piden también “para ayer”.

Cuando se trata de un proyecto similar a otros que hemos hecho podremos basar la estimación en nuestros datos históricos, tipo de cliente, tipo de proyecto, equipo que lo va a llevar a cabo, plazos realistas en los que en otras ocasiones se ha ejecutado, y muchos otros factores que nos ayudarán a decidir. Además, existen muchas herramientas que nos pueden ayudar a dar una estimación en función del tipo de proyecto que ejecutemos, desde técnicas Delphi, analogías, técnicas de descomposición o simuladores.

Pero, ¿y si no es así? ¿Si es nuevo para nosotros o incluso para la compañía? ¿Qué hacer entonces? ¿Nos lanzamos al vacío y “vamos viendo”? Esa técnica de “a salto de mata” y de “ya vamos viendo” no suele dar nada más que dolores de cabeza, disgustos y malentendidos, así que vale la pena hacer un esfuerzo, estimarlo y ser absolutamente transparentes y claros con una verdad como un templo… LAS ESTIMACIONES ESTÁN SUJETAS A ERROR. ¿Cuándo no tenemos error? A posteriori, a toro pasado, cuando vienen todos a opinar sobre si habría sido mejor esta u otra decisión, pero antes de empezar, seamos claros: cuanto menos conocimiento tengamos, más porcentaje de error cometeremos.

En estas situaciones suelen resultar muy útiles las técnicas de gestión ágil, planificar el proyecto en iteraciones en las que iremos entregando resultados al cliente, éste nos dará feedback y en base a éste iremos construyendo.

Ya, sí, pero … ¿y la primera estimación? Pues cambiemos el chip, no pensemos en la cantidad de trabajo que puede hacer una persona al día; porque no lo sabemos y porque cada persona tiene una productividad diferente que incluso depende del tipo de tarea. ¿Y si no estimamos por horas… cómo lo hacemos? Las técnicas ágiles proponen una técnica de estimación por PUNTOS, en la que le damos un punto a una tarea conocida por todo el equipo y, a partir de ella, cada miembro del equipo le da puntos a los demás. Cuando todos los miembros del equipo vota, curiosamente las aproximaciones se van aproximando a un número con el que todos nos encontramos cómodos, y que consideramos como válido para arrancar. La premisa es que cuanto mayor es el valor, obviamente mayor es el error cometido: todos sabemos diferenciar entre tareas que llevan 1 hora o 2 horas, pero aproximar si nos llevará 123 horas o 127 es mucho más complicado ¿o no?

Para empezar a “jugar” con estas estimaciones, existe una técnica basada en la Serie de Fibonacci, que es una serie numérica en la que cada número se obtiene de la suma de los dos anteriores: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, …

Las barajas de “planning poker” se basan en la serie de Fibonacci  pero tienen ciertas variaciones. Se incluye el 0 para elementos que requieren un esfuerzo casi nulo y  1/2 para actividades muy pequeñas pero que ya tienen un poquito de entidad. Además, a partir del 21 las barajas suelen pasar al infinito (∞) y que significará que la tarea se ve demasiado compleja para estimarla al completo y es mejor dividirla y volver a estimar. También suelen incorporar una carta de “pausa” que los miembros del equipo desean parar el análisis para continuarlo más tarde y una interrogación para situaciones en las que no se tiene ni idea del tiempo y habrá que comentarlo.

BarajasPlanningPoker.jpg

¡Adelante! Involucra a tu equipo para que te ayude a estimar y verás que, además de ello, se sentirá partícipe de las decisiones que se tomen y se consolidará la sensación de pertenencia, de equipo, indispensable para el éxito de los proyectos.

 

 

 

 

 

 

 

¿Tenemos claro qué es y qué no es un proyecto?

Antes de comenzar a hablar de gestión de proyectos, algunas definiciones que las distintas publicaciones sobre gestión comparten, con independencia de si éstas son de corriente iterativa, ágil o predictiva.

  • Proyecto: Esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único.

De esta definición hay que quedarse con dos aspectos sin los cuales no hablamos de proyecto, sino de operación, de funcionamiento rutinario, o de cualquier otra cosa.

En primer lugar, la temporalidad. Ninguna metodología de gestión llama “proyecto” a algo que no termina nunca; tiene que estar definido un principio y un final, y lo que ocurra a partir de ahí será otro proyecto, o un mantenimiento, u otra cosa que nos queramos “inventar”, pero no un proyecto. El final se alcanza cuando se alcanzan los objetivos de dicho proyecto, o bien cuando se determina que hay que pararlo porque nunca se van a conseguir.

En segundo lugar, la unicidad del resultado. Producir en serie no es un proyecto, es una producción y la gestión no es la misma. Esto no quiere decir que el resultado tenga que ser tangible, no tiene que ser un producto, pero sí tiene que ser único, aunque en el desarrollo se puedan ejecutar acciones repetitivas (no confundamos). Por ejemplo, la construcción de dos casas idénticas por el mismo equipo de trabajo constituye dos proyectos de construcción diferentes, pese a que van a ser similares en el desarrollo, pero tendrán diferentes situaciones, circunstancias e interesados.

El patrón dialéctico

La dialéctica puede parecernos un arte muy antiguo, de los tiempos de Platón y Sócrates, pero sin embargo, no deja de estar completamente vigente en la actualidad. ¿Cuántas veces hemos puesto dos ideas contrarias sobre la mesa para quedarnos con la del “medio”? Esto no es más que dialéctica: partir de una tesis, su antítesis, y quedarse con la síntesis, que a su vez se convertirá en tesis para que el conocimiento pueda seguir evolucionando.

En la gestión de proyectos también sucede lo mismo. Todos pensábamos hasta no hace demasiado tiempo, en que los modelos predictivos eran “los buenos”. Se había reunido el “Comité de Sabios” y se habían escrito múltiples libros sobre los procesos de planificación, seguimiento y control de los proyectos para convertir éstos en éxito. Pero entonces aparecieron los agilistas, que se empezaron a cuestionar todo lo relacionado con la gestión predictiva. Como siempre, ya lo dicen los refranes, “en el medio está la virtud” y los extremismos no son nunca verdades absolutas (casi nada lo es), y así nacen corrientes como Scrum Manager, que trata de quedarse con la síntesis de ambos (que no la suma), con lo mejor de los dos mundos.

A lo largo de estos posts iré intentando comentar lo mejor de estos dos mundos en base  a mi experiencia en los distintos proyectos en los que he participado a lo largo de los más de 15 años de experiencia. De todos he aprendido, de los buenos y sobre todo de los malos momentos que han requerido adaptar métodos y respuestas a entornos reales, a clientes reales, a equipos reales y a “sufrimientos” reales.

Lo que he aprendido de toda mi experiencia es que no hay verdades absolutas, que la razón no siempre importa, ni siquiera tenerla ni no tenerla, y que lo que importa realmente es darlo todo para que tus proyectos, tu equipo, tu empresa, tus clientes sean los mejores y consigan éxitos.