"(Del ingl. behaviorism) Estudio de la conducta en términos de estímulos y respuestas."

Sabéis que me gusta comentar libros: en esto soy bastante clásico. Aún no sé si acabaré pasándome al ebook pero, mientras tanto, mi retina está habituada a leer en papel.

Otra cuestión es cómo elijo mis lecturas. En el caso del libro que os comento en este artículo, la elección estuvo basada en que está co-escrito por los autores de Peopleware.

En el mismo, a lo largo de sus 238 páginas describen 86 patrones de comportamiento en proyectos de desarrollo de software. Indican cuáles son sus características y cuáles pueden sus consecuencias, positivas o negativas.Aunque los autores, y la editorial, están especializados en temas TIC, es un libro que puede ser leído por aquéllos a los que le interese conocer cómo nos comportamos a la hora de participar en un proyecto.

El título del libro hace referencia a los nombres del primer y último patrón analizados, cuya lista completa podéis leer aquí. El nombre en sí mismo no dice gran cosa y muchas veces cobra sentido una vez leído su contenido.

A continuación paso a describir algunos de los patrones que más me han llamado la atención. Queda a vuestro criterio si corresponde o no con vuestra experiencia.

• Adrenaline Junkies: las organizaciones adictas a la adrenalina o los proyectos que sufren esta adicción se caracterizan por confundir la agitación con la productividad. Viven en un continuo estado de "suspensión" con la esperanza de que esta hiperactividad conlleve, per se, que los objetivos se alcancen.
• Dead Fish: desde el primer día el proyecto no tiene ninguna oportunidad de conseguir los objetivos propuestos; la mayoría de la gente que participa en el mismo lo sabe y no dice nada.
• Happy Clappy Meetings: este patrón se detecta en las siguientes situaciones. Está claro que una moral elevada indica que la organización goza de buena salud. Si la moral es baja es que algo va mal. En ese momento alguien tiene la feliz idea de hacer/promover/forzar que la moral suba y entonces todo estará arreglado. Esto se suele materializar en reuniones en las que cualquier comentario crítico es visto como un intento de sabotaje para conseguir el fin descrito. En dichas reuniones hay que aplaudir felizmente.
• Eye Contact: las organizaciones deberían saber lo importante que es que los miembros de un mismo equipo estén situados en espacios cercanos cuando acometen tareas complejas.
• Lease Your soul: la tecnología no merece que vendamos nuestra alma por ella, sólo alquilarla. Creemos en una tecnología mientras nos sea útil: en el momento en que encontremos otra que sirva mejor a nuestro propósito, convirtámonos a ella sin prejuicios.
• System Development Lemming Cycle: de la misma forma que, a veces, no se sigue una receta de cocina al pie de la letra sino que se toman las indicaciones generales para conseguir el plato deseado, es posible que nos tengamos que desviar del procedimiento descrito en aras del objetivo perseguido.
• I Gave You a Chisel. Why aren't You Michelangelo?: por increíble que parezca hay organizaciones en las que existe la creencia que la inversión en las mejores herramientas hará que un equipo sea bueno utilizándolas.
• Dashboards: una pizarra en la que aparezca el estatus del proyecto no mejora el liderazgo del mismo: lo revela. Los malos equipos se resisten a que en las mismas aparezcan los aspectos negativos.
• Endless Huddle: el recurso más precioso de un proyecto es el tiempo. El líder debe explicar que una cosa en acatar las decisiones y otra aceptarlas.
• Film Critics: existe una tipología de personas que pueden aparecer en los proyectos. Actúan como críticos de cine: si bien pertenecen al equipo, no se involucran, a última hora resaltan los aspectos que fallan y llegan a creer que, aunque el proyecto fracase, ellos pueden tener éxito. Este tipo de comportamientos surgen porque los fomenta la organización. Su actitud hace que se desvíe el objetivo del proyecto, evitando errores en lugar de ir hacia el fin propuesto.
• One Troat to Choke: si hemos visto imágenes de cómo funciona la cocina de un restaurante, comprobamos que todo se realiza con eficiencia y regularidad, que todos saben lo que tienen que hacer y los demás saben a qué se dedica uno. ¿Podríamos decir lo mismo del equipo en el que estamos?
• Soviet Style: el producto que estamos desarrollando no sólo debe cumplir los requerimientos funcionales que se le solicitan sino hacerlo atractivo. No por casualidad ha triunfado el iPod: es un reproductor MP3, de los que existen cientos en el mercado, pero todo el mundo lo ve como diferente.
• Natural Authority: las decisiones las debería tomar alguien que tenga autoridad sobre el tema en cuestión, independientemente de la posición jerárquica que ocupe.
• Silent Gives Concent: es una mala política utilizar la de "el que calla otorga" para llegar a acuerdos/compromisos. Los puntos que se alcancen con la misma deberían ser aclarados.
• Straw Man: los mejores analistas evitan realizar a sus clientes preguntas como "¿Qué es lo que quieres?". En su lugar lo van guiando, no lo colocan ante un papel en blanco.
• Counterfeit Urgency: una táctica utilizada a veces cuando el presupuesto se reduce es la de crear una falsa situación de urgencia, que hace aumentar la presión y reducir los plazos. Y a menos tiempo, menos dinero gastado.
• Short Pencil: una drástica reducción de costes, que puede implicar una reducción de personal, puede conllevar una caída en la eficiencia y, paradójicamente, un aumento final de dichos costes. "We need to distinguish between cost reduction and organizational bulimia." (Ken Orr).
• Poker Night: unos de los indicadores de la buena salud de un equipo puede ser el que realizan juntos actividades fuera del trabajo.
• False Quality Gates: la sintaxis (procedimientos) no es relevante si la semántica (el producto a desarrollar) no es correcta. A menudo el personal dedicado a Calidad no entiende el producto/problema a fabricar/resolver.
• Cider House Rules: si las normas que rigen el comportamiento a seguir por los miembros de un proyecto están escritas por personas que desconocen ese trabajo, puede que no se cumplan.
• Atlas: no se puede gestionar de la misma forma a un equipo de cinco personas que a uno de quince. Un líder debe hacer crecer el potencial de liderazgo de su equipo.
• Everyone Wears Clothes for a Reason: cuando el ratio de información a la que hay que atender crece de manera exagerada, estamos sobrecargados. "An abundance of information creates a paucity of attention." (Herb Simon). Quizás internet ha contribuido a agudizar este comportamiento.
• Peer Preview: sería interesante que en el proceso de selección de un nuevo miembro de un equipo, el resto de componentes del mismo participasen en una entrevista con él para, después, dar su opinión. Esto no sustituiría ningún otro paso del proceso de selección ni delegaría la decisión final de quién resulta elegido.
• The Blue Zone: "The correct amount of anarchy on a project is not zero." (Mike Mushet).
• News Improvement: puede ocurrir que la realidad de un proyecto se perciba mejor en los niveles bajos de una jerarquía que en los altos, debido a la tendencia a edulcorarla conforme las noticias ascienden en la misma. Eliminar las malas noticias puede hacer que un proyecto alcanzable se torne en irresoluble.
• Journalists: algunos jefes de proyecto comentan lo que sucede en el mismo, incluso las malas noticias, con tal imparcialidad que pierden la noción de que su rol es, precisamente, que el proyecto llegue a buen término.
• The Empty Chair: es útil/necesario tener una persona dentro del equipo que vele por la visión del cliente a lo largo del proyecto.
• Ben: si tienes un buen trabajador (hace su labor, ayuda a sus compañeros, crea buen ambiente…), no lo rompas sobrecargándolo de tareas: no mates a la gallina de los huevos de oro.
• Undivided Attention: dedicar una persona a múltiples proyectos simultáneamente, hace que su productividad descienda drásticamente. Gerald Weimberg estima que el coste del cambio de contexto de una persona asignada a tres proyectos es del 40% de su tiempo.
• Food++: comer juntos o, mejor aún, elaborar una comida y luego comerla juntos hace que un equipo se siente unido.
• Orphaned Deliverables: nadie discute que el principal entregable es el producto final. Pero ¿qué hacemos con el resto de entregables? ¿Realmente son necesarios? Una regla de oro para saberlo es la siguiente: "Si hay un espónsor que patrocina un entregable, éste se realiza. Si no, no." Corolario: "Si crees que hay un entregable que es interesante confeccionar pero nadie lo financia, busca un espónsor para el mismo."
• Hidden Beauty: "La perfección se alcanza no cuando no hay nada más que añadir sino cuando no hay nada que quitar." (Antoine de Saint-Exupery).
• I Don't Know: en lugar de ver la frase "No lo sé" como un signo de debilidad, debe tomarse como una invitación a encontrar la solución.
• Children if Lake Wobegon: el mánager de un equipo tiene dos roles: el de entrenador y el de juez.
• Co-Education: los desarrolladores esperan que los clientes expresen los requerimientos del producto a desarrollar, y éstos aprenden a esperar que los desarrolladores entiendan lo que hay que hacer.
• Brownie in Motion: el orden correcto en el comienzo de un proyecto es: 1º Tener claro qué es lo que hay que hacer. 2º Incorporar las personas al proyecto. No al revés.
• The Sun'll Come Out Tomorrow: si en fases/iteraciones anteriores de un proyecto han surgido imprevistos: ¿por qué no reflejar en la planificación del resto del proyecto que puede volver a haberlas?
• Paper Mill: si nadie sabe por qué se crea un documento, algo falla. Los documentos crean ansiedad y preguntas del tipo: "¿puedo tener una copia de eso?"
• Offshore Follies: el outsourcing conlleva aspectos que no hay que obviar: diferentes localizaciones, diferentes zonas horarias…
• Lessons Unlearned: las organizaciones son reacias a dedicar tiempo a la fase de "Lecciones aprendidas" pues ¡el proyecto ya ha terminado! y hay que ir a por otro. A veces se realizan estas sesiones como un mero trámite.
• Sanctity of the Half-Baked Idea: en los buenos equipos no hay temor por parte de sus miembros a exponer ideas incompletas ni a que se debatan.
• Template Zombies: si estás más preocupado en tener plantillas de modelos de documentos que en su contenido, se acaba creyendo que rellenando los mismos se soluciona el problema.

Éste quizás no sea un libro tan troncal como Peopleware pero es más cercano a la realidad y más fácil de leer.

Referencia:
"Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior"
Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson, and Suzanne Robertson
Dorset House

Carlos Urtasun - CEIN - curtasun[arroba]cein.es