Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

Come gestire progetti uniformi e misurabili: focus su tipologie e requisiti

pittogramma Zerouno

Metodologia

Come gestire progetti uniformi e misurabili: focus su tipologie e requisiti

Con questo articolo ha inizio un percorso sui temi della misurazione e del monitoraggio dei progetti e dei contratti ICT partendo da due schemi di classificazione relativi alle tipologie di progetto (123) e di requisiti (ABC) da poter considerare per una migliore gestione di un contratto, ICT e non.

03 Mag 2019

di Luigi Buglione

La misurazione e il monitoraggio dei progetti e dei contratti ICT è da sempre una delle principali preoccupazioni dei CIO e oggi, con la complessità infrastrutturale dei sistemi informativi e delle architetture applicative, è un tema quanto mai di attualità. Con questo articolo dedicato a due schemi di classificazione relativi alle tipologie di progetto (123) e di requisiti (ABC) iniziamo una serie di approfondimenti su questa tematica.

Le macro caratteristiche di un progetto ICT

Il PMBOK (Project Management Body Of Knowledge) definisce un progetto come “a temporary endeavor undertaken to create a unique product, service, or result” e un contratto ICT di fatto suddivide un progetto complessivo in più sotto-progetti.

Nella versione più estesa pertanto si partirebbe da un progetto di sviluppo (DEV – Development), per passare poi alla sua operatività (OPS – Operation), per finire con una serie di interventi manutentivi (SVC – Service/Mainteinance), utili a prolungarne il ‘valore’ per i suoi stakeholder nel tempo.

Cos’è lo schema 1-2-3 nella gestione dei progetti IT

Quindi la gestione di un sistema implica un progetto di servizio il cui ‘scope’ (ambito) può essere suddiviso, seguendo il principio del ‘divide-et-impera’, in tre sotto-progetti, ciascuno con ‘scope’ puntuali e collegati ma da poter gestire separatamente. Da qui nasce lo schema ‘123’, laddove, invertendo le proporzioni note come la ‘regola di Pareto’, i tempi e i costi del DEV rispetto all’OPS/SVC potrebbero essere in una proporzione del 20/80.

La manutenzione può essere di diversi tipi, seguendo la classificazione proposta dallo standard ISO/IEC 14764:2006:

  • correttiva (suddivisa in correttiva e preventiva)
  • evolutiva (suddivisa in adeguativa e migliorativa)

e rappresenta con l’esercizio (OPS) nella vita utile di un servizio/sistema la gran parte del progetto di servizio complessivo, diversamente dalla percezione comune, numeri alla mano (figura 1).

grafico - schema 123
Figura 1 – Lo schema 123 per la progettazione di progetti IT

Separando le parti (1-2-3) in contratti e gestioni distinte, sebbene intimamente collegate tra loro, si porrebbe una attenzione proporzionata a ciascuna delle parti, partendo dalle stime tecniche fino alla gestione economica. Si pensi ai livelli di servizio e alle misure per il controllo di ciascuna parte: ‘a plan of measures is not a measurement plan’, con un numero bilanciato di misure, da collegare in modo causale tra di loro per restituire un maggior valore informativo. Un esempio: misure e KPI relativi all’affidabilità (reliability) di un prodotto/servizio dipendono strettamente dalla qualità degli outcome prodotti, che a loro volta dipendono da come la prima progettazione e realizzazione sia stata ‘buona alla prima’ (c.d. first take), adottando tecniche che DevOps definirebbe di tipo ‘shift left’.
Quindi guardare il progetto complessivo, gestendo i singoli progetti ‘elementari’ e le relazioni tra loro, diventa sempre più fondamentale per contratti che vorrebbero essere gestiti più in termini di ‘valore’ che di pura ‘redditività’, misurati pertanto con VOI (Value on Investment) che non con il ROI (Return on Investment).

Lo schema ‘ABC’: cosa è e come applicarlo nello schema ‘123’

Ogni pianificazione nasce da un set di requisiti forniti dai diversi stakeholder. Ma i requisiti in un progetto non sono tutti uguali. Alcuni sono relativi alle funzionalità di un prodotto/servizio (COSA), altri a COME realizzarle o a quali livelli (QUANDO), espressione rispettivamente (COSA) di FUR (Functional User Requirements) e (COME e QUANDO) NFR (Non-Functional Requirements).

Cosa misurano i requisiti utente

Ma cosa misurano? Un prodotto/servizio e non un progetto: difatti non comprendono anche i requisiti gestionali ed organizzativi necessari alla loro messa in opera. Riassumendo, da ogni requisito utente (UR) si potrebbero avere quindi requisiti di prodotto/servizio funzionali (tipo A), non funzionali (tipo B) e gestionali (tipo C). Mettendoli insieme, si ottiene lo schema ‘ABC’ e la figura 2 propone le possibili combinazioni.

Figura 2 – Schema ABC delle possibili combinazioni dei requisiti utente

In un progetto software, per esempio:

  • i task derivati da requisiti di tipo A sarebbero eseguiti principalmente da analisti/programmatori/tester (quelli che nelle tecniche Agile quali Scrum sarebbero definiti il ‘team’);
  • i task di tipo B sarebbero eseguiti da specialisti di prodotto, esperti di usabilità, DBA, architetti, configuration manager e via dicendo;
  • infine quelli di tipo C sarebbero eseguiti dai cosiddetti ‘gestionali’ quali un project manager, un misuratore, un service manager, un quality assurance (QA)/experience assurance (XA) ed altri che contribuiscono indirettamente alla creazione/modifica di un prodotto/servizio tramite task ‘altri’.

Distribuzione di effort e costi di un progetto ICT

Per conoscere una proporzione indicativa della distribuzione degli effort e costi di un progetto ICT, si consideri il doppio triangolo proposto nella figura 3, con distribuzioni che variano, ovviamente, in funzione del tipo di progetto (sviluppo, manutenzione) e del cosiddetto ‘dominio funzionale’, ovverosia della famiglia di progetti considerata (nel mondo software, lo standard ISO/IEC 14143-5 propone criteri di classificazione standard dal 2004): un progetto di software gestionale non potrebbe essere validamente comparato con uno per app mobile o per uno sviluppo di rete. È necessario pertanto classificare e clusterizzare i progetti in tipi omogenei ed equivalenti, per ogni pratica ed obiettivo di benchmarking.

schema effort costi
Figura 3 – Proporzione indicativa della distribuzione degli effort e costi di un progetto ICT

La figura 4 invece illustra una possibile distribuzione degli effort ABC per alcuni possibili ‘domini funzionali’.

grafico effort per domini
Figura 4 – Possibile distribuzione degli effort ABC per alcuni possibili ‘domini funzionali’

Come poter derivare queste proporzioni in un progetto? Non esistono ‘silver bullet’; basta considerare il Gantt/WBS di un progetto, classificare ciascun task ‘atomico’ secondo la natura del requisito (ABC) che lo origina e calcolare i totali per ciascun tipo in valore assoluto e quindi in percentuale sul totale generale. Nel caso di dubbio sulla classificazione di un task, questo potrebbe non essere ancora ben dettagliato, richiedendo una ulteriore scomposizioner in sotto-task, possibilmente assegnabili anche a personale diverso (per esempio: l’analisi, come le altre fasi tecniche, possono essere scomposte in due parti: funzionale e non-funzionale), come illustrato in figura 5.

grafico granularità dei task
Figura 5 – Granularità dei task in un progetto e classificazione secondo la tipologia di requisito utente

Alcune misure/KPI per ciascuno dei diversi tipi di requisito potrebbero essere:

  • (A) Function Point;
  • (B) misure qualitative/tecniche relative al prodotto/servizio derivate ad esempio dalla norma ISO/IEC 25023 o dalla tecnica IFPUG SNAP;
  • (C) non esistendo al momento una definizione condivisa, standard di ‘project size’, si possono identificare misure specifiche per ciascuna tipologia di task di questo tipo o, come spesso accade, passare direttamente ad una stima in giorni/persona.

La tecnica EAM (Entità-Attributo-Misura) può aiutare a classificare e determinare correttamente un ‘measurement plan’ bilanciato.

Riprendendo pertanto lo schema ‘123’, come in figura 6, i progetti di sviluppo (tipo 1) hanno tutti e tre i tipi di requisito (ABC), quelli di esercizio/operatività (tipo 2) solo quelli di tipo B/C. Le funzionalità sviluppate in questa fase difatti si ‘usano’, non si modificano. Infine, nei progetti di manutenzione (tipo 3) gli interventi di tipo correttivo saranno di tipo B/C, mentre quelli di tipo evolutivo possibilmente di tipo A e sicuramente di tipo B/C. ‘Possibilmente’ perché molti interventi di piccola manutenzione evolutiva possono non comportare modifiche funzionali (es: cambi grafici, aspetti qualitativi, prestazionali, …).

grafico schema 123 e abc
Figura 6 – Schema 123 e schema ABC

Schema ‘123’+’ABC’: una combinazione di ‘valore’ per una migliore gestione contrattuale

Attualmente molti contratti ICT considerano le misure funzionali di un prodotto software quali i Function Point (quale che sia lo standard applicato: IFPUG, COSMIC, NESMA, FISMA, Mark-II) la base di conteggio per la corresponsione di un singolo macro-progetto ICT che però include sotto-progetti di più tipi (1, 2, 3) e che quindi potrebbe non avere effort direttamente proporzionali alle formali quantità censite (valide solo per alcune delle suddette tipologie).
Ciò ha comportato (e ancora rischia di comportare) discussi tra le parti contrattuali, non perimetrando il corretto ‘scope’ progettuale usando la corretta combinazione di misure e KPI, ma semplificandone eccessivamente la gestione e riconduncendola principalmente a misure di tipo funzionale, non sempre, come detto, applicabili.
Potrebbe l’applicazione di questa semplice scomposizione di macro-progetti in sotto-progetti con un ambito ben definito essere l’inizio di un nuovo percorso nella contrattualistica ICT?
GUFPI-ISMA ha ridefinito nel 2016 le proprie Linee Guida con un primo volume relativo ai Principi, Assunzioni e Best Practice Contrattuali (PABCP) con i principali aspetti da poter osservare anche per auto-valutazioni dei propri contratti a cui seguirà a breve un secondo volume con indicazioni operative sui singoli lemmi discussi.

Interessati a saperne di più? Seguite i nostri prossimi contributi su ZeroUnoWeb e visitate il sito web GUFPI-ISMA per ulteriori spunti ed approfondimenti!

Luigi Buglione

Luigi Buglione è professore associato presso l'École de Technologie Supérieure (ETS) - Université du Québec, Canada e attualmente lavora come specialista in Process Improvement & Measurement presso Engineering Ing. Inf. SpA (precedentemente Atos Origin e prima di SchlumbergerSema) a Roma, Italia. Collabora con diverse associazioni ed è attualmente Presidente del Gruppo Utenti Function Point Italia – Italian Software Metrics Association (GUFPI-ISMA) e Direttore Conferences & Education dell’International Function Point Users Group (IFPUG).

Argomenti trattati

Approfondimenti

G
GUFPI-ISMA
S
Software Quality
Come gestire progetti uniformi e misurabili: focus su tipologie e requisiti

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

    LinkedIn

    Twitter

    Whatsapp

    Facebook

    Link

    Articolo 1 di 4