Diseño colaborativo: abriendo el proceso de diseño

El título de esta entrada es también el de un artículo que escribí por encargo de mi amigo Carlos Jiménez para el número 12 de la revista MasD, de la que es editor.

El artículo, Diseño colaborativo: abriendo el proceso de diseño, explica lo que desde nuestra práctica entendemos como proceso de diseño colaborativo, algunas nociones de cómo llevarlo a cabo y qué ventajas puede tener sobre modelos más tradicionales. El artículo es una destilación de lo que hemos aprendido investigando y experimentando en el estudio de diseño y desarrollo web montera34, desde que lo pusimos en marcha allá por 2004, Juan López-Aranguren, Ruben Lorenzo, Pablo Rey y yo.

Resumen

Frente a las formas tradicionales de organizar el proceso de diseño se pueden plantear nuevos esquemas más flexibles que desdibujan la separación entre cliente y diseñador. Los procesos de trabajo colaborativo facilitan la comunicación entre las distintas partes implicadas a cambio de debilitar las barreras de conocimiento de los distintos expertos, incluidos los diseñadores. Por otra parte, las nuevas tecnologías, al tiempo que facilitan la comunicación y el intercambio de conocimiento, también permiten al diseñador acceder a un amplio catálogo de soluciones disponibles, modificando por completo el entorno en el que desarrolla su trabajo y relativizando la importancia de la originalidad en el proceso de diseño. En este nuevo paradigma, la gestión del conocimiento creado colectivamente (procomún) y la comunicación con el cliente pasan a ser habilidades imprescindibles para llevar a buen fin cualquier proceso de diseño.

Introducción

Las nuevas posibilidades tecnológicas no sólo sirven para mejorar la eficiencia de los procesos tradicionales, sino que también pueden dar lugar a nuevas formas de organización, aspecto en el que tal vez resida su mayor potencial. En este sentido, las nuevas herramientas de trabajo colaborativo, que permiten, entre otras cosas, que varias personas trabajen en paralelo sobre un mismo proyecto, abren la posibilidad a nuevas formas de organizar el trabajo que aún están, mayormente, por explorar.

En este artículo se exploran las posibilidades que ofrece el trabajo colaborativo y la organización horizontal en el caso del diseño web, a partir de la experiencia que ha acumulado el estudio Montera34, que a lo largo de una serie de encargos profesionales ha ido desarrollando una metodología de trabajo basada en estos principios. En cualquier caso, las lecciones aprendidas en este proceso no se restringen al campo del diseño web, sino que tienen aplicación a otros ámbitos profesionales relacionados con el diseño, como pueden ser la arquitectura y el urbanismo, en incluso a los principios fundamentales que guían la organización económica y empresarial.

Cambios en el paradigma organizativo

La forma tradicional de organizar el trabajo en un entorno altamente especializado parte de un esquema claramente jerarquizado, en el que los trabajadores con mayor grado de especialización (expertos) deben desarrollar unas partes concretas de un todo que sólo conoce su superior jerárquico, ya sea responsable o coordinador de un departamento dentro de una empresa, o cliente que contrata a un profesional independiente.

En este esquema jerárquico, cada participante tiene un rol muy definido y un área de actuación perfectamente acotada. El resultado del proceso depende fundamentalmente de que un «coordinador» sea capaz de comunicarse eficazmente con cada uno de los «expertos» y organizar un plan de trabajo que evite contradicciones, duplicidades, retrasos, solapamientos, etc. entre las distintas partes del proceso. Los diferentes «expertos» apenas se comunican entre sí, lo cual puede generar un cuello de botella y todo tipo de problemas en caso de que el «coordinador» no desarrolle sus funciones de manera impecable. Es un esquema frágil, porque un fallo en cualquiera de sus elementos (ya sea el coordinador o cualquiera de los expertos) puede provocar una parálisis en el conjunto del equipo (no es un esquema a prueba de fallos) y además resulta difícil sustituir alguna de las partes sin provocar retrasos.

El esquema tradicional permite y fomenta la hiper-especialización (sólo los coordinadores deben conocer mínimamente las áreas de especialización que caen bajo su responsabilidad) al tiempo que, según se extienden y complejizan los procesos, tiende a generar mega-estructuras jerárquicas cada vez más frágiles. La culminación última de este modelo sería el taylorismo, en que se lleva la hiper-especialización hasta sus últimas consecuencias en nombre de la eficiencia y a costa de la flexibilidad.

Sin embargo, desde hace décadas, las grandes empresas industriales aplican un nuevo paradigma de producción flexible basada en la descentralización y la autonomía de las distintas fases que conforman el proceso productivo (para una revisión analítica de las nuevas formas organizativas, véase Rivas, 2002). El toyotismo sería otro ejemplo de este tipo de organización horizontal: la conformación de un equipo de trabajadores expertos que trabajan conjunta y no aisladamente y que reciben un reconocimiento global por las aportaciones que realizan en forma de mejoras al proceso productivo (Fujimoto, 1999). Sin embargo, las profesiones liberales basadas en el conocimiento (como sería el caso del diseño) llevan un considerable retraso en este cambio.

El profesional liberal siempre ha sido reacio a compartir sus conocimientos y crear equipos de trabajo realmente horizontales, debido principalmente a que es consciente de la fragilidad de su «ventaja comparativa», que es precisamente dicho conocimiento especializado. Los tradicionales estudios de arquitectos y diseñadores se han organizado, por tanto, siguiendo un esquema jerárquico en el que la cúspide viene a estar ocupada por el socio o socios fundadores, en tanto que el resto de trabajadores se organiza por debajo en departamentos aislados entre sí, de manera que sólo unas pocas personas conocen los engranajes del funcionamiento del estudio en su totalidad. En el caso de profesiones con un fuerte componente creativo (como sería el campo del diseño, pero también, la comunicación, la publicidad u otros afines) se produce, además, un fenómeno de feroz competencia, acompañada de las inevitables envidias, traiciones, etc. Está claro que este entorno ha sido tradicionalmente hostil a cualquier avance en el trabajo en equipo (aunque finalmente, por una cuestión de economía de escalas, la mayoría de las grandes empresas del sector trabajen con equipos creativos y no con personas aisladas) y, sobre todo, a cualquier propuesta para «compartir» conocimientos. Esta relación al interior de las empresas o equipos de trabajo también se ha trasladado, por supuesto, a la relación con el cliente; el cliente paga por un producto, pero el proceso que lleva al producto es «secreto industrial», el know-how es el activo más valioso de cualquier empresa dedicada a la prestación de servicios. Sin embargo esta relación está cambiando, en parte gracias a cambios en el entorno cultural de los nuevos profesionales, y a un cambio en el contexto económico y social que está generando un nuevo tipo de empresas de servicios.

Una nueva generación de profesionales de la programación y el diseño web han demostrado su competencia y valía profesional, no a través de una larga carrera profesional en distintas empresas del sector, sino a través de aportaciones gratuitas de su tiempo y su trabajo a diversos proyectos de software libre, donde los méritos se demuestran al compartir habilidades y conocimientos con la comunidad (Zeitlyn, 2003). Por otra parte, el exceso de información disponible y la nueva economía de la atención[1] requieren, no de guardar celosamente el conocimiento, sino de difundirlo lo más posible para demostrar la valía y la capacidad de quien lo ha generado. Es la estrategia de una nueva generación de profesionales que se ha encontrado un espacio laboral copado por la «vieja guardia» y que necesita nuevas estrategias para hacerse un hueco en un mercado profesional saturado. Sin embargo, esta estrategia, que podríamos considerar como una respuesta de «supervivencia», está demostrando, sobre una organización básicamente horizontal y aparentemente caótica, una capacidad sorprendente para generar innovaciones, tanto en los procesos como en los productos, sin renunciar a la calidad, sobre un nuevo modelo descentralizado alternativo al modelo jerárquico tradicional (Raymond, 1999).

Parecería necesario mencionar algún logro de este nuevo sistema organizativo, pero en realidad sus principales logros son bien conocidos, aunque pocas veces se caiga en la cuenta de su carácter «colaborativo». Dejando al margen la propia sociedad, que podría considerarse un gran producto colectivo de la colaboración (aunque imperfecta), el ejemplo más paradigmático de este tipo de organización es la propia ciencia occidental, regida por el principio fundamental del intercambio de conocimiento y la realización de nuevas aportaciones sobre el conocimiento ya consolidado (Kuhn, 1970). Mientras que el ámbito de las invenciones y de la ingeniería se ha guiado principalmente por al ánimo de lucro y el afán de lograr ventajas competitivas, el conocimiento científico sobre el que se basaba se ha construido fundamentalmente sobre la colaboración, dejando al margen las patentes y otros mecanismos de apropiación exclusiva del conocimiento. Concretando un poco más, uno de los ejemplos más espectaculares de esfuerzo colectivo y colaborativo sería la «red de redes», Internet (Abbate, 1999). Su propio diseño como red descentralizada donde ninguno de los nodos es imprescindible ha implicado la colaboración de equipos independientes y autónomos que se encarguen del mantenimiento de cada uno de dichos nodos. En cuanto a los aspectos técnicos, el Protocolo de Internet (IP) está diseñado específicamente para poder «albergar» distintos protocolos de comunicación entre máquinas, que se han ido incorporando con el tiempo proporcionando el soporte para nuevos servicios; especialmente los servicios más populares, como son el correo electrónico (e-mail) y la World Wide Web (WWW), o simplemente Web, se apoyan en protocolos abiertos y públicos sobre los que diversos agentes han construido sus propios servicios, como serían buscadores, sistemas de publicación online, redes sociales, etc. Por último cabría mencionar el movimiento del software libre como gran proyecto «auto-consciente» de colaboración en torno a la generación de software de calidad, entre cuyos logros cabría destacar proyectos como GNU, Linux, Apache, Mozilla, OpenOffice, WordPress o MySQL, cada uno de ellos con distintos grados de implicación de grandes empresas y diferentes comunidades de usuarios (Salus, 2005). También en el mundo del software comercial ha prendido en mayor o menor medida la metodología de la colaboración, a través de la filosofía del open source o «código abierto», una vez que empresas de todos los tamaños han descubierto las ventajas en términos de costes y de calidad de este nuevo enfoque.

Por qué un proceso de diseño colaborativo

¿En qué medida puede aplicarse al diseño, y qué beneficios puede traer, un enfoque más abierto, horizontal y colaborativo?

Podríamos decir que el proceso de diseño por encargo consiste en dos tareas fundamentales: ejecutar el diseño y comunicarse con el cliente. La primera requiere de un conocimiento específico de las herramientas y el medio; la segunda es cuestión de tiempo, más cuanto menos fluida es la comunicación, cuantas más interferencias se encuentran en el camino que ha de seguir la información. Tradicionalmente un cliente ha recurrido a un diseñador para paliar una falta de conocimiento o una falta de tiempo. La figura del especialista en diseño, el experto, cubría estas carencias con sus servicios. Esto ha cambiado en nuestros días: el peso de cada una de las partes, ejecución y comunicación, ha variado con la irrupción de dos nuevas herramientas en el sector: el ordenador personal e Internet. Estas herramientas además permiten al cliente decidir qué carga de trabajo atribuye al diseñador: ya no es un todo o nada.

Como en tantos otros sectores, en el mundo del diseño, las nuevas tecnologías han democratizado el sector, haciendo que la tarea de ejecución sea accesible a un grupo cada vez más numeroso de personas, perdiendo importancia el papel del diseñador como experto y reduciendo la brecha de conocimiento entre clientes y diseñadores.[2]

Por otro lado, Internet usado convenientemente permite que la información fluya de manera más directa entre la gente dedicada o interesada por el diseño. Las posibilidades que ofrece la red para compartir información de manera horizontal han propiciado la incorporación indirecta, y muchas veces invisible, de nuevos actores a cualquier proyecto de diseño: hoy día la reutilización de ideas, material y trabajo ya desarrollado por otros constituye una parte fundamental en cualquier proceso de creación.

Este escenario digital en el que se desarrolla el trabajo de diseño ofrece nuevas posibilidades y obliga a repensar el papel de los actores, desde el cliente al diseñador, del proceso de diseño, y la gestión del conocimiento generado.

El contexto de producción de un diseño: transparencia y producción colaborativa

Quizás uno de los episodios más importantes de la historia reciente de Internet sea también uno de los más absurdos. Cuando en noviembre de 2010 Wikileaks publicó en su sitio web más de 250.000 comunicaciones entre el Departamento de Estado de Estados Unidos y sus embajadas algo cambió a escala internacional: la política y la diplomacia se pusieron del revés cuando los medios generalistas dieron la noticia. Es difícil encontrar gente que no leyera sobre ello, que no se enterara de la publicación de los cables. Pero aún es más difícil encontrar alguien que se haya leído alguno. Lo absurdo es que, exagerando, daba igual lo que contasen esos cables, eran el MacGuffin de Hitchcock. Lo realmente importante fue la idea de cómo la transparencia puede cambiar un sistema cuando se eliminan los obstáculos que impiden fluir la información.

Uno de los episodios más repetidos de la historia de Internet es la demanda por copia, por vulneración de derechos de autor sobre una creación, un meme en toda regla. Una de las últimas disputas de este tipo en el mundo del diseño la ha protagonizado la empresa LayerVault que ha demandado a la empresa Designmodo (Lafuente, 2013). LayerVault ha desarrollado un entorno de trabajo para diseñadores en el que ha utilizado —para botones, iconos y demás elementos del entorno— un estilo denominado diseño plano. Por su parte, Designmodo ha desarrollado un conjunto de elementos (botones, iconos, paletas de colores…) para utilizar en desarrollo web bajo la denominación de Flat UI que también emplea diseño plano.

La sucesión de acontecimientos desde que LayerVault demanda a Designmodo es bien representativa de cómo la transparencia y la producción colaborativa están cambiando el sector del diseño y la manera de ejercer la profesión.

LayerVault demandó a Designmodo en septiembre de 2012 por utilización indebida de material que consideró de su propiedad: «I am the exclusive rights holder for the artwork contained within Flat UI, Free Web User Interface Kit» (GitHub, 2012). Es decir, LayerVault se proclamó dueño del trabajo realizado por Designmodo, Flat UI, ya que lo consideró una copia del suyo. Cuando la noticia empezó a circular por Internet mucha gente interesada se dedicó a examinar el código de las aplicaciones de ambas empresas, descubriendo que no había relación directa entre ellos (Bruun, 2013), con lo que la opinión generalizada demostró que no había habido copia. No hizo falta esperar el veredicto de un tribunal: en ese momento la acusación de que LayerVault quería apropiarse de un estilo, el diseño plano, empezó a predominar en Internet. Para demostrar que LayerVault no creó el estilo plano, y no tiene por tanto ningún derecho sobre él, de nuevo los interesados fueron reuniendo ejemplos de herramientas anteriores a LayerVault que también usan el mismo estilo. Ante esta situación, LayerVault rectificó explicando su postura (Grinshtein, 2013): su intención nunca fue apropiarse de un estilo, nunca demandó por ello, sino por la copia de algunos elementos, algunos iconos. Acto seguido empezaron a aparecer en la red comparativas entre los iconos de LayerVault, Flat UI y otros conjuntos de iconos anteriores a ambos que muestran las similitudes entre los tres. Si LayerVault fue víctima también fue culpable.

La capacidad de acceso generalizado y sin intermediarios a la información primaria (documentos de demanda, código de las aplicaciones, declaraciones de las partes) impide el control del relato por una de las partes. De la misma manera que la transparencia irrumpió en el mundo diplomático y político, está cambiando las reglas del juego del diseño, permitiendo detectar malas prácticas que la posibilidad de controlar el relato mantenía ocultas.

Como efecto secundario está desterrando valores del diseño que se revelan obsoletos. El trabajo de un diseñador no es crear o desarrollar un estilo, es y ha sido siempre encontrar una solución a un problema, como señala Keenan Cummings (2013), lo cual incluye aplicar estilos ya creados. Tradicionalmente el mundo del diseño se ha construido en torno a la originalidad, el objeto único o el estilo propio, como principal valor que podía aportar el diseñador. Hoy en día, y más en un sector tan conectado como el diseño web, a un diseñador no le resulta tan fácil aportar originalidad, y empieza a cuestionarse que el coste de dicha búsqueda esté realmente justificado.

El catálogo de soluciones de diseño disponibles para su utilización o adaptación es tan amplio que, aun sin llegar a pensar que pueda ser completo, debe replantearse, en términos de rentabilidad, si no resulta más práctico centrar los esfuerzos del diseñador en investigar las posibilidades ya existentes y aplicar la creatividad sobre todo a adaptar dichas soluciones a las necesidades concretas del cliente. En este nuevo contexto, queda románticamente relegada a un plano muy secundario la idea de creación original, de marca personal o de estilo propio; la originalidad es más que nunca, un lujo.

Aceptar que la labor del diseñador debe centrarse en la búsqueda y el análisis de soluciones ya desarrolladas, evaluando la posibilidad de incorporarlas a la solución final, ahorra tiempo y dinero a cualquier proyecto, aumentando la eficiencia de la producción. Además una solución depurada por el trabajo de una comunidad entera tiene muchas más garantías de calidad que el trabajo desarrollado íntegramente por una única persona o equipo (Raymond, 1999).

Ante estas nuevas reglas del juego es necesario redefinir también en el mundo del diseño, como ya ha ocurrido en otros contextos como la producción de software, el concepto de autoría. Es importante incluir a los actores indirectos en el proceso, reconocer a los diseñadores que han invertido su tiempo en las soluciones ya desarrolladas que se incorporan al desarrollo. Este reconocimiento es fundamental para que el hecho de liberar el trabajo desarrollado para que lo usen otros tenga un retorno en sus autores. Por otro lado es igualmente importante respetar escrupulosamente las condiciones de uso que, bajo mecanismos legales disponibles para licenciar creaciones intelectuales —como son los diseños— hayan elegidos los autores para su trabajo.

La labor del diseñador hoy día incluye la gestión del conjunto de soluciones disponibles en Internet, de las que se nutre. Ese conocimiento debe tratarse como un procomún, alimentarlo para que siga creciendo. El reconocimiento es la herramienta fundamental para que funcione la creación colectiva porque convierte el compartir en un mecanismo beneficioso para los autores, que reciben visibilidad y reputación. No únicamente beber de él, alimentar ese procomún deviene algo rentable. Los mecanismos legales, las licencias de las creaciones intelectuales, deben reforzar la cadena de producción colaborativa, obligando a los diseñadores a generar un retorno para que otros reutilicen igualmente su trabajo, evitando la apropiación del trabajo ya desarrollado. El reconocimiento y la reputación permiten incorporar dentro del sistema una forma de producción no basada en el intercambio monetario y que aumenta de manera considerable la eficiencia de un proceso de diseño.

El proceso de diseño colaborativo

Dentro de este contexto de diseño en red, en el que los profesionales del sector colaboran compartiendo su trabajo, tiene sentido pensar en una manera de funcionar similar entre las partes implicadas directamente en un proceso concreto de diseño: el cliente y el diseñador. Para que se produzca una colaboración fluida entre ambas partes hay que eliminar las parcelas de acción y conocimiento tradicionales de cada actor.

El cliente tiene que tener la capacidad de habitar el terreno del diseño y para que se produzcan estas incursiones debe adquirir ciertos conocimientos necesarios. Por un lado los conocimientos técnicos, el manejo de las herramientas utilizadas en la ejecución del diseño. Pero sobre todo el diseñador[3] debe liberar el código fuente del proceso, hacerlo abierto, de manera que el cliente tenga capacidad de decisión para modificarlo según sus necesidades, que conoce mucho mejor que el diseñador o desarrollador. Conocer el código fuente del proceso permite al cliente valorar en las mismas condiciones que lo hace el diseñador cada decisión que se toma en el proceso de diseño. De esta manera la labor del cliente no será confiar en el buen hacer profesional del diseñador, ni imponer siguiendo una intuición o un capricho, sino participar activamente y con responsabilidad en cada decisión. Así la relación entre el diseñador y el cliente no se establece como un voto de confianza que éste deposita en aquél en función de sus trabajos anteriores. La acción, el trabajo y la responsabilidad del resultado son compartidos.

Esto no quiere decir necesariamente que el papel del diseñador como ejecutor desaparezca, pero el hasta ahora cliente tiene la capacidad de decidir en qué medida utiliza los conocimientos especializados del hasta ahora experto. Entre las partes se acuerda qué tareas ejecutará cada uno. Previamente a las tareas a desarrollar por el cliente, el diseñador procede a la transferencia de los conocimientos necesarios.

Cada fase del proceso de diseño tiene que ser valorada por el cliente antes de tomar la decisión, usando parámetros adecuados y suficientes. Tradicionalmente el cliente ha valorado el proceso únicamente según parámetros económicos, monetarios. Esto no es suficiente para que ambas partes elijan libre y conjuntamente cómo organizar el proceso. Hace falta poder cuantificar el trabajo. Para ello hay que despiezar el proceso en tareas, y evaluar cada una de ellas según el tiempo necesario para completarla. Además hay que encontrar una unidad que permita poner en relación unas tareas con otras para fijar su peso relativo dentro del conjunto del proceso. En el caso del desarrollo web, por ejemplo, una posible unidad de medida de las tareas sería la línea de código. La cantidad de líneas de código que hay que escribir para completar una tarea del proceso puede ofrecer una aproximación al tiempo que demandará, teniendo siempre presente que hay tareas cuya dificultad (y consecuente dedicación de tiempo y esfuerzo) no se traduce necesariamente en líneas de código. Todos estos aspectos hay que tenerlos en cuenta y trasladarlos al cliente para que pueda supervisar la tarea adecuadamente.

Posteriormente hay que incorporar los parámetros que definen la cantidad de conocimientos necesarios para desarrollar cada tarea, para poder evaluar la complejidad de la transferencia del diseñador al cliente.

Y por último valorar, en este caso de manera cualitativa, qué utilidad futura puede tener para el cliente adquirir dichos conocimientos. Quizás le sirvan para ganar autonomía en el futuro, para no tener que depender de expertos, quizás le suponga un ahorro de dinero a largo plazo, quizás pueda aplicar los conocimientos adquiridos en otros contextos.

Esta metodología de valoración de cada tarea permite un proceso de diseño más flexible, que se adapta mejor a los condicionantes de tiempo y dinero del proyecto. En definitiva, permite al cliente decidir qué quiere gastar, su tiempo o su dinero. Pero además le permite decidir el grado de autonomía digital y tecnológica con la que quiere funcionar, desde un modelo totalmente «asistencial» y dependiente del experto, a otro en el que el control del proceso queda por completo en sus manos.

Herramientas para un desarrollo colaborativo y abierto

Una idea que recorre toda la metodología para un proceso de diseño abierto y colaborativo es que un diseñador concreto no debe ser imprescindible en ningún momento, el proyecto no puede depender de una persona. Un proceso óptimo permite que un diseñador desarrolle una de las tareas y otro, o el mismo cliente, le pueda sustituir en la siguiente.

Para que esto sea posible es importante el uso de herramientas libres y formatos estándares para no generar dependencias al proyecto. El uso de herramientas propietarias limita la capacidad de elección de la forma de trabajo, obliga a que todo el que quiera participar del proyecto use dichas herramientas. El uso de formatos o herramientas propiedad de una empresa, que sólo son manejables con el software que esa empresa comercializa, deja a los procesos de diseño a merced de las decisiones del propietario del formato. La evolución del programa FreeHand, desarrollado y comercializado por la empresa Macromedia, es un buen ejemplo. Macromedia fue comprada en 2005 por Adobe, que paró el desarrollo de FreeHand y lo dejó morir. Los usuarios de FreeHand se han quedado atrapados en su última versión, liberada allá por 2003.

La documentación del trabajo realizado es imprescindible para que el proceso de diseño sea abierto y permita la incorporación de manera fácil e inmediata de nuevos diseñadores, y la participación del propio cliente en el proceso.

El uso de un sistema de control de versiones como git permite la monitorización del proceso por parte del cliente. Git requiere un desarrollo ordenado del proceso de diseño por tareas, commits en su lenguaje. Git guarda registro del número de líneas de código escritas para cada tarea y de la persona que la ha realizado. La línea de código permite medir la envergadura de cada tarea del proceso, pero al ser un parámetro utilizado en cualquier desarrollo llevado a cabo con un sistema de control de versiones, es una medida universal que permite comparar un desarrollo concreto con todos los demás. En este sentido la publicación del código de un desarrollo, además de permitir su reutilización por otros proyectos, es un ejercicio de transparencia por parte del diseñador. Al estar el código disponible para que cualquiera lo examine es una garantía de honestidad para el cliente. Si hay irregularidades en la ejecución, tarde o temprano saldrán a la luz, como ocurrió en la historia entre LayerVault y Designmodo.

El caso del diseño web: la experiencia de montera34

Para ilustrar estos cambios en el contexto y el proceso de diseño podemos ver dos trabajos realizados por el estudio montera34 en los que se ha aplicado la metodología descrita.

El entorno de trabajo

Montera34 es un estudio pequeño formado por cuatro profesionales. Desde el principio se ha hecho un esfuerzo por mantener una estructura ligera para minimizar el tiempo y el dinero dedicado a las labores de mantenimiento. Montera34 no es una empresa, es solo una marca bajo la que se firman trabajos. La única estructura que la soporta es un servidor web en el que se aloja su página web y las de los clientes que lo desean, una cuenta de correo y una cuenta de Twitter.

La implicación de sus integrantes es desigual y discontinua, en función de sus necesidades y apetencias, no hay compromiso alguno de dedicación porque no es necesario para que el proyecto común salga adelante, precisamente por su ligereza. Cada integrante gana en función de lo que trabaja y todos se benefician de la visibilidad de la marca que alimentan.

Frecuentemente Montera34 colabora con otros pequeños estudios y profesionales para desarrollar encargos. Para visibilizar esta red de colaboradores se ha puesto en marcha la plataforma Desarrolladores en Red. El funcionamiento es similar a la dinámica entre los miembros de Montera34: no hay reglas preestablecidas para trabajar conjuntamente, no hay compromiso previo, no hay obligación de llevar trabajo a la red. El integrante que lleva un proyecto a la red elige sus colaboradores para ese trabajo en concreto, y entre ellos llegan a un acuerdo económico y deciden cómo trabajarán.

En definitiva, Desarrolladores en Red es la puesta en práctica de la creación colectiva a pequeña escala. Sus nodos van alimentando un banco de recursos que circula ágilmente entre ellos, que se nutre, y alimenta a su vez, ese procomún del que hablábamos antes.

A nivel competitivo, el modelo de Desarrolladores en Red es interesante ya que permite asumir encargos de envergadura que un pequeño estudio tradicional, sin los recursos suficientes, no puede. Para asumir estos encargos un pequeño estudio tiene que cambiar de escala, complejizar su organización y aumentar sus recursos. Una vez que lo ha hecho está obligado a incrementar su volumen de trabajo para poder mantener la nueva estructura. Para Desarrolladores en Red la envergadura del encargo define el número de nodos que participan en el desarrollo, pero la estructura no tiene que cambiar. En ningún caso las decisiones tomadas hipotecan el futuro de la red ni de sus nodos. Es un ejemplo de flexibilidad basada en la horizontalidad.

A continuación se describirán una serie de trabajos en los que se ha seguido un enfoque de diseño colaborativo. En algún caso se trata de proyectos en marcha, cuyo producto final aún no se ha completado. Sin embargo, puesto que su ejemplaridad radica más en el proceso de desarrollo que en el producto final, pueden servir perfectamente para ilustrar el enfoque planteado.

Ecómetro: la importancia relativa de la herramienta

El estudio madrileño Satt Arquitectura contactó con Montera34 para llevar a cabo el desarrollo del Ecómetro, «una herramienta de código abierto para la medición y lectura transversal de la ecología en el proceso de diseño, construcción y uso de los edificios, que cuantifica tanto los impactos sobre la Tierra, como sobre los ecosistemas y la salud humana». Básicamente consiste en una herramienta de certificación libre, transparente y modificable.[4]

Los criterios de medición son públicos y cualquier interesado puede participar en su definición. Por otro lado el código de la herramienta es abierto, está a disposición de cualquiera bajo una licencia GPL. La posibilidad de modificar criterios y código hacen útil y versátil el sistema de certificación, ya que permiten su aplicación a arquitecturas que pueden estar en cualquier parte del mundo, afectadas por factores ambiente totalmente diferentes, construidos con materiales distintos, sujetos a normativas que no tienen nada que ver.

Varias sesiones de trabajo conjunto entre Satt, Montera34 y Domenico Di Siena, otro de los nodos de Desarrolladores en Red, permitieron dejar atrás los roles tradicionales de cliente y diseñador. Esto permitió concederle una importancia relativa a la herramienta, que en un principio parecía el centro del proyecto, y empezar a pensar que lo más importante era trabajar con la gente potencialmente interesada en utilizar una herramienta como la que sería el ecómetro.

Se abrió el proceso de diseño a toda la comunidad interesada. Esto permite definir los criterios de evaluación de manera colectiva. El desarrollo de la herramienta se aplazó a una segunda fase, lo que permitió igualmente ir nutriéndola con los aportes de la comunidad. La herramienta ha sido así ideada por la gente que la va a usar en un primer momento.

En el desarrollo de la herramienta intervinieron también otros tres nodos de Desarrolladores en Red: Jorge Chamorro se encargó de coordinar el diseño y la usabilidad, El Pixel Vivo de la maquetación web, y Capitan SEO de la programación.

Úbiqa: el valor del desarrollo existente

La empresa Úbiqa de Bilbao trabaja con contenido transmedia generado de manera colectiva a través de talleres con distintos comunidades. Úbiqa encargó a Montera34 el desarrollo de la plataforma Identikit, un conjunto de herramientas para facilitar la publicación y la edición del contenido transmedia generado en los talleres, y que constituya un archivo para que cualquiera pueda generar su relato de las realidades en las que se insertan los talleres.

Debido a la complejidad del desarrollo planteado, Montera34 y Domenico Di Siena propusieron una semana intensiva de trabajo junto a Úbiqa para acotar el trabajo y priorizar las necesidades. Durante esa semana se rescató un portal desarrollado para otro proyecto de Úbiqa, Nikmashup. Tras analizar la web conjuntamente se llegó a la conclusión de que la plataforma Nikmashup cubría casi el cincuenta por ciento de las necesidades a las que debía responder el desarrollo de Identikit. El trabajo que suponía modificar y extender el código existente para convertir Nikmashup en la herramienta buscada era aproximadamente un cuarto del necesario con el planteamiento inicial.[5]

El caso de Úbiqa es paradigmático como proceso de diseño abierto porque la apertura se produjo desde ambas partes: Úbiqa consiguió que Montera34 y Domenico Di Siena entendiesen de manera amplia el proceso en el que estaban inmersos, hasta el punto de tener capacidad propositiva y legitimación para tomar decisiones.

Boston Planning: los beneficios de la creación en red

El Departament of Urban Studies & Planning del Massachusetts Institute of Technology (MIT) entró en contacto con Montera34 para desarrollar una visualización en forma de línea del tiempo de los hitos del desarrollo urbano de la ciudad de Boston. Un desarrollo de este tipo es costoso y complejo si se plantea de manera integral.

Desde montera34 se planteó una labor de búsqueda de la solución existente que se adaptase mejor a los requisitos del proyecto Planning Boston. Se encontró el software Simile, desarrollado también en el entorno del MIT, y se adaptó mínimamente. El tiempo total dedicada al proyecto planteado de esta manera fue de 32 horas: 11 de búsqueda y estudio de documentación; 16,75 de desarrollo; y 4,25 de reuniones y comunicación.

En el desarrollo de Planning Boston se ha acreditado convenientemente el uso de un software desarrollado previamente, que había sido liberado bajo una licencia que permite su uso y modificación. Montera34 por su parte, ha liberado el código desarrollado a partir de Simile bajo las mismas condiciones.

Conclusiones

Podríamos decir que las dos partes que completan un proceso de diseño tradicional, la comunicación con el cliente y la ejecución del diseño están bien delimitadas y ocurren en un orden concreto: en la fase de comunicación el cliente transmite al diseñador su necesidad; en la fase de ejecución el diseñador traduce a diseño las palabras del cliente.

Los roles y las tareas también están claramente definidos debido a una brecha de conocimiento: el cliente es asistido por el diseñador al cien por cien, se pone en manos de un experto que tiene el conocimiento necesario al que él no tiene acceso.

En un proceso de diseño colaborativo y de código abierto la comunicación y la ejecución están entrelazadas. El cliente sigue de forma continua el proceso dividido en tareas y lo evalúa gracias a los parámetros que lo cuantifican.

Los roles tradicionales de cliente y diseñador se definen en función de los recursos disponibles. En función de lo que el cliente esté dispuesto a gastar, su tiempo o su dinero, se decide quién se hace cargo de cada una de las tareas de producción. El grado de autonomía con el que quiera trabajar el cliente define la cantidad de conocimientos que el diseñador debe transferir al cliente.

En definitiva, un proceso colaborativo y de código abierto permite flexibilidad en la ejecución, y proporciona versatilidad para adaptarse a las condiciones económicas y de tiempo concretas de un proyecto. La transparencia y los parámetros adecuados de valoración permite al cliente ser una parte activa y consciente en la toma de decisiones, lo que hace que la responsabilidad se reparta.

Notas

[1] Gracias a las facilidades que ofrece la tecnología para la creación de contenidos, el recurso realmente escaso y valioso por el que hay que competir ha dejado de ser la información, para pasar a ser la atención del público; la dificultad ya no reside en escribir un libro o grabar un disco, sino en que finalmente alguien lo lea o lo escuche (Davenport et al, 2002).

[2] Habría que matizar varios aspectos de esta visión optimista de las nuevas tecnologías en general, y de Internet en particular. Primero, a pesar de las esperanzas puestas en ella, no deja de ser una nueva tecnología que se inscribe en el contexto social y político, es decir, no constituye por sí misma una «revolución» en la comunicación (Wolton, 2000). Segundo, como herramienta, hay que tener en cuenta los costes asociados y las barreras de acceso existentes (Vázquez, 2003), que dificultan que llegue realmente a todo el público; además, a pesar de su potencial liberador, también permite un mayor control por parte de los agentes más poderosos, Estados y grandes empresas (Mander, 1994); en este sentido, no dejaría de ser un reflejo de sus propios orígenes, en una extraña combinación de proyecto militar y comunidades hacker libertarias (Castells, 2001). Por último, en una visión exclusivamente pragmática, como repositorio de información, no deja de ser una colección claramente sesgada, que responde fundamentalmente a los intereses de sus usuarios más activos, ya sean éstos personas, empresas o instituciones varias.

[3] En lo que sigue se personaliza en el diseñador el conjunto de personas y/o saberes que intervienen en el proceso de diseño y desarrollo del producto, asumiendo que el «diseño» es la parte central del encargo, y que el «diseñador» actúa como intermediario entre cliente y desarrolladores. Pueden darse otros casos en que el «diseño» sea un mero aspecto colateral del «desarrollo» de un producto. La casuística es muy amplia y aquí nos centraremos en el caso prototípico.

[4] En el momento de la publicación de este artículo, está finalizando la primera fase del desarrollo de la herramienta ecometro: http://blog.ecometro.org

[5] En el momento de la publicación de este artículo, está finalizando la fase de modificación de la plataforma Nikmashup.

Referencias

Abbate, Janet (1999): Inventing the Internet. Cambridge, Mass.: MIT Press

Bruun, Nick (2013). «Who owns flat?». En: Nick bruun code, rants, randomness. Disponible en: http://bruun.co/2013/03/06/who-owns-flat (Consulta: 14 de abril de 2013).

Castells, Manuel (2001): «Internet, libertad y sociedad: una perspectiva analítica». Universitat Oberta de Catalunya (UOC). Disponible en: http://www.uoc.edu/web/esp/launiversidad/inaugural01/intro_conc.html (Consulta: 25 de mayo de 2013).

Cummings, Keenan (2013). «Stop Stealing My Style, Bro». En: Field Study. Disponible en: http://blog.keenancummings.com/post/44715900168/stop-stealing-my-style-bro (Consulta: 14 de abril de 2013).

Davenport, T. H., Beck, J. C., Vilaplana, J. C. G. (2002). La economía de la atención: el nuevo valor de los negocios. Paidós.

Fujimoto, T. (1999). The evolution of a manufacturing system at Toyota. Oxford University Press on Demand.

GitHub (2013): «2013-03-06-LayerVault.md». GitHub / DMCA. Disponible en: https://github.com/github/dmca/blob/master/2013-03-06-LayerVault.md (Consulta: 14 de abril de 2013).

Grinshtein, Allan (2013): «Looks like the pitchforks are out over on HN…» En: LayerVault. What’s up with the DMCA? Disponible en: https://news.layervault.com/stories/1992-layervault-whats-up-with-the-dmca (Consulta: 14 de abril de 2013).

Kuhn, Thomas S. (1970): The Structure of Scientific Revolutions. Chicago: University of Chicago Press.

Lafuente, Diego M. (2013). «No me robes el estilo». En: minid.net. Disponible en: http://minid.net/2013/03/20/no-me-robes-el-estilo/ (Consulta: 14 de abril de 2013).

Mander, Jerry (1994). En ausencia de lo sagrado. El fracaso de la tecnología y la sobrevivencia de las naciones indígenas. Santiago de Chile: Cuatro Vientos.

Raymond, Eric S. (1999). «The cathedral and the bazaar». Knowledge, Technology & Policy, 12(3), 23-49. Versión española de José Soto Pérez: «La Catedral y el Bazar» Disponible en: http://biblioweb.sindominio.net/telematica/catedral.html (Consulta: 14 de abril de 2013).

Rivas Tovar, L. (2002) «Nuevas formas de organización». Estudios Gerenciales, Norteamérica, 0, mar. 2002. Disponible en: http://www.icesi.edu.co/revistas/index.php/estudios_gerenciales/article/view/77 (Consulta: 14 de abril de 2013).

Salus, Peter H. (2005). The Daemon, the Gnu and the Penguin. Disponible en: http://www.montanalinux.org/files/The_Daemon_the_GNU_and_the_Penguin.pdf (Consulta: 25 de mayo de 2013).

**Vázquez Espí, Mariano* (2003): «Luces y sombras de las tecnologías de la información y comunicación (TICS)», en José I. Porras y Rubén Araya (Ed.): e-democracia. Editorial Universidad Bolivariana, Santiago, 2003

Wolton, Dominique (2000): Internet ¿y después? Una teoría crítica de los nuevos medios de comunicación. Barcelona: Gedisa.

Zeitlyn, D. (2003). «Gift economies in the development of open source software: anthropological reflections». Research Policy, 32(7), 1287-1291. Disponible en: http://www.idi.ntnu.no/grupper/su/bibliography/pdf/newoyvh/zeitlyn2003.pdf (Consulta: 14 de abril de 2013).