Il Metodo MoSCoW

Gestione delle priorità

Gestire un prodotto comporta prendere decisioni continue in contesti complessi e partecipare a vari incontri con interlocutori esterni e interni all’azienda, i cosiddetti stakeholder.

I Product Manager, responsabili della gestione di un prodotto, affrontano tutti i giorni questa sfida, valutando molteplici fattori decisionali, spesso in conflitto tra loro.

Tuttavia, i Product Manager possono combinare uno o più sistemi per aumentare il loro impatto sull’organizzazione, come illustrato in questo e nei prossimi articoli sulla gestione delle priorità.

Questa serie è dedicata all’introduzione delle principali tecniche di prioritizzazione, finalizzate a guidare i risultati (positivi) che si vogliono ottenere con le prossime funzionalità di prodotto.

Le tecniche presentate includono: MoSCoW, Punteggio RICE (e sue varianti), Kano Model e WSJF.

Questo insieme di tecniche costituisce una cassetta degli attrezzi per il Product Manager, che potrà gestire diverse situazioni e definire le azioni da compiere per ottenere i risultati migliori nel suo abituale contesto di lavoro. Applicare queste tecniche può migliorare notevolmente la produttività, aumentare la soddisfazione del cliente e massimizzare il ritorno sugli investimenti.

Il metodo MoSCoW

Il metodo MoSCoW, introdotto da Clegg e Barker nel 1994, prende il nome dall’acronimo formato dalle iniziali di Must have, Should have, Could have e Won’t have, che rappresentano quattro categorie qualitative di priorità.

Questa tecnica di priorizzazione si può utilizzare per allineare gli stakeholder esterni e interni sull’importanza relativa degli outcome di prodotto, con l’obiettivo di ottimizzare il valore derivante dal lavoro del team di sviluppo.

Il metodo MoSCoW trova applicazioni in vari ambiti, ma in genere è particolarmente efficace per gestire le priorità nei limiti di un periodo di tempo definito, il cosiddetto timebox. Ad esempio, nel settore dello sviluppo software, è adatto a guidare le attività all’interno di uno Sprint di Scrum, tipicamente della durata di due settimane.

Must have

Gli elementi classificati come Must have sono considerati critici e imprescindibili per il successo della prossima release di prodotto. La mancanza anche di uno solo Must have è considerata un insuccesso. Tuttavia, con il consenso degli stakeholder, un elemento Must have si può declassare in Should have (vedi sotto).

Questi elementi corrispondono a bisogni non negoziabili e obbligatori; il prodotto, la user story o la feature perderebbero di significato con Must have incompleti o mancanti. Sono tipicamente requisiti di legge, norme di sicurezza o studi di fattibilità della soluzione.

Should have

Gli elementi classificati come Must have sono considerati critici e imprescindibili per il successo della prossima release di prodotto. La mancanza anche di uno solo Must have è considerata un insuccesso. Tuttavia, con il consenso degli stakeholder, un elemento Must have si può declassare in Should have (vedi sotto).

Questi elementi corrispondono a bisogni non negoziabili e obbligatori; il prodotto, la user story o la feature perderebbero di significato con Must have incompleti o mancanti. Sono tipicamente requisiti di legge, norme di sicurezza o studi di fattibilità della soluzione.

Could have

Gli elementi identificati come Could have sono desiderabili, ma non indispensabili, e vengono spesso definiti nice-to-have. Possono migliorare l’esperienza utente o la soddisfazione del cliente a un costo contenuto in un certo timebox. Si tratta di iniziative che si possono sacrificare per lasciare spazio alle altre categorie, e il loro impatto è minore nel caso siano escluse dal rilascio del prodotto. Ad esempio, un elemento Could have potrebbe riguardare la personalizzazione dei colori o altre piccole variazioni all’interfaccia utente.  

Won’t have (this time)

Gli elementi indicati come Won’t have non si possono realizzare in un certo periodo perché sono meno critici, apportano un basso valore aggiunto oppure risultano infattibili per la capacità di lavoro o i vincoli correnti (quali, ad esempio, competenze del team o contingenze economiche). Gli elementi Won’t have vengono scartati o rimandati a un futuro timebox. In termini di allineamento, i team sono consapevoli che tali elementi non devono essere considerati in quel momento specifico e quindi possono mantenere il focus sulle priorità attuali.

Utilizzo del metodo MoSCoW

In un contesto noto, il metodo MoSCoW costituisce una strategia efficace per mitigare il rischio associato ai rilasci del prodotto, con gli elementi Must have che possono pesare fino al 60% del totale. Questa tecnica ha il notevole vantaggio di coinvolgere negli stessi incontri le aree commerciali e tecniche dell’azienda, garantendo così un allineamento generale per prendere decisioni informate e condivise.

Nonostante MoSCoW sia un approccio qualitativo per la sua natura stessa ha il grande vantaggio di essere sintetico, specie in fase di triage delle iniziative. Questa schematicità semplifica il processo decisionale e permette di concentrarsi sui requisiti essenziali di quel contesto aziendale.  

Inoltre, coinvolgendo sempre gli stessi interlocutori, il gruppo di decisori migliora nel tempo, diventando sempre più affidabile nella gestione delle priorità.

Un altro vantaggio si realizza nell’applicazione ex post del metodo per confrontare le iniziative passate. Infatti, una chiara distinzione tra Must have e Should have, supportata da esempi specifici, contribuisce a distinguere ciò che è indispensabile rispetto a ciò che è desiderabile, senza per forza sacrificare tutti o in parte gli elementi Should have (che nella pratica potrebbero valere tra il 20% e il 40% degli elementi).

Infine, MoSCoW suggerisce di documentare eventuali workaround di prodotto, in modo da fornire linee guida pratiche per gestire soluzioni alternative senza perdere di vista le priorità concordate.

Limiti del metodo MoSCoW

Il metodo MoSCoW, per quanto vantaggioso, pone alcune sfide nella gestione di un processo decisionale equilibrato e trasparente delle priorità.

Innanzi tutto, per evitare di valutare solo iniziative Must have, si possono introdurre criteri oggettivi per valutare la differenza tra elementi di pari priorità, e per esempio adottare un sistema a punti per analizzare opzioni identiche.

È importante poi conciliare le opinioni degli stakeholder, specie se possono influire sul processo decisionale per il loro ruolo o prestigio istituzionale. Una retrospettiva sulle classificazioni Must have e Should have può contribuire a ridurre i conflitti futuri e garantire il coinvolgimento di tutte le persone interessate al prodotto.

Infine, l’adozione di un processo strutturato per documentare le decisioni prese riduce le discussioni future e agevola il confronto sugli elementi Won’t have, che spesso tende a dilungarsi inutilmente. In questo modo, si potranno limitare le rinunce o i ritardi di alcune iniziative.

Conclusioni

In sintesi, il metodo MoSCoW, con le categorie Must, Should, Could e Won’t’ have, è uno strumento efficace per gestire le priorità di prodotto in un contesto complesso, ma noto. Si può utilizzare per allineare gli stakeholder, ottimizzare il lavoro e mitigare i rischi dello sviluppo di nuove iniziative. Questa tecnica è chiara, sintetica e veloce se adottata con regolarità dallo stesso gruppo di decisori. Tuttavia, per un utilizzo ideale, potrebbero essere necessari criteri oggettivi e processi strutturati per ricostruire le decisioni passate e conciliare le opinioni degli stakeholder.  

Autore: Maurizio Vaggi