Da due-tre anni a questa parte, oltre a coltivare la passione / lavoro per lo sviluppo di applicazioni web, mi sono interessato alla gestione dei progetti.

Inizialmente è stato uno shock: da un giorno all’altro mi hanno detto: "tie’, questa è la tua nuova collega, così potrai fare il doppio di quel che facevi già. Trattala bene". Con la mia collega siamo cresciuti insieme, per un po’, poi le nostre strade si son separate, lei ha gestito progetti ed altre persone, eccetera.

All’inizio non capivo. Non capivo le dinamiche di responsabilità, i problemi di comunicazione, la differenza tra autorità ed autorevolezza. Mi mancava qualcosa.

Un giorno, a Fiumicino, di ritorno da una trasferta piuttosto faticosa, mi balza l’occhio su  un libro: Il project Management - Come gestire il cambiamento e l’innovazione

Con non poca fatica inizio la lettura in aereo. Niente da fare, serve concentrazione. A casa, piano piano, pagina dopo pagina, mi si apriva un panorama di cose nuove. Alcune in realtà non lo erano affatto, le avevo già viste in Ingegneria del Software. Ma mancavano del background culturale da cui provenivano: la realtà industriale e la cosiddetta industria del software hanno tanti punti in comune, ma anche tantissime divergenze. Non si può applicare la logica produttiva manifatturiera al software, perché il software non può essere paragonato ad una macchina. Anzi, un software è più simile alla catena di montaggio che produce la macchina. E le famigerate Software factories descritte in "the business of Software" di Cusumano non hanno sempre prodotto grandi software, alla fine.

Gran parte dei problemi di gestione in un progetto software sono legati alla comunicazione. Alla fine, un progetto software
 è fatto di persone che comunicano. Ed è per questo motivo che è difficile gestire grossi progetti, con molte persone.

Il numero di discorsi si moltiplica esponenzialmente all’aumentare delle persone coinvolte, ed il progetto tende quindi a rallentare fino quasi a fermarsi.

Questo comportamento è illustrato dalla legge di Brooks:

Adding manpower to a late software project makes it later.

Aggiungere risorse umane ad un progetto già in ritardo non fa altro che ridardarlo ulteriormente.

Le persone partecipanti al progetto devono prendere confidenza con i protocolli usati, le abitudini, le usanze, il vocabolario… Insomma, si devono acclimatare, e questo comporta un costo in termini temporali. Non sempre, inoltre, tutto fila liscio: per alcune persone l’integrazione potrebbe risultare difficile se non dannosa, per vari motivi:

• Mancanza di fiducia
• Mancanza di chiarezza nei ruoli
• Motivazioni personali
• Scarsa adattabilità

Su queste cose vorrei ritornarci in seguito, per il momento mi fermo qui