Negli ultimi giorni sto lavorando a un progetto con Jacopo e stiamo applicando un processo di sviluppo totalmente agile. Abbiamo discusso parecchio su come pianificare le priorità delle cose da fare e abbiamo sostanzialmente evidenziato due modelli che voglio condividere.
In questo modello, vengono fatte per prime le funzionalità ad alto valore e basso effort. Successivamente le funzionalità ad alto valore ed alto effort e per ultime le funzionalità a basso valore e basso effort.
E’ utile quando si vogliono rilasciare velocemente delle nuove funzionalità, ma ha il rischio che funzionalità particolarmente complicate (ad alto effort, quindi anche a maggior rischio) comportino problemi quando è troppo tardi per porvi rimedio.
In realtà è più sicuro avere il seguente approccio.
Facendo prima le funzionalità ad alto valore ed alto effort, si scoprono subito i problemi e si lasciano le funzionalità a basso effort per tutta la seconda parte della realizzazione. Come dire: le rogne prima le affronti, meglio è.
Da notare che in entrambi i casi le funzionalità a basso valore e alto effort non dovrebbero essere fatte: non sono essenziali e costano tanto. Un buon motivo che aiuta il cliente a scegliere cosa non fare.
Può sembrare un modello semplice, ma spesso è complicato stabilire le priorità di un progetto e fare una valutazione dell’effort per ogni singola funzionalità.
La mancanza di tempo è la scusa più comune, una giustificazione più che altro verso se stessi. Con le metodologie agili esiste una facile pratica chiamata planning game che aiuta molto.
In alternativa, si rischia di considerare che tutto sia importante e tutto sia facile, mentre non è mai così.
Comunque questo è solo il primo macro-livello del modello di pianificazione che stiamo costruendo, ma fornisce le basi per una discussione iniziale.
Tu cosa ne pensi? Hai mai pianificato il lavoro sulla base del valore e del costo delle feature? Che problemi/benefit hai avuto?
8 commenti ↓
Capire cosa non fare (le funzionalità a basso valore e alto effort) è sempre molto importante, ma di solito si preferisce dire al cliente “questa funzione la rimandiamo in una futura Fase 2 ”
certo, per prima cosa abbiamo una questione di chiarezza nei confronti del cliente. questo diventa un problema quando il cliente realizza che le cose non verranno fatte comunque. quindi: meglio dirlo subito e affrontare il problema.
(cmq secondo me il fatto che un progetto web non risponda a tutte le specifiche esigenze dell’utenza deve essere visto come un valore, non come un limite)
personalmente credo che procedendo per iterazioni, una feature a priorità bassa possa diventare importante in una successiva iterazione, perchè il feedback degli utenti cambia con l’uso del software.
se invece abbiamo un processo waterfall, non ci sono molte speranze: posticipare una feature equivale sostanzialmente a non farla.
Flow Interactive ha scritto un post su come raccogliere le priorità di un progetto web con le Scorecards.
Il post è molto interessante e, tra le altre cose, utilizzano la matrice di priorità che ho descritto in un precedente post.
sai che ti sei perso le immagini del post?
ah grazie interessante…
[...] Il design di un’applicazione prevede che si facciano delle scelte sulle funzionalità che potranno avere gli utenti. La strategia di design -lo dico da tempo- per me è prima di tutto scegliere cosa non fare. [...]
[...] di molto simile l’ho trattato parlando di come impostare inizialmente un progetto e di come definire le priorità di un progetto. Poi ci sono altri miei post sul tema [...]
[...] riconoscerle ed abbandonare gli schemi usuali per concentrarsi totalmente sull’emergenza. La priorità ed il proprio tempo deve essere dedicato alla gestione della situazione di emergenza. Regole [...]