Il rischio nei progetti yIMS™

Custom Software: quali i rischi in un progetto software ad-hoc

Maso Ricci

Che le soluzioni di sviluppo custom siano un business rischioso non è di certo un segreto. Ci sono tante cose che possono andare storte o funzionare in modo differente da quello atteso e tentare di costruire un software che risponda precisamente ad esigenze uniche, che nessun software commerciale ha saputo soddisfare, non è certo indolore. É qualcosa di veramente difficile.
I nostri clienti sanno bene che è una cosa impegnativa, rischiosa e ci ingaggiano proprio per la nostra esperienza e le nostre capacità nel gestire questo rischio.

Ogni cliente, per noi, è importante quanto gli altri, non cerchiamo storie d'amore ma solidi e produttivi legami: per ciascuno desideriamo la felice conclusione del progetto e per ciascuno profondiamo tutto l'impegno di cui siamo capaci, affidandoci alla nostra esperienza ed alle nostre competenze. Ma nonostante la nostra professionalità e l’interesse congiunto capita che qualche progetto incontri qualche difficoltà e finisca di traverso. Ci sono un sacco di fattori che possono portare a questo triste risultato.

Talvolta è il cliente stesso a contrastare il cambiamento, nonostante sia consapevole della necessità. Anche se può sembrare un paradosso è possibile: in alcuni ambienti il cambiamento è molto lento e spesso indesiderato perché contrario alla politica della standardizzazione dei processi, altrove sono le persone che tentato di resistere ai mutamenti perché ormai “affezionati” ai modelli già in place. Mi è capitato di vivere in prima persona situazioni in cui il team di analisi non è stato accolto con fiducia e ogni commento è stato recepito come un rimprovero. Anche in questi casi siamo riusciti a guadagnarci le simpatie di tutti attraverso i risultati.

Purtroppo capita anche che siano proprio le persone a non lavorare bene insieme: in qualunque team, a prescindere da competenze tecniche ed esperienza, bisogna che sussista alchimia, che i membri si fidino gli uni degli altri e che condividano lavoro e idee in maniera positiva. In alcuni casi, soprattuto quando i nostri team di sviluppo si sono affiancati al personale del cliente, quel qualcosa non si è creato all’istante e quel particolare rapporto di fiducia ha richiesto del tempo per instaurarsi. Sono i casi in cui gli ingranaggi vanno a posto con calma, ci vuole un po’ perché l’orologio prenda a girare.

In talune situazioni i colpevoli siamo noi stessi. Migliorare i processi spesso significa semplicemente analizzarli con cura, magari con l’imparzialità del punto di vista esterno. E questo ci ha permesso tramite la sola analisi di  di ridurre le necessità richieste ad un nuovo software.

Infine può capitare che non sia qualcosa di ben definito: tralasciando le difficoltà economiche, i cambi di rotta e il fattore umano, la tecnologia alla quale il cliente si affida potrebbe essere relativamente nuova o poco conosciuta, o magari potrebbero essere coinvolte tecnologie o sistemi proprietari che vanno integrati as-is.

Nessuno può prevedere tutto ciò che potrebbe potenzialmente influenzare il progetto, è il bello della vita! Per questo motivo oltre ad un’adeguata preparazione è necessario essere pronti e saper reagire agli imprevisti, piuttosto che lavorare soltanto sulle previsioni. E questa capacità non deve essere appannaggio esclusivo del PM o del responsabile dello sviluppo, è necessario che ciascuna delle persone coinvolte senta suo il progetto e sia in grado di captare tempestivamente ogni presagio per rispondere direttamente al problema oppure per evidenziare la cosa a chi ha il potere per gestirla. Questo è un fondamentale del risk management. ...sembra così banale quando viene raccontato così, vero?

Ovviamente non basta identificare i rischi, occorre saperli valutare, gestire e contrastare. Nella mia esperienza ho preso a identificare i rischi come “oggetti” causa/effetto: in questo modo si evita di pensare ai rischi come degli eventi esclusivamente negativi e li si percepisce come modifiche non volute alla rotta stabilita che potrebbero verificarsi in assenza di un’azione correttiva.
Per tutti questi eventi in grado di mutare il progetto, bisogna poi identificare i due fattori chiave: la probabilità che si verifichino effettivamente e l’impatto sul progetto intero.

Eppure identificare e gestire fattori di rischio all’interno di un progetto è un’arte che pochi riescono a padroneggiare. E nessuno conosce una ricetta segreta: non si tratta di una scienza esatta, c’è bisogno di avere sensibilità per queste cose. E questa sensibilità è una merce rara, nonostante tutto. Ecco perché molti clienti non vogliono rischiare senza avere un’adeguato supporto.