Metodo MoSCoW: Come trarre il meglio dalla prioritizzazione

La prioritizzazione ha giocato un ruolo significativo nel successo di molte app ricche di funzionalità come Slack e GitLab. Inizialmente, offrivano un insieme limitato di funzionalità essenziali per i loro utenti. Con il tempo, questo set è stato integrato con altre caratteristiche. Railsware condividerà il proprio stile di prioritizzazione e mostrerà come usiamo il metodo MoSCoW per portare a termine lunghe liste di compiti.

Perché avete bisogno della prioritizzazione?

Di regola, la routine quotidiana include un mucchio di compiti. Idealmente, avrete abbastanza tempo ed energia per coprirli tutti – ma potrebbe accadere che il numero di compiti sia immenso e le risorse disponibili non siano in abbondanza. È qui che entra in gioco la prioritizzazione.

Questo termine denota un processo per filtrare ciò che si deve fare in ordine di importanza o rilevanza. Per esempio, se state costruendo una casa, non è probabile che iniziate con il tetto o le pareti fino a quando le fondamenta non sono state fatte. Naturalmente, le cose sono molto più complicate nel settore dello sviluppo web, e questo esempio non può rivelare l’intero valore della definizione delle priorità.

Progetti complessi e numerose startup fanno uso di tecniche avanzate di prioritizzazione. Queste di solito consistono in quadri noti per requisiti specifici o regole che migliorano il processo decisionale. Il successo nella prioritizzazione è spesso determina il successo dell’azienda stessa. Rimanere intrappolati nei compiti in sospeso e incompiuti è una strada dritta verso il fallimento. Ecco perché le aziende prestano particolare attenzione a quali metodi di prioritizzazione utilizzare. Ce ne sono diversi, ma tutti hanno alcune caratteristiche comuni come l’orientamento verso gli input (interni o esterni) e gli strumenti quantitativi o qualitativi.

A proposito, stiamo assumendo. Controlla le nostre offerte di lavoro.

Orientamento esterno significa che è necessario coinvolgere le parti interessate al di fuori del team di sviluppo per stabilire le priorità, mentre i metodi orientati internamente possono essere eseguiti puramente in-house. I metodi quantitativi comportano una maggiore attenzione alle metriche numeriche nella definizione delle priorità, mentre quelli qualitativi si basano maggiormente su opinioni di esperti, votazioni, classificazioni. In considerazione di ciò, sono tradizionalmente divisi nelle seguenti categorie:

Qui potete leggere in dettaglio le diverse tecniche di prioritizzazione Agile.

Railsware preferisce una tecnica sviluppata da Dai Clegg nel lontano 1994. Inizialmente si chiamava MSCW, ma furono aggiunte due O per migliorare la pronunciabilità. Questo lo fece anche suonare come la capitale della Russia. Vediamo come funziona.

Che cos’è MoSCoW?

Per capire il succo del metodo MoSCoW, dobbiamo guardare alla sua origine – metodo di sviluppo dinamico dei sistemi (DSDM). Si tratta di una struttura per la gestione di progetti Agile creata su misura dai professionisti con l’obiettivo di migliorare la qualità nei processi RAD (rapid app development). Un segno distintivo dei progetti DSDM è la qualità, i costi e il tempo rigorosamente determinati in una fase iniziale. In vista di questo, tutti i compiti del progetto devono essere assegnati in base all’importanza. La necessità di gestire le priorità ha innescato l’invenzione di un meccanismo specializzato di prioritizzazione.

Questo meccanismo è stato implementato tramite MoSCoW – una soluzione semplice ma potente per impostare le priorità sia con che senza timebox. Tuttavia, mostra una migliore efficienza se si ha una certa scadenza per un compito, una caratteristica, una sotto caratteristica, una funzionalità, ecc. Il framework è applicabile a tutti i livelli di prioritizzazione del progetto dall’alto al basso, così come a tutte le funzioni e le aree di interesse.

L’abbreviazione MoSCoW (eccetto le lettere vocali) è scolpita con le prime lettere delle categorie di priorità con cui lavora. Queste sono Must-haves, Should-haves, Could-haves e Won’t-haves. Ed è così che puoi definire quale compito cade in quale categoria.

Regole di priorità

Queste regole o requisiti stimano l’importanza di ogni compito/processo/caratteristica/ecc. Ogni azienda o team di lavoro usa il proprio approccio per fissare i requisiti, ma, in generale, non si differenziano molto e sono così.

Must-haves

Questi sono i requisiti di massima priorità, che formano la base della pipeline principale. Evitarli significa bloccare l’intero progetto o ulteriori attività. Come regola, l’avvio del prodotto dipende interamente dalla definizione dei must-have, usando indicatori come “necessario per il lancio”, “necessario per la sicurezza”, “necessario per la validazione”, “necessario per fornire una soluzione fattibile”, ecc.

• Possiamo andare avanti con il progetto se questo compito non viene svolto? – se NO, è MUST

Should-haves

Questo tipo di requisito è di priorità secondaria. Gli “Should-haves” non influenzano il lancio e, tradizionalmente, sono considerati importanti ma non cruciali. Differiscono dai must-have per la disponibilità di un workaround. Quindi, il fallimento di un compito “should-have” è improbabile che causi il fallimento dell’intero progetto. Se stai costruendo un prodotto, sarà ancora utilizzabile anche se questi requisiti non sono soddisfatti.

• Andremo avanti con il progetto se questo compito viene fatto un po’ più tardi? – se SI, è DOVUTO

Potrebbe-essere

Il prossimo requisito è meno importante dei due precedenti ma comunque desiderato. Se confrontiamo i could-have con i should-have, il primo è definito da un minor grado di effetto negativo se omesso. Tradizionalmente, i requisiti prioritari di terzo livello nel quadro Agile MoSCoW sono realizzati se un progetto non è molto vincolato nel tempo. Nell’ambito dello sviluppo del prodotto, possiamo chiamarli tweaks a basso costo.

• Possiamo sacrificare questo compito fino alla scadenza? – se SI, è COULD

Won’t-have

È anche possibile incontrare questo tipo di requisiti sotto il nome di would-have o wish-to-have, ma queste varianti non sono riconosciute dalla Wiki. Tuttavia, indipendentemente dal nome scelto, questi requisiti definiscono la priorità più bassa per i compiti che non sono fattibili da implementare con un particolare budget e scadenza. Won’t-have non significa un rifiuto completo di qualcosa. Prevede la reintroduzione in condizioni favorevoli in futuro.

• Si può tornare a farlo quando le cose vanno meglio? – se SI, è WON’T

Come si usa

Tutto sembra semplice in teoria, ma lo è in pratica? Verifichiamo come funziona un’analisi MoSCoW di prioritizzazione delle funzionalità attraverso l’esempio di una normale applicazione web. Come esempio, useremo funzioni di base prese da uno dei prodotti Railsware:

• Un utente può iscriversi
• Un utente può effettuare il login
• Un utente può reimpostare la password
• Un utente può scegliere il sistema di fatturazione
• Un utente può cancellare l’account
• Un utente può aprire una pagina di time-pagina di monitoraggio del tempo
• L’utente può scegliere le opzioni di monitoraggio del tempo
• L’utente può installare una versione mobile dell’app
• L’utente può scegliere il tema visivo dell’app

In base a particolari esigenze di budget e tempo, possiamo individuare le caratteristiche più fondamentali da implementare nel prodotto minimo realizzabile. Dopo l’analisi delle priorità, abbiamo le seguenti:

• Un utente DEVE iscriversi
• Un utente DEVE fare il login
• Un utente DEVE reimpostare la password
• Un utente DEVE aprire una pagina di time-tracking

I compiti con la massima priorità sono seguiti da funzionalità importanti, anche se non vitali per l’app. Queste sono:

• Un utente DEVE scegliere il sistema di fatturazione
• Un utente DEVE cancellare l’account
• Un utente DEVE scegliere le opzioni di time-tracking

L’evoluzione dell’app prevede la sua disponibilità sui dispositivi mobili. Tuttavia, questo compito è solo bello da avere a questo punto.

• Un utente POTREBBE installare una versione mobile dell’app

E ora la caratteristica meno prioritaria. Mira a migliorare l’esperienza dell’utente una volta che l’app è in pista. La selezionabilità del tema non è sicuramente quello che faremo ora. Tuttavia, questa caratteristica è salvata per dopo.

• L’utente non sceglierà il tema visivo dell’app QUESTA VOLTA.

La cosa più difficile della prioritizzazione è essere icily intelligente e concentrarsi sui compiti essenziali da fare. Altrimenti, si può cadere nella trappola del TUTTO-È-MUST, secondo la quale qualsiasi caratteristica come l’opzione del sistema di fatturazione o la disponibilità dell’app mobile si trasforma nel must-have. Ed è per questo che il metodo Agile MoSCoW è forte. Ti permette di definire un set di funzionalità di base, che ha la massima priorità e sottolinea che non è necessario abbandonare nulla. Il sano equilibrio tra must-have + should-have è il 50% dell’intero scopo. Tutti i compiti (o quasi) saranno implementati in seguito, ma nell’ordine della loro importanza per il tuo obiettivo. L’obiettivo di questo esempio è quello di costruire un MVP, e la categorizzazione qui sopra mostra il progresso previsto delle funzionalità dell’app.

Abbiamo molte conoscenze da condividere con te. Unisciti al team di Railsware.

MoSCoW pro e contro

Il framework è abbastanza popolare tra i progetti Agile con timebox fissi poiché permette di gestire i requisiti per una specifica release di un prodotto. Questo metodo di prioritizzazione ha dimostrato la sua efficienza e affidabilità anche nella nostra azienda, e lo consigliamo ai nostri clienti. Tuttavia, non è perfetto, naturalmente, e uno sguardo imparziale può rivelare alcuni difetti associati alla tecnica MoSCoW. Diamo un’occhiata ai suoi punti di forza e di debolezza.

MoSCoW prioritization at Railsware

Diamo un’occhiata a come stabiliamo le priorità in azienda.

Sviluppo del prodotto: ci basiamo su una roadmap dove sono specificate le caratteristiche del prodotto e l’ordine della loro implementazione. Di norma, sfruttiamo il MoSCoW per definire quale caratteristica va per prima, quale viene per seconda e così via, tenendo conto della loro importanza e dell’interdipendenza delle caratteristiche. Must-haves e Should-haves sono destinati al rilascio del prodotto. I “Could-haves” e i “Won’t-haves” sono rimandati al futuro.

HR e reclutamento: la prioritizzazione si basa su requisiti come la richiesta di particolari competenze, la disponibilità di budget, il timebox (quanto urgentemente abbiamo bisogno di queste competenze), e così via. Sfruttiamo i modelli simili di definizione delle priorità in altre aree di attenzione tra cui l’on-boarding, il branding, il marketing, ecc.

La più grande sfida della metodologia è che tutti gli stakeholder devono avere abbastanza familiarità con il contesto per stimare correttamente le caratteristiche. Inoltre, gli stakeholder che rappresentano diverse funzioni come le vendite, lo sviluppo, il marketing, hanno la loro visione delle priorità, che non sempre funziona verso una corretta prioritizzazione. Gli investitori di solito trattano tutte le caratteristiche come Must-have dal loro punto di vista generale e hanno bisogno che siano fatte senza alcun rispetto del loro ordine di implementazione.

Railsware ha una struttura organizzativa olacratica. Sfruttiamo la leadership collettiva basata sul modello RASCI e prendiamo decisioni su diverse cose, inclusa la prioritizzazione attraverso il voto. I membri del team possono scegliere tra diverse opzioni come voglio davvero, voglio e non voglio. Ogni opzione implica un punto particolare. L’opzione con il maggior numero di punti ha la priorità più alta. Per piccoli contesti, un ruolo responsabile (team leader, project manager, ecc.) può essere incaricato di stabilire le priorità da solo.

Alternative a MoSCoW che potresti trovare utili per il tuo progetto

Railsware usa pesantemente il framework Agile MoSCoW e ne è soddisfatto. Tuttavia, ciò non significa che siamo chiusi ad altre soluzioni. Inoltre, un buon product manager deve considerare le metriche chiave del prodotto e costruire le priorità in base ad esse. Quindi ecco alcune altre tecniche utili di cui potete beneficiare.

Modello Kano

Con questo quadro, potete definire quanto gli utenti sono soddisfatti delle caratteristiche del prodotto. Il modello Kano si basa su un questionario, che viene utilizzato per imparare l’atteggiamento degli utenti verso una particolare caratteristica (come, aspetta, non piace, neutrale, ecc.). Visivamente, il modello può essere espresso attraverso un diagramma bidimensionale dove l’asse verticale è responsabile del livello di soddisfazione dell’utente (da totalmente frustrato a incredibilmente felice) e quello orizzontale mostra o quanto è stato investito nella caratteristica (Investimento), quanto bene è stato implementato (Implementazione), o quanto gli utenti ne beneficiano (Funzionalità).

La categorizzazione dei requisiti include quattro tipi che sono prioritari nel seguente ordine: must-be, performance, attraente e indifferente. I must-be sono alcune cose di base che gli utenti generalmente si aspettano. I requisiti di performance (conosciuti anche come monodimensionali) sono la media aurea e permettono di aumentare il livello di soddisfazione. I requisiti attraenti sono quelli che migliorano l’esperienza dell’utente. Questi sono nice-to-have o could-have secondo il MoSCoW. Quelli indifferenti sono meno prioritari e a volte anche completamente omessi.

Valore vs Complessità

Questa tecnica di prioritizzazione è una delle più semplici. La si può incontrare anche sotto i nomi di Valore contro Costo o Valore contro Sforzo. Il metodo sembra intuitivo e mira a massimizzare la consegna del valore. La stima dell’importanza delle caratteristiche si basa su quanto sforzo viene investito per implementarle e quanto valore porteranno. Ecco come appare visivamente:

Wrapping up

L’arte di stabilire le priorità mostra l’efficienza del vostro flusso di lavoro. La scelta di Railsware è il framework di gestione dei progetti MoSCoW, che ha fatto una buona mostra di funzionalità e prodotti versatili. Tuttavia, potrebbe essere meno utile per progetti immensi con più squadre coinvolte nella pipeline. Vi consigliamo di trovare una soluzione di prioritizzazione efficace che si adatti alle vostre esigenze uniche, e di evitare sempre di rimanere intrappolati in innumerevoli compiti in sospeso.