Post in Translation – Progettare come un team: guida pratica alla collaborazione interfunzionale

Riteniamo che la collaborazione interfunzionale acceleri la fornitura di risultati migliori per i nostri utenti. Tuttavia, non è sempre ovvio come dovrebbe essere esattamente. Quali pratiche sono necessarie per il successo del team? Quali valori dovrebbe incarnare il team?

Un articolo di Valerie Roske e Christopher Taylor Edwards

originariamente apparso su thoughtworks.com

E chi siamo? Siamo uno sviluppatore (Valerie) e un designer (Christopher) che amano l’abbinamento interfunzionale. Abbiamo messo in pratica tutto ciò che suggeriamo di seguito in un team distribuito e in un contesto ad alta pressione e sensibile al tempo, in cui non c’era accesso alle capacità di progettazione all’interno della clint organization.

Anche lavorando in tempi di consegna stretti, abbiamo trovato un modo per dare la priorità all’apprendimento e alla sperimentazione. In “Design as a Team Guidebook”, ti mostreremo come puoi farlo anche tu.

Forniremo esempi specifici di come può essere la collaborazione interfunzionale, condividendo alcuni dei valori e dei principi che ci motivano. Ci auguriamo che questo possa servire da ispirazione per i tuoi team e ampliare la tua percezione di come il design possa offrire un valore maggiore durante il processo aziendale.

Dovresti continuare a leggere questo articolo se:

• Sei un designer che cerca di definire l’aspetto dell’agilità del design, dalla strategia all’esecuzione;
• Sei un product manager che ha bisogno di articolare la differenza tra il proprio ruolo e quello di designer;
• Sei un membro del team di consegna (sviluppatore / analista della qualità / project manager / ecc.) E ti chiedi: “Che cos’è il design? Perché o come dovrei partecipare?“;
• Sei un team leader che cerca di capire come costruire la cosa giusta;
• Stai cercando alcuni esempi specifici di come abbattere i silos nello sviluppo del prodotto e fornire rapidamente nuove funzionalità ai tuoi utenti.

Il flusso di lavoro disconnesso

Superare l’inerzia organizzativa è difficile. I silos tra design, business e tecnologia promuovono cicli di feedback più lunghi tra la scoperta e la consegna. Senza una cultura della collaborazione interfunzionale, lottiamo per stare al passo con il ritmo del cambiamento richiesto dalle esigenze aziendali e degli utenti.

Non mancano le metodologie per introdurre approcci incentrati sull’uomo nel tuo sviluppo tecnologico – Lean UX, Agile Experience Design, Balanced Teams, Human-Centered Design, DesignOps e Design Thinking – per citarne alcuni. Oltre a mettere le persone al primo posto, queste strategie sottolineano l’importanza dei risultati rispetto all’output come misure chiave del successo ed evidenziano la collaborazione cross-functional o cross-disciplinary come motore critico per raggiungere tali risultati.

Se ti senti sopraffatto dall’analisi di tutte queste metodologie, non sei il solo. Senza modelli per tradurre la strategia in tattica, potresti trovarti a chiederti se stai facendo le cose per bene. Forse la tua attuale pratica di progettazione assomiglia a questo:

• I product manager raccolgono un elenco di requisiti dagli esperti in materia di business, che poi trasmettono ai progettisti;
• I designer sviluppano modelli ad alta fedeltà in solitudine, senza alcun feedback da parte degli utenti reali. I designer caricano i mockup nelle story card e non li rivisitano mai più;
• I developer utilizzano i prototipi come specifiche perfette per i pixel, rendendo difficile porre le domande giuste senza comprendere il design dell’interazione sottostante e come questo lavoro si inserisce nel percorso dell’utente;
• I quality analist testano i comportamenti dell’applicazione senza comprendere i risultati previsti, ad esempio il modo in cui tali funzionalità risolveranno i problemi degli utenti e supporteranno le esigenze aziendali;
• Nessuno misura se ciò che è stato consegnato ha effettivamente aggiunto valore per gli utenti;

Nello scenario precedente, questi ruoli hanno un’interazione minima tra loro e spesso non fanno parte della stessa squadra. Potrebbero, tuttavia, affermare di lavorare in un ambiente collaborativo. Non hanno completamente torto, poiché il risultato finale deriva da una combinazione di sforzi. Ma questo non è ciò che intendiamo quando parliamo della collaborazione nell’accoppiamento interfunzionale.

Questo flusso di lavoro disconnesso è orientato agli handoff. Gli handoff sono l’antitesi della collaborazione.

Il rapporto tra innovazione ed empatia

La creazione di ottimi prodotti human-centered inizia con la creazione di empatia con i nostri utenti e tra di loro e con l’adattamento rapido a ciò che scopriamo sulle loro esigenze. Possiamo mappare questo punto di vista con le tre lenti dell’innovazione:

• Quali sono le esigenze che stiamo cercando di soddisfare? (La nostra soluzione è preziosa?)
• Come effettuiamo le consegne? (La nostra soluzione è fattibile?)
• Possiamo sostenere il nostro slancio? (La nostra soluzione è fattibile?)

L’empatia è ciò che fa circolare la nostra ricerca e comprensione attraverso le tre lenti. Usiamo la nostra empatia con l’utente per raggiungere una comprensione del valore e della fattibilità. Usiamo l’empatia per creare fiducia reciproca e collaborare meglio.

Confidando l’uno nell’altro attraverso la collaborazione, cerchiamo di comprendere la fattibilità in relazione a ciò che è prezioso e praticabile nel mercato del nostro prodotto. Tutto questo è un lavoro di progettazione. Abbiamo tutti molto da imparare dai nostri utenti e gli uni dagli altri, motivo per cui crediamo nel potere della progettazione come squadra.

Nel nostro approccio, il design è una responsabilità condivisa. Ciò significa creare una comprensione condivisa del percorso dell’utente e lavorare insieme fianco a fianco per sfruttare le diverse abilità e prospettive che ognuno porta con sé.

Il risultato di questo lavoro rappresenta la nostra ipotesi su ciò che è fattibile, visibile e prezioso, che richiede ulteriori test in produzione. Senza questo, i product manager stanno semplicemente indovinando le esigenze degli utenti, i progettisti consegnano le specifiche dell’interfaccia utente senza spiegazioni e gli sviluppatori stanno codificando senza capire.

Una composizione equilibrata del team è fondamentale per un’efficace collaborazione interfunzionale perché sblocca potenziali opportunità di apprendimento che non avremmo considerato altrimenti. Le coppie designer / sviluppatore (come noi!) Tendono a guidare lo slancio di un team costruito in questo modo, poiché il valore che otteniamo da questo particolare match-up è il più evidente, ma ci sono così tante altre possibilità a nostra disposizione.

Cosa potremmo imparare se analisti della qualità e designer si accoppiassero? Responsabili di prodotto e sviluppatori? Progettisti e ingegneri per l’affidabilità del sito? Sviluppatori e personale dell’assistenza clienti?

Quando il design è una pratica di squadra, iniziamo anche a riesaminare le responsabilità dei nostri ruoli e il modo in cui il lavoro di tutti contribuisce a ciò che sappiamo sul percorso dell’utente.

Il nostro approccio: pratiche minime realizzabili

Tradurre questa visione in azione richiede l’allineamento dei comportamenti con i valori e le esigenze del team. Nel nostro team, li abbiamo resi espliciti facendo brainstorming e votando i principi, oltre a redigere uno statuto di squadra. Questo ci ha permesso di chiederci continuamente quali pratiche dovevamo aggiungere o modificare per abilitare la nostra visione e per collaborare attivamente.

Abbiamo riconosciuto che la formazione di nuove abitudini richiede uno sforzo deliberato, quindi abbiamo sempre cercato di pensare a qualsiasi nuova pratica come una “pratica minima realizzabile“. Una pratica minima realizzabile è la cosa più semplice che possiamo fare per ottenere l’apprendimento di cui abbiamo bisogno, con il più piccolo gruppo possibile di partecipanti richiesto.

Abbiamo utilizzato feedback in tempo reale e retrospettive per migliorare le nostre pratiche e per garantire che i loro scopi fossero ancora validi. Nel peggiore dei casi, abbiamo perso da 30 minuti a un’ora di tempo cercando qualcosa che abbiamo prontamente scartato. Nella migliore delle ipotesi, abbiamo imparato qualcosa di prezioso e ripetuto per la prossima volta.

Utilizzando le pratiche minime realizzabili che miravano a risolvere i problemi reali che stavamo affrontando, non abbiamo perso tempo in nuove pratiche inefficaci. Il nostro team è sempre stato pronto a provare diversi esperimenti, perché le attività erano sempre programmate per il tempo e orientate ai risultati.

Esempi di pratiche interfunzionali

Ciò che troverai nella guida Design as Team Guidebook sono oltre 20 pratiche di collaborazione interfunzionale e alcuni dei valori e dei principi che ci hanno motivato. Ci auguriamo che questi esempi ti diano alcune idee su come tradurre la strategia in tattica per la risoluzione dei problemi.

Ecco un paio di esempi di come ci siamo “accoppiati”:

• Design&Tech Debt Audit

La maggior parte dei team ha familiarità con il concetto di debito tecnico, gli altri tengono traccia del debito di progettazione. Il debito di progettazione è l’insieme di problemi di usabilità relativi al fatto che il contenuto sia percepibile, utilizzabile, comprensibile, solido e coerente. Nella migliore delle ipotesi, è una stranezza leggermente irritante dell’interfaccia utente; e nel peggiore dei casi, può impedire attivamente agli utenti di completare i loro obiettivi. L’accumulo di debito di progettazione può erodere la fiducia degli utenti nel sistema, o peggio, in se stessi, per non essere in grado di capire come superare il problema.

Gli sviluppatori del nostro team erano già abbastanza esperti nella gestione del debito tecnico derivante da esperienze precedenti, quindi lo sforzo per introdurre una nuova dimensione in un’abitudine esistente è stato piuttosto basso. Sviluppatori, analisti della qualità e progettisti catturerebbero sia il debito tecnico che il debito di progettazione quando li osservavano e, come gruppo, rivederebbero regolarmente e assegnerebbero priorità agli elementi raccolti in base alla loro comprensione dello sforzo e dell’impatto.

• Esplorazione di soluzioni accoppiate

Come molti team di ThoughtWorks, eravamo abituati all’idea di “accoppiamento” come comprensivo di altri ruoli e attività oltre alla semplice programmazione. Una coppia comune era un designer e uno sviluppatore e l’attività dipendeva da chi guidava l’esplorazione.

Ad esempio, designer e sviluppatori hanno abbozzato insieme per valutare rapidamente le opzioni di progettazione, mettendo in vista la fattibilità tecnica. Sviluppatori e progettisti hanno codificato insieme, convalidati durante l’implementazione e hanno avuto la possibilità di fare compromessi al volo quando i vincoli sono stati scoperti. Questi tipi di esplorazioni hanno aumentato l’empatia tra i membri del team per i punti di vista tecnici e di progettazione e hanno promosso una proprietà condivisa dell’esperienza utente.

Misurare l’impatto

È un esercizio utile valutare continuamente le nostre pratiche rispetto ai nostri valori per decidere quando aggiungere, modificare o persino abbandonare quelle pratiche. Come sappiamo che il nostro modo di lavorare contribuisce direttamente a risultati di successo per i nostri utenti?

Possiamo misurare l’efficacia di pratiche specifiche attraverso retrospettive in tempo reale, ma per valutare le nostre pratiche tecniche e sociali in modo più olistico, dobbiamo guardarle dal punto di vista delle Tre Lenti dell’Innovazione. Il successo del tuo prodotto non dipende solo da come vende e dal suo valore per l’azienda, dipende anche dalla salute tecnica, dalla salute del team e dalla felicità degli utenti. Crediamo che dobbiamo misurare l’impatto su tutte queste variabili.

Fondamentalmente, la nostra capacità di misurare l’impatto si riferisce alla composizione del team e alla legge di Conway. È impossibile districare gli artefatti del nostro lavoro dal modo in cui lo facciamo. Le tre lenti dell’innovazione illustrano bene questo principio: per progettare efficacemente come una squadra, dobbiamo reimmaginare i modelli di comunicazione esistenti all’interno dell’organizzazione e affrontare le disfunzioni socio tecniche che sono barriere per un feedback più rapido.

Conclusioni: concentrarsi sulle pratiche per acquisire metodologie di collaborazione interfunzionali

La strategia senza tattica è impossibile e la tattica senza strategia è miope. Concentrarsi prima sulle pratiche ci aiuta ad acquisire fluidità nelle metodologie dei team interfunzionali.

Progettare in team significa ridurre l’attrito e l’inerzia e pensare a come appare lo sviluppo agile del software oltre il regno degli sviluppatori. È il front-end della consegna continua (continuous delivery).

Può essere sorprendente che alcune delle nostre attività possano essere considerate un atto di design. Il design riguarda visione, intenzione e azione, immaginazione di possibilità e costruzione di un nuovo futuro insieme. Quando adottiamo un approccio incentrato sulle persone, iniziamo a esaminare più da vicino il nostro impatto collettivo sui nostri utenti, sul nostro team e sulla nostra comunità in generale. Questo, in breve, è ciò che significa progettare come una squadra. Ricollegare queste pratiche a principi e valori è ciò che ci aiuta a capire perché sono preziose e ci consente di replicare il successo da un team all’altro.

Va bene se la tua squadra non è pronta per tutto questo in una volta. Ci vuole tempo per crescere e il cambiamento non è facile. Le nostre pratiche sono solo un punto di partenza. Ad esempio, se ti trovi in un ambiente in cui la sperimentazione è accolta dalla paura e dalla resistenza, potresti iniziare con alcune vittorie più piccole e veloci.

Ti incoraggiamo a remixare e inventare il tuo in base ai valori concordati dal tuo team e ai problemi che stai cercando di risolvere. Ciò che conta di più è provare, ascoltare e osservare, imparare cose e continuare a fare progressi.