Peopleware

Hoy me gustaría escribir mis impresiones sobre un libro que he tenido la oportunidad de leer estos días y que me ha causado una gran impresión. Se trata de la tercera edición de Peopleware de Tom DeMarco y Timothy Lister (que comparte apellido con el mítico dirigente del Quinto Regimiento, pero no tiene nada que ver con él). Esta obra, habla sobre lo que rodea al software sin incluir una sola línea de código. Tiene como tesis principal una interesante idea: los mayores problemas del software no son técnicos, son problemas relacionados con el trato, la gestión, la interacción, los entornos de trabajo en los que participamos las personas, o dicho de otro modo, lo mayores problemas del desarrollo del software son de naturaleza humana más que técnicos. Esta idea es desarrollada a lo largo de 39 capítulos. El libro describe un fenómeno por el cual la mayoría de los desarrolladores vivimos una ilusión por la que creemos que estamos en la brecha de creación de nueva tecnología, mientras en realidad, muy poca gente trabaja creando tecnología puntera y el 99% de la gente que escribimos software utilizamos tecnología hecha por terceros (librerías, frameworks, lenguajes, hardware, paradigmas, patrones de diseño, etc) para hacer aplicaciones de uso diario de todo tipo. A esto le que llaman en inglés High-Tech Illusion.

Si eres un desarrollador con unos cuantos años de experiencia, que has tenido la oportunidad de trabajar en varias en empresas, la lectura del libro te generará un sin fin de sensaciones de haber vivido las situaciones que se describen y de haber pensado anteriormente muchas de las conclusiones a las que se llegan.

Uno de los aspectos que se critica en el libro es la manera en la que se organizan las oficinas de un tiempo a esta parte. Buscando un aire de modernidad se han eliminado los despachos y las puertas, y todos convivimos en oficinas diáfanas donde generalmente hay más ruido de lo que sería conveniente para poder concentrarse y donde es difícil encontrar un espacio para tener una reunión. El libro pone un ejemplo de algo que yo he visto en muchas ocasiones: personas trabajando en la cocina de la empresa para tener algo de tranquilidad. Los autores del libro llevan décadas realizando ejercicios en empresas para medir la productividad donde han encontrado evidencias de una menor productividad si el espacio de trabajo poco adecuado para la concentración.

El liderazgo dentro de los equipos es otro elemento al que los autores prestan atención en el libro. Se realiza una crítica a super liderazgos donde el jefe de equipo quiere tomar cada decisión y no deja que ningún detalle no pase por el mismo, o liderazgos basados en hacer que los elementos del equipo o equipos de la misma empresa luchen entre ellos. Otro tipo de liderazgo descrito como nocivo es aquel que se basa en cargar de trabajo de manera extrema a los miembros del equipo, consiguiendo que solo estén contentos los «workaholics», hasta el día que se hartan y se marchan de la empresa también. Eso me hace recordar un jefe que yo tuve cuando trabajaba en la industria de los aviones hace unos años, que nos mentía sobre las fechas de entrega de la siguiente versión, diciéndonos que la fecha era unos días antes de lo que realmente era y forzandonos a echar muchas horas para llegar a esa fecha ficticia. Recomiendan más un líder cuya función principal es facilitar que el equipo que pueda trabajar tranquilo, eliminando las trabas que vayan surgiendo, y confiando en lo que puedan hacer aunque eso conlleve que comentan errores. También hablan de la importancia del capital humano y del tremendo coste que tiene perder a un trabajador frente al coste que podría tener mantenerlo, coste que a menudo es despreciado por las empresas.

Con respecto a los equipos, lanzan la idea de que un equipo bien engrasado que se conoce mucho y tiene buena sintonía, puede alcanzar cotas de productividad altísimas. Conseguir esto es muy complicado pero muchas veces se consigue involucrando a los elementos del equipo para conseguir una alta calidad en el software que producen. Esto entra en conflicto con los objetivos de las empresas que a veces les basta con un nivel de calidad bajo (ya que el mercado esta acostumbrado a que el software tenga muchos fallos) pero necesitan una velocidad alta para llegar al mercado rápido. De llegar una armonía entre ambos aspectos puede depender el éxito de un equipo. También se apunta que un exceso de burocracia en una empresa puede matar a un equipo. Y  la separación física de un equipo de manera generalizada también. Quien haya trabajado en remoto empatizará con esto último…

El libro está plagado de muchas más ideas y ejemplos concretos. Lo que he citado son algunos de los que han quedado marcados en mi cabeza, supongo que influenciado por mis propias experiencias personales. Es un libro altamente recomendable, que aconsejo a cualquiera que se dedique a hacer software. Viene a reforzar una idea que me viene rondando últimamente y que seguramente es una obviedad: la gestión de todo lo que rodea a hacer software (algo grande que se venda y lo use gente, no una POC) es tremendamente difícil.