“He contratado a un equipo de payasos y…”, “Pero… ¿qué estás haciendo, so payaso?”, y “¿Qué pintan aquí estos payasos?” son frases corrientes… ¡en cualquier proyecto software! De hecho esta correspondencia (informáticos = payasos) está tan asumida y extendida (“¡Ay, es que son tantos…!”) que sorprende que no exista un cuerpo doctrinal sobre el que basar estrategias, tácticas y números circenses de mayor calado. Pero vayamos primero a los antecedentes.
El problema básico de los informáticos (al menos en su devenir profesional) siempre ha sido su carencia de identidad, en cualquiera de sus roles adoptados: “programador” se ha asimilado a “persona sin vida social” (y, por tanto, con limitadas capacidades de comunicación); “analista” a “consultor”; “consultor” a “vendedor”; “analista-programador” a “vendedor sin vida social”; “diseñador” a “mitad vendedor, mitad programador”; y, en fin, “ingeniero-analista-programador” se ha asociado, típicamente, a “semoviente con ciertas capacidades táctiles”. Esta confusión ha complicado enormemente la gestión interna de los equipos informáticos, y su presentación externa (“¡Hola, soy Isabel Morcillo, analista-ingeniera de diseño de programación. Y me odio por esto!”).
Por otro lado, en la ingeniería del software se están aplicando desde hace años exitosos esquemas de estudio del comportamiento de los usuarios basados en técnicas de Diseño de Interacción y de la segmentación de tales usuarios en “personas” (es decir, personajes prototípicos del análisis), lo que facilita su trato, comprensión y posible maltrato posterior una vez armados con el software. Así que… ¿por qué no aprovechar las técnicas del Diseño de Interacción para tratar con los integrantes de un equipo de desarrollo software? Como sostenía Recesvinto Pérez… “si los payasos pueden saludarse en un congreso e identificarse rápidamente (“Hola, yo soy un augusto”, “¿Qué tal? Yo ejerzo de payaso blanco, pero estoy pensando en pasarme a trombo, porque cargo con demasiada presión”)… ¿por qué no habrían de hacer lo mismo los informáticos en el ámbito reducido de un proyecto?”.
Así que vayamos a la correspondencia: en cada equipo software habrá que asignar los siguientes roles, lo que se podrá conseguir muy rápidamente, pues los comportamientos están bien asentados:
- Jefe de Pista: es el que hacer desfilar a los demás y los presenta, saluda al público, emite sonidos guturales y muchas veces uno piensa que en realidad es un impostor. En nuestro caso suele ser un socio de consultoría.
- Payaso Blanco: es el payaso elegante, hierático y de comicidad pasiva (le ocurren cosas, pero no hace casi nada). Se equipara con el Jefe del Proyecto.
- Augusto: es el payaso tosco y burlón, le gusta la anarquía y le ocasiona muchos quebraderos de cabeza al payaso blanco; además hace reír mucho al público con sus ocurrencias ridículas. Su figura se asocia, inequívocamente, a la de “programador listo”.
- Trombo (o segundo Augusto): se trata de un payaso risible, pero sin los méritos del augusto para provocar situaciones ridículas de valía, así que es un apoyo del primer augusto para procurar quebraderos de cabeza al payaso blanco. En la práctica es un programador del montón.
- Excéntrico: es un augusto listo, de la misma catadura que un pueblerino sabio, como Josep Pla; así que sabe que hace reír al público, pero mantiene más dignidad que el augusto clásico en su pose y en su tozudez. Se asimila a un diseñador Web.
- Vagabundo: es un augusto solitario, sin relaciones sociales y que suele dar risa porque da pena. Esta figura se suele asociar a un analista software.
- Mimo: no habla, pero parece dotado de buenas cualidades físicas y de movimiento. Suele encargarse de la intendencia (instalación de software, redes, café, etc.) en los proyectos.
Bien: con esto ya estamos preparados para comunicarnos mejor entre proyectos. Así, si un colega me cuenta… “tengo un payaso casi-blanco, 2 augustos en liza, un excéntrico a ratos, dos vagabundos peleones, diez trombos[-ados] y ningún mimo”… inmediatamente uno se hace a la idea de cómo será el proyecto. Pero, claro, esto no dice nada del resultado, porque el resultado de los proyectos siempre es… ¡algo! Y es que… ¡Ay! Lo malo de la informática es que el software, al final, siempre funciona 
.
P.S.: Tengo que agradecer la inspiración de este artículo, por orden, a Recesvinto Pérez, a ClownPlanet y a Michel Tournier.
