Qualunque progetto non può fare a meno di un approccio sistematico nella fase di preparazione, e del controllo rigoroso durante l’esecuzione. Le attività di un progetto si eseguono una sola volta, o almeno dovrebbero essere eseguite una sola volta. I rifacimenti sono  dannosi e sono sempre frutto di un errore di valutazione in una fase precedente.

Nei progetti di sviluppo software, se i processi sono ben definiti, il team di progetto può dedicarsi maggiormente al lavoro produttivo e procedere spedito verso la conclusione del progetto. Mentre in presenza di processi vaghi, il team  dovrà dedicare più tempo alla correzione di errori precedenti o a negoziare la corretta prosecuzione del progetto.

Per “Processi Software” si intende una serie di attività preliminari indispensabili per mettere insieme tutti gli elementi di un progetto di sviluppo software. Steve McConnell  nel suo  libro dal titolo “Software Project – Survival Guide” osserva l’effetto  positivo dell’orientamento ai processi e del disastro in sua  assenza.

Per processo si  può intendere una infinità di cose, ma nello sviluppo software generalmente si intende:

• Ottenere per iscritto tutte le esigenze dell’utente (requirement),

• Stabilire una procedura formale per controllare le variazioni alle esigenze dell’utente,

• Verificare la validità tecnica dei requisiti espressi dall’utente, del relativo disegno e del successivo codice prodotto,

• Sviluppare il piano di qualità con piano di test, piano  di verifica e tracciamento degli errori con successive correzioni.

• Sviluppare il piano di implementazione per stabilire l’ordine dell'entrata in produzione dei singoli componenti da integrare,

• Individuare gli strumenti  per il controllo automatico del codice,

• Rivedere periodicamente i costi  e le stime dei tempi ad ogni milestone del progetto. Ad esempio:

  • al completamento dell’analisi delle esigenze dell’utente,

  • al completamento della scelta dell’architettura,

  • al completamento del disegno di dettaglio,

  • al completamento  di implementazione di ogni fase.

Ovviamente, ci possono essere molti altri processi, ma ciò che conta è l’approccio sistematico al problema. I processi definiti possono essere pienamente condivisi da alcuni, magari esagerando nella fiscalità della loro applicazione, mentre, purtroppo, possono essere ritenerli inutili ed ignorati da altri. Questa seconda categoria è pericolosa, per se stessa, per il team di progetto e per il committente.

Un Capo Progetto, anche se molto esperto, non può esimersi dal fornire o pretendere tutte le informazioni  relative all’oggetto da realizzare, perché un fallimento mette a  repentaglio i finanziamenti del committente, il posto di lavoro del team di progetto  ed il patrimonio della sua azienda.  L’approccio sistematico consente di individuare in ogni momento gli scostamenti dal piano, l’incidenza degli  errori, il contenuto esatto del progetto ed i relativi costi e le stime a finire.  L’approccio sistematico con l’utilizzo di procedure predefinite, senza burocratizzare ogni passaggio, ha dei costi stimati tra il 10 ed il 20% dell’intero progetto.

McConnell  dimostra che lil 15- 20% in project management è un investimento giustificato,  se confrontato con il  costo del  lavoro improduttivo (trashing) dovuto alla scoperta di errori in fasi troppo avanzate dello sviluppo.

Le fasi in cui si possono introdurre degli errori in un progetto di  sviluppo sono nell’ordine:

1. Requisiti (Requirement )

2. Architettura (Archittecture) 

3.  Disegno di dettaglio (Detailed design)

4. Codifica (Construction)

Più avanti nel tempo viene scoperto l’errore o la mancanza di una funzione importante, più alti saranno i costi in termini di lavoro improduttivo. Per lavoro improduttivo bisogna intendere qualsiasi attività di rifacimento (codifica, casi di prova, manuali utente, specifiche tecniche, manuali  operativi). Risolvendo i problemi nelle prime fasi  anziché nelle ultime si possono ottenere risparmi  da 50 a 200 volte.

 “An investment made in process at beginning of the project produces large returns later in the project”

("Un investimento fatto all'inizio del progetto produce grandi ritorni più tardi nel progetto")

 Ecco la rappresentazione grafica dell'incidenza del lavoro improduttivo in assenza di un approccio per  processi.

Se, a inizio progetto, si trascura  l’approccio sistematico, ne consegue che appena le cose si complicano, si è costretti a mettere ordine improvvisando procedure analoghe a quelle che si dovevano adottare nella fase iniziale del progetto. In questo caso, il lavoro improduttivo anziché essere  lineare, si impenna, rendendo anche necessaria l'istituzione di nuovi processi di gestione.  In pratica il lavoro improduttivo (riunioni, rifacimenti, discussioni, analisi a posteriori) impediscono di svolgere lavoro  produttivo, arrivando  anche  a bloccare l'avanzamento del progetto,  come si può osservare nel grafico che segue (esempio di stallo prima della conclusione del progetto).

Dotandosi fin dall’inizio di procedure e strumenti per controllare il progetto, la quantità di lavoro improduttivo  può essere contenuta ai soli errori umani, tipici dei progetti di sviluppo software.

L'intero team, orientato ai processi, sembrerà meno produttivo nella fase iniziale ma poi procederà senza alcun ostacolo.

L’impegno iniziale nel documentare sistematicamente il piano di progetto, le riunioni periodiche ed il coinvolgimento delle parti interessate (utenti, supporto tecnico, assistenza fornitori, committente) effettivamente  è maggiore. Però superata la fase di avvio, l’ambiente diventa sereno e si procede con la massima speditezza verso il traguardo.

Tutti i membri del team di progetto, qualunque sia il loro ruolo, hanno una chiara visione dello stato di avanzamento dei lavori. Non vi sono corse al recupero dei ritardi ed il morale del gruppo di lavoro è alto in quanto lo stress è minimo. Anzi, poiché il team di progetto in questo modo crede in quello che fa, l'entusiasmo e la fiducia in se stessi aumenta in vista del completamento del progetto. Se il progetto è organizzato per rilasci parziali, questo approccio consente di soddisfare anche le aspettative dell’utente.  Il grafico rappresenta il rapporto tra  lavoro improduttivo per rifacimenti e gestione  di progetto, rispetto al lavoro produttivo che in pratica anziché aumentare come nel caso precedente, tende a scomparire, salvo le riunioni  di verifica e di accettazione  del prodotto verso fine progetto.