Diseñadores de desarrollo, cemento y arqueología
Últimamente lo arquitectónico y constructivo me rodea y se cuela por todos los huecos de mi vida. Obviamente tiene que ver con que mi pareja sea arquitecta y que trabaje habitualmente a pie de obra, rodeada de otros arquitectos, cuadrillas de albañiles, fontaneros, cerrajeros, chalecos reflectantes, botas de seguridad, hormigón y polvo por todas partes. Mucho polvo. Aquí una de las fotos que hace ella, sacándole el lado bonito al asunto:
El caso es que en sus días de descanso no hemos tenido mejor idea que reformar un baño en el piso y hacer algunos cambios en el refugio de campo el que he escrito algunas de estas cartas. Total, que estamos metidos en dos obras ahora mismo, con posibilidad de meternos en otra en el Instituto, que ya puestos…
Cuento todo esto porque el otro día Marina Aísa publicó un artículo estupendo que reflexiona sobre ese tramo oscuro e incierto que queda entre lo que diseñamos y lo que construimos cuando creamos un producto digital. En otras palabras más prosáicas: las malditas diferencias entre el diseño y el html final. Marina viene a decir que la solución está en que existan herramientas que se acerquen cada vez más hasta que llegue un punto en el que se diseñe generando directamente el código. Y tiene mucha razón.
El problema que describe Marina no es nuevo: en arquitectura pasa exactamente lo mismo: lo que se diseña en los planos y los renders de la mesa del arquitecto luego pasa por un filtro de realidad tremendo y acaba no siendo lo proyectado. La diferencia depende de varios factores:
La cantidad de soluciones prefabricadas y componentizadas que se usen vs. los trabajos de “artesanía”: si se diseñan unas claraboyas o una barandilla que hay que hacer in-situ es mucho más probable que salgan distintas que si el arquitecto elige una solución de mercado que sólo hay que comprar e instalar. Es obvio que el buen criterio del arquitecto está en saber qué cosas merecen soluciones a medida y en cuáles se ahorra tiempo y se asegura calidad tirando de componentes.
El rol del arquitecto de obra, el que no proyecta, sino que supervisa y se encarga de aportar soluciones sobre la marcha cuando aparecen contratiempos (un material no llega, unos cálculos estaban mal) para que la obra no pare. Ese arquitecto, no siendo dueño intelectual del diseño, es su garante, pero desde el realismo: se encarga de que el resultado sea lo más fiel a lo proyectado dentro de las circunstancias y con los medios que se den.
Lo primero lo tenemos en los productos digitales: los sistemas de diseño en el lado del diseñador y la componentización, librerías, etc. en el lado del programador web. Lo segundo, un diseñador asignado a la fase de desarrollo, me parece cada vez más necesario y creo que nadie lo hace.
El rol del Diseñador de Desarrollo, si me permitís el bautizo, tendría dos partes:
La primera sería interiorizar el trabajo de diseño previo, la naturaleza y propósito del negocio y del proyecto, la lógica de todas las funcionalidades y procesos, la consistencia de la solución a lo largo de todas las pantallas y la esencia de todas las armonías, la estética y los elementos comunicacionales, artísticos y demás. En esa parte, el diseñador de desarrollo (DD) habría estado desde el inicio, escuchando y empapándose.
En la segunda parte, el DD acompañaría a los desarrolladores (de front y back) en todo el proceso, explicando, aclarando, corrigiendo diseño cuando surgen cambios, diseñando elementos o pantallas nuevas y —esto es lo más importante— haciendo ajustes cuando por tiempo, coste o circunstancias hay que simplificar la complejidad de diseño en algún punto y facilitar la tarea de desarrollo.
Tengo ganas de hablar de esto con gente que sabe y tiene experiencia, ver si le ven sentido y qué otras ideas se les ocurren. Le he propuesto a Marina que hagamos un curso breve sobre ese tema, sobre cómo tender puentes entre diseño y desarrollo, desde las técnicas (ella sabe de esto) y quizás también desde el diseño de equipos y ahí Jorge y Sergio, a cargo del Programa de Dirección de Producto, tendrán mucho que decirnos.
Se me ocurre que deberíamos llevar a ese curso a arquitectos para que nos expliquen lo bueno y lo malo de sus métodos, quizás también a otras profesiones donde lo ideado y lo producido pueden diferir ¿Cocineros quizás? ¿Alguna otra profesión? ¿Cómo titulamos un curso así?
Me fascina la arqueología que hay en una obra, cuando tras picar asoma lo que había debajo, sea la geología del terreno, las piedras de hace trescientos años o las decisiones de los fontaneros de hace veinte años. Me pregunto si los programadores sienten lo mismo al ver código viejo.