Progetti software come startup di impresa

Qualche mese fa abbiamo pubblicato un post contenente una riflessione sulle caratteristiche che giudichiamo essenziali perché un progetto software si possa dire un progetto di successo.

Vogliamo riprendere l’argomento proponendo il nostro punto di vista sui ruoli, le strategie e le responsabilità nel garantire questo risultato.

Dinamiche come quelle descritte dalla simpatica strip che introduce l’articolo sono senz’altro familiari a chiunque abbia avuto a che fare con la realizzazione di progetti software.

La complicata realtà che la vignetta racconta è quella di progetti nei quali:

• i clienti sono investiti (o si appropriano) dell’onere/onore di tradurre le loro esigenze in requisiti funzionali;
• il project manager si limita a svolgere funzioni di rendicontazione e di mediazione formale tra il cliente e il team di progetto;
• i programmatori  interpretano il loro lavoro come mera codifica software di requisiti funzionali voluti e descritti da altri, rispetto ai quali poco o niente sono interessati a comprendere.

La nostra esperienza documenta in modo inequivocabile che una configurazione di questo tipo del “team esteso” di progetto (dove comprendiamo anche il cliente) non può funzionare! Genera aborti progettuali o comunque progetti che non possono in nessun modo dirsi di successo: per raggiungere gli obiettivi, tempi e costi lievitano all’inverosimile.

Un progetto software è una realizzazione di una complessità intrinseca che chi non ne ha mai fatto diretta esperienza difficilmente riesce ad immaginare. Non a caso la disciplina del project management si è sviluppata nei tempi moderni per fare fronte a problematiche di gestione di grandi opere civili, militari o importanti realizzazioni software.

All’interno di un progetto software si sovrappongono aree di competenza e tematiche molteplici:

• il dominio applicativo al quale il progetto si rivolge (cartelle cliniche piuttosto che processi industriali, fiscali, di vendita, …);
• la gestione, anche psicologica. di team di persone compositi;
• la pianificazione e il controllo gestionale di risorse (cose e persone);
• le tecnologie molteplici alle quali un progetto software può fare riferimento;
• usabilità delle interfacce software;
• gestione di dinamiche tipiche dell’organizzazione all’interno della quale il risultato progettuale deve essere calato e messo in esercizio;

Com’è possibile che il “team esteso” di progetto riesca ad essere presente e competente su tutti questi fronti?

Se diamo per scontati vincoli di dimensionamento del team derivanti da budget spesso sottodimensionati (sopratutto in Italia la percezione del costo/valore della produzione software è poco diffusa tra i manager) e, l’impossibilità pratica per progetti “normali” di poter coinvolgere specializzazioni professionali così variegate, quali opzioni rimangono?

La prima opzione, quella normalmente praticata, è la rinuncia a qualche dimensione del problema. Il fornitore (interno o esterno che sia) riduce il suo ruolo al solo ruolo tecnico: in fondo siamo dei programmatori, dei tecnici del software, diteci cosa volete e ve lo realizziamo con tempi e costi variabili, dipendenti dalla capacità del richiedente di descrivere requisiti in modo chiaro e tempestivo. In questo scenario, il cliente viene investito di fatto dell’onere -del tutto improprio- di tradurre le sue esigenze in requisiti e le dinamiche di interazione progettuale diventano quelle descritte dalla vignetta.

La seconda via, è la strada che quotidianamente mettiamo in pratica con i nostri progetti. L’idea nella sua essenza è quella di mettere in moto all’interno del  team di progetto esteso, una dinamica analoga a quella che si genera nelle startup di impresa.

Perché ciò si possa realizzare, da un punto di vista organizzativo, è fondamentale che il team si configuri come una task force: tutte (o quasi) le risorse sono per un certo periodo di tempo dedicate al progetto; il project manager diventa una sorta di CEO di questa startup di impresa, il mercato (lo sponsor del progetto) diventa, in modo più o meno diretto, familiare a tutti i componenti del team e diventa partecipe della vita e dello sviluppo del progetto.

Nelle startup di successo, prima di arrivare ad una strutturazione di organigrammi complessi, il team di impresa è snello e pur prevedendo alcune distinzioni di responsabilità, tutti si debbono sentire responsabili di tutto. La realtà ci testimonia come questo sia il miglior modo per conciliare, costi contenuti e velocità nei processi decisionali, garantendo un accettabile livello di presidio di tutte le dimensioni dei problemi e delle dinamiche che il percorso progettuale/imprenditoriale presenta.

Il primo risultato prodotto dalle startup normalmente non è perfetto ma, se la soluzione è ben costruita, ci sarà modo di migliorarlo senza aggravi di costi eccessivi, in modo continuativo a partire dall’istante successivo alla messa alla prova della soluzione rilasciata.

La stessa dinamica deve succedere nel team di progetto: le diverse predisposizioni o specializzazioni dei diversi componenti del team vengono valorizzate dal Project Manager/CEO ma nessuna specializzazione assegnata può e deve diventare motivo per perdere una preoccupazione globale di tutti su tutti sugli obiettivi progettuali. Il dominio tematico in modo più o meno approfondito diventa una competenza una problematica familiare a tutti.

In un quadro operativo di questo tipo, quando il P.M. o un qualunque programmatore sospetta che il cliente non abbia le idee sufficientemente chiare nel formulare le sue richieste, che la soluzione funzionale proposta  sia parziale e non riesca a tenere conto di casistiche che il cliente o il collega in questo momento non riesce a vedere, si deve sentire in dovere di intervenire per provare a verificare i suoi dubbi.

La distinzione di ruolo tra il committente e il team di progetto tende a scomparire: dover ritornare sul codice a causa di una errata specificazione di un requisito deve risultare una sconfitta per tutti! Realizzare una interfaccia percepita poco usabile da parte degli utenti finali con il rischio che questo determini un rigetto della soluzione realizzata è una preoccupazione diffusa.

Il cambiamento di metodo che proponiamo (e pratichiamo !), oltre a basarsi su alcuni accorgimenti organizzativi, è fondamentalmente una strategia volta al coinvolgimento delle persone, una responsabilizzazione diffusa tra tutti gli attori che partecipano al progetto. Alla fine di un progetto dedicato ad una cartella clinica relativa a patologie genetiche, il fatto che un programmatore diventi un discreto conoscitore delle problematiche caratteristiche di quella patologia diventa la norma.

Un effetto collaterale entusiasmante di questa esperienza è che, mentre si arriva a conquistare risultati progettuali soddisfacenti, si vedono fiorire e crescere le persone e le relazioni tra persone in modo sistematico, a volte clamoroso.

Il progetto successivo gode dei risultati dei progetti precedenti: team affiatati e desiderosi di fare altre esperienze interessanti e coinvolgenti, capacità diffusa di leggere e immergersi nella realtà caratteristica del nuovo progetto, potenziale opportunità di trasporre soluzioni identificate nei vecchi progetti, magari rivolte a domini applicativi molto differenti, sui nuovi progetti.