🎲 Introduzione

Amare la semplicità

Tool brutti e complessi. Roadmap articolate e improbabili. Comunicazioni infinite attorno al nulla. La complessità è ovunque e – spesso – è lo standard. È “inclusa nel pacchetto”, perché si è sempre fatto così. Vuoi un semplice strumento di Project Management e trovi Time Tracking, fatturazione, gestione delle ferie e dei permessi... tutto incluso, tutto nel pacchetto.

Questa sovrabbondanza genera confusione. Porta al cosiddetto “overhead”, cioè allontana l’attenzione delle persone da ciò che è più importante: fare bene il proprio lavoro.

Ancora oggi, gran parte della nostra operatività in Moze viene gestita tramite fogli Google. Abbiamo tentato in alcune occasioni di adottare strumenti specializzati, e in molti casi ne siamo usciti più incasinati di prima. Strumenti progettati attorno all’idea di qualcun altro. Adattarli alle proprie esigenze richiede uno sforzo considerevole, non sempre con un beneficio tangibile.

Da tempo abbiamo abbandonato la teoria della massimizzazione, l’idea che di più è meglio. Più strumenti, più persone, più processi di comunicazione... ma a volte, per portare a termine un compito, basta uno scambio veloce a voce o su Slack. Inseguiamo la semplicità in tutto quello che facciamo. Ci chiediamo continuamente: “Questo elemento è veramente essenziale per raggiungere il nostro obiettivo? C’è qualcosa che possiamo semplificare o snellire nel processo o negli strumenti?”.

Questa mentalità ci ha permesso di assistere i nostri clienti in modo più efficace. In passato, i clienti si presentavano con lunghe liste di funzionalità, oppure con idee vaghe e complesse. Noi tendevamo ad assecondare il loro approccio scrivendo, gratuitamente, documenti di specifiche basati su quelle indicazioni. Ma è estremamente difficile stimare preventivamente i dettagli di un progetto complesso. Senza una discussione approfondita, è probabile che diventi un lavoro lungo, tedioso e poco efficace. Iniziando in questo modo, ci siamo trovati molte volte a dover gestire progetti senza fine e a dover gestire relazioni complesse con i clienti.

Oggi non adottiamo più questo approccio. Quando un cliente propone un nuovo progetto, ci concentriamo maggiormente sulla facilitazione di una conversazione approfondita anziché su uno scambio asettico di documentazione. Per farlo, ci chiudiamo in una stanza per alcuni giorni di lavoro con il cliente, affrontando la complessità partendo dal generale (“cosa vi ha portato ad affrontare questo progetto?” e “cosa sperate di ottenere?”) e arrivando al particolare (“definiamo insieme un ipotetico flusso utente”).

In questo modo si rompe il tradizionale schema in cui il cliente chiede e l’agenzia risponde. Invece, si collabora attivamente per comprendere e definire il problema, arrivando a una soluzione condivisa, almeno a livello concettuale. In Moze questa fase, che sintetizza varie metodologie tra cui il Design Sprint di GV e lo User Story Mapping di Jeff Patton, la chiamiamo Co-design Workshop. Indipendentemente dalla terminologia utilizzata, è fondamentale che questa attività venga remunerata. Perché? Perché la retribuzione consente di dedicare l’impegno necessario per valutare adeguatamente un nuovo progetto. È una fase di vera progettazione che precede l’implementazione, una fase di confronto e decisione su “cosa” e “come”, prima di passare al “fare”.

Passare ad un approccio di questo tipo può sembrare sfidante. Nel nostro caso, abbiamo iniziato proponendo ai nostri clienti di svolgere l’analisi preliminare ad un prezzo molto accessibile. Questa scelta si è dimostrata vincente poiché ci ha permesso di acquisire esperienza, perfezionare competenze cruciali di facilitazione e costruire un track record che generasse fiducia nei nuovi clienti. Nel corso degli anni, il nostro processo ha subito variazioni significative, ma il nostro obiettivo principale è rimasto lo stesso: comprendere cosa fare, prima di agire.

Hellotime

Schedule 🤩People and 📖project
in a 🙈simple and ⚡️easy way