Cuando tu plan de proyecto es un suicidio… y no lo sabes

Durante un tiempo estuve leyendo un libro titulado Pensar rápido, pensar despacio, del premio nobel Daniel Kahneman. Y digo durante un tiempo porque es un libro bastante extenso (más de 600 páginas) con partes muy densas que a veces tuve que repasar para quedarme con la idea.

En este libro, el autor analiza la forma en la que pensamos y por qué razonamos de la manera en la que lo hacemos.

En una sección en particular, la cual me resultó especialmente interesante, habla sobre los sesgos o sobre cómo determinadas acciones o hechos nos influyen a la hora de tomar decisiones.

En otro capítulo aborda el hecho de lo optimistas que podemos llegar a ser a la hora de tomar una decisión o de predecir algo. Por ejemplo, a la hora de abordar un plan muchas veces sólo miramos aspectos positivos del mismo (cuando se crea un plan para un proyecto, se emprende en un nuevo negocio…) de cara a tomar la decisión de si abordarlo o no. Sería algo así como una forma de verlo lo más positivo o asequible posible para que, de esta manera, nos convenzamos a nosotros mismos de que es posible. A este hecho le denomina “Falacia de la planificación”.

Entrando más a fondo en este tema, comenta que una forma de cambiar este tipo de conductas es a través de hacernos preguntas incómodas que nos permitan hacer una pasada por aspectos que podrían impactar negativamente en el resultado final, e incide en el hecho de que, haciendo un análisis más exhaustivo de la situación, podríamos cambiar nuestro plan y conseguir que fuera más certero (por ejemplo, consultando a expertos o buscando más puntos de vista).

Expectativas vs. Realidad en IT

Esta lectura me ha hecho reflexionar sobre proyectos de mi vida profesional en los que he participado de una manera u otra y en la que he visto cosas como:

• Un responsable decide que un desarrollador tiene que salir del proyecto porque es una persona tóxica: no para de decir que el plan no es realista, que no hemos tenido en cuenta todas las situaciones, que no lo vamos a conseguir…
• Un gerente le pregunta a un jefe de proyecto cuándo va a tener una release disponible. Este le da una fecha pensando más en cumplir sus expectativas más que en sí se puede abordar.
• Un jefe de proyecto transmite un plan de proyecto a un equipo de desarrollo. El equipo no lo ha creado pero viéndolo a alto nivel considera que es realista. Una semana después de que arranque, el plan ya ha cambiado cuatro veces y nadie se para a plantear si la fecha inicial que se transmitió se va a conseguir.

Hay más situaciones, pero me quedo con estas porque tienen un denominador común: el plan venía impuesto a la gente que tenía que abordarlo. Tristemente estas situaciones se dan actualmente en muchas organizaciones y seguirán ocurriendo durante mucho tiempo. La pregunta que yo me haría es: ¿Hasta cuándo?

Cuando fallamos en un plan que nos han impuesto fallamos dos veces. La primera vez porque el plan no es realista. Una vez que se llega a esta conclusión (y con la consecuente bronca al equipo de desarrollo que no “ha sido capaz” de no seguir un plan que le han impuesto) se pregunta a la gente que va a ejecutar el plan que piense en uno (como una vida extra en un videojuego). Aquí entramos en el farragoso juego del “no se puede tardar tanto”, “tiene que estar antes de X pero tú ponme la fecha”, etc. Al final, el equipo termina rehaciendo un plan tan influenciado por el positivismo de un responsable que dejar de ser suyo. Es algo así como “miéntete a ti mismo para mentirme a mi” y en este momento es cuando hemos fallado la segunda vez. El resultado de situaciones como esta no hace falta que las comente, hay muchos ejemplos y experiencias que se podrían contar, así que si te animas a compartir, déjanos la tuya en los comentarios.

La reflexión que hago es: hasta qué punto la oleada Agile ha venido a cambiar esto y si lo está consiguiendo. Por ejemplo, Scrum a través de los sprints nos hacen bajar el nivel de incertidumbre y ser más certeros porque no hablamos de un sprint goal de más de 30 días y tampoco nos hacen ser infalibles, nos podemos equivocar igual (tanto desde el punto de vista de estrategia de negocio del Product Owner como desde el punto de vista de la auto-organización del equipo de desarrollo a la hora abordar la complejidad propia del desarrollo de un producto). En este sentido, a la hora de buscar compañeros de batalla a la hora de desarrollar un proyecto o producto, prefiero a gente que sepa generar auto-organización en el equipo, que sean profesionales y que tengan autocrítica, más que gente que prediga con una bola de cristal cuál va a ser la fecha final de un proyecto. No voy a estar rodeado de futurólogos, pero al menos estaré con gente que lo va a hacer lo mejor posible.

Se que si algún gerente o responsable lee esto pensará: “Vale, pero yo necesito una fecha”. En respuesta, le invitaría a reflexionar sobre si cada vez que ha impuesto una fecha esta se ha cumplido sin cambiar la calidad, el alcance o alguna de las mil variables que implica.

Imagen: unsplash | rawpixel