El mito de la desviación en proyectos de software

El mito de la desviación en proyectos de software


En el mundo del desarrollo de software está muy extendida la palabra desviación aplicada al proyecto. Cuando un proyecto se desvía quiere decir que se planificó inicialmente en un tiempo determinado y con un presupuesto acotado y que actualmente ese tiempo y/o presupuesto se ha superado.

En gestión de proyectos, como en todo, las palabras y el lenguaje importa, por lo que me gustaría escribir y reflexionar sobre este aspecto tan interiorizado y aceptado que creo que merece la pena una revisión.

Por qué se desvían los proyectos (el mito)

Tengo un proyecto en mente: comprar un pez para mi hijo.

En el momento en el que planifico lo que hago es imaginar cómo va a ser la construcción de ese proyecto, por lo que imagino la construcción mediante la compra de las piezas de la pecera, el pez y el agua. También anticipo que el mantenimiento de ese proyecto requerirá un bote de comida de peces cada cierto tiempo. Este es el diseño/visión de mi proyecto:

El mito de la desviación en proyectos de software

Llega el momento de la ejecución o implementación del proyecto. Voy con mi hijo a la tienda de animales y comienzo la construcción. El dependiente me asesora correctamente y me explica en qué consiste realmente esto de tener un pez. Seguramente acabaré comprando una pecera mayor de la que me había imaginado, además de piedrecitas, una planta de plástico, algún pez de más, y productos específicos para tratar el agua. El resultado final es éste:

El mito de la desviación en proyectos de software

Evidentemente, tanto el esfuerzo necesario para montar la segunda pecera como para mantenerla va a ser más grande, y el presupuesto necesariamente deberá crecer para comprar todos los elementos necesarios.

En este caso podríamos decir que claramente el proyecto se ha desviado.

Lo que realmente ha pasado (la realidad)

Como cliente lo que busco es obtener el producto que se ajuste a mis necesidades y que me aporte el máximo valor por el precio que voy a pagar. En el caso particular de este proyecto, lo que busco es una pecera que haga feliz a mi hijo y que no desentone con el comedor. Seguramente cuando empecé el proyecto no tenía ni idea de peces ni peceras, no sabía las posibilidades que tenía a la hora de construir mi proyecto. Tenía claras algunas cosas básicas, como por ejemplo que no quería un pez de plástico cochambroso metido en un vaso de agua ni tampoco un acuario de 500 litros con tiburones y rayas venenosas que me ocupara medio comedor. Quería simplemente “una pecera que esté bien”.

El vendedor/asesor/consultor hizo un excelente trabajo asesorándome sobre los distintos tipos de peces, qué cuidados y productos necesita cada uno, sobre los elementos ornamentales que pueden ayudar a adecuar el aspecto de la pecera acorde con mi comedor, y de los productos básicos de mantenimiento para que el animal tenga una vida digna. No me ha vendido la moto, simplemente me ha asesorado en mi decisión.

El resultado final es que tengo una pecera que me gusta y que creo que se ajusta a lo que necesitaba, mi hijo contentísimo porque tiene su pez, y el pez… bueno quiero pensar que también es feliz. Me había imaginado otra cosa al principio, mucho más simple, pero durante el proceso he comprendido que realmente necesitaba otra cosa, he visto las posibilidades y sin irme al extremo de un acuario XXL he obtenido la mejor pecera dentro de mis posibilidades y preferencias.

El mito de la desviación en proyectos de software

Desviarse significa literalmente salirse del camino trazado. En este caso no teníamos camino porque ni siquiera teníamos el destino claro. La realidad es que el proyecto no se ha desviado, simplemente a la hora de planificar no tenías 100% claro lo que queríamos exactamente, solo teníamos una idea y un objetivo/requerimiento, que era tener una pecera con un pez “que esté bien”. Cuando hicimos el plan nos faltaba muchísima información aparte de unos requerimientos mucho más claros, y además durante el desarrollo esos requerimientos han cambiado (he decidido que quería más de un pez, que quería una planta, piedrecitas, etc…). Si me hubiera ceñido al plan inicial es más que probable que mi hijo no estuviera tan feliz, la pecera desentonara en el comedor y el pez la palmara a las 3 semanas por no hacer el tratamiento correcto al agua. No me hubiera “desviado” pero el resultado final sería ostensiblemente peor.

Propuesta: Cambiar el lenguaje y la visión de la planificación

Es imposible evitar “desviarse”, es una batalla perdida, a no ser que tu trabajo sea tan repetitivo que permita hacer ese tipo de planes al dedillo (cosa que en software no se da nunca).

Es como intentar acertar la quiniela. Hay gente que lo intenta, existen peñas quinielísticas que utilizan información histórica y estadística, gente que estudia trayectoria de los equipos, estado de forma y mental de los jugadores, condiciones meteorológicas, tácticas y estrategias utilizadas. Pese a que solo tienes que decidirte por 1, X o 2, la cantidad de variabilidad que entra en juego en el momento en el que el balón comienza a rodar hace que todo lo anterior sea casi irrelevante. Es probable que aciertes 7, 8, 9  incluso 10 partidos, pero habrán otros 4-5 partidos que se te van a “desviar”. Pese a que nuestro trabajo no es tan variable, la única manera de conocer todas las variables es “hacer el trabajo”. Solo cuando lo terminas eres capaz de saber “cuánto cuesta”.

En el mundo de la planificación valoración y estimación son sinónimos. Pese a que etimológicamente sean lo mismo, tengo especial preferencia por la palabra “estimación” por encima de “valoración” por lo siguiente: Si hago una valoración de una tarea en “10” y tras terminarla he consumido “15”, parece que el valor de la tarea sigue siendo 10. Es mentira, es una tarea de 15, pero que al no tener toda la información a priori la he infravalorado. Sin embargo si digo que la he estimado en 10 me suena a que con la información que tengo creo que voy a tardar 10. Estoy estimando o jugando a adivinar un valor que desconozco.

A la hora de describir la situación final siempre intento evitar la palabra desviación, no es que me haya desviado al hacer la tarea, ya que la ejecución de la tarea ha sido la correcta. Lo que ha pasado es que me faltaba mucha información a la hora de estimar, con lo cual podría hablar de estimación incompleta o bien si me quiero enfocar en la ejecución, que me he visto obligado a alterar unos planes imperfectos.

Conclusiones

Que nadie me malinterprete. No estoy diciendo que no se deba estimar ni planificar.

Lo que sí que debemos hacer es dejar de criminalizar a los equipos o ingenieros que se “desvían”, incluso si las estimaciones las hacen ellos mismos. Pese a que cuenten con las más sofisticadas herramientas en las oscuras artes adivinatorias del mundo del desarrollo de software, la cantidad de variables a la hora de implementar una tarea o proyecto hace que sea virtualmente imposible adivinar una valoración con la precisión que la dirección espera.

También deberíamos comenzar a flexibilizar los planes que hacemos, ya no porque sea muy complicado estimar, sino también para adaptar el plan a las necesidades que vayan surgiendo y cambiando a lo largo de la vida del proyecto, tanto de los usuarios como del propio entorno del proyecto.

Para ello el primer paso es llamar a las cosas con precisión en el lenguaje:
– No se desvía un proyecto o tarea, se debe desviar o modificar el plan para adaptarse a las evidencias de las nuevas circunstancias.
– El valor de una tarea solo podemos saberlo a posteriori, a priori tendremos una idea feliz que llamaremos estimación (por no llamarle adivinanza o revelación)

Que el plan de proyecto se desvíe o fallar en las estimaciones puede ser muy bueno si el nuevo plan incluye tareas y características de mucho valor de negocio. Que se lo digan a mi hijo que está contentísimo con su pez.

También te puede interesar...

Resumen del libro Coaching Agile Teams de Lyssa Ad... El libro Coaching Agile Teams de Lyssa Adkins es una referencia obligada dentro del mundillo Agile. Prácticamente todo el mundo que conozco y se lo ha...
Resumen Agile Retrospectives de Esther Derby y Dia... El libro Agile Retrospectives de Esther Derby y Diana Larsen es un manual para Scrum Masters sobre cómo facilitar las retrospectivas en los equipos. ...
Cómo preparar una Sprint Review (Review Series II)... En el primer artículo de la serie vimos algunos antipatrones de Sprint Review comunes que restaban efectividad a esta sesión tan importante de Scrum. ...

Dejar un comentario

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

3 ideas sobre “El mito de la desviación en proyectos de software

  • margarita

    En efecto. Hacemos un presupuesto de costes, sobre algo que desconocemos. Por eso se llama presupuesto, porque presuponemos, y no siempre acertamos.

  • Juan José Ruiz Ruiz Torre

    Totalmente de acuerdo con Manuel creo que lo correcto es hablar de desviaciones de las planificaciones para adaptarse a las nuevas circunstancias-evidencias.
    Y creo que todos los que nos dedicamos profesionalmente al mundo del desarrollo de software deberíamos empezar a realizar una continua acción “evangelizadora” a este respecto.
    Me ha gustado mucho el post, artículo, tu opinión o como se quiera definir.
    ¡¡Buen trabajo!!.
    Gracias por compartirlo.