Equips multidisciplinaris de desenvolupament de producte digital

Introducció

Des de fa anys, l’habitual en el món de la construcció de programari i productes digitals ha estat tenir equips organitzats per gremis. Tanmateix, en els últims temps, hem vist una tendència creixent a treballar organitzats en equips multidisciplinaris.

Això és, veníem d’estructures en què hi havia equips de desenvolupament, de disseny, d’analistes, de QA, de gestió de projectes, de sistemes, de business intelligence, etc. Fins i tot, quan construir programari esdevenia més complicat, podien estar dividits per subgremis encara més especialitzats, per exemple, equips de frontend i backend en el desenvolupament o de research i UI en el disseny.

En molts contextos, aquesta organització per gremis s’ha vist limitada enfront dels equips multidisciplinaris, en què persones amb habilitats i especialitats diferents treballen alineades per assolir un objectiu comú. Gràcies en bona part a la popularització de metodologies iteratives i incrementals, aquesta nova forma d’organització ha resultat més efectiva per adaptar-se a un món tan canviant com el que vivim actualment.

Quins beneficis té treballar en equips multidisciplinaris?

Com que estan alineats a un objectiu comú i tenen les capacitats necessàries per impactar en qualsevol pas del flux de lliurament de valor d’una organització, els equips poden treballar més eficientment i obtenir resultats de manera més efectiva.

Amb flux de lliurament de valor, em refereixo al terme de lean manufacturing: el flux de passos pel qual una iniciativa avança des de la seva conceptualització fins que aconsegueix l’impacte de valor. En cas de creació de productes digitals, seria des de la identificació de l’oportunitat o problema fins que la solució és en mans de les persones usuàries que interactuen i de les quals n’observem l’impacte.

En canvi, quan hi ha diversos equips que participen en el flux de lliurament de valor, succeeixen els anomenats hand-offs o traspassos entre equips. Aquest procés tendeix a ser més problemàtic i ineficient, ja que cada equip pot tenir objectius molt diferents i poden fins i tot entrar en conflicte entre ells.

Els hand-offs acostumen a generar més burocràcia entre equips. En cas d’errors o d’haver de fer ajustos, l’esforç de canviar-los és més gran. Poden generar més temps d’espera, discussions per dirimir on comencen o acaben les responsabilitats de cada equip, que s’intenti anar cap a una solució definitiva des de l’inici, que no hi hagi un ownership clar sobre la iniciativa, etc.

Quan un equip és multidisciplinari i està empoderat, té capacitat de prendre decisions i iterar de manera molt més ràpida.

Com a benefici col·lateral, quan es treballa en un equip multidisciplinari, potencialment, hi haurà més satisfacció laboral per part de les persones que el componen i això, juntament amb la col·laboració entre les persones amb diferents habilitats, fomenta que hi hagi més creativitat posada al servei de l’objectiu comú.

Però hem de tenir en compte que un equip multidisciplinari no és simplement posar un conjunt de persones amb perfils diferents a treballar i esperar que funcioni perfectament per art de màgia. És força possible que en un equip multidisciplinari es repeteixin patrons de l’organització per gremis. Pot ser que dins de l’equip no s’estigui realment alineat i continuï havent-hi hand-offs. En aquests casos, repliquen els mateixos problemes, però a una escala més petita.

Això és un fet que podem i hem de treballar a tres nivells: individualment, en equip i en l’àmbit organitzacional.

En l’àmbit individual

En l’àmbit individual, hauríem d’aprendre els fonaments d’altres rols que participen en la creació de productes digitals. No cal obsessionar-se amb conèixer tots els detalls, però és important conèixer un mínim de la naturalesa de la resta de rols: les motivacions i incentius que solen tenir, les pràctiques utilitzades, ser conscient dels processos i eines que usen en el seu dia a dia, etc. Això ajuda a tenir una relació més empàtica i fluida en el dia a dia amb la resta de les persones de l’equip.

Per exemple, en quines temàtiques s’hauria d’interessar algú de desenvolupament que vulgui col·laborar millor amb els qui dissenyen? Usabilitat, arquitectura de la informació, mètodes de recerca, psicologia del color, accessibilitat, tipografia, disseny d’interacció, prototipat, copywriting, tècniques de disseny centrat en persones usuàries, etc.

I per a algú de disseny que vulgui treballar millor al costat dels qui desenvolupen? Arquitectura de programari, gestió de deute tècnic, testing automàtic i altres pràctiques d’integració i lliurament continu, estàndards web, disseny orientat a components, etc.

Addicionalment, en els últims anys, han aparegut els termes product designer i product engineer o developer. Si aprofundim una mica en aquests termes més enllà d’una qüestió de moda, bàsicament, és involucrar-se i col·laborar amb els rols de product management d’una manera més activa, de manera que tots els rols comparteixin les responsabilitats relacionades amb l’impacte aconseguit per l’equip.

Això significa que cada persona, des de la seva àrea d’especialitat, es va trobant en un punt comú, en què algunes responsabilitats es van difuminant entre tot l’equip de producte. Per arribar a aquest punt, tots els rols han de mirar de capacitar-se en qüestions molt més enllà dels dissenys pixel perfect i el codi net: obtenir una visió més estratègica i treballar amb dades per millorar la presa de decisions.

En el pla d’equip

A més de les bones intencions individuals en què cada persona mira de ser empàtica amb la resta, com a bon grup de persones multidisciplinari, hem d’assemblar-nos com un equip.

És essencial tenir alineament cap a la meta comuna i que sigui específica. Sense voler entrar en diferents metodologies que es poden usar, la consecució o no de la meta, si és possible, hauria d’estar basada en dades quantitatives o qualitatives, i establir una o diverses mètriques que ajudin a conèixer si es va en bon camí cap a ella. No sempre és possible pel context, però tenir algun tipus de dashboard que sigui fàcil d’accedir per part de qualsevol persona de l’equip és ideal i, en cas que no ho sigui, almenys recopilar les dades i observar les mètriques com a equip amb certa recurrència perquè puguem veure si anem per bon camí o hem d’iterar per corregir el rumb.

Encara que no siguin necessàriament totes les persones d’un equip i no exigeixi el mateix grau d’implicació per a tothom en cada activitat, sí que s’haurien de veure implicats els diferents rols en el procés complet des del discovery fins al delivery, i, en alguns contextos, fins i tot en l’estratègia de llançament.

És important que hi hagi representació de l’equip en fase d’anàlisi de problemes o oportunitats que hi ha en l’organització de manera primerenca i en els exercicis de research que es facin. Sigui tenint entrevistes amb stakeholders clau conjuntament; participant tant en anàlisis quantitatives segons dades com en qualitatives fent shadowing; involucrant-se en focus groups o en entrevistes amb persones usuàries, etc.

En idear conjuntament solucions a alt nivell, els diferents rols aporten des de la seva especialitat, mirant de buscar quelcom viable en el pla de negoci; factible de construir tècnicament; i desitjable per part de clients o persones usuàries. Per a això, podem fer experiments previs per aprendre sobre diferents aspectes sobre els quals volem reduir incertesa: proves de concepte o prototips tècnics, tests qualitatius amb persones usuàries, tests A/B quantitatius, etc. Protegint així la inversió i amplificant els aprenentatges.

La comunicació entre les persones és el més complicat en la construcció de programari.

Així que, a més de mirar de tenir una comunicació activa, s’ha de treballar un llenguatge ubic dins del context del domini del producte en qüestió, tant dins de l’equip com amb la resta d’stakeholders. Així, hauríem d’evitar utilitzar termes diferents o falsament específics tant en converses com en la diferent documentació escrita, això inclou tant els artefactes de disseny d’UI com el mateix codi font. Addicionalment, podem anar construint un glossari perquè aquest llenguatge es vagi fent més explícit.

Específicament per millorar la comunicació i col·laboració entre els rols de disseny i desenvolupament, podem utilitzar diferents pràctiques.

Per exemple, invertir esforç a crear i mantenir un design system que ajudi a tenir més consistència de producte tant visual com d’interacció. Aquests fan que els equips que els usin puguin ser més eficients. Aquests no han de reinventar la roda i faciliten la comunicació dins del mateix equip, ja que al voltant del design system, el normal és tenir un UI Kit per a disseny i llibreries de components per a desenvolupament.

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

Podem complementar-ho amb l’ús de design tokens, que són els àtoms sobre els quals es construeix un design system: colors, tipografies, iconografia, espaiat, etc., amb una nomenclatura que els dona entitat a partir del seu ús. D’aquesta manera, es facilita la consistència i manteniment dels dissenys visuals, i es poden implementar mecanismes per sincronitzar UI Kit i les llibreries de components.

Una altra manera de facilitar la col·laboració per escurçar el cicle de feedback el màxim possible és usar pràctiques emmarcades en el que s’ha començat a popularitzar sota l’etiqueta The Hot Potato Process en alguns cercles:

• Fer pair-design al costat de rols de desenvolupament, ja sigui esbossant en paper fins amb una eina de disseny sobre una UI d’alta fidelitat. La idea darrere és que es tinguin en compte la factibilitat i la desitjabilitat, assumint de manera primerenca trade-offs d’un costat o l’altre, si cal.

• Revisions freqüents d’avanços en el disseny UI per part de desenvolupament, sigui síncronament o asíncronament. Moltes vegades es comet l’error de voler tenir dissenys d’UI molt tancats i complets, per la qual cosa qualsevol canvi resulta en un esforç més gran i genera fricció entre rols.

• Revisions freqüents del producte per part de disseny. Tal com es va construint el software i després d’assegurar que funcionalment és correcte, amb tests automàtics i manuals per part dels rols de desenvolupament, els dissenyadors revisen que la implementació de la UI correspon a allò acordat en el disseny UI d’alta fidelitat. Tot i que encara no estan molt popularitzades, han començat a emergir eines per automatitzar tests visuals. En aquests casos, aquestes revisions seran més lleugeres o amb una naturalesa més exploratòria.

«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» (Donen Mall, The Hot Potato Process).

Tot això hauria d’estar acompanyat sempre amb un esperit de millora contínua, millora que de vegades pot tenir a veure amb individualitats, però normalment l’hauríem de veure amb el prisma de ser un equip multidisciplinari.

Una pràctica poderosa per a això és fer retrospectives d’equip recurrents. Si treballem amb una metodologia basada en iteracions, ens podem reservar tenir sempre una sessió per iteració, o tenir una sessió recurrent agendada cada poques setmanes si usem una metodologia sense iteracions. L’important és tenir un moment de reflexió conjunta i que es pugui sortir amb una sèrie d’accions per millorar com a equip, accions a les quals es donarà seguiment en retrospectives futures.

Una altra pràctica similar, però que es diferencia a no tenir una naturalesa recurrent, són els postmortems. Aquests es donen quan ocorre un esdeveniment especial al voltant del qual volem fer una anàlisi en profunditat de què va ocórrer, què es va fer bé per valorar-ho i no tan bé per buscar accions de millora. Els postmortems poden tenir un origen d’alguna mena d’incident negatiu que ha afectat l’equip, com alguna mena d’incident que ha tingut un impacte negatiu en els nostres clients, o simplement que es vulgui observar què es podria haver fet millor al voltant d’una iniciativa o projecte que hem dut a terme com a equip.

Quan posem en marxa qualsevol d’aquestes pràctiques, hauríem de mirar que resultin espais psicològicament segurs per a les persones que hi participen, intentant evitar culpabilitzar i tractar-ho de manera més sistèmica. En acabar, hauríem d’obtenir accions concretes i persones responsables en empènyer aquestes accions. És una bona pràctica que quedin documentades per escrit, això ajuda a fer més explícites les accions, ens permet tenir un històric de cara al futur i ajuda a la transparència tant dins de l’equip com cap a fora si ho deixem accessible per a la resta de l’organització.

En el pla organitzacional

Per poder tenir equips multidisciplinaris alineats, els responsables pel que fa a una organització haurien de proveir d’una visió i missió perquè sigui compartida per tota ella. Al costat d’això, haurien d’estar definits l’estratègia i els objectius d’alt nivell. Idealment, aquests últims haurien d’estar secundats per dades i ser fàcils d’accedir per qualsevol persona que formi part de l’organització.

S’hauria d’establir una estructura d’equips tenint en compte la càrrega cognitiva i l’estratègia de l’organització. Així, cada equip hauria de tenir un àmbit d’actuació, amb uns objectius definits que serveixin per establir la meta compartida per l’equip. Intentant equilibrar això amb evitar sitges de coneixement i excés de visió de túnel per part dels equips, a més de mirar de tenir persones amb habilitats necessàries per arribar a bon port, sigui a través de contractacions o capacitant a través de formacions o mentories.

En aquesta estructuració d’equips, hi pot haver tipologies d’equips més especialistes o transversals, sense estar impactant directament en el flux de lliurament de valor. De fet, en organitzacions de certa escala acostumen a ser força necessaris. L’objectiu d’aquests pot ser habilitar d’alguna forma als equips multidisciplinaris, ajudant-los temporalment o formant-los; o bé facilitar el seu treball establint una plataforma en forma de processos, documentació o eines que redueixin la càrrega cognitiva i friccions en el flux de lliurament de valor que poden tenir els equips multidisciplinaris.

La millora contínua també s’ha de donar en l’estructura organitzacional, però els qui són responsables de l’organització han de dotar de certa estabilitat i continuïtat l’estructuració d’equips ajudant al fet que s’assenteixin, ja que les persones que treballen en un grup necessiten un rodatge per convertir-se en un equip, i es requereix un temps per observar l’impacte que obtenen.

Conclusió

En el món de creació de projectes o productes digitals, els equips multidisciplinaris continuaran sent tendència per la seva millor adaptació a l’actual entorn canviant. Perquè aquests funcionin bé, hem de tractar de treballar-los personalment, amb la resta de l’equip i en el pla organitzacional.

I, en essència, en qualsevol dels nivells, hem de buscar tres factors:

• Mirar que les persones que formin l’equip estiguin alineades cap a una meta comuna. I també que la seva meta estigui dins dels objectius de l’organització.

• Mirar que el conjunt de capacitats individuals faci viable aconseguir aquesta meta, o que almenys puguin arribar a capacitar-se per fer-ho.

• Mirar que sempre hi hagi respecte, i aconseguir que hi hagi empatia entre les persones de l’equip i de la resta de l’organització amb què s’interactuï.

Sí, factors infinitament més fàcils de verbalitzar que d’aconseguir.

Referències

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ínia]. Disponible a: https://www.producttalk.org/2024/06/product-trios/

SUTILO, Abel (2018). «Diseñadores desarrolladores y viceversa». Slideshare [en línia]. Disponible a: 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ínia]. Disponible a: https://www.youtube.com/watch?v=sGJSUfQuQXg

KHOLMATOVA, Alla (s.d.). «Meet “Design Systems”, A New Smashing Book». Smashing Mazazine [en línia]. Disponible a: 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ínia]. Disponible a: https://www.uifrommars.com/design-tokens-que-son-ventajas/

MALL, Dan (2019). «The Hot Potato Process». Danmall.com [en línia]. Disponible a: 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ínia]. Disponible a: https://teamtopologies.com/book

Cita recomanada: LATORRE, Dani. Equips multidisciplinaris de desenvolupament de producte digital. Mosaic [en línia], gener 2025, no. 202. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n202.2410