Un nuovo progetto porta sempre con sé entusiasmo, aspettative e una certa dose di prudenza. Quando iniziamo a confrontarci con un nuovo team che sta valutando di lavorare con noi, una domanda arriva quasi sempre: qual è il vostro approccio?
La risposta, per noi, non può essere unica. Negli anni abbiamo imparato che molti problemi nei progetti digitali nascono da un errore iniziale: applicare lo stesso metodo a contesti molto diversi. È una delle ragioni per cui i progetti, spesso, non vanno esattamente come previsto. Ci sono progetti che possono essere affrontati in modo lineare, altri che richiedono analisi approfondita, altri ancora in cui la strada emerge solo lavorando per ipotesi e iterazioni.
Per orientarci usiamo il framework Cynefin, un modello decisionale sviluppato da Dave Snowden che aiuta a distinguere i diversi tipi di contesto e a scegliere il metodo più adatto alla situazione reale.
Quando discutiamo un nuovo prodotto digitale, quindi, la prima cosa che cerchiamo di capire non è soltanto cosa bisogna costruire, ma in quale contesto ci stiamo muovendo.
Cynefin identifica cinque domini: semplice, complicato, complesso, caotico e disordinato. Ognuno corrisponde a un contesto diverso e richiede quindi un approccio diverso. Guardare un progetto attraverso questa lente aiuta a scegliere il metodo con maggiore consapevolezza. Vediamo come applichiamo questi domini nel nostro lavoro.
#1 Semplice - Just do it
Il dominio semplice riguarda i progetti in cui il quadro è chiaro fin dall’inizio. I requisiti sono noti, la soluzione è largamente prevedibile e le dipendenze esterne restano contenute. Il lavoro non procede per scoperta, ma per esecuzione.
Succede, ad esempio, con un one pager, un sito di marketing o un brand sprint per una startup quando il posizionamento è già stato compreso bene insieme ai founder. In questi casi si può seguire un piano ordinato, con fasi abbastanza definite e un orizzonte spesso di poche settimane.
Ma attenzione: semplice non significa facile. Il rischio maggiore qui è la sottovalutazione. Senza un’esperienza solida o un processo rigoroso da seguire, è un attimo scambiare un progetto complesso per uno semplice, partendo al buio e finendo dritti contro un muro.
Il diavolo, come sempre, sta nei dettagli. Spesso ciò che sembra lineare nasconde insidie che emergono solo quando si scava sotto la superficie. Per questo, anche quando la strada appare spianata, il nostro compito è andare oltre il brief: continuiamo a chiedere, indagare e mettere in discussione le certezze iniziali.
#2 Complicato - Discovery prima, Delivery poi
Il dominio complicato riguarda i progetti in cui l’obiettivo può anche essere chiaro, ma il percorso per arrivarci richiede analisi, competenza e allineamento.
Succede spesso, per esempio, in un progetto di UX/UI design in cui serve capire bene il dominio di business, raccogliere know-how da stakeholder diversi e chiarire priorità e vincoli prima di progettare. Lo stesso vale per una piattaforma web con integrazioni ERP da analizzare o per un replatforming che richiede di studiare un sistema esistente.
In questi casi, in Moze, non partiamo subito dall’esecuzione. Apriamo il progetto con una fase iniziale di discovery, fatta di workshop e momenti di lavoro strutturati che servono a chiarire obiettivi, requisiti, vincoli e priorità, ma anche — quando necessario — a comprendere bene l’as-is di partenza.
Nel tempo abbiamo definito anche un formato che chiamiamo Co-design Workshop, utile per passare da un concept iniziale a un set di specifiche condivise o a un prototipo navigabile su cui allinearsi.
Solo quando il perimetro è stato definito con sufficiente chiarezza ha senso partire con la fase di implementazione vera e propria, nel design o nello sviluppo. Il punto, qui, è capire cosa fare prima di farlo.
#3 Complesso - Evoluzione continua
Il dominio complesso riguarda i progetti in cui il contesto cambia mentre si lavora. In questi casi provare a definire tutto a priori può essere persino controproducente: rallenta il progetto e porta a costruire piani che diventano obsoleti troppo in fretta.
Succede, per esempio, nello sviluppo di un nuovo prodotto, quando la direzione prende forma mano a mano che si fa customer discovery e si testa la risposta del mercato. Oppure in situazioni con dipendenze esterne, requisiti che possono emergere solo progressivamente, vincoli tecnici o sistemi legacy che si comprendono davvero solo iniziando a intervenire. Qui non si può né eseguire un piano lineare, né fare un’analisi iniziale e poi impegnarsi su un piano rigido.
In questi casi, in Moze, facciamo una discovery iniziale per definire una prima direzione e poi lavoriamo per sprint, come estensione del team del cliente. È un approccio che usiamo sia su prodotti complessi dal lato UX/UI, sia nello sviluppo iterativo e incrementale, quando il software prende forma poco alla volta. Negli anni abbiamo visto che questo modello funziona bene soprattutto nei contesti di innovazione digitale, dove il cambiamento è una costante.
I domini del caotico e del disordine
Il dominio caotico riguarda situazioni in cui non esiste un percorso leggibile a priori e la priorità è intervenire rapidamente per ristabilire controllo. Può emergere in attività di manutenzione straordinaria del software, nella gestione urgente di vulnerabilità o nell’aggiornamento di package e dipendenze. In questi casi il focus non è pianificare bene, ma ridurre il rischio e riportare stabilità.
Il dominio del disordine è invece quello in cui non è ancora chiaro quale sia davvero la natura del problema. È una condizione abbastanza comune all’inizio di un progetto, quando ci sono molte informazioni ma manca ancora una lettura condivisa del contesto. Da qui parte il lavoro di inquadramento: capire in quale dominio ci si trova, per scegliere il metodo più adatto.
Qual è il vostro approccio?
Alla domanda “qual è il vostro approccio?”, quindi, la risposta corretta per noi è sempre: dipende dal contesto. Non tutti i progetti chiedono lo stesso metodo, e cercare di affrontarli tutti allo stesso modo è spesso il modo più rapido per generare attriti, ritardi o aspettative sbagliate.
Usare questa lente aiuta soprattutto a partire con il frame giusto: capire quando ha senso eseguire, quando serve prima analizzare, e quando invece bisogna lavorare per iterazioni accettando che una parte della direzione emerga strada facendo. Non è una garanzia che tutto andrà liscio, naturalmente. Anche il metodo più adatto non elimina del tutto il rischio di problemi o imprevisti.
Quello che può fare, però, è far emergere prima i nodi reali, soprattutto quando esistono criticità più strutturali. Ci è capitato, per esempio, di accompagnare due team di due aziende diverse in una fase di co-design attorno all’idea di una possibile joint venture per un nuovo prodotto digitale. Proprio grazie al lavoro di discovery e facilitazione è emerso con chiarezza che non c’erano i presupposti operativi perché l’iniziativa potesse funzionare davvero. Il progetto, a quel punto, non ha avuto seguito.
Sono casi limite, ma succedono. E anche in situazioni come questa, accorgersi prima di avviare il progetto vero e proprio non è un fallimento: è già un risultato utile. Inquadrare bene il contesto non serve a promettere certezze assolute, ma a prendere decisioni migliori prima che tempo, budget ed energie vengano investiti nella direzione sbagliata.
