C’è una frase che in consulenza, almeno qui da noi, suona quasi come una bestemmia. Una di quelle cose che pensi mentre guardi l’ennesima riunione trasformarsi in un catalogo di richieste, ma che poi non dici. Perché non sta bene, perché “il rapporto col cliente”, perché il commerciale ti fulmina con lo sguardo e qualcuno ti ricorda che “siamo qui per soddisfare le esigenze”.
Eppure.
Il cliente ha torto.
Non sempre, ovviamente. Non su tutto. Però molto più spesso di quanto ci piaccia ammettere. E mi chiedo se il problema vero non sia il cliente in sé, ma la bugia gentile che gli raccontiamo da anni. Quella del “il cliente ha sempre ragione”. Una bugia che nel software italiano ha fatto danni che non si riescono nemmeno a contare bene, perché i fallimenti raramente hanno un cartello con scritto “fallimento”. Di solito sono più silenziosi. Sono progetti che finiscono in produzione e poi nessuno li usa. Sono soldi bruciati in cose che non migliorano niente. Sono notti lunghe di persone che sapevano che stava andando storto, ma non avevano lo spazio, o il permesso, di dirlo.
Questo è un pezzo un po’ cattivo, sì. Non vi chiedo di essere d’accordo. Vi chiedo solo di essere onesti, almeno per il tempo di questa lettura.
Il sì che uccide i progetti #
Ho visto morire più progetti per un sì che per un no.
Il meccanismo è quasi sempre lo stesso, e proprio per questo fa paura. Il cliente chiede qualcosa. Tu lo sai, lo senti, lo vedi nei dettagli: è sbagliato tecnicamente, o economicamente, o proprio come direzione. Ma dici sì lo stesso.
Dici sì perché c’è un contratto. Perché c’è una relazione da proteggere. Perché “poi lo sistemiamo”. Perché la stretta di mano è già avvenuta e tornare indietro sembra una sconfitta. Perché dire no è scomodo, richiede argomenti, richiede energia, e soprattutto richiede coraggio.
E allora il progetto non muore in un colpo solo. Muore un sì alla volta.
Ogni sì aggiunge una feature che nessuno userà. Ogni sì sposta un pezzo di scadenza, o comprime un pezzo di qualità. Ogni sì rende l’architettura un po’ più fragile e il codice un po’ più contorto, finché quello che stai costruendo non assomiglia più a un prodotto, ma a un compromesso stratificato.
Alla fine consegni un software che fa centocinquanta cose, nessuna bene, e il cliente ti guarda e dice: “non è quello che volevo”.
E qui c’è la parte che brucia, perché in un certo senso ha ragione. Non è quello che voleva. È quello che ha chiesto. Sono due cose diverse.
E forse il nostro mestiere, quello vero, non è eseguire ordini. È riconoscere la differenza.
Catalogo degli orrori (tutti veri, purtroppo) #
Quello che segue è vero. I nomi sono cambiati, ma le dinamiche no. E se vi viene da pensare “ne ho visto uno identico”, ecco, non siete soli.
Il gestionale infinito #
Un’azienda medio-grande chiede un gestionale. Fin qui tutto normale. Poi, mentre si sviluppa, ogni reparto aggiunge requisiti. Risorse umane vuole il modulo ferie, marketing vuole la dashboard, amministrazione vuole l’integrazione col commercialista, e ognuno è convinto di essere il centro del mondo.
Nessuno ha il potere di dire basta, perché ogni reparto è un “cliente interno” che “ha ragione”. Risultato: diciotto mesi di sviluppo, un prodotto che fa tutto male, e dopo il rilascio l’azienda continua a usare Excel. Che alla fine, nel suo piccolo, almeno non tradisce.
Il bando fotocopia #
Un comune deve digitalizzare un servizio. Il bando viene scritto copiando quello di un altro comune, magari tre volte più grande, con bisogni completamente diversi. Dentro ci finiscono requisiti che suonano bene sulla carta, ma che nessun cittadino userà mai.
Chi vince l’appalto spesso lo sa. Ma il bando è il bando. Quindi si costruisce esattamente quello che è scritto. Si consegna, si collauda, si spuntano caselle. La piattaforma va online.
Sei mesi dopo il servizio viene gestito ancora al telefono.
E la cosa più triste è che, formalmente, è andato tutto bene.
L’app che doveva cambiare tutto #
Una PA locale vuole un’app mobile per i cittadini. Il decisore è un assessore che ha visto l’app di un altro comune e la vuole uguale. Niente analisi dei bisogni, niente ricerca utente, niente di niente. Solo: “voglio l’app”.
Il fornitore la costruisce. Al lancio la scaricano in quattrocento. Dopo tre mesi la usano in dodici, contando i dipendenti del comune.
L’assessore fa la conferenza stampa e parla di innovazione. Il fornitore incassa e passa al prossimo.
E io non riesco mai a decidere chi mi metta più a disagio in questa storia.
Il restyling che era una riscrittura #
Un cliente chiede di “dare una rinfrescata” al sito. Il commerciale vende un restyling. Alla prima riunione operativa emerge che il sito non ha un CMS, il database è un foglio Excel, i contenuti non esistono, e “rinfrescata” significa ripensare tutta la presenza digitale.
Ma il preventivo è quello di un restyling, la timeline è quella di un restyling, e le aspettative sono quelle di un restyling.
Tutti sanno che non è un restyling. Nessuno lo dice.
Il progetto zombie #
Un progetto doveva durare sei mesi e entra nel terzo anno. Non funziona, non viene usato, ma nessuno lo chiude perché chiuderlo significherebbe ammettere che è stato un errore.
Il cliente continua a pagare change request. Il fornitore continua a fatturare. Entrambi sanno che è morto. Entrambi fanno finta che sia vivo.
Non fallisce mai ufficialmente. Semplicemente smette di essere nominato nelle riunioni, come uno zio scomodo di cui non si parla a pranzo.
Perché succede davvero #
Succede perché il nostro settore ha un problema strutturale con la verità.
Il modello di business della consulenza IT italiana è costruito sul sì. Vinci i progetti dicendo sì. Mantieni i clienti dicendo sì. Fai carriera dicendo sì. L’intero sistema, dai commerciali ai project manager fino agli sviluppatori, è ottimizzato per minimizzare il conflitto e massimizzare la fatturazione a breve termine.
Il guaio è che breve termine e lungo termine sono in guerra.
Dire sì oggi significa quasi sempre pagare domani. Ogni feature in più è debito tecnico. Ogni requisito accettato senza analisi è una bomba a orologeria. Ogni timeline compressa per compiacere qualcuno è una garanzia di straordinari, spesso non pagati, e di qualità sacrificata.
E intanto il cliente non impara mai. Non perché sia stupido, ma perché nessuno gli dice che quella richiesta era sbagliata. Nessuno gli dice che quel bando era scritto male. Nessuno gli dice che quell’app non serviva a nessuno.
Circondato da gente che annuisce, il cliente continua a chiedere le stesse cose sbagliate, e il ciclo ricomincia.
E qui arriva la parte che dà fastidio, perché sposta la responsabilità.
Non è colpa del cliente. È colpa nostra.
È colpa di un settore che ha rinunciato al proprio ruolo, quello dell’esperto. Quello che sa cose che il cliente non sa e che ha il dovere, non il diritto, di dirle.
Il no come servizio #
Il miglior servizio che puoi rendere a un cliente è dirgli no.
No, quella feature non serve.
No, quella timeline non è realistica.
No, quel bando è scritto male e se lo seguiamo alla lettera costruiremo qualcosa di inutile.
No, non ti serve un’app.
No, non ti serve l’AI.
No, non ti serve un restyling. Ti serve fermarti e capire cosa vuoi fare davvero.
Ogni no costa. Costa scomodità, costa tensione, costa qualche telefonata difficile. A volte costa il progetto.
Però ogni no è anche un atto di rispetto verso il cliente, perché lo tratta come un adulto capace di ascoltare la verità, non come qualcuno da accontentare per quieto vivere.
I clienti migliori che ho avuto nella mia carriera sono quelli a cui ho detto più no. All’inizio si irrigidiscono, com’è normale. Poi, se resisti e se argomenti con calma, succede una cosa: capiscono che quando dici sì puoi essere creduto.
La fiducia non si costruisce sull’accordo continuo. Si costruisce sulla sincerità.
E la sincerità, nel nostro settore, è rara. Forse più rara di un buon developer. Forse più rara di un progetto consegnato in tempo. Forse più rara di un bando scritto bene.
Un manifesto minimo, senza eroismi #
Non so se questo sia un manifesto, ma se lo è, per me sta in tre righe.
Non dire sì quando sai che è no.
Non costruire quello che il cliente chiede se sai che non è quello che gli serve.
E quando sbagli, perché sbaglierai e sbaglieremo tutti, almeno sbaglia dicendo la verità, non annuendo.
Il cliente non ha sempre ragione. Ma merita sempre qualcuno che abbia il coraggio di dirglielo.