Vicios peligrosos en la gestión de proyectos


Quiero hablar de algo que he oído al 99% de directores de proyecto, jefes de proyecto, gerentes de proyecto, e incluso a Scrum Masters. Como los gases tienden a ocupar el 100% del volumen disponible, una tarea asignada a una persona tenderá a ocupar el 100% del tiempo asignado para ella, o incluso más. Por eso, “lo que hay que hacer” es asignar un poco menos de tiempo y así en el mejor de los casos lo tendremos antes, y en el peor lo tendremos a tiempo. Esto puede tener un corolario, la Ley de Parkinson, que dice que si a alguien le quitas tareas, no conseguirás acortar el tiempo sino que esa persona generará tareas nuevas para rellenar ese “hueco”.

Bien, primero de todo deberíamos poner el foco en establecer una diferencia entre el volumen del gas y el tiempo disponible para una tarea. Mientras el volumen que tiene el gas es el que es, lo que hay, el tiempo de una tarea normalmente viene dado o bien por una estimación o bien por una fecha establecida inamovible que nada tiene que ver con la tarea. En ambos casos el tiempo disponible no será nunca el tiempo requerido para hacer esa tarea, puesto que este tiempo requerido lo sabemos siempre a posteriori, cuando la tarea está ya hecha. El tiempo disponible es entonces, directamente, un deseo que nos creamos y nos creemos nosotros mismos, es poco más que una mentira.

Ahora partimos del tiempo estimado, que supongamos que es mejor que el tiempo impuesto “porque sí”. Bueno pues decimos que lo mejor es dejar siempre un poco menos para apretar a ver si se puede hacer antes o si se desvía que aun estemos a tiempo. Para ilustrar esta falacia, cojamos una herramienta muy útil en gestión de proyectos llamada el triángulo de hierro que establece una relación difícil de romper entre las personas o recursos, el tiempo y el alcance de un proyecto.

Triángulo de hierro

¿Qué pasa cuando fijas recursos y alcance y coges el tiempo, que de base es mentira, y lo acortas? Pues que lo que sufre es la 4ª dimensión oculta del triángulo, la calidad. Una tarea que necesita un tiempo T para hacerla con la calidad adecuada, no se puede hacer en menos de T, y si intentas hacerla en menos probablemente lo consigas, pero lo que te encontrarás es que te dejarás cosas por hacer o por probar, y probablemente tendrá más errores, y el producto probablemente será más costoso de mantener y de integrar, y lo que hayas “ahorrado” en tiempo de desarrollo muy probablemente lo acabes pagando a posteriori. La deuda técnica no tiene ese nombre por casualidad, ésta tiene siempre intereses y los intereses siempre se acaban pagando caros.

Otro pensamiento común es que si a un desarrollador no le dices exactamente lo que tiene que hacer y no le dices un tiempo ajustado que cumplir, tenderá a perder el tiempo y a relajarse para acabar tardando más de la cuenta en completar la tarea. Sobre todo cuando no tienen tanta experiencia. Bien, esto directamente es negar la realidad. Los desarrolladores, sobre todo los menos experimentados, tienden a ser excesivamente optimistas en sus estimaciones. Pero que muy optimistas. Y no lo son por naturaleza, ni lo son porque les han enseñado así en la facultad. Son optimistas, primero de todo porque están comprometidos con su trabajo, porque tienen ganas de agradar y de sorprender, a veces de hacer épica y realizar una tarea en tiempo récord para demostrar que valen. Estamos hablando de gente que muchas veces invierte su tiempo libre en leer artículos o libros, asistir a eventos relacionados con su trabajo o directamente a trabajar, ya sea en esas tareas épicas a las que se han comprometido o en proyectos personales. Me cuesta creer que alguien que está pensando en perder el tiempo haga todo esto, la verdad. Si no estás de acuerdo con esto probablemente no confíes en tu propio equipo, y ese tema es más complicado de resolver.

En definitiva, si quieres que una tarea se haga correctamente, con la calidad y en el tiempo adecuado prueba a hacer lo siguiente:

  • Identifica claramente en qué consiste la tarea y elimina todo aquello que no aporte valor de la tarea, es decir simplifícala al máximo.
  • Asegúrate de comunicarla efectivamente a la persona que la tiene que hacer, asegúrate que ha entendido en qué consiste y su finalidad.
  • Procura no decirle lo que tiene que hacer, y mucho menos cuando el que lo va a hacer tiene mucha más idea que tú.
    Establece una estimación de tiempo aproximado pactando con esta persona. Busca el compromiso, no la imposición.

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 This is Lean Te traigo el resumen This is Lean de Niklas Modig. Este libro es un imprescindible manual de qué es realmente lean explicado en un lenguaje claro y di...
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. ...

Dejar un comentario

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

Una idea sobre “Vicios peligrosos en la gestión de proyectos