Cuando el Arte ataque

Por Martín Salías, @martinsalias

Etiquetas: diseño, feedback, evolución, arte

Little boxes on the hillside,

Little boxes made of ticky tacky,

Little boxes on the hillside,

Little boxes all the same.

There's a green one and a pink one

And a blue one and a yellow one,

And they're all made out of ticky tacky

And they all look just the same.

Little Boxes, Malvina Reynolds, 1962

Hoy en día estamos tratando de adaptar Scrum a proyectos de desarrollo de todo tipo. Pero su origen, antes de que Schwaber y Sutherland trajesen la idea al mundo del software, estuvo en varias compañías –sobre todo en Japón– tratando de reinventarse a sí mismas innovando con productos que no existían y que nadie podía "diseñar" desde cero.

El famoso artículo "The New New Product Development Game" , que tomaron de base los autores de Scrum, se refería básicamente a ese tipo de proyectos de alta complejidad y sin definiciones claras, a la búsqueda de ideas disruptivas que generaran un mercado nuevo, y en algunos casos, salvaran a la empresa de su extinción.

Quienes llevamos tiempo en la comunidad ágil ya sabemos que Scrum nos sirve como "las rueditas" de aprendizaje de la bicicleta, y muchos reconocemos que es solamente parte de un camino, y no un destino.

El problema, me parece, comienza cuando nos quedamos ahí, y Scrum (u otros frameworks similares) comienzan a hacernos daño, limitando a los equipos a un estilo de comunicación más folklórico que liberador, donde todo lo esperamos de ese proceso de feedback de los clientes o "del negocio". Se supone que mucho del ritmo y de los principios de Scrum nos deberían haber ayudado a mejorar esa conexión, pero ¿y ahora qué?

No sé lo que quiero, pero lo quiero "ya"

La premisa inicial de reunirnos con los clientes es muy buena si los clientes realmente comprenden (tal vez con nuestra ayuda) los desafíos o problemas que enfrentan.

Pero esto no siempre es así.

Y no estoy hablando de equipos con poco nivel de madurez que esperan que sus clientes les "pidan" lo que necesitan. Me refiero a equipos lo bastante maduros como para llevar la conversación a los motivos raíz y ofrecer soluciones, participando activamente en el diseño.

En entornos de emprendimiento y búsqueda de nuevos productos, es muy probable que necesitemos encontrar soluciones a problemas que no son tan claros ni para nuestro público objetivo. Incluso cuando tenemos una audiencia conocida y cercana, pensar con ellos cómo resolver su problemas, desarrollando la empatía, nos lleva, como vemos frecuentemente a productos idénticos unos a otros, como las "cajitas" en la canción del epígrafe, todas hechas iguales.

La magia ocurre por allá afuera

Lo que nos pasa muchas veces cuando encaramos proyectos en equipo es que a lo largo del tiempo caemos más y más en sesgos cognitivos como:

• Efecto de ambigüedad: cuando tendemos a descartar la exploración de ciertas alternativas porque nos parece que nos faltan datos

• Focalismo: mantener permanentemente un punto de vista inicial como referencia

• De Confirmación: cuando prestamos más atención a los datos o alternativas que confirman nuestros preconceptos

Y muchos otros. De esta manera nos colocamos "anteojeras" que nos mantienen enfocados en esa idea inicial, en ese problema y esa visión que probablemente establecimos en conjunto al comienzo de nuestro recorrido.

¡Qué bueno! El foco tiene muchos beneficios, sobre todo a la hora de avanzar una vez que decidimos lo que queremos.

Pero a veces nos aleja de la creatividad y nos lleva a construir "más de lo mismo". Cuando nos pasa en el arranque del diseño de producto, o por largos períodos de tiempo en los que no nos cuestionamos el objetivo final o el plan que trazamos, desperdiciamos la oportunidad que nos dimos con el paradigma ágil, y nos quedamos con el beneficio más obvio pero menos valioso: sólo minimizamos el desperdicio y tal vez avanzamos algo más rápido.

El enemigo del arte

Ese foco colaborativo y metódico, lleno de feedback y empirismo que nos trajo la agilidad puede ser también un problema a largo plazo, porque había una promesa más grande cuando hablábamos de abordar problemas complejos: la de destrabar un proceso creativo que nos llevara a soluciones nuevas, mejores en sí mismas y mejores por el disfrute y el aprendizaje.

El movimiento Software Craftsmanship recuperó ese sentido de artesanía en varios sentidos, sobre todo en la expresividad y en la revaloración de la relación de artesanos y aprendices. Pero personalmente siento que nos falta buscar en el Arte.

No pretendo que todo equipo se convierta en una comunidad artística. El Arte va más allá de la utilidad y busca sensaciones a través de un proceso estético per se, sin una meta explícita. Pero en toda creación hay algo de arte, una posibilidad de expresión que la mayoría de las veces desoímos, tal vez por temor. Porque no es lo que se espera.

Mi propuesta es apropiarnos de elementos y recursos del arte que a muchos les suenan ajenos al desarrollo de productos o servicios, pero que yo considero vitales para salir del ciclo del tedio y la anomia.

Primera palabra rara: Serendipia

El término "serendipity" es un invento del historiador del arte Horace Walpole en una carta de alrededor de 1750, en el que hacía referencia a la historia persa de “los tres príncipes de Serendip”, quienes iban descubriendo, por accidente o sagacidad, cosas que no buscaban.

Es como "encontrar la aguja en el pajar" sin buscarla, o como dice mi amigo Arvindra Sehmi, “buscar la aguja en el pajar, y en el proceso encontrarse a la hija del granjero”.

Si bien la idea de la serendipia es la de ese "accidente afortunado" como en el caso de la penicilina, o (el más famoso en el ambiente ágil) los post-its, la verdad es que no alcanza con “toparse” con un hecho inesperado. Tenemos que estar en la situación y la capacidad de aprovecharlo, en un estado mental que nos permita percibir esas oportunidades.

Por eso creo que algo que falta en muchos equipos es la introducción (balanceada) de una cierta cantidad de caos. A veces podemos lograrlo con enfoques lúdicos como "apagar la realidad" durante una sesión de diseño (una técnica común en los viejos días de Extreme Programming), dejando que por unos minutos todos busquen soluciones imposibles, sin limitaciones físicas, técnicas ni legales. Al terminar el tiempo vemos qué ideas locas aparecieron y pensamos qué podemos aprovechar en la realidad. Muchas veces aparecen soluciones novedosas pero totalmente posibles que no se nos habían cruzado por delante.

Como ésta, hay muchas técnicas para "salirse de la caja", pero lo más importante es tener la actitud y la intención de hacerlo frecuentemente. Si bien no podemos forzar la serendipia, podemos fomentar contextos inesperados, y sobre todo estar atentos a soluciones y perspectivas poco usuales.

Como siempre la clave es el balance. Pero definitivamente la innovación no se alienta recorriendo un camino pre-establecido.

Segunda palabra rara: Exaptación

La evolución tiene idas y vueltas imprevistas. Por eso nuestra especie siempre tuvo tendencia a buscar un diseñador detrás de las cosas. Pero más allá de disputas religiosas o espirituales, el proceso evolutivo descrito por Darwin todavía tienen mucho por aprovechar.

La exaptación es una característica que mezcla atributos emergentes con cambios de contextos aparentemente fortuitos. Es como la serendipia de la naturaleza misma.

El ejemplo clásico de exaptación es el de las plumas, que se originaron como un mecanismo de regulación de la temperatura pero más tarde demostraron ser eficaces controlando caídas, hasta convertirse en instrumental de vuelo. Las mismas plumas también se convirtieron por exaptación en mecanismos de seducción entre las aves, potenciando su variedad de colores.

¿Cómo aprovechar la exaptación en la creación de productos? Fundamentalmente, mirando a nuestro alrededor.

Ejemplos sintéticos de este proceso son los acelerómetros que hoy tenemos en todos nuestros teléfonos para detectar cuando ponemos la pantalla horizontal o vertical, y adaptar el contenido a partir de eso. La tecnología diminuta y de bajo costo que permitió que se popularizaran se desarrolló en su momento para prevenir daños en los discos rígidos de las computadoras portátiles. Como los cabezales lectores no deben tocar la superficie de los discos, estos sensores se minimizaron para que ante un movimiento repentino, éstos se retirasen, evitando el contacto en un impacto, similar a los air-bags de los automóviles.

Cuando el equipo de diseño de iPod/iPhone se dió cuenta que un dispositivo rectangular permitía diferentes modos de uso, mirar fuera de su espacio de problema le permitió exaptar aquellos sensores, lo que no sólo resolvió esa característica, sino que también abrió el camino de aprovechar otros sensores como termómetros, brújulas, fotodetectores y otros por venir.

Si esos equipos se hubiesen quedado con el feedback del usuario, todavía tendríamos un botón para rotar la pantalla, y tal vez otros sensores no hubiesen llegado aún. Otro riesgo del foco excesivo.

Tercera y última palabra rara: Oulipo

Para ser consistente, voy a hacer trampa. Me voy de los conceptos y salto directamente a otro movimiento, a primera vista muy diferente de la agilidad, pero que yo siempre sentí relacionados.

Oulipo es un nombre inventado para un grupo de escritores. Una especie de sigla engañosa de "Ouvroir de littérature potentielle" (algo así como Taller **de Literatura Potencial). Varios de estos escritores eran también matemáticos, y por estas cosas interesantes que surgen al reunir gente rara (como Raymond Queneau, François Le Lionnais, Italo Calvino ó Georges Perec), se dedicaron entre ellos a realizar ejercicios literarios con restricciones duras.

Lo que el grupo reconoció es la utilidad de las estructuras para liberar la creatividad. Algo que suele sonar poco intuitivo es fácil de apreciar en la insistencia de Shakespeare en el uso de los pentámetros yámbicos, o los tercetos endecasílabos de Dante en la Divina Comedia (una obra de estructura matemática cercana a la relojería).

Para elevar el desafío, en Oulipo inventaban todo el tiempo restricciones más y más complejas, las que a veces quedaban en juegos exploratorios, pero en muchos casos resultaron en obras increíbles.

Muchas de estas restricciones se originaron en la combinación de mecanismos matemáticos como el desplazamiento, sustitución, adición, sustracción, multiplicación, división, deducción o contracción a objetos lingüísticos como la letra, el fonema, la sílaba, la palabra, el sintagma, la oración o el párrafo.

Algunas de estas combinaciones los forzaron a escribir obras como "Cent mille milliards de poèmes" (Queneau) compuesto por diez sonetos que se imprimen y encuadernan de manera que cada línea queda en una tira de papel que puede voltearse por separado (como en algunos libros para niños), de manera que puede cualquiera de las líneas de un soneto (que tiene catorce versos) puede combinarse con las de otro, generando 1014 combinaciones (los cien billones de poemas del título).

Georges Perec, por su lado, produjo dos obras famosísimas: "La Disparition", una novela enteramente escrita sin utilizar la letra E (salvo por el nombre del autor), y “La Vie mode d'emploi” (Manual de Uso de la Vida), una novela que es un conjunto de novelas con una estructura intercalada sumamente compleja.

Finalmente, el enorme Italo Calvino escribió cuentos como "L'incendio della casa abominevole", alrededor de 1977, utilizando un programa en una computadora para aprovechar la combinatoria no en la sintaxis, sino en la narrativa misma. El protagonista es además, un programador. ¿Ven cómo todo nos conecta?

Gracias por llegar hasta aquí

Si llegaste hasta aquí, estimada lectora o lector, tal vez te preguntes si hay una conclusión a todo esto. Y si, yo tengo una, pero te propongo que saques la tuya. Lo mío es más que nada un llamado a la acción, pero a una acción que usualmente nadie te pide:

Tirá el sombrero sobre la cerca, como dice un refrán estadounidense. Ya no queda otro camino que ir a buscarlo, no importa lo que haya del otro lado.

Busquemos aventuras posibles en este océano calmo que puede ser el trabajo cotidiano. Perdamos tiempo un poco explorando y buscando nuevas posibilidades. Rompamos las reglas. Mientras no nos alejemos mucho de nuestros principios, no deberíamos tener grandes problemas. Y los problemas pequeños son los que nos hacen aprender.

Muchos conocen la historia del "Chaos Monkey" (el mono del caos) de Netflix. Ellos encontraron que para aprender más rápidamente de sus errores, necesitaban más problemas en producción, y ésta herramienta se diseñó para generarlos.

Ir por el camino señalado no nos genera problemas, pero es aburrido.

Recuperemos la pasión detrás del paradigma ágil.

[https://hbr.org/1986/01/the-new-new-product-development-game]