Tre anni, un gestionale per clinical trials, zero release. Una storia vera raccontata senza filtri — ma con molto sarcasmo.
Esiste un tipo molto specifico di azienda tech italiana.
Ha un CTO con il titolo di CTO ma senza le competenze di un developer junior alla sua prima settimana. Ha manager che gestiscono con la tecnica avanzata del "vediamo come va" — tecnica che, lo anticipo, non va mai particolarmente bene. Ha processi scritti da qualcuno in un momento di ottimismo che non vengono seguiti da nessuno. E ha, nascosto da qualche parte in organico, un developer solitario che tiene tutto in piedi mentre gli altri organizzano riunioni su come tenere tutto in piedi.
Per tre anni quel developer sono stato io. Questa è la storia.
Il progetto
Gestionale per clinical trials. Dati medici. Processi regolati dalla normativa europea. Roba seria, insomma.
Una persona sola — io — a progettarlo, svilupparlo, mantenerlo, supportarlo, spiegarlo e tenerlo in vita.
Tre anni di lavoro. Mai andato in produzione.
Lascio un momento di silenzio per far assorbire questa informazione.
La visione strategica
Il motivo per cui il sistema non ha mai visto un utente reale non è tecnico. Il codice funzionava. L'architettura reggeva.
Il motivo è che le decisioni venivano prese da persone che non capivano cosa stavano decidendo. Requisiti cambiati settimana dopo settimana. Priorità ribaltate senza preavviso. E a un certo punto la proposta definitiva: cambiare l'architettura intera in corsa, per inseguire un trial clinico importante che avrebbe dovuto essere la svolta.
La decisione è stata presa senza una stima dei tempi reali. Senza capire cosa significava tecnicamente. Con la certezza tipica di chi non ha mai scritto una riga di codice che "non dovrebbe essere complicato".
Il trial non è arrivato. Meno male — perché non eravamo pronti. Non lo era il software, non lo era l'azienda.
Alla riunione successiva, chi aveva proposto e approvato quella strategia ha guardato il soffitto con l'espressione di chi stava pensando ai fatti suoi. Nessuna parola. Nessuna responsabilità. Classe cristallina.
Il paradosso del developer invisibile
Tre anni su un progetto che non è mai andato in produzione insegnano una cosa precisa: puoi fare tutto bene e finire comunque nel niente, se intorno a te nessuno sa dove sta andando.
Non è un fallimento tecnico. È un fallimento organizzativo che ricade su chi ha lavorato davvero.
La cosa più bizzarra? Durante quei tre anni il progetto veniva presentato all'esterno come una priorità assoluta. Nelle slide era sempre "quasi pronto". Nelle riunioni interne era sempre "ci manca poco". Nel mio computer era una cosa seria che meritava tempo, risorse e decisioni coerenti — tre cose che non sono mai arrivate insieme nello stesso momento.
Il finale
Ho rassegnato le dimissioni. Sono stato incoraggiato ad anticipare le ferie — presumibilmente per gestire meglio la narrativa interna durante la mia assenza.
Ho accettato con piacere. Ferie pagate mentre altri gestiscono narrazioni sono sempre un buon compromesso.
Un mese dopo firmavo con un'altra azienda.
Quello che mi porto dietro
Ho imparato a vedere i sistemi interi, non solo i ticket. Ho imparato che saper leggere un'organizzazione vale quanto saper scrivere codice. Ho imparato a riconoscere presto le aziende che cercano eroi solitari da consumare — e a non candidarmi.
E ho imparato la lezione più importante, quella che non trovi in nessun corso online:
Un progetto che non va mai in produzione non è un progetto. È una scusa per non decidere mai niente — pagata da chi lavora davvero.
Sapere quando andarsene è una competenza tecnica.
KernelMe è il posto dove metto queste cose per iscritto. Perché ricordarsi da dove si viene aiuta a capire dove si vuole andare.