Review de Peopleware

A principio de año, releí Peopleware y descubrí que sigue sorprendiéndome. A lo largo de esta entrada voy a intentar mencionar los puntos más destacables del libro, la mayoría ya comentados por @jacegu o @juanignaciosl. Principalmente lo hago como ejercicio mental de asimilación (más un ejercicio de autocrítica), así que esperad muchos más análisis de libros.

Peopleware me parece un libro muy bueno, la mayor parte de los temas que trata están en absoluta vigencia a día de hoy pese a que fue escrito en 1987 por Tom DeMarco y Timothy R. Lister. He leído la segunda edición, que data de 1999 e incluye 8 capítulos adicionales. La estructura del libro la podéis ver en los posts de los excelentes blogs que he mencionado antes. Cómo me queda poco espacio no tratado, menciono los puntos (que desde mi experiencia laboral) me parecen más olvidados (o que hay que mencionar más).

• Desmonta la creencia de que “Management is kicking ass”. Peopleware destruye el mito de que las personas sólo trabajan si tienen una fecha límite cercana o alguien dándoles golpes continuamente. Introduce la idea de que el mejor manager es aquel que hace tres cosas:

  1. Consigue a la gente adecuada.
  2. La hace feliz.
  3. La deja tranquila/en paz.

• El mejor manager es aquel que no se entromete, se dedica a quitar obstáculos del camino del equipo. Por supuesto todo esto os sonará bastante, pero hace 23 años eran conceptos nuevos (cómo decía @jacegu, un visionario). Si hay personas que de verdad no hacen nada (comenta que hay personas que su aportación al equipo pasa desapercibida, pero que aconsejan o aportan al éxito común) no debe ser el manager el que de con la vara si no el propio equipo.¡

• Las personas no son reemplazables, no es lo mismo un Mario que una Luisa, no son intercambiables. Cada persona tiene sus puntos fuertes y sus debilidades, la marcha de una persona es un duro golpe al bienestar y el desarrollo de un proyecto. Que la gente sea feliz y esté a gusto en su trabajo es muy muy importante.

• En las empresas se ha instaurado el aumento de la productividad a base de más horas de trabajo no remuneradas. Todo este tipo de gestión sólo conlleva a burnout y turnover (gente quemada y abandonos). La empresa nunca se queja porque la gente haga más horas de trabajo siendo muy peligroso para el trabajador y el producto. Es común la presión continua basada en phony deadlines (hitos que no se pueden fallar pero que son falsos). Los autores analizan un estudio que concluye que los proyectos que no tenían estimaciones se desarrollaron más rápido que aquellos estimados por el manager o el propio equipo.

En mi experiencia laboral pecamos de las dos cosas, no hay control de las horas de más (pero si al revés) y demasiados hitos falsos.

• Los autores concluyen que lo más importante son las PERSONAS (el típico ratio de un buen programador frente a uno malo). No hay pociones mágicas ni herramientas maravillosas, ya lo comentaba Fred Brooks: No silver bullet.

• Pese a que los managers y el mercado afirman primar la calidad, no es así. El nivel de calidad que le gustaría alcanzar a un desarrollador está más allá del que la mayor parte de clientes está dispuesto a pagar (ante un producto en una determinada fecha con errores z y uno pagando un extra por menos errores, suelen preferir el producto con menos calidad). El mercado se ha acostumbrado a productos de baja calidad, software defectuoso. La calidad siempre sale perdiendo. De forma irónica porque:

“Quality, far beyond that required by the end user, is a means to higher productivity”

• La calidad es “gratis” si estás dispuesto a pagar bastante por ella (tienes que invertir tiempo y dinero pero obtienes mayores beneficios que el coste en forma de mayor productividad). El desarrollador siente el código como suyo y cualquier chapuza es una mancha para sí mismo, algo de lo que no está orgulloso (pride in code).

En mi experiencia personal, la calidad siempre sale perdiendo. Todos lamentamos  o intentamos desvincularnos del mal código que hemos escrito. Es nuestro y está ahí, las excusas de tiempo no valen (mejorar, mejorar, mejorar). Sobre el tema, just say “NO” o We´ll try.

• Dedican varios capítulos a la distribución de la oficina, pero lo que me parece más importante es los puntos dedicados al ruido. Las típicas frases de no hacemos nada de 9 a 5, indican que el espacio de trabajo está lejos de ser óptimo. Una buena oficina necesita conjugar tranquilidad con espacio y sitios para reunirse en equipo o en parejas sin molestar al resto. El tiempo más importante es el tiempo de flujo (FLOW), cuando estás concentrado en la tarea entre manos y el tiempo pasa volando. Sugiere medir y primar ese tiempo para evaluar si un ambiente es beneficioso en vez del tiempo de cuerpo presente que consideran inútil.

Este aspecto me afecta mucho en mi día a día y sólo he sido más consciente de él gracias a Peopleware. Al final en la oficina (con espacio diáfano) todos tendemos a utilizar cascos (con las desventajas que causan) para aislarnos del numeroso ruido que nos rodea. En este sentido tengo que hacer auto crítica, ya que soy un gran generador de ruido. El teléfono o una puerta común nos crean distracciones continuas, es muy difícil concentrarse por la mañana (y más teniendo en cuenta que suelo contestar muchas dudas asíncronas a lo largo de la mañana). Las conversaciones que se puedan trasladar, deben de realizarse fuera de la sala común.

• Los autores dedican bastantes capítulos a los equipos compenetrados, los _jelled teams_que llaman. Son grupos de personas que trabajan muy bien juntos y se complementan, trabajan como una sola persona. Comenta varios puntos que dificultan su creación:
  • La gestión defensiva (managers que ven al equipo como una amenaza a su autoridad).
  • Burocracia.
  • Participar en múltiples proyectos, estar continuamente cambiando de contexto.
  • Separación física entre los miembros de grupo.
  • Reducción de calidad (orgullo inexistente/desprecio del código propio).
  • Límites de tiempo absurdos.

• Comentan las ventajas de probar proyectos nuevos, con nuevas tecnologías que incentiven el deseo de aprender de los programadores, realizar juegos de programación…

• Y por último concluye atacando a las grandes Metodologías (con M mayúscula).  Sobre todo ataca a CMM (uno de los antecesores de CMMI) por desincentivar la innovación. Una empresa con un alto grado de madurez (CMM/CMMI) tiende a aceptar proyectos dónde pueda aplicar su proceso repetible y gestionado y no innovar con proyectos con riesgo y nuevas tecnologías (los más divertidos) por miedo a perder su preciado nivel o no obtener los resultados habituales. También comentan:

Worse, Methodologies encourage people to build documents rather than do work.

Resumiendo un libro muy, muy recomendable para todos (técnicos/gestores). A mi me ha servido para recordar un par de puntos en los que en mi empresa flojeamos y poder dar con la vara a quién sea necesario (o con el libro). Es un libro breve, muy asequible, una lectura imprescindible.