Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti

Nel numero:

319 settembre
, anno 2025

Agile Portfolio Management

II parte: La matrice Impact/Effort

Stefano Leli
Stefano Leli

Stefano Leli, appassionato di sviluppo software fin da bambino, è da sempre alla ricerca di nuovi spunti per migliorare il proprio lavoro. Nel 2003 sente casualmente parlare del manifesto agile e inizia titubante a praticare XP. Da quel momento il suo approccio allo sviluppo software è diventato una integrazione continua delle più moderne tecnologie agili. Attualmente svolge attività di sviluppo software, training e coaching con particolare enfasi nell’introduzione di metodologie agili.

Mettere in fila tante cose

Agile Portfolio Management

II parte: La matrice Impact/Effort

Immagine di Stefano Leli

Stefano Leli

  • Questo articolo parla di: Lean/Agile, Organizzazione aziendale, Project Management

Introduzione

Nel precedente articolo abbiamo guardato alle molte componenti del portfolio management. Mettere in fila le varie iniziative e scegliere quali effettivamente intraprendere e con quale priorità rappresentano attività fondamentali nella strategia aziendale. Non è facile e richiede anzitutto una condivisione delle informazioni, una comunicazione serrata e alcuni strumenti che possano aiutare nel processo decisionale.

In questo secondo articolo, completiamo il nostro discorso presentando uno strumento semplice, ma che presuppone un approccio coerente con quanto ci siamo detti fin qui. Quanto raccontiamo in questo articolo si basa su esperienze reali, sulle modalità cn cui come abbiamo affrontato la questione.

 

La matrice “impact–effort”

Lo strumento di cui parliamo è la matrice Impact/Effort che si basa sui concetti di “impatto” e di “impegno”, “sforzo”. Lo dico subito: è uno strumento valido, che nella mia azienda ci piace molto e che usiamo con profitto. Ma non è l’unico, come abbiamo visto, e magari per molti non sarà neanche il migliore. Per noi funziona.

Figura 1 – La matrice Impact/Effort.
Figura 1 – La matrice Impact/Effort.

 

La matrice ha due assi:

  • impact: quanto è importante, quanto è impattante questa iniziativa per il successo della la nostra organizzazione;
  • effort: quanto costa, quanto è grande, quanto sforzo richiede questa iniziativa.

 

L’uso è facile: prendiamo le nostre iniziative, le discutiamo insieme, le valutiamo sulla base dell’impatto e dello sforzo e le mettiamo su questi quadranti.

Quelle in alto a sinistra hanno un grande impact e un piccolo effort: saranno le prime che faremo. Quelle opposte, in basso a destra, sono le prime che scartiamo: costano tanto, valgono poco. O le abbandoniamo definitivamente o, quantomeno, le posticipiamo di tanto, rivalutandole in seguito.

Poi abbiamo quelle in basso a sinistra: costano poco, ma valgono anche poco. Non le scartiamo, le teniamo lì e le faremo se abbiamo un “buco”, uno spazio disponibile.

E quelle in alto a destra? Queste valgono tanto, ma costano pure tanto. Qui la decisione non è facile. Potremmo provare un approccio che dice: “Riusciamo a dividerle?”. Siamo bravi a fare le MVP, ormai abbiamo capito come si fanno. Proviamo a farlo, proviamo a capire se riusciamo, suddividendole, a portarne una parte su un quadrante e una su un altro. Ma siamo sicuri che questo approccio funzioni?

Figura 2 – Collocando le varie iniziative sui diversi quadranti, in base all’impact e all’effort, possiamo avere indicazioni per la prioritizzazione.
Figura 2 – Collocando le varie iniziative sui diversi quadranti, in base all’impact e all’effort, possiamo avere indicazioni per la prioritizzazione.

 

Definire Impact ed Effort

Se vogiiamo usare questo strumento, occorre anzitutto definire che cosa siano Impact ed Effort.

Effort potrebbe voler dire soldi da spendere, o tempo da impiegare. Impact potrebbe voler dire lavorare a prodotto di qualità con standard alti, oppure avere tanti clienti. Non tutti hanno la stessa visione. Ma ricordiamoci che questo è uno strumento di “conversazione” per comunicare e prendere delle decisioni. Non è uno strumento gestionale di pianificazione.

È chiaro che occorredefinire quali sono i driver di impatto e i driver di effort. E quindi iniziamo a dire: “Ma per noi come azienda che cosa ha senso contemplare come effort o come impact?”.

L’esempio con una banca

Un esempio del modo in cui possiamo cercare di definire questi driver è rappresentato dal lavoro che abbiamo fatto con una banca. Abbiamo dato dei valori (0, 1, 2) a diversi elementi dell’impact: quanto pregiudica la strategia dell’azienda il non fare questo lavoro, quanto è importante il branding che può garantire, e così via. E abbiamo anche cercato di misurare i driver dell’effort: tempo necessario, costi, ma anche un aspetto che era tipico di questa azienda, ossia la complessità legata all’organizzazione. Infatti si trattava di una realtà divisa in dipartimenti, e ci siamo resi conto che più dipartimenti partecipavano, maggiore era l’effort, legato al fatto che ci sono più persone da cocordinare, più manager con cui relazionarsi, più diversità da tenere in considerazione.

Tra l’altro, però, questo ci dice anche che si tratta di uno strumento “neutro”: la matrice Impact/Effort non si applica solo a realtà di tipo “agile”, con i team cross-functional e così via, ma anche a strutture più tradizionali.

Abbiamo necessità di comunicare chiaramente cosa significa 0, 1 o 2 come valore, quindi ne dobbiamo dare anche una definizione qualitativa. Ma una volta che abbiamo fatto questo lavoro, possiamo avere dei driver per l’impact e l’effort con i quali calcolare il “peso”. E una volta che abbiamo la possibilità di dare un valore affidabile a Impact ed Effort, la nostra matrice funziona e ci aiuta nelle decisioni.

Per esempio, nel caso della banca, se abbiamo dato 2 al driver di impatto “Impact not doing”, significa che stiamo parlando di qualcosa da dover fare per forza, che probabilmente è legato a una normativa o a una legge e quindi non possiamo non farlo.

Figura 3 – Definire i driver di Impact ed Effort è fondamentale per “pesare” adeguatamente impatto e sforzo.
Figura 3 – Definire i driver di Impact ed Effort è fondamentale per “pesare” adeguatamente impatto e sforzo.

Come nel planning poker

Questo è un lavoro da fare collaborativamente, così come si pesano le storie utente nel planning poker. Non dimentichiamo che la defininizione dei driver di Impact ed Effort e la collocazione delle iniziative nella matrice si basano sulla comunicazione. La matrice Impact/Effort è uno strumento di comunicazione collaborativa.

Con questo strumento, costruiamo delle matrici che ci fanno vedere in che modo le nostre iniziative vanno a posizionarsi nei vari quadranti e, sulla base di tale collocazione, ci consentono di fare alcuni ragionamenti. Potremmo avere un affollamento nel quadrante in basso a sinistra: tante iniziative piccole che portano poco valore… però possiamo trovare il modo di farle. Oppure ci capita di avere tante iniziative nel quadrante in basso a destra: quelle che costano tanto, ma hanno poco valore.

Ricordo bene di quella volta in cui, in un incontro C-level, un dirigente dell’azienda si è alzato e ha detto: “Ma scusate, se abbiamo tante iniziative che costano così tanto e portano così poco valore, perché le facciamo? Perché le abbiamo messe a piano?”. Ecco, era la prima volta che si incontravano per condividere queste informazioni. Il lavoro delle due ore successive, anziché pianificare attività, fu: “Buttiamole via, troviamo il modo per non farle: stiamo dicendo tutti assieme che non porta nessun valore farle”. E, a costo di ripetermi, dico ancoa una volta che questo è possibile perché la matrice Impact Effort è anzitutto uno strumento che serve ad abilitare la comunicazione.

 

Tenere in considerazione la capacità dei team

Grazie alla matrice Impact/Effort, abbiamo inquadrato le nostre iniziative e le abbiamo ordinate in base alla priorità. Basta tutto questo? No, perché — se ancora non l’abbiamo fatto — adesso è il momento di iniziare a coinvolgere le persone che producono, che lavoreranno su queste iniziative, quindi i team, quindi tutta la parte produttiva.

Attenzione, perché il fatto di aver messo in fila tutte le iniziative e di aver dato loro una priorità non vuol dire che poi dobbiamo farle tutte: dobbiamo fare quelle che si possono fare in base alla capacità dei team che abbiamo a disposizione. Saranno i team che, in modalità pull, prenderanno dall’elenco delle iniziative prioritizzate quelle che ritengono effettivamente di poter portare a termine.

Token Game: uno strumento utile

Abbiamo diversi strumenti a disposizione per svolgere questo processo di scelta e presa in carico delle iniziative da svolgere. Uno di questi è il Token Game, basato su “monetine”, che utilizziamo in modo piuttosto proficuo. Funziona nel modo seguente:

  • L’elenco delle iniziative è chiaro e ordinato per priorità. Sappiamo quali fare per prime e quali invece lasciare per ultime. Però dobbiamo capire quali possiamo prenderci in carico, quali siamo in grado di comletare in base alla nostra capacity. Un conto è aver pianificato tutto in base alla priorità, un conto è sapere cosa effettivamente riusciamo a concludere.
  • Quindi, portiamo al tavolo della decisione chi nel concreto dovrà fare il lavoro: sono coloro che meglio di tutti conoscono il “costo” reale in termini di tempo e impegno di realizzare quelle attività. I team di sviluppo fanno le loro considerazioni.
  • I team avranno a disposizione dei token, delle monetine, che riflettono la loro capacità di lavoro e “spenderanno” tali monetine sulle varie iniziative. Ogni token vale 2, massimo 3 settimane di giorni lavorativi. E quando le monetine saranno finite, significa che non si possono più prendere in carico ulteriori iniziative.

Con questo meccanismo del Token Game, ci apriamo anche delle interessanti opzioni.

  • Le iniziative che restano fuori, che non sono coperte da monetine, diventano oggetto di ulteriore conversazione: non dobbiamo necessariamente buttarle via, ma dobbiamo ragionare sul fatto che, se vogliamo farle, o troviamo altre monetine aggiungendo risorse, oppure spostiamo delle monetine da altre iniziative.
  • Questo strumento si adatta bene anche in quelle realtà in cui i team non sono di tipo crossfunzionale, unitario e stabile, in stile Scrum. Si adatta anche a quelle situazioni più tradizionali e non Agile — e sono tantissime — in cui l’azienda ha delle iniziative e i team si creano intorno ad esse, prendendo un po’ da un dipartimento e un po’ da un altro. Quando abbiamo tanti dipartimenti che devono collaborare, i dipartimenti dicono: “OK, io ce ne metto 10, tu ce ne metti 20”. “Bene, siamo a 30. Dobbiamo trovarne altre 10 e l’iniziativa si può fare”. Che poi, banalizzando, questo significa che io ci metto Tizio, tu ci metti Caio, lui ci mette Sempronio: dobbiamo trovare un’altra persona e così abbiamo creato il team che porterà avanti l’iniziativa.
  • La situazione ottimale sarebbe coinvolgere queste persone del team fin dall’inizio, perlomeno alcune di queste, che dovrebbero essere presenti in tutta la fase di pianificazione e prioritizzazione, per far sì che, quando arriviamo poi all’implementazione, molti elementi dei team siano già a bordo. È anche possibile raccontarlo e spiegarlo in un secondo tempo, ma il coinvolgimento precoce è sicuramente migliore.

 

La revisione del piano

Chiaramente non dobbiamo fare l’errore che abbiamo sempre imputato ai metodi cosiddetti “a cascata”, ossia quello di fare una pianificazione iniziale e considerarla valida per tutto il tempo di svolgimento dell’iniziativa.

Dobbiamo ripetere questo tipo di pianificazione con una certa regolarità: non possiamo farlo solo una volta all’inizio dell’anno, senza rivalutarla. Andrebbe fatta più volte l’anno. Quanto spesso? L’ottimale potrebbe essere su base trimestrale, ma la realtà è che dipende da quante volte, realisticamente, possiamo ripetere questo ciclo di pianificazione: meglio farlo una volta in meno, ma farlo regolarmente, che imporsi di farlo in teoria ogni tre mesi e poi non farlo…

In questo ciclo di revisioni della pianificazione, insieme a tutte le persone coinvolte, ci poniamo varie domande:

  • Ma la nostra pianificazione che abbiamo fatto all’inizio dell’anno è ancora valida?
  • Ci sono nuove iniziative?
  • Ci sono iniziative che nel frattempo sono diventate più importanti e quindi le mettiamo più in alto?
  • Ci sono iniziative che nel frattempo sono diminuite di importanza e quini le mettiamo più in basso?

il concetto fondamentale è che dobbiamo riuscire a fare qualcosa di sostenibile e alla fine dell’anno dobbiamo essere contenti di aver realizzato quello che serviva maggiormente per l’azienda. Abbiamo massimizzato il tempo che abbiamo trascorso, cercando di concentrarci solo sulle cose che per tutta quanta l’azienda, grazie alla comunicazione di tutte le persone, sono importanti per quell’azienda.

 

Misurazioni per il miglioramento continuo

Non possiamo concludere questa riflessione senza un accenno al tema delle misurazioni.

Per poterci trovare ogni tre mesi a capire se il nostro piano sta andando bene, se quello che abbiamo pianificato sta portando il valore che abbiamo atteso e se conviene continuare su un’iniziativa o concentrarsi su un’altra, dobbiamo trovare dei modi per poterle misurare queste iniziative, per poter misurare l’andamento del nostro piano.

Ed è importante chiedersi quali sono i metodi e gli strumenti che ci possono essere utili per misurare. Noi non siamo fondamentalisti, quindi qui possiamo avere addirittura dei Gantt, se sono adatti al contesto, o possiamo usare dei Burndown Charts più diffusi nel mondo Agile. quel che conta è disporre di uno strumento che serva a trovare le metriche che meglio funzionano all’interno della vostra azienda, e che siano però specchio reale dell’andamento del vostro piano.

 

Per concludere

Finiamo quindi con un breve riassunto per punti di quanto detto in questa riflessione.

  • Basiamo la nostra pianificazione strategica sulla condivisione tra le persone. Quindi non stiamo nella stanza dei bottoni, ma condividiamo il processo di pianificazione.
  • Non vogliamo trovare un modo per fare tutto, ma vogliamo trovare il modo migliore per fare le cose più importanti per l’azienda. Se non comunichiamo non abbiamo possibilità di scelta.
  • La nostra pianificazione che facciamo all’inizio dell’anno non è un oracolo che dobbiamo per forza perseguire: dobbiamo essere pronti a rivalutare il nostro piano. Ogni tre mesi ci rimettiamo al tavolo e cerchiamo di trovare il modo per chiederci come sta andando.

 

 

 

 

Facebook
Twitter
LinkedIn
Stefano Leli
Stefano Leli

Stefano Leli, appassionato di sviluppo software fin da bambino, è da sempre alla ricerca di nuovi spunti per migliorare il proprio lavoro. Nel 2003 sente casualmente parlare del manifesto agile e inizia titubante a praticare XP. Da quel momento il suo approccio allo sviluppo software è diventato una integrazione continua delle più moderne tecnologie agili. Attualmente svolge attività di sviluppo software, training e coaching con particolare enfasi nell’introduzione di metodologie agili.

Immagine di Stefano Leli

Stefano Leli

Stefano Leli, appassionato di sviluppo software fin da bambino, è da sempre alla ricerca di nuovi spunti per migliorare il proprio lavoro. Nel 2003 sente casualmente parlare del manifesto agile e inizia titubante a praticare XP. Da quel momento il suo approccio allo sviluppo software è diventato una integrazione continua delle più moderne tecnologie agili. Attualmente svolge attività di sviluppo software, training e coaching con particolare enfasi nell’introduzione di metodologie agili.
Tutti gli articoli
Nello stesso numero
Loading...

Dall’età del ferro all’età del cloud

Perché solo DevOps non basta più

Modelli LLM: Come funzionano?

II parte: BNN e ANN, una visione OO

Talento, performance, carriera: uno sguardo d’insieme

III parte: Considerazioni sul Performance Management

Nella stessa serie
Loading...

Agile Portfolio Management

I parte: L’arte di mettere in fila tante cose

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte