Quando un progetto va male, tutti guardano allo sviluppo. Al team, ai tempi, al budget. Il problema, quasi sempre, era già lì settimane prima — quando nessuno aveva ancora scritto una riga di codice.
C’è un tipo di conversazione che conosciamo bene. Un’organizzazione ha completato un progetto digitale, o è a metà, e qualcosa non torna. I costi sono cresciuti oltre le previsioni. Il sistema funziona, ma non risolve quello che avrebbe dovuto. Oppure non lo usa nessuno.
La causa viene cercata nello sviluppo: il team non ha capito le esigenze, la tecnologia era sbagliata, le specifiche erano incomplete. Raramente qualcuno guarda alla fase precedente — quella in cui si è deciso cosa costruire, per chi e perché. È lì che quasi tutto si decide. Ed è lì che quasi tutto va storto.
Il costo delle domande non fatte
Prima di ogni progetto c’è un momento in cui il costo di cambiare direzione è ancora basso. È la fase in cui si analizza l’ecosistema esistente, si mappano le dipendenze critiche, si traducono gli obiettivi di business in requisiti tecnici verificabili. Quello che chiamiamo assessment operativo non è una formalità — è il momento in cui emergono le cose che nessuno aveva esplicitato.
In un progetto che ci è stato portato a metà sviluppo — l’organizzazione cercava supporto dopo che i tempi avevano iniziato a slittare — abbiamo trovato tre mesi di lavoro, circa 60.000 euro di investimento, destinati a un sistema di reportistica che nessuno usava. Non perché fosse mal costruito. Gli operatori lavoravano su mobile in magazzino, e il sistema era stato progettato per desktop. Non era mai stato chiesto esplicitamente, non era mai stato verificato. La scoperta era arrivata al collaudo. Rifare l’interfaccia aveva richiesto altre sei settimane e spostato il go-live di due mesi.
Una singola domanda posta prima avrebbe evitato tutto. Ma quella domanda non era nel processo.
Un progetto che parte senza aver capito il contesto non è un progetto. E’ un’ipotesi costosa.
Le domande che fanno la differenza
Non si tratta di fare più riunioni o raccogliere più requisiti. Si tratta di fare le domande giuste — quelle che nessuno pone perché rallentano l’avvio, ma che determinano se il sistema avrà valore reale o sarà dismesso entro due anni.
Le tre domande che cambiano tutto
- Qual è il processo che si blocca se questo sistema non funziona per 24 ore?
- Quale dato oggi viene ricostruito manualmente — e da chi?
- Quale integrazione sarà inevitabile nei prossimi 12-24 mesi?
Queste domande non sono tecniche. Sono domande di business. Ma le risposte determinano scelte architetturali che, se prese nella direzione sbagliata, costano mesi e budget per essere corrette.
Perché non tutti sono pronti a lavorare così
L’assessment operativo richiede che l’organizzazione sia disposta a rispondere a domande scomode prima di avere un preventivo in mano. Richiede che i decisori dedichino tempo a una fase che non produce ancora nulla di visibile. Richiede di accettare che la risposta possa essere “non siete pronti a partire adesso”.
Non tutte le organizzazioni sono in questa condizione. Alcune hanno vincoli di tempo reali che rendono impossibile rallentare. Alcune hanno già preso decisioni architetturali che non possono essere rimesse in discussione. Alcune non hanno ancora chiarezza sugli obiettivi di business — e costruire un sistema in quella condizione produce quasi sempre risultati che deludono.
Con queste organizzazioni, il lavoro più utile che possiamo fare non è iniziare a sviluppare. È aiutarle a capire cosa serve prima di farlo.
Il vantaggio di chi fa le domande giuste prima
Le organizzazioni che investono nella fase di definizione non ottengono solo sistemi migliori. Ottengono sistemi che le persone usano davvero, che reggono la crescita, che si integrano con quello che verrà dopo. E non devono rifarlo da capo diciotto mesi dopo il lancio.
Il vantaggio competitivo non sta nella tecnologia scelta. Sta nel metodo con cui si arriva a sceglierla.
Il problema non è mai nello sviluppo. È nel momento in cui si decide di iniziare senza aver capito.