"La prontezza è tutto." - Amleto V:ii:215
Un progetto, come la vita, è incerto. I rischi vengono identificati non per il gusto di farlo ma per anticiparli e
ridurli, se possibile, o per affrontarli direttamente quando le strategie di mitigazione non hanno funzionato.
Il rischio guida i piani di iterazione; le iterazioni vengono pianificate per risolvere dei rischi specifici, tentando
o di contenerlo o di ridurlo. L'elenco dei rischi viene revisionato periodicamente per valutare l'efficacia delle
strategie di mitigazione del rischio, che a sua volta guida le revisioni al piano del progetto e ai conseguenti piani
di iterazione.
La chiave per gestire il rischio è non aspettare che si materializzi (e diventi un problema o un errore), per
decidere cosa fare. Come una modifica di pochi gradi alla rotta di un volo transoceanico ha un grosso effetto su dove
atterra l'aereo, la gestione precoce del rischio è quasi sempre meno costosa e fastidiosa di una pulizia dopo
l'accaduto.
Esistono tre principali strategie [BOE91]:
-
Evitare il rischio. Riorganizzare il progetto in modo che non possa essere influenzato da quel rischio.
-
Trasferimento del rischio. Riorganizzare il progetto in modo che qualcun'altro o qualcos'altro si occupi del
rischio (cliente, fornitore, banca, altro elemento, ecc.). Una strategia specifica dell'evitare il rischio.
-
Accettazione del rischio. Decidere di convivere con il rischio come circostanza imprevista. Monitorare i
sintomi del rischio e decidere sul piano di emergenza da utilizzare nel caso emerga il rischio.
Se si decide di accettare il rischio, si può tentare di mitigarlo, vale a dire intraprendere qualche azione
immediata per ridurne l'impatto.
E' importante distinguere fra rischi diretti e indiretti. In parole povere, un rischi diretto è quello su cui si ha un
qualche grado di controllo; i rischi indiretti sono quelli impossibili da controllare.
Pur non restando ignoranti sui rischi indiretti, hanno poche conseguenze in senso pratico: poiché non è possibile
modificarli, non è costruttivo preoccuparsene eccessivamente. A dispetto del fatto che il mondo potrebbe finire
domani, potrebbe anche non finire e se non finisce sarebbe stato meglio se il lavoro fosse stato
continuato!
A volte un rischi indiretto può essere in realtà un rischi diretto camuffato. Ad esempio, si può dipendere da dei
fornitori esterni per un componente o un insieme di componenti. Questo sembra essere un rischio indiretto, ma
disponendo di piani di emergenza per quei componenti, è possibile prendere il controllo di quel rischio: si possono
scegliere dei fornitori alternativi o sviluppare da soli la funzionalità. In molti casi si ha più controllo di quanto
si pensi!
Con i rischi indiretti, o si individua un metodo per acquisire un certo grado di controllo sui rischi, o se ne prende
semplicemente nota e si passa avanti. Non ha senso angosciarsi su qualcosa che non può cambiare.
Organizzazione
-
C'è sufficiente impegno sul progetto (incluso il settore dirigenziale, i tester, QA ed altre parti esterne
coinvolte)?
-
Si tratta del più grande progetto mai tentato da questa organizzazione?
-
Esiste un processo ben definito per la progettazione software? Acquisizione e gestione dei requisiti?
Finanziamento
-
E' disponibile il finanziamento per portare a termine il progetto?
-
Sono stati stanziati dei fondi per la formazione e il mentoring?
-
Esistono dei limiti di budget tali da dover distribuire il sistema ad un costo fisso o da correre il rischio di una
cancellazione del progetto?
-
Le stime dei costi sono accurate?
Persone
-
Sono disponibili persone sufficienti?
-
Hanno gli skill e l'esperienza appropriati?
-
Hanno già lavorato insieme prima?
-
Credono nel successo del progetto?
-
Le rappresentative di utenti sono disponibili a partecipare alle revisioni?
-
Sono disponibili esperti del dominio?
Tempi
-
La pianificazione è realistica?
-
La funzionalità può essere gestita dall'ambito per rispettare i tempi?
-
Quanto è critica la data di distribuzione?
-
Esiste un tempo per "farlo bene"?
-
Cosa succede se la concorrenza raggiunge prima il mercato?
-
Cosa succede se i fondi sono a rischio (un altro modo di vederla è chiedersi "cosa può garantire un finanziamento
adeguato")?
-
Il valore proiettato del sistema è maggiore del costo proiettato? (accertarsi di giustificare il tempo-valore del
denaro ed il costo del capitale).
-
Che succede se non vengono stipulati i contratti con i fornitori chiave?
-
L'esito positivo può essere misurato?
-
Esiste un accordo su come misurare l'esito positivo?
-
I requisiti sono abbastanza stabili e ben compresi?
-
L'ambito del progetto è fisso o continua ad espandersi?
-
Le scale temporali dello sviluppo del progetto sono brevi ed inflessibili?
-
La tecnologia è stata comprovata?
-
Gli obiettivi di riutilizzo sono ragionevoli?
-
Un prodotto di lavoro deve essere utilizzato almeno una volta, prima di poter essere riutilizzato.
-
Potrebbero essere necessari diversi rilasci di un componente prima che sia sufficientemente stabile da
poterlo riutilizzare senza modifiche significative.
-
I volumi di transazione nei requisiti sono ragionevoli?
-
Le stime di incidenza della transazione sono credibili? Sono troppo ottimistiche?
-
I volumi di dati sono ragionevoli? Possono essere mantenuti sui mainframe attualmente disponibili o, se i requisiti
portano a credere che una workstation o un sistema di reparto faranno parte della progettazione, i dati possono
ragionevolmente risiedere lì?
-
Esistono dei requisiti tecnici insoliti o impegnativi che richiedono al team del progetto di affrontare problemi
dei quali non hanno esperienza?
-
L'esito positivo dipende da prodotti, servizi o tecnologie nuovi o non provati, oppure hardware, software o
tecniche nuove o non provate?
-
Esistono dipendenze esterne da interfacce per altri sistemi, inclusi quelli esterni all'impresa? Le
interfacce richieste esistono o devono essere create?
-
Sono presenti dei requisiti di disponibilità e sicurezza estremamente inflessibili (ad esempio, "il sistema non
deve mai dare errore")?
-
Gli utenti del sistema sono inesperti nei confronti del tipo di sistema da sviluppare?
-
Esiste un rischio aumentato a causa della dimensione o della complessità dell'applicazione o della novità della
tecnologia?
-
E' presente un requisito per il supporto della lingua nazionale?
-
E' possibile progettare, implementare ed eseguire questo sistema? Alcuni sistemi sono troppo vasti o complessi per
funzionare correttamente.
-
Il progetto dipende da altri progetti di sviluppo (paralleli)?
-
L'esito dipende da prodotti pronti o da componenti sviluppati esternamente?
-
L'esito dipende dall'integrazione di tool di sviluppo (tool di progettazione, compilatori e così via), da
tecnologie di implementazione (sistemi operativi, databases, meccanismi di comunicazione fra processi ecc. ecc.)?
Si dispone di un piano di riserva per distribuire il progetto senza queste tecnologie?
L'esperienza insegna che l'85% dei rischi hanno un impatto diretto o indiretto sui tempi e quindi implicitamente sui
costi. Forse il 5% ha solo un impatto sui costi. Il resto non ha impatto diretto sui costi o sui tempi, ma sulla
qualità, ad esempio.
Se il nemico è una scadenza, affrontarlo con distribuzioni incrementali. Evitare di avere una distribuzione enorme nel
tentativo di rispettare la pianificazione.
Alcuni progetti hanno delle scadenze "improrogabili". Ad esempio. il software per analizzare "dal vivo" il risultato di
un'elezione nella notte dell'elezione ha poco valore se è pronto la settimana dopo le elezioni. Oppure il software
potrebbe essere reso obsoleto dalla concorrenza: viene lanciato un prodotto concorrenziale migliore quando il proprio
software è ancora in fase di costruzione. Improvvisamente si è fuori dal gioco e non c'è molto che si possa fare. In
generale, tuttavia, pochi progetti hanno delle scadenze così critiche. I ritardi inficiano principalmente sui costi.
In generale, pianificare i tempi in modo uguale alla migliore stima, più una ragionevole contingenza,
commitment = stima + contingenza
Altri suggeriscono di impostare le aspettative della tempificazione uguali alla strategia di riserva, vale a dire
basarle sui piani di emergenza, ma questo è un po' troppo pessimistico perché non tutti i rischi si
materializzeranno davvero.
I rischi della tempificazione sono integrati in alcuni tool di stima e dei costi. Ad esempio nel modello COCOMO, molti
dei portatori di costo, come:
-
complessità (cplx)
-
vincoli in tempo reale (time)
-
vincoli di memoria (stor)
-
esperienza (Vexp)
-
disponibilità di buoni tool (tool)
-
pressione sui tempi (sced)
sono in effetti dei fattori di rischio.
Tecniche più sofisticate per la gestione del rischio implicano l'uso della simulazione Monte Carlo, in cui viene
eseguito un enorme numeri di "scenari" con un tool di simulazione per calcolare i rischi globali e le contingenze [KAR96].
|