Alberto Mucignat

Alberto Mucignat


Random thoughts around web stuffs (è tutto un equilibrio sopra la follia)

settembre: 2019
L M M G V S D
« Ott    
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Categorie


Definire le priorità di un progetto

AlbertoAlberto

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?

Comments 8
  • Marco Balzerani
    Posted on

    Marco Balzerani Marco Balzerani

    Author

    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 ” 🙂


  • Alberto
    Posted on

    Alberto Alberto

    Author

    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.


  • Alberto Mucignat
    Posted on

    Alberto Mucignat Alberto Mucignat

    Author

    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.


  • fullo
    Posted on

    fullo fullo

    Author

    sai che ti sei perso le immagini del post?


  • Alberto
    Posted on

    Alberto Alberto

    Author

    ah grazie interessante… 😉