Equipos multidisciplinares de desarrollo de producto digital

Introducción

Desde hace años, lo habitual en el mundo de la construcción de software y productos digitales ha sido tener equipos organizados por gremios. Sin embargo, en los últimos tiempos, hemos ido viendo una creciente tendencia a trabajar organizados en equipos multidisciplinares.

Esto es, veníamos de estructuras en las que había equipos de desarrollo, de diseño, de analistas, de QA, de gestión de proyectos, de sistemas, de business intelligence, etc. Incluso, mientras construir software se volvía más complicado, podían estar divididos por subgremios todavía más especializados, por ejemplo, equipos de frontend y backend en el desarrollo o de research y UI en el diseño.

En muchos contextos, esta organización por gremios se ha visto limitada frente a los equipos multidisciplinares, en los que personas con habilidades y especialidades diferentes trabajan alineadas para conseguir un objetivo común. Gracias en buena parte a la popularización de metodologías iterativas e incrementales, esta nueva forma de organización ha resultado más efectiva para adaptarse a un mundo tan cambiante como el que vivimos actualmente.

¿Qué beneficios tiene trabajar en equipos multidisciplinares?

Al estar alineados a un objetivo común y tener las capacidades necesarias para impactar en cualquier paso del flujo de entrega de valor de una organización, los equipos pueden trabajar más eficientemente y obtener resultados de forma más efectiva.

Con flujo de entrega de valor, me refiero al término lean manufacturing: el flujo de pasos por el que una iniciativa avanza desde su conceptualización hasta que consigue el impacto de valor. En caso de creación de productos digitales, sería desde la identificación de la oportunidad o problema hasta que la solución está en manos de las personas usuarias que interactúan y observamos su impacto.

En cambio, cuando hay varios equipos que participan en el flujo de entrega de valor, suceden los llamados hand-offs o traspasos entre equipos. Este proceso tiende a ser más problemático e ineficiente, ya que cada equipo puede tener objetivos muy diferentes y pueden incluso entrar en conflicto entre ellos.

Los hand-offs suelen generar más burocracia entre equipos. En caso de errores o de tener que hacer ajustes, el esfuerzo de cambiarlo es mayor. Pueden generar mayores tiempos de espera, discusiones por dirimir dónde empiezan o acaban las responsabilidades de cada equipo, que se intente ir hacia una solución definitiva desde el inicio, que no haya un ownership claro sobre la iniciativa, etc.

Cuando un equipo es multidisciplinar y está empoderado, tiene capacidad de tomar decisiones e iterar de forma mucho más rápida.

Como beneficio colateral, cuando se trabaja en un equipo multidisciplinar, potencialmente, habrá mayor satisfacción laboral por parte de las personas que lo componen y eso, junto con la colaboración entre las personas con distintas habilidades, fomenta que haya más creatividad puesta al servicio del objetivo común.

Pero debemos tener en cuenta que un equipo multidisciplinar no es simplemente poner a un conjunto de personas con perfiles diferentes a trabajar y esperar que funcione perfectamente por arte de magia. Es bastante posible que en un equipo multidisciplinar se repitan patrones de la organización por gremios. Puede que dentro del equipo no se esté realmente alineado y siga habiendo hand-offs. En esos casos replican los mismos problemas, pero a menor escala.

Esto es algo que podemos y debemos trabajar a tres niveles: individualmente, en equipo y a nivel organizacional.

A nivel individual

A nivel individual, deberíamos aprender los fundamentos de otros roles que participan en la creación de productos digitales. No es necesario obsesionarse con conocer todos los detalles, pero es importante conocer un mínimo de la naturaleza del resto de roles: las motivaciones e incentivos que suelen tener, las prácticas utilizadas, ser consciente de los procesos y herramientas que usan en su día a día, etc. Esto ayuda a tener una relación más empática y fluida en el día a día con el resto de las personas del equipo.

Por ejemplo, ¿en qué temáticas debería interesarse alguien de desarrollo que quiera colaborar mejor con quienes diseñan? Usabilidad, arquitectura de la información, métodos de investigación, psicología del color, accesibilidad, tipografía, diseño de interacción, prototipado, copywriting, técnicas de diseño centrado en personas usuarias, etc.

¿Y para alguien de diseño que quiera trabajar mejor junto a quiénes desarrollan? Arquitectura de software, gestión de deuda técnica, testing automático y otras prácticas de integración y entrega continua, estándares web, diseño orientado a componentes, etc.

Adicionalmente, en los últimos años, han aparecido los términos product designer y product engineer o developer. Si ahondamos un poco en estos términos más allá de una cuestión de moda, básicamente, es involucrarse y colaborar con los roles de product management de una forma más activa, compartiendo todos los roles las responsabilidades relacionadas con el impacto conseguido por el equipo.

Esto significa que cada persona, desde su área de especialidad, se va encontrando en un punto común, en el que algunas responsabilidades se van difuminando entre todo el equipo de producto. Para llegar a ese punto, todos los roles deben tratar de ir capacitándose en cuestiones mucho más allá de los diseños pixel perfect y el código limpio: obtener una visión más estratégica y trabajar con datos para mejorar la toma de decisiones.

A nivel de equipo

Además de las buenas intenciones individuales en las que cada persona trata de ser empática con el resto, como buen grupo de personas multidisciplinar, debemos ensamblarnos como un equipo.

Es esencial tener alineamiento hacia la meta común y que esta sea específica. Sin querer entrar en distintas metodologías que pueden usarse, la consecución o no de la meta, de ser posible, debería estar basada en datos cuantitativos o cualitativos, estableciendo una o varias métricas que ayuden a conocer si se va en buen camino hacia ella. No siempre es posible por el contexto, pero tener algún tipo de dashboard que sea fácil de acceder por parte de cualquiera del equipo es ideal y, en caso de que no lo sea, al menos recopilar los datos y observar las métricas como equipo con cierta recurrencia para que podamos ver si vamos por buen camino o debemos iterar para corregir el rumbo.

Aunque no sean necesariamente todas las personas de un equipo y no exija el mismo grado de implicación para todo el mundo en cada actividad, sí que deberían verse implicados los distintos roles en el proceso completo desde el discovery hasta el delivery, y, en algunos contextos, incluso en la estrategia de lanzamiento.

Es importante que haya representación del equipo en fase de análisis de problemas u oportunidades que hay en la organización de forma temprana y en los ejercicios de research que se hagan. Ya sea teniendo entrevistas con stakeholders clave conjuntamente; participando tanto en análisis cuantitativos según datos como en cualitativos haciendo shadowing; involucrándose en focus groups o en entrevistas con personas usuarias, etc.

Al idear conjuntamente soluciones a alto nivel, los distintos roles aportan desde su especialidad, tratando de buscar algo que sea viable a nivel de negocio; factible de construir a nivel técnico; y deseable por parte de clientes o personas usuarias. Para ello podemos hacer experimentos previos para aprender sobre distintos aspectos sobre los que queremos reducir incertidumbre: pruebas de concepto o prototipos técnicos, test cualitativos con personas usuarias, test A/B cuantitativos, etc. Protegiendo así la inversión y amplificando los aprendizajes.

La comunicación entre las personas es lo más complicado en la construcción de software.

Así que, además de tratar de tener una comunicación activa, se debe trabajar un lenguaje ubicuo dentro del contexto del dominio del producto en cuestión, tanto dentro del equipo como con el resto de stakeholders. Así que deberíamos evitar utilizar términos diferentes o falsamente específicos tanto en conversaciones como en la diferente documentación escrita, esto incluye tanto los artefactos de diseño de UI como el propio código fuente. Adicionalmente, podemos ir construyendo un glosario para que este lenguaje se vaya haciendo más explícito.

Específicamente para mejorar la comunicación y colaboración entre los roles de diseño y desarrollo, podemos utilizar diferentes prácticas.

Por ejemplo, invertir esfuerzo en crear y mantener un design system que ayude a tener mayor consistencia de producto tanto visual como de interacción. Estos hacen que los equipos que los usen puedan ser más eficientes al no tener que reinventar la rueda y facilitan la comunicación dentro del propio equipo, ya que alrededor del design system, lo normal es tener un UI Kit para diseño y librerías de componentes para desarrollo.

«A set of connected patterns and shared practices, coherently organized to serve the purposes of a digital product» (Alla Kholmatova, Design Systems).

Podemos complementarlo con el uso de design tokens, que vendrían a ser los átomos sobre los que se construye un design system: colores, tipografías, iconografía, espaciado, etc., con una nomenclatura que les da entidad a partir de su uso. De esta manera, se facilita la consistencia y mantenibilidad de los diseños visuales, y se pueden implementar mecanismos para sincronizar UI Kit y las librerías de componentes.

Otra forma de facilitar la colaboración para acortar el ciclo de feedback lo máximo posible es usar prácticas enmarcadas en lo que se ha empezado a popularizar bajo la etiqueta The Hot Potato Process en algunos círculos:

• Hacer pair-design junto a roles de desarrollo, ya sea bocetando en papel hasta con una herramienta de diseño sobre una UI de alta fidelidad. La idea detrás es que se tengan en cuenta la factibilidad y la deseabilidad, asumiendo de forma temprana trade-offs de uno u otro lado, de ser necesario.

• Revisiones frecuentes de avances en el diseño UI por parte de desarrollo, ya sea síncrona o asíncronamente. Muchas veces se cae en el error de querer tener diseños de UI muy cerrados y completos, por lo que cualquier cambio resulta en un mayor esfuerzo y genera fricción entre roles.

• Revisiones frecuentes del producto por parte de diseño. Tal como se va construyendo el software y tras asegurar que funcionalmente es correcto, con test automáticos y manuales por parte de los roles de desarrollo, los diseñadores revisan que la implementación de la UI corresponde a lo acordado en el diseño UI de alta fidelidad. Aunque aún no están muy popularizadas, han empezado a emerger herramientas para automatizar test visuales. En esos casos, estas revisiones serán más ligeras o con una naturaleza más exploratoria.

«I’ve seen designers and developers often fall victim to is believing that handoff goes one way. Designers hand off comps to developers and think their work is done. That puts a lot of pressure on the designer to get everything perfect in one pass» (Dan Mall, The Hot Potato Process).

Todo esto, debería estar acompañado siempre con un espíritu de mejora continua, mejora que en ocasiones puede tener que ver con individualidades, pero normalmente la deberíamos ver con el prisma de ser un equipo multidisciplinar.

Una práctica poderosa para ello es hacer retrospectivas de equipo recurrentes. Si trabajamos con una metodología basada en iteraciones, podemos reservarnos tener siempre una sesión por iteración, o tener una sesión recurrente agendada cada pocas semanas si usamos una metodología sin iteraciones. Lo importante es tener un momento de reflexión conjunta y que se pueda salir con una serie de acciones para mejorar como equipo, acciones a las que se irá dando seguimiento en futuras retrospectivas.

Otra práctica similar, pero que se diferencia en no tener una naturaleza recurrente son los postmortems. Estos se dan cuando ocurre un evento especial alrededor del cual queremos hacer un análisis en profundidad de qué ocurrió, qué se hizo bien para ponerlo en valor y no tan bien para buscar acciones de mejora. Los postmortems pueden tener un origen de algún tipo de situación negativa que ha afectado al equipo, como algún tipo de incidente que ha tenido un impacto negativo en nuestros clientes, o simplemente que se quiera observar qué se podría haber hecho mejor alrededor de una iniciativa o proyecto que hemos llevado a cabo como equipo.

Cuando ponemos en marcha cualquiera de estas prácticas deberíamos tratar de que resulten espacios psicológicamente seguros para las personas que participan, intentando evitar culpabilizar y tratarlo de manera más sistémica. Al terminar, deberíamos obtener acciones concretas y personas responsables al empujar dichas acciones. Es una buena práctica que queden documentadas por escrito, esto ayuda a hacer más explícitas las acciones, nos permite tener un histórico de cara al futuro y ayuda a la transparencia tanto dentro del equipo como hacia fuera si lo dejamos accesible para el resto de la organización.

A nivel organizacional

Para poder tener equipos multidisciplinares alineados, los responsables a nivel de una organización deberían proveer de una visión y misión para que sea compartida por toda ella. Junto a ello, deberían estar definidos la estrategia y los objetivos de alto nivel. Idealmente, estos últimos deberían estar apoyados por datos y ser fáciles de acceder por cualquier persona que forme parte de la organización.

Se debería establecer una estructura de equipos teniendo en cuenta la carga cognitiva y la estrategia de la organización. Así, cada equipo debería tener un ámbito de actuación, con unos objetivos definidos que sirvan para establecer la meta compartida por el equipo. Intentando equilibrar eso con evitar silos de conocimiento y exceso de visión de túnel por parte de los equipos, además de tratar de tener personas con habilidades necesarias para llegar a buen puerto, ya sea a través de contrataciones o capacitando a través de formaciones o mentorías.

En esta estructuración de equipos, pueden existir tipologías de equipos más especialistas o transversales, sin estar impactando directamente en el flujo de entrega de valor. De hecho, en organizaciones de cierta escala suelen ser bastante necesarios. El objetivo de estos puede ser habilitar de alguna forma a los equipos multidisciplinares, ayudándoles temporalmente o formándoles; o bien facilitar su trabajo estableciendo una plataforma en forma de procesos, documentación o herramientas que reduzcan la carga cognitiva y fricciones en el flujo de entrega de valor que pueden tener los equipos multidisciplinares.

La mejora continua también debe darse en la estructura organizacional, pero quienes son responsables de la organización deben dotar de cierta estabilidad y continuidad a la estructuración de equipos ayudando a que se asienten, ya que las personas que trabajan en un grupo necesitan un rodaje para convertirse en un equipo, y se requiere de un tiempo para observar el impacto que obtienen.

Conclusión

En el mundo de creación de proyectos o productos digitales, los equipos multidisciplinares van a seguir siendo tendencia por su mejor adaptación al actual entorno cambiante. Para que estos funcionen bien, debemos tratar de trabajarlos a nivel personal, con el resto del equipo y a nivel organizacional.

Y, en esencia, en cualquiera de los niveles, debemos buscar tres factores:

• Tratar de que las personas que formen el equipo estén alineadas hacia una meta común. Así como que su meta esté dentro de los objetivos de la organización.

• Tratar de que el conjunto de capacidades individuales haga viable alcanzar esa meta, o que al menos puedan llegar a capacitarse para hacerlo.

• Tratar de que siempre haya respeto, y de conseguir que exista empatía entre las personas del equipo y del resto de la organización con las que se interactúe.

Sí, factores infinitamente más fáciles de verbalizar que de conseguir.

Referencias

POPPENDIECK, Mary; POPPENDIECK, Tom (2013). The Lean Mindset: Ask the Right Questions. O’Reilly.

TORRES, Teresa (2024). «Product Trios: What They Are, Why They Matter, andHow to Get Started». Product talk [en línea]. Disponible en: https://www.producttalk.org/2024/06/product-trios/

SUTILO, Abel (2018). «Diseñadores desarrolladores y viceversa». Slideshare [en línea]. Disponible en: https://es.slideshare.net/slideshow/disenadores-desarrolladores-y-viceversa/104855167

ANSIO, Carmen; BARRIOS, María (s.d.). «Desarrollo y diseño: todas a unafuenteovejuna». YouTube [en línea]. Disponible en: https://www.youtube.com/watch?v=sGJSUfQuQXg

KHOLMATOVA, Alla (s.d.). «Meet “Design Systems”, A New Smashing Book». Smashing Mazazine [en línea]. Disponible en: https://www.smashingmagazine.com/design-systems-book/

BUSQUETS, Cris (s.d.). «Design Tokens: qué son, ventajas y cómo diseñarlos eimplementarlos». Ui from mars [en línea]. Disponible en: https://www.uifrommars.com/design-tokens-que-son-ventajas/

MALL, Dan (2019). «The Hot Potato Process». Danmall.com [en línea]. Disponible en: https://danmall.com/posts/hot-potato-process/

PAIS, Manuel; SKELTON, Matthew (2019). «Team Topologies: organizing businessand technology teams for fast flow». Team topologies [en línea]. Disponible en: https://teamtopologies.com/book

Cita recomendada: LATORRE, Dani. Equipos multidisciplinares de desarrollo de producto digital. Mosaic [en línea], enero 2025, no. 202. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n202.2410