Gestione dei progetti

Introduzione

La progettazione di servizi o sistemi complessi (ad esempio siti internet o applicazioni di grandi dimensioni) coinvolge generalmente gruppi di lavoro numerosi, e può durare molti mesi o anni di lavoro. Per questo motivo, diventa fondamentale adottare delle metodologie progettuali finalizzate a gestire questo processo.

In questo capitolo ci proponiamo di identificare queste metodologie.

Descriveremo il modello a cascata e l'approccio agile, le due principali metodologie di sviluppo del software.

Dall'altra, identificheremo alcuni aspetti più strettamente specifici allo UX design, identificando i vari piani -- nella terminologia di @Garrett_2003 -- ma soprattutto cercando di capire quali sono le domande a cui l'UX designer deve rispondere.

Gestire un progetto

A process model is a description of the significant aspects of the tasks that are accomplished during the development of software, including the artifacts produced, the agents involved in the activities, and the relationships between these entities.
\cite

Gestire un progetto significa:

• identificare gli obiettivi e i risultati attesi, e se possibile quantificarli;
• identificare i vincoli;
• identificare e gestire le risorse;
• pianificare il processo in modo da raggiungere gli obiettivi rispettando i vincoli;
• monitorare il processo ed aggiustarlo quando necessario;
• mantenere un ambiente di lavoro calmo, positivo e produttivo.

Nella gestione di un progetto vanno tenuti in considerazione 4 aspetti [@Easterbrook2001]:

• il prodotto;
• le risorse;
• i tempi;
• i fattori di rischio;

Gestione del rischio

Nel processo progettuale possono emergere degli ostacoli e degli imprevisti che ritardano lo sviluppo o che costringono a modificarne delle parti.

Con gestione del rischio si intendono quelle pratiche finalizzate a prevenire l'insorgere degli ostacoli ed a minimizzarne gli effetti negativi. Il principio sottostante è che la prevenzione del rischio è meno costosa che la gestione dell'evento negativo.
È utile valutare il rischio nel momento in cui si fanno delle scelte progettuali.

Andranno monitorati gli aspetti legati alle risorse umane e alle loro competenze, al budget e alle risorse disponibili, al tempo, agli strumenti necessari. Va tenuto conto che i requisite e il contesto possono cambiare; che possono emergere problemi di performance del software; infine, è necessario evitare di sviluppare funzioni solo marginalmente utili.

Mancanza di adeguate competenze

Uno dei rischi è quello di non avere un team adeguato al progetto. Per prevenire questa possibilità è necessario reclutare persone competenti e se necessario formarle, e costruire un buon clima all'interno del team (team building).

Budget e tempistica non realistica

Uno dei rischi più frequenti, nello sviluppo di un progetto, è quello di sforare i tempi o il budget. Questo evento rischia di mettere a repentaglio il successo del progetto.
Per minimizzare questo rischio è indispensabile, all'inizio, fare stime corrette di tempi e costi, magari rivolgendosi ad esperti.

L'approccio agile alla progettazione, che vedremo nelle prossime sezioni, cerca di affrontare diversamente questo problema.

Sviluppo di funzioni non necessarie

Un progetto, quando non è banale, consiste nello sviluppo di artefatti con una serie di funzionalità.
Uno degli errori più frequenti è quello di sviluppare funzioni meno importanti, a discapito di funzioni necessarie.
Questo errore può portare al problema sopra accennato di una dilatazione di tempi e costi.

Uno dei fini del coinvolgimento degli utenti nella fase di ricerca è quello di minimizzare questo rischio identificando i loro reali bisogni, attraverso strumenti come il free listing e la valutazione di importanza.

Modifiche dei requisiti

Questa è una situazione molto frequente, o perché i requisiti iniziali vengono modificati dal committente oppure perché si è modificato il contesto (basti pensare, ad esempio, all'impatto della pandemia).

Una dettagliata stakeholder analysis, in cui i requisiti vengono contrattati e stabiliti a priori in maniera chiara, può aiutare a definire dei requisiti meno soggetti a cambiamenti.

Un atteggiamento diverso è quello dell'approccio agile, in cui si adotta uno sviluppo iterativo e incrementale: in questo caso ad ogni iterazione è possibile aggiornare la lista dei requisiti.

Mancanza degli strumenti necessari all'implementazione

in fase di progettazione si deve tener conto dei problemi legati all'implementazione, per evitare di progettare prodotti molto belli sulla carta ma di fatto impossibili da realizzare, o la cui affidabilità tecnica li rende di fatto inutilizzabili.

Per minimizzare questo rischio è necessario analizzare il contesto tecnologico (anche attraverso lo studio degli utenti), i requisiti tecnici e le tecnologie disponibili.

Nell'approccio agile (sviluppo early and frequent di versioni preliminari funzionanti del prodotto) questo rischio è minimizzato: gli ostacoli tecnologici emergeranno da subito e sarà possibile adattare il progetto, magari ad una versione più povera, con requisiti più bassi, ma di possibile implementazione. Nell'approccio a cascata viene generalmente implementato un poc (Proof of concept): una versione funzionante di un sottoinsieme di funzionalità - generalmente quelle che potrebbero risultare più complesse o sfidanti.

Problemi di performance del prodotto

Sebbene progettato e sviluppato in maniera corretta, un prodotto può non funzionare come si vorrebbe, e possono emergere problemi di tipo tecnico - tecnologico. Per prevenire questi problemi è utile fare delle simulazioni e dei benchmark di performance. Inoltre è importante monitorare il prodotto ed il loro uso, soprattutto nei primi tempi dopo la distribuzione.

L'approccio iterativo è finalizzato ad anticipare l'emergere di questa problematica. Se una versione preliminare del prodotto viene rilasciata in tempi stretti, è possibile testare sul campo questi rischi e prendere tempestivamente dei provvedimenti. Nell'approccio a cascata, il poc è utile anche a monitorare questo rischio.

Documentazione

La documentazione è importante, in quanto il designer deve poter comunicare con il management, con il cliente, con i programmatori. Nelle prime fasi di sviluppo la documentazione è il prodotto, durante la fase di testing la documentazione aiuta ad identificare gli errori e a correggerli.

Una buona documentazione può aiutare, nella fase di distribuzione (deployment), a scrivere una buona manualistica, e nella fase di redesign aggiornare e migliorare il prodotto diventa più semplice.

Il modello a cascata

La modalità di progettazione tradizionale, sviluppata intorno agli anni settanta, è definita a cascata, in quanto presuppone una sequenza quasi lineare di passaggi.

La figura descrive graficamente il modello. Si inizia con l’analisi dei requisiti, si passa ad una fase di analisi, progettazione, implementazione, test e distribuzione.

Le fasi nel modello a cascata

Nel modello che proporrò in questo corso si distinguono le seguenti fasi:

• esplorazione
• ricerca
• rappresentazione
• progettazione
• test
• implementazione

Vantaggi del modello a cascata

Le persone hanno bisogno di pianificare il loro lavoro, per sapere come procedere e per evitare la sensazione di sovraccarico.

Una ragionevole fase di analisi e pianificazione iniziale costituisce una buona base per la progettazione e l'implementazione, che diminuisce il rischio di errori o la necessità di modifiche strategiche al progetto.

L'adozione di standard procedurali può essere di aiuto soprattutto nella gestione contemporanea di più progetti, ma anche per affinare la metodologia fra un progetto e l'altro. Diviene inoltre più facile verificare il progetto, collaborare con altri team o con persone esterne, condividere materiale o software.

Se si segue uno standard procedurale diventa più facile misurare i progressi fatti e gli eventuali problemi.

Limiti dell'approccio a cascata

L'approccio classico (a cascata) a volte fallisce, in quanto emergono una serie di problemi che costituiscono dei seri ostacoli al successo progettuale [@Parnas]:

• difficoltà nello stabilire i requisiti del cliente
• difficoltà nell'analizzare i vincoli progettuali
• difficoltà del team a comprendere il progetto
• cambiamenti esterni
• errori
• rigidità cognitiva

Questi limiti possono portare ad un aumento della probabilità di fallimento del progetto [@Ferreira2007].

Lo svantaggio maggiore del modello a cascata è legato al fatto che non tutto è analizzabile a priori: spesso vi sono vincoli, interni o esterni al progetto, che non possono essere analizzati con precisione nelle fasi iniziali, e possono emergere solo in fase di test.