Sobre el Diseñador de Desarrollo
Ayer, en una de las cartas del newsletter De Ulm a Cádiz, donde publico ideas y vivencias que tienen que ver con la creación del Instituto Tramontana, propuse un rol intermedio entre el diseñador y el desarrollador. Lo llamé Diseñador de Desarrollo, haciendo la analogía con el arquitecto de obra clásico, el que supervisa y ajusta, pero no necesariamente proyecta.
Creo que esa figura podría responder al problema eterno de las diferencias (a menudo déficits) entre lo que se define cuando se conceptualiza y diseña y lo que se acaba desarrollando, cuando surgen problemas, limitaciones (de tiempo o tecnológicas) o malas interpretaciones.
El rol del arquitecto de obra lo describí así:
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.
Y mi propuesta para un diseñador de desarrollo la enuncié así:
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.
La idea ha dado que hablar bastante, he recibido unos cuantos mensajes con experiencias y comentarios sobre el tema, tanto por email como en Twitter.
El comentario más generalizado ha sido que no habría que crear un rol específico, que se trata de que la persona de diseño y la de desarrollo hablen más, que haya diálogo y estén ambos involucrados desde el principio. Este hilo de Carlos Hernández ilustra bastante bien algunas de las reacciones:
Carlos apunta en su hilo a algo que no puedo negar. Es obvio que la comunicación es importante y que es bueno que ambos roles sepan de lo que hace el otro. Pero no creo que con buena voluntad se resuelva un problema que es estructural. Trataré de describir unos escenarios muy comunes en proyectos que tienen cierta entidad, para que se entienda la dificultad —a veces imposibilidad— de comunicación entre equipos de diseño y desarrollo:
Diferentes empresas
A menudo la empresa que hace diseño no es la que desarrolla. Esto puede pasar porque el cliente ha elegido a una empresa especializada en diseño y luego el trabajo de desarrollo lo hace internamente. Yo mismo he diseñado y dirigido equipos de diseño para clientes que han trabajado así. En esos casos puedes reservar tiempo para acompañar a desarrollo, pero la realidad es que no tienes facilidad para tener a personas de tu equipo físicamente al lado de otras de otra empresa que trabaja desde su propia oficina.
Diferentes tiempos
A menudo se hace el diseño y no se sabe cuándo se implementará el desarrollo. Cuando se trabaja en modo consultoría, es importante tener a las personas asignadas a proyectos con la mayor antelación posible. Si el diseño se hace entre enero y marzo y el desarrollo se sabe que se hará entre abril y junio por otra empresa distinta, ¿Cómo demonios puedo reservar yo tiempo de alguien que debería estar en esos días en otro proyecto para que acompañe al equipo de desarrollo asistiéndole constantemente?
Diferentes ubicaciones
A lo anterior sumemos cuando el diseño se hace, por ejemplo, en Madrid y el desarrollo en Bilbao o en Argentina. En esos casos, el acompañamiento y la asistencia, en el mejor de los casos, se queda en unas videoconferencias rápidas, a menudo incómodas, para resolver dudas.
Lo cierto es que en muchísimos casos concurren esos tres escenarios. De hecho, cuanto mayor es el proyecto, más probable es que concurran: proyectos con equipos deslocalizados que trabajan de forma asíncrona y hasta en idiomas diferentes. ¿De verdad creemos que la buena voluntad y el espíritu de comunicación van a ser suficientes para asistir a desarrollo cuando se encuentre dificultades con los diseños?
Como en todo, la buena voluntad y la actitud son importantes, pero a medida que los sistemas humanos se vuelven complejos, tenemos que convertir lo deseable en legal, trasladar los buenos hábitos en leyes y normas y asignar tiempo y personas a ello. Por eso, a partir de cierto tamaño, creo que un proyecto debería tener un Diseñador de Desarrollo.
Un par de aclaraciones:
Estoy hablando de la creación de productos digitales desde consultoría, como proveedores a un cliente, no como equipos internos.
Esto tiene sentido para proyectos medios-grandes, con planificaciones relativamente complejas y equipos numerosos, donde se trocea el trabajo. En proyectos sencillos obviamente no aplica.
Que haya un DD no quiere decir que los diseñadores no deban saber de tecnología o que en la fase de concepto inicial no deba haber gente técnica. Ojo, lo aclaro antes de que se me tiren al cuello. Eso me parece una MAG-NI-FI-CA práctica. Pero lo uno no quita a lo otro, porque por mucho que sepan de programación o sistemas los diseñadores, habrá contratiempos, habrá cambios, habrá imprevistos.
En la carta propongo que el Instituto Tramontana hospede un evento, mitad encuentro de debate mitad curso, donde quienes saben de esto puedan aportar sus puntos de vista, puedan enseñar y entre todos podamos reflexionar sobre el tema y quizás hacer cambios en el modo en que trabajamos y proveemos diseño. ¿Qué os parece?
La foto es de una de las obras en las que ha trabajado Jara. Aquí más fotos suyas.