Il tecnico smanettone molte volte da un tempo basso anche perchè non ha tutti gli elementi su cui valutare il progetto.
Tipicamente a monte è stata fatta una analisi sommaria, tipicamente da un non tecnico che ha scritto un bel documento word di specifica dei requisiti e che per mancanza di tempo, aumento dei costi (il tempo è denaro dopotutto) o di competenza viene fatto passare come documento di analisi.
Un documento del genere non includerà mai tutte le casistiche limite e andarle a discutere tutte a priori a mio parere ha anche poco senso perchè:
- i tempi di analisi esploderebbero ed il commerciale non te li passerebbe mai
- non si può porre un limite alla fantasia all’utente che tipicamente non ha limiti ma al limite gli si potranno proporre dei metodi per lavorare che risolvano il suo “problema”

Camillo Precisini invece non sarà mai pago dell’analisi (sia che la faccia lui sia che venga fatta da un’analista) ponendo sempre dubbi (ragionevoli o meno) per cui il progetto avrà non solo una stima eccessiva di giornate e terminerà in ritardo ma il suo sviluppo partirà pure in ritardo.
Se poi aggiungiamo che per molti non tecnici la documentazione da loro prodotta è sempre sufficiente e non ne serve altra per procedere con lo sviluppo (analisi e progettazione vengono quasi sempre dimenticate e il testing percepito come incapacita del tecnico stesso di scrivere codice come si deve) la frittata non è fatta in arrivo ma già in partenza.

Per mediare i due estremi (e per esperienza diretta) è a mio parere sempre e comunque necessaria una fase di macro analisi fatta da un tecnico (sembra stupido specificarlo?) che parteciperà attivamente a tutto il progetto.
Questo si occuperà di individuare le macro aree da sviluppare e procederà alla micro analisi.
Collaborerà attivamente con il progettista e con gli sviluppatori se non è grado, per tempi e dimensioni del progetto ad essere parte integrante del team in queste fasi.
Dopo “la perdità di tempo iniziale” (perchè come già detto non scrivere codice vuol dire essere indietro agli occhi esterni) con ogni probabilità si riuscirà a:
- consegnare un semilavorato in grado di trattare il “caso buono” e cioè quello per cui i dati seguono il flusso ideale nell’applicativo.
- adattarsi fin da subito a soluzioni limite perchè non ci si vedrà costretti fin dal giorno zero (primo rilascio) ad accrocchiare soluzioni per tappare le falle
- realizzare qualcosa di abbastanza robusto da non andare in errore ogni 3 per 2.
- di instaurare un rapporto di fiducia con il committente che non si basa sul “siccome paghi faccio tutto quello che vuoi” ma piuttosto sul “siccome paghi vogliamo offrirti un servizio di qualità” (e le due cose di solito non coincidono).

Alla fine cosa si scopre?
Che per aumentare le speranze di riuscita di un progetto il Project Manager deve essere un tecnico (e con buone competenze) e che deve avere le mani in pasta nel progetto e non solo coordinare il team ed i rapporti con il cliente (che alla fine si riduce a fare il passacarte).
Ho scoperto l’acqua calda?
Secondo me si… purtoppo la realtà dimostra che non è così.

Scusa ancora la lunghezza (non è una risposta ma quasi un post…)

ciao Terenzio