C'è un equivoco che torna sempre, soprattutto quando si parla di sviluppo software: se una cosa si può fare, allora si deve fare.
La realtà è un'altra. Un progetto può essere tecnicamente fattibile — magari anche relativamente semplice — e allo stesso tempo essere una pessima idea da iniziare: la tecnologia lo permette, il contesto intorno lo rende ingestibile. Ed è qui che si vede la differenza tra chi sviluppa e chi fa consulenza.
Fattibile non significa sostenibile
Costruire una demo è spesso facile. In poche ore puoi dimostrare che una certa cosa "funziona": estrai un dato, automatizzi un passaggio, fai vedere un risultato. Il problema è che quella demo viene quasi sempre interpretata come una promessa.
Una soluzione che gira una volta può non reggere alla seconda. Su un caso controllato può funzionare; davanti alla variabilità del mondo reale può crollare. Funzionare oggi non garantisce di essere mantenibile tra sei mesi, quando i casi limite iniziano a emergere. La distanza tra "si può fare" e "funziona davvero in produzione" è esattamente il posto dove nascono i problemi, e quella distanza è fatta soprattutto di aspettative.
L'allineamento conta più del codice
I progetti software non saltano perché il codice è difficile. Saltano perché chi lo commissiona e chi lo costruisce stanno risolvendo due problemi diversi senza accorgersene.
Succede quando il problema non è definito con chiarezza, quando i limiti tecnici vengono trattati come ostacoli negoziabili, quando il budget è scollegato dalla complessità reale, quando una prova diventa — nella percezione del cliente — una garanzia.
In queste condizioni, il progetto parte già disallineato, e più vai avanti, più l'allineamento peggiora. All'inizio sono piccole incomprensioni, poi diventano discussioni, poi diventano "ma tu avevi detto che…". E a quel punto il problema diventa relazionale, prima ancora che tecnico. È la stessa dinamica che porta a scope creep continuo travestito da agilità.
Il vero lavoro di un consulente
Chi è all'inizio della carriera tende a dire sì. È normale: vuoi lavorare, vuoi dimostrare che sei capace, vuoi portare a casa il progetto. Con il tempo, inizi a vedere pattern che si ripetono.
Non guardi più solo cosa ti stanno chiedendo di costruire. Guardi quanto è chiaro il problema, quanto sono realistiche le aspettative, quanto è disposto il cliente ad accettare vincoli e compromessi, quanto è probabile che a metà progetto il perimetro cambi.
E a un certo punto capisci che il tuo lavoro non si esaurisce nel costruire software: comprende anche decidere se vale la pena iniziare a costruirlo. Dire sì a un progetto con presupposti sbagliati sposta il problema più avanti nel tempo, quando sarà più costoso per tutti — chiamarla flessibilità è un'illusione consolatoria.
Il costo dei progetti sbagliati
Accettare un progetto che nasce male ha sempre lo stesso finale. All'inizio sembra tutto normale. Poi arrivano le prime frizioni, il perimetro si allarga, le aspettative cambiano, il tempo non basta più. A quel punto qualcuno perde: a volte il cliente, che si ritrova con qualcosa che non corrisponde a quello che aveva in testa; a volte il fornitore, che lavora più del previsto per rimanere dentro a una promessa fatta troppo presto; spesso entrambi.
E nel mezzo c'è la cosa più costosa: tempo buttato. Tempo che non torna indietro, né per chi paga né per chi lavora. È lo stesso meccanismo per cui partire da una conversazione sul budget invece che da un preventivo salva entrambe le parti dal disastro.
Il no come atto professionale
Dire no a un progetto, in molti casi, equivale a riconoscere un rischio prima che sia tardi — più che a rifiutare un'opportunità. È dire: in queste condizioni, con queste aspettative e questo livello di chiarezza, la probabilità che questo progetto finisca male è troppo alta. Più che una questione di volontà, è una questione di responsabilità.
Chi dice sì a tutto sembra più disponibile: spesso è solo meno esperto, o meno attento alle conseguenze. Chi si ferma prima evita di creare un problema che poi qualcuno dovrà risolvere.
Il segnale da leggere
Se un professionista ti dice di no, la lettura più semplice è che "non ha voglia" o "non ha capito il progetto". A volte è vero. Più spesso, però, sta vedendo qualcosa che tu, da dentro, non riesci ancora a vedere: un disallineamento che crescerà, una complessità nascosta, una combinazione di fattori che rende il progetto fragile prima ancora di iniziare. Per riconoscerli prima ho dedicato un articolo specifico ai segnali che un progetto software finirà male.
Non tutti i progetti vanno iniziati. E una delle competenze più sottovalutate, in questo mestiere, è saperlo riconoscere prima.
Simone Giusti
Consulente software strategico
