Título original: Peopleware y Equipos Ágiles

Autor: Javier Garzás

Editorial: 233gradosdeTI

Páginas: 200 (color)

Idioma: español

ISBN: 978-84-697-7450-2

Palabras clave: Proyectos, gestión equipos

Esta reseña nació cuando, hace unos meses, un grupo de compañeros de empresa asistimos a una keynote de Javier Garzás llamada  “Qué es la Agilidad y cómo te puede ayudar a no acabar en una empresa zombi“:  Keynote en la Universidad de Alicante.

La verdad es que nos pareció muy interesante, pues  ya seguíamos desde hace tiempo el blog de Javier.

Así que cuando saltó la noticia  de que Garzás había publicado un nuevo libro, varios fuimos los que nos apresuramos a adquirirlo.

Destacar que es todo un detalle que el autor te dedique el libro bajo petición. Adicionalmente, yo obtuve un dibujo de Darth Vader de bonus. ¡Mola!

Ya entrando en materia,  el objetivo del libro es profundizar en el cambio en la organización de las personas y en los equipos dedicados al software/hardware que se ha producido en las últimas décadas. Según la Wikipedia, Peopleware es “…cualquier cosa que tenga que ver con el papel de las personas en el desarrollo o uso de software y sistemas hardware, incluyendo cuestiones como productividad de los desarrolladores, trabajo en equipo, dinámicas de grupo, la psicología de la programación, gestión de proyectos, factores de organización, diseños de interfaces de usuario e interacción hombre-máquina.”

Originalmente, “Peopleware, Projects and Teams” es el título de un libro de los años 80 de los autores De Marco/ Lister, referido específicamente al desarrollo de software.

Javier desea remarcar la importancia de las personas en los proyectos/productos /equipos, pues en el fondo son la clave del éxito de cualquier proyecto.

El principal mensaje del autor, adquirido a través de una experiencia de haber trabajado en un montón de empresas remarcables, es que en el desarrollo de software se debe  dejar atrás el taylorismo y la industrialización. Pues se implantó esa visión también en los proyectos de desarrollo de software, un verdadero error, pues no es adecuado y ha generado muchos más problemas de los que ha solucionado. Desarrollar software no es lo mismo que construir un puente o levantar un edificio.

El nacimiento de la agilidad y del Manifiesto Ágil fue una reacción a lo poco apropiados que eran los métodos de trabajo tradicionales para gestionar el desarrollo de proyectos de software. Es más, cambiando la palabra “Software” por “soluciones” se puede aplicar el manifiesto ágil más allá del desarrollo de software.

La visión del Management ya no es gestionar a las personas como a máquinas y procesos (versión 1.0), sino orientada a personas y equipos en una estructura organizativa pensada para ello (versión 3.0).

Destaca que en las empresas existen “tribus” entendidas como la forma en la que trabajan, que hace que se entienda mejor el concepto de “Peopleware” y que van desde el tipo 1 (individualismo por la superviverncia)  hasta el tipo 5 (equipo ágil).

Se mencionan los equipos Good to Great, que cumplen con  siete pautas que distinguen  a las empresas punteras del sector, que pasaron de lo bueno a lo excelente.

Los equipos son complejos. Por eso, la adaptabilidad es adecuada para los sistemas complejos y para las incertidumbres.

Ante todo, en la gestión de equipos debería evitarse tratar de resolver problemas complejos con soluciones fáciles, que suelen acabar empeorando el problema que pretendían solucionar: es lo que se llama reduccionismo o “populismo tecnológico”  (véase el caso del efecto cobra). Pensad en ejemplos que se os ocurran (fomentar el presencialismo en la empresa en lugar de la productividad, montar sistemas para fichar todas las mañanas, exigir un montón de documentación, nombrar un comité para resolver un problema, etc…)

Los equipos de trabajo deberían de contar con las siguientes características:

• Estar motivados. El tema de las motivaciones y recompensas tiene mucha miga. El autor alerta de que las recompensas pueden hacer que las personas trabajen casi exclusivamente para obtenerlas.
• Ser Auto organizados, pero que un equipo sea dirigido y organizado por sus propios miembros no significa que non haya jefes o managers. lLa diferencia es que estos se reducen a lo necesario.
• Ser Mutifuncionales, todos deberían de poder hacer casi cualquier tarea dentro del equipo
• Por supuesto, ser Productivos. en este punto, ojo con medir el trabajo con sistemas que no favorecen la calidad, como el de contar las lineas de código/hora.

Y un equipo debería de estar orientado a la mejora continua, es preciso fomentar una cultura de la reflexión y de la mejora (a través de sesiones de Retrospectiva o de Lecciones Aprendidas).

Resumiendo, un gran libro que merece una lectura detenida, (yo ya lo he releído un par de veces), pues la gestión de los equipos y de las personas tiene actualmente más importancia que nunca si se desea obtener el éxito en  proyectos o iniciativas.