Hace unos días mi amigo Juan Gabardini me pidió que le recomendara material sobre Diseño Colaborativo y como muchas veces, ese pedido me puso a pensar y repensar. Me acordé que había algo en nuestro libro “Construcción de software: una mirada ágil”, en el capítulo de Diseño y Arquitectura, pero también como me suele pasar, encontré al revisarlo que en el libro no decíamos exactamente lo que yo quisiera decir ahora. Esto, sumado a la falta de otras referencias inmediatas que me surgieran, me llevó a escribir este post.
El diseño es un proceso creativo que consiste en generar alternativas y luego elegir una de ellas, plasmando esa decisión de alguna manera (esquema, diagrama, dibujo, código, texto, etc.). Esas alternativas surgen tanto a partir de las restricciones (entre ellas los requerimientos) como de la historia personal de los involucrados, como suma de sus experiencias.
El diseño colaborativo se caracteriza principalmente porque durante la primera etapa los participantes reconciben sus ideas a la luz de las ideas de los demás (Lee Devin acuñó el término en su libro Artful Making), creando así nuevas ideas que son potencialmente mucho más interesantes que las ideas originales aportadas por los participantes. Luego de generar esas ideas en forma colectiva, se procede a elegir entre ellas y plasmar esa decisión.
Un aspecto interesante de este proceso es que además de producir mejores ideas, permite también aprovechar el aporte de todos al máximo, no sólo por lo que vale en sí mismo si no por lo que puede despertar en los demás. De alguna manera, esto resuena con el ideal budista de “mente de principiante”, es decir, ser capaz de mirar el mundo con la perspectiva de otro, que sabe menos pero está por eso fresco y sorprendido por las cosas que nos parecen obvias (y por lo tanto no pensamos en desafiar). Un requisito fundamental para este tipo de proceso es que las personas estén dispuestas a “soltar” sus ideas y cambiarlas (este es uno de los aspectos del release, o desapego, otra característica budista 🙂 ).
En otro sentido muy cercano a la agilidad, en el diseño colaborativo la decisión de qué idea seleccionar no es tomada por una jerarquía (el arquitecto o grupo de arquitectura), si no que es tomada en forma conjunta. Existen múltiples dinámicas para esto, como por ejemplo:
* Cada participante vota (cada uno puede tener X votos, donde X es aproximadamente igual a un tercio del total de opciones).
* Buscar consenso (tiene el riesgo de producir parálisis, por eso podemos poner un límite de tiempo, ver el capítulo “Buscando Consentimiento” de Por un Scrum popular, notas para una revolución ágil, de Tobias Mayer y Alan Cyment).
* Rotar un responsable de la decisión (por ejemplo, rotar el rol de quién decide un empate en la votación o cuando no hay consenso luego de transcurrido un cierto período de tiempo).
Un proceso colaborativo exitoso típicamente se caracteriza por:
* No se puede a posteriori identificar de quién fue una idea, porque fue modificada por varios y se transformó tanto que la idea seleccionada no es ninguna de las ideas originales. Esto es algo que descubrí aplicando estas ideas en la realidad y que he visto repetirse hasta formar un patrón. Mi propio acto de intentar identificar la persona que originó la idea es un gesto de apego interesante :-).
* El proceso mismo promueve la autonomía y actúa como motivador para los participantes.
* Requiere condiciones de ambiente seguro para la participación y muchas veces un facilitador para mantener ese espacio.
* Una etapa clara de divergencia (generar ideas libremente sin juzgarlas ni criticarlas) y otra de convergencia (validar esas ideas contra las condiciones objetivas, ajustar aspectos específicos, seleccionar una idea, plasmar esa selección).
* Límites al proceso claros, por ejemplo, duración, objetivos y alcance. En particular, el time-boxing suele servir como límite a la etapa divergente.
* Alguna de las ideas generadas supera en algún aspecto a las soluciones de compromiso típicas o evidentes (esto depende de que los recursos, por ejemplo el tiempo, no sean muy limitados, si lo son tendemos a terminar en soluciones de compromiso).
Cuestiones que dificultan un proceso de diseño colaborativo:
* Egos muy desarrollados.
* Apego a las ideas (propias o de los demás).
* Comunicación violenta (corporal, verbal, etc.) que reduce las oportunidades de ofrecer ideas.
* Tiempo muy limitado (es difícil hacer ambas etapas si el proceso debe durar 10min).
* Jerarquías muy marcadas (ejemplo, nadie quiere proponer ideas que puedan incomodar al gerente presente).
* Actitud crítica durante la etapa inicial (gente que comienza sus frases diciendo “No”, “Pero”, etc., puede disuadir a otros de ofrecer ideas).
* Falta de límites u objetivos claros (por ejemplo, la falta de un tiempo máximo definido a priori puede dejar estancar la conversación sin que se tome una decisión).
Es muy importante diferenciar las dos etapas, la divergente y la convergente, y los modos apropiados a cada una. En la primera el modo es abierto y permisivo, no criticamos ni buscamos menoscabar las ideas, sólo hacerlas crecer y desarrollarse. En la segunda etapa, sí es importante cerrar, descartar ideas inviables, discutir las consecuencias detalladas de cada una, y tomar una decisión. Me ha ocurrido en varias conversaciones en los últimos años que el proceso no le queda claro o le “hace ruido” a la gente cuando se los describo, porque me enfoco estrictamente en la primera etapa (divergente). Mi propio enamoramiento (apego) con la etapa divergente me ha hecho olvidar el foco en la segunda, darlo por descontado, lo que es un error y muchas veces me ha llevado a discutir con mis interlocutores que (con razón) no entienden cómo puede ser efectivo un proceso así. En algún caso, me han dicho cosas como “Pero si el otro está equivocado, no podemos dejar de decírselo”. Claro, eso tiene sentido cuando estamos convergiendo en la decisión, pero no ayuda cuando estamos creando alternativas.
Espero que les resulte interesante, y me gustaría escuchar sus comentarios.
Diego
Blog de Diego Fontdevila 
Yo tambien tengo problemas con la parte divergente, jaja.
Me gustaría que te explayaras, saliendo un poco del diseño de software, el diseño de una “solución”. En mi mundo es como impacta la seguridad en la arquitectura de una aplicación. No resulta muy colaborativo pues aunque a grandes rasgos se apunta para el mismo lado, hay intereses encontrados interárea.
Además tengo serios problemas con lo de consensuar. Había leido exactamente la idea formulada como “el conocimiento científico no es consensuado” pero no la puedo encontrar, así que expongo la mía. Ante los hechos, no hay consenso. Si falta información necesitamos un consenso, por ejemplo, en algún momento se intuía que la Tierra no era el centro del sistema solar. No bien hay pruebas irrefutables a favor o en contra, se acabó el consenso. No sé si me explico.
Gracias Charly, voy entre líneas
“Me gustaría que te explayaras, saliendo un poco del diseño de software, el diseño de una “solución”. En mi mundo es como impacta la seguridad en la arquitectura de una aplicación. No resulta muy colaborativo pues aunque a grandes rasgos se apunta para el mismo lado, hay intereses encontrados interárea.”
Creo que hay dos condiciones para la colaboración en este contexto, uno es la cooperación (como vos decís, tirar más o menos para el mismo lado) y el otro la disponibilidad de recursos. En tu ejemplo se da algo que no es condición pero ayuda mucho, y es tener gente con formaciones/perspectivas distintas.
Yo diría que si no se cumple cualquiera de estas dos condiciones caemos en la solución de compromiso. En el caso de conflictos serios de intereses, a veces hacemos “horse-trading”, o “toma y daca”, una para vos y una para mí. Esto es lo peor que podemos hacer en diseño, nos aleja de una solución creativa y superadora. En el caso de falta de recursos, por ejemplo tiempo, también tendemos a resolver sin pensar mucho ni intercambiar ideas, ajustándonos a las restricciones y buscando algo así como el mal menor.
Ahora bien, creo que en el caso concreto que vos traés, que es el de la seguridad, el secreto está en que los especialistas participen tempranamente del proceso, idealmente durante la definición del backlog (antes del diseño). Eso permite alinear mejor los esfuerzos durante el proyecto, además de ayudar a que se entiendan las razones detrás de esos intereses en conflicto. Esto crea además una mentalidad de abundancia, es decir, si discuten cuando todavía está todo por hacer todos sienten que tienen más energía y oportunidades de “hacer las cosas bien”. Más allá de eso, puede que ayude mucho algún facilitador (puede ser un arquitecto con ese perfil).
“Además tengo serios problemas con lo de consensuar. Había leido exactamente la idea formulada como “el conocimiento científico no es consensuado” pero no la puedo encontrar, así que expongo la mía. Ante los hechos, no hay consenso. Si falta información necesitamos un consenso, por ejemplo, en algún momento se intuía que la Tierra no era el centro del sistema solar. No bien hay pruebas irrefutables a favor o en contra, se acabó el consenso. No sé si me explico.”
Entiendo claramente, en este caso no es “reconstruir la realidad con nuestro acuerdo”, al estilo deconstructivista, si no llegar al consenso al elegir las alternativas no descartadas mediante criterios objetivos (es decir, las que de acuerdo al conocimiento del equipo, cumplen con solucionar el problema). En mi experiencia, esto muchas veces no ocurre, y usamos una función de fuerza como las que describo, el que tiene el voto de desempate, o el time-box como límite, o ambos juntos.
Hola Diego, me parece claro y completo tu post. Sólo se me ocurre agregar la dimensión del tiempo Kairos, que tiene que ver con lo vivencial y la innovación. El tiempo Cronos, en cambio, tiene que ver con lo lineal y lo controlable. Hay cosas que siguiendo un proceso de diseño colaborativo se alcanzan soluciones satisfactorias, pero otras veces, sobre todo cuando es necesario dar un salto de perspectiva o se requiere la precondición de un proceso de desarrollo humano, es necesario dejar que ocurran ciertas cosas que no se saben explicar y dejar que emerja la solución. Ese dejar emerger puede ser un momento Eureka, o un largo camino de atenta observación, análisis y experimentación.
Un cálido abrazo, Ingrid
Gracias Ingrid querida, totalmente de acuerdo, a veces el tiempo Cronos necesario como recurso es mucho mayor que una horas, o simplemente no es el momento apropiado, o la gente que participa no ha aprendido lo que necesita sobre el problema o la solución para producir resultados extraordinarios.
Hoy hablaba con un equipo sobre la posibilidad de distanciar sus retrospectivas, en lugar de acercarlas, para dar tiempo a que ocurran cosas y reflexiones interesantes, y me acordé de tu comentario.
Voy a tomar esto para mi próximo post sobre Diseño Emergente 🙂 gracias de nuevo, un abrazo,
Diego