Los Osos de la Mala Suerte. The Ramones. Rocky Balboa. Los Doce del Patíbulo. Los héroes de verdad son feos.

Son inadaptados. Su atuendo es inapropiado, no tienen estilo y ni siquiera conocen todas las reglas […] A pesar de sus deficiencias, encuentran maneras de alcanzar el éxito, apostando a todo con pasión, persistencia e imaginación. Por estas razones, cuando las cosas se ponen difíciles, son los equipos feos los que ganan.

El único uso de la belleza aplicada a los equipos, que tenga sentido, es el concepto japonés de wabi-sabi. A grandes rasgos, wabi-sabi significa una belleza especial encontrada en los objetos o ambientes de simpleza rústica.

Así entonces, los equipos feos que he descrito al principio de este capítulo como el perdedor, el inadaptado, representan los equipos wabi-sabi. Estos son grupos que comparten cicatrices, han fallado juntos y se han recuperado juntos, y que todavía luchan como un equipo. Y es solamente a través de este tipo de experiencias que un equipo puede desarrollar un carácter que posee cualquier aproximación con la belleza.

— Andrew Stellman, Jennifer Greene. Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders, (O’Reilly Media, 2009).

En 1987 el libro Peopleware: Productive Projects and Teams definió la dinámica necesaria para lograr equipos de trabajo que mejoren las probabilidades de éxito en nuestros proyectos o cómo generar equipos mediocres que obtengan los «resultados de siempre». En dicha publicación se manejan temas como por qué es necesario eliminar la cubiculomanía en nuestras oficinas o cuáles son las ventajas de que el grupo completo trabaje en una sala de juntas.

En Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders (Equipos Hermosos: Historias Inspiradoras e Ilustrativas por Líderes de Equipo Veteranos) de Andrew Stellman y Jennifer Greene, nos muestran la práctica – o falta de ésta – sobre la teoría presentada en Peopleware. El formato del libro es simple: por un lado se tienen entrevistas a líderes de la industria de software como Steve McConnell o Tim O’Reilly, donde responden a preguntas concretas relacionadas con equipos de trabajo, metodologías o manejo de conflictos; por otro lado, los demás colaboradores nos cuentan sus «historias desde la trinchera» donde las anécdotas que describen y los antecedentes que las preceden son extraordinariamente diversas: desde el desarrollo del Internet Explorer 4, el software embebido del Boeing 777 o la dinámica del equipo que creó al Subversion. También nos narran historias relacionadas a temas de metodología de desarrollo, como un piloto de Extreme Programming o cómo levantar requerimientos de manera ágil para un cliente fastidiado.

Un par de recomendaciones

Las historias que se comieron tardes completas de mi tiempo fueron aquéllas contenidas en la sección «Obstáculos». Éstas son verdaderos cuentos de horror donde los protagonistas nos platican cómo sobrevivieron a penurias, trampas y malos colaboradores: desde jefes que no entienden la utilidad de una revisión por pares, ejecutivos que discriminan a sus empleadas sólo por ser mujeres, hasta gerentes a los que les importa un pepino la salud de sus desarrolladores. El relato que me pareció más conmovedor es el de un sobreviviente del 9/11: cómo su empresa desapareció literalmente aquél día – ésta se encontraba en el piso 78 de la Torre 2 del World Trade Center – y cómo tuvieron que implementar un DRP para darle continuidad al negocio.

En cuanto a entrevistas, las dos que me parecen más memorables son las de Peter Glük, ingeniero de software senior en la NASA, y Neil Siegel, vicepresidente e ingeniero en jefe de Northrop Grumman Information Systems. Ambos nos cuentan cómo funcionan los equipos de desarrollo – que en algunos casos pueden ser muy extensos – en sus respectivas organizaciones. Esto es especialmente importante si consideramos que la NASA y Northrop Grumman proveen algunos de los sistemas más complejos construidos por el hombre y de cuyo funcionamiento dependen vidas humanas y millones de dólares en equipo:

[Comparando una aplicación empresarial común contra un proyecto para la NASA]

(Peter Glük): Si una aplicación empresarial no funciona bien, el costo de una falla son unos cuantos clientes encolerizados. […] Si nosotros tenemos una falla en un caso atípico, puede que no tengamos una segunda oportunidad.

Andrew Stellman, Jennifer Greene. Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders, (O’Reilly Media, 2009).

Y algunos tips y trucos de desarrollo de sistemas

Aunque la mayoría de las anécdotas y entrevistas presentadas son más para cultura general y entretenimiento personal, leyendo entre los diferentes capítulos encontramos algunos tips muy buenos para manejar equipos de trabajo y terminar bien nuestros proyectos de software. Por ejemplo, de nueva cuenta, Peter Glük de la NASA nos da una idea de cómo ser exhaustivos con la calidad de nuestros desarrollos:

[Describiendo cómo se realizan los sets de pruebas]

(Peter Glük): Tienes un simulador de software que puede ejecutarse en una estación de trabajo y que básicamente, modela el entorno en el que el software de la nave espacial opera. Tienes modelos de la aviónica. Tienes modelos de la dinámica del vehículo; es decir, los movimientos rotacionales y traslacionales del mismo. Tienes modelos de los planetas y cualquier factor externo de importancia para tu sistema.

A continuación, el software puede funcionar en un ambiente que simula lo que se va a esperar durante su operación. Puedes correr pruebas de tal manera que confirmen que el comportamiento es como lo esperas, tanto para casos nominales como casos atípicos, de modo que puedas identificar los lugares donde la protección a fallos está funcionando correctamente y lugares donde es necesario corregirla de alguna manera.

También se aprovechan los sets de pruebas en hardware. Esa es tu prueba de mayor fidelidad. Duplicas la electrónica [del vehículo] y cargas tu set de pruebas, probando el software como si estuviera en un vuelo real. Observas cómo se comporta, y esperas que se maneje en la forma esperada.

Andrew Stellman, Jennifer Greene. Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders, (O’Reilly Media, 2009).

Es decir, en una organización como ésta el secreto es probar, probar, probar: primero en simuladores de software, luego con carga que simule el ambiente productivo y si es posible, probando en un ambiente análogo al de producción. Sin embargo, no nos vayamos con la finta, pues también ellos han metido las cuatro: por falta de pruebas de integración, en septiembre de 1999 el Mars Climate Observer, cuyo costo fue de US$ 327.6 millones, se perdió debido a que el equipo de control de Tierra usaba medidas inglesas para calcular los parámetros de aterrizaje, mientras que la nave operaba con el Sistema Métrico Decimal.

Conclusiones

En cuanto al libro, es una buena lectura que no sólo los sistemólogos pueden disfrutar; aunque algunas anécdotas y entrevistas parecen más de entretenimiento que de aprendizaje, en general son bastante amenas, mostrando algunos tips de desarrollo y administración de proyectos que significaron el éxito para los equipos de trabajo involucrados y que de acuerdo a la circunstancia, podemos recrear.