La stima dei costi che nessuno prenderà sul serio

Nel mondo dei progetti IT esiste un rituale tanto comune quanto inutile: chiedere ai tecnici di stimare tempi e costi, per poi ignorare completamente le loro previsioni e sostituirle con numeri inventati dal reparto commerciale. Le stime tecniche finiscono nel cestino per fare spazio a previsioni ottimistiche scollegate dalla realtà.

Questo non è un bug del processo, è una feature. La stima tecnica serve per avere un numero da cui partire per negoziare al ribasso fino a raggiungere il prezzo che permette di battere la concorrenza.

La pressione commerciale che distorce tutto

I progetti vengono venduti con la promessa di costare meno della concorrenza. La logica commerciale è semplice: per vincere serve il prezzo più basso. Che quel prezzo non copra il lavoro necessario è un dettaglio di cui preoccuparsi dopo il contratto.

La pressione commerciale porta a sconti progressivi. Si parte dalla stima tecnica, si toglie il 20% per “ottimizzazione”, poi un altro 15% per “competitività”, poi ancora un 10% come “sconto strategico”. Il risultato è un prezzo che copre forse la metà del lavoro effettivo.

Ma i requisiti cambieranno comunque, quindi si recupererà con le modifiche. Almeno questa è la teoria. Nella pratica, i clienti pretendono che le modifiche rientrino nel prezzo originale perché “erano implicite”.

Le scuse per scadenze impossibili

I clienti sono maestri nel giustificare deadline assurde. “Il nostro fornitore ci abbandonerà il mese prossimo!” Spoiler: è lì da quindici anni e non se ne andrà. È solo pressione per ottenere priorità e sconti.

Oppure “La licenza scade tra due mesi!” Quella licenza che magicamente si può sempre rinnovare. Le scuse per giustificare tempistiche assurde sono un’arte: “È per allinearci con la strategia aziendale” (quale?), “Dobbiamo essere pronti per il lancio” (di cosa?).

Queste frasi permettono di usare buzzword senza spiegare nulla. Agile, scalabile, cloud-native, blockchain-ready. Parole che suonano impressionanti ma non significano niente.

L’elasticità dei requisiti

Nessuno si accorge più della differenza tra la stima iniziale e la realtà. I requisiti cambiano così spesso che è come misurare un elastico: dipende da quanto lo tiri.

Un semplice form di login diventa autenticazione biometrica con riconoscimento del DNA. La “pagina di contatto base” si trasforma in un CRM completo. Il “report semplice” evolve in business intelligence con dashboard interattive.

Ogni volta che un requisito cambia, si potrebbe rinegoziare. Ma il cliente sostiene che il nuovo requisito era “ovviamente implicito” in quello originale. “Quando abbiamo chiesto autenticazione era chiaro che volevamo anche recupero password, doppia autenticazione e integrazione con Active Directory”.

Il teatro della stima tecnica

Mentre il tecnico aggiorna per la centesima volta il foglio di calcolo, qualcuno ha già venduto il progetto promettendo la luna con tempi di consegna di una pizza. Le ore di sviluppo vengono trattate come risorse infinite comprimibili a piacimento.

La logica sembra: se una donna fa un bambino in nove mesi, nove donne lo faranno in un mese. La complessità intrinseca del software viene ignorata.

Quando gli sviluppatori protestano, la risposta è “dovete essere più efficienti” oppure “con agile si può fare”. Come se agile fosse una formula magica che trasforma due mesi di lavoro in due settimane.

L’esplosione del budget

Il budget segue un percorso prevedibile. Si parte da una cifra ottimistica. Poi emergono modifiche: “Solo questo piccolo cambiamento”. Poi altre: “È una cosa veloce”. Poi integrazioni: “Ci vorranno pochi giorni”.

È come mangiare un biscotto e finire per divorare l’intero pacco. Solo che invece dei biscotti sono ore di sviluppo, e invece dei sensi di colpa c’è il management che chiede perché ci vuole così tanto per un pulsante.

Ogni feature aggiuntiva sembra triviale singolarmente. Ma la somma di cento “piccole cose” è un progetto completamente diverso da quello stimato inizialmente.

La deadline immutabile

L’unica vera costante è l’imprevedibilità. I requisiti cambiano, le priorità si ribaltano, le emergenze si moltiplicano, ma la deadline rimane fissa come una stella polare.

Non importa quante modifiche siano state richieste, quante funzionalità aggiunte, quanti problemi emersi. La data di consegna stabilita nel contratto rimane sacra. L’unica cosa più irrealistica di una stima iniziale è credere che qualcuno la prenderà sul serio.

Quando si fa notare che le modifiche hanno fatto slittare i tempi, la risposta è sempre: “Ma la deadline non può cambiare, è scritta nel contratto”. Che anche i requisiti siano cambiati viene dimenticato.

La stima come strumento di negoziazione

La stima iniziale, già di per sé imprecisa, diventa semplicemente uno strumento di negoziazione commerciale. Il prezzo raramente riflette il vero impegno richiesto.

Con la volatilità dei requisiti e i continui cambiamenti, spesso ci si ritrova a non accorgersi nemmeno di quanto il progetto stia deviando dal piano. Le modifiche si accumulano una dopo l’altra, ciascuna apparentemente piccola, fino a quando il progetto finale non ha quasi nulla in comune con quello stimato.

La stima diventa un numero simbolico, un punto di partenza per una negoziazione che si protrarrà per tutta la durata del progetto.

La sfida vera della stima

Stabilire tempi e costi precisi per un progetto informatico è una delle sfide più ardue. Non è fare calcoli matematici: è quasi una premonizione, prevedere l’evoluzione di un progetto complesso e in continuo mutamento.

La difficoltà parte dall’ambiguità nei requisiti. Si parte con informazioni incomplete e, man mano che si avanza, nuove necessità emergono come funghi, gonfiando costi e tempi. Le previsioni devono essere continuamente ricalibrate, ma riconoscere ufficialmente questi cambiamenti diventa una battaglia.

La scommessa inevitabile

La stima di tempi e costi è un esercizio di equilibrio tra desideri, pressioni commerciali, volatilità dei requisiti e variabili imprevedibili. Ogni stima è una scommessa audace, dove il vero costo e il tempo necessario rimangono spesso un mistero fino all’ultimo.

Mentre i numeri vengono continuamente rinegoziati, il progetto si trasforma in un perpetuo “Verrà fatto… forse”, in cui la precisione è un lusso raro. L’importante non è stimare correttamente, ma stimare in modo strategicamente utile: abbastanza basso da vincere il contratto, abbastanza alto da non sembrare completamente folli.

La vera abilità non sta nel prevedere accuratamente il futuro, ma nel gestire le aspettative quando il futuro si rivela inevitabilmente diverso dalle previsioni. E in questo, l’industria IT ha sviluppato una competenza impareggiabile nell’arte di far sembrare che tutto proceda secondo i piani, anche quando chiaramente non è così.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT
• Cosa fa un Sistemista in un Managed Service Provider: ruolo e giornata tipo
• Dieci clienti, un solo Sistemista: come si gestiscono le priorità in un Managed Service Provider