Gestión de proyectos Software (I)

Desde hace unos días estoy leyendo un libro interesantísimo sobre gestión de proyectos software. Lo conocí gracias al jefe de una empresa para la cual tuve una entrevista de trabajo, y la verdad es que ha sido todo un hallazgo. El libro en cuestión se titula Peopleware, Productive projects and teams y sus autores son Tom DeMarco y Timothy Lister, dos eminencias en la consultoría de gestión y equipos software. La editorial es Dorset House Publishing Co., y tan sólo tiene unas 260 páginas que se pasan volando gracias a sus amenos ejemplos y disertaciones que hacen de su lectura pasar un rato ameno en unos casos y divertido en otros.

Este libro, de cuya primera publicación han pasado unos veinte años, está en plena vigencia aún hoy en día, pues a pesar de tratarse de un libro relacionado con la Informática trata más bien el aspecto sociológico de las relaciones humanas en el entorno de trabajo y de la productividad laboral.

Tan interesante me ha parecido este libro, cuya lectura recomiendo a todo el mundo cuya profesión exija un desempeño en equipo considerable e importante (sea en el mundo de la informática o no), que voy a colocar algunos fragmentos de entre las muchas notas que he tomado durante su lectura, añadiendo otras aclaraciones de mi propia cosecha. Mi pretensión es despertar el interés de mis lectores y que, quizá, se acerquen a esta obra:

Factores de inhibición en el crecimiento de un equipo (‘teamicides’)

No existe una fórmula mágica que nos permita hacer que un grupo funcione, alcance un estado máximo de motivación hacia su trabajo, hasta el supremo estado en el cual los proyectos se convierten en retos personales. Lo único que se puede hacer es mantener una serie de comportamientos, por parte del Gestor del grupo, que favorezcan tales situaciones, pero el éxito no está asegurado al 100%. El libro compara esta situación a aquella en la cual queremos plantar un huerto: es importante utilizar las semillas adecuadas, abonar y regar; esto es indispensable para que las plantas crezcan, y sin embargo puede que otros factores impidan el germinamiento de las semillas y que posteriormente las plantas den su fruto.

Sin embargo, a pesar de que no podemos asegurar el cómo conseguir que un equipo alcance el supremo estado de cohesión, lo que sí existe es la solución al problema inverso: qué factores “marchitarán”, “pudrirán” y “secarán” el crecimiento del grupo. Éstas son las siguientes:

Gestión defensiva

Una vez elegido el equipo, debemos confiar en él. Si crees que alguien va a cometer un error, permíteselo para que aprenda, ya lo arreglará cuando caiga en la cuenta. De otro modo inhibirás su voluntad de decisión, no le dejarás experimentar ni aprender por sí mismo, y se sentirá frustrado.

Burocracia

Hay que documentar con sentido: lo necesario, pero no más, ni menos tampoco. De otro modo convertiremos la labor de documentación en un papeleo absurdo, aburrido y poco productivo, que además llevará mucho tiempo mantener.

Separación física

Facilita la interacción, la comunicación, el crecimiento como equipo; mantenlos juntos, en un mismo despacho a ser posible. Evitarás muchas llamadas telefónicas entre ellos, que tan molestas son y tanto interrumpen los momentos de máxima concentración (lo que los autores llaman flow, porque en este estado de máxima concentración el trabajador se vuelve increíblemente productivo y las horas pasan volando).

Fragmentación del tiempo

Rompe el crecimiento del grupo, al tener que intercambiar grupos. Interrumpe la motivación y el flow. El tiempo se fragmenta entre varios proyectos, y es difícil cambiar la mente entre uno y otro. Cada trabajador, en un sólo equipo, en un sólo proyecto.

Productos de baja calidad

Si las fechas de entrega no son realistas, el producto al final tendrá mala calidad (otro día hablaré de todo esto). A los desarrolladores les partirá el alma hacer las cosas por debajo de lo que sus habilidades les permite hacer, perderán la motivación, dejarán de creer en lo que hacen y se marcharán a otro lugar.

Estimaciones temporales imposibles

Como ya he dicho, ya hablaré largo y tendido de lo nefasto de esto. El equipo tirará la toalla o se agobiará ante tales estimaciones. Se verá obligado a realizar un montón de horas extras que no serán más productivas, y ya veremos por qué. Sabrán que esas estimaciones no son factibles y no se las creerán, tomando sus propias estimaciones, y al final sintiéndose engañados porque les han dado una fecha que no era la real.

Control del equipo

Deja al equipo relacionarse e interactuar a su aire, que crezcan juntos. El gestor debe intervenir lo menos posible, y en ningún caso romper el estado libre en el que trabajan. Cuando un equipo marcha bien, la mano del gestor es invisible, el equipo siente como si nadie les ordenara. Las cosas simplemente suceden. Sin embargo el gestor está ahí, todo está previsto, marcando pequeños hitos en los pequeños logros que se van logrando.


“Peopleware, Productive projects and teams”

Tom DeMarco y Timothy Lister

Dorset House Publishing Co.,

2 pensamientos en “Gestión de proyectos Software (I)

  1. Pingback: Gestión de proyectos Software (II) « Realizando la idealidad

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s