Novembre 2023, Romiltec aveva sette mesi di vita. Pochissimi clienti veri, abbastanza fame da accettare quasi qualunque cosa. Una mattina di metà novembre arriva un’email: un cliente nuovo (una mid-size con presenza nazionale) ci chiede una feature custom su una piattaforma loro esistente, in PHP legacy. Termine: due settimane. La firma del preventivo era già stata trasmessa. Ho detto no la sera stessa. Continua leggendo gli altri post di Workshop.
La richiesta
La feature in sé era ragionevole: una sezione area riservata clienti con autenticazione SSO appoggiata al loro sistema di autenticazione aziendale, integrata in un portale CMS legacy che si portava dietro anni di personalizzazioni accumulate. Tre livelli di permessi, dashboard differenziata per ruolo, audit log per la compliance interna.
Il problema non era la feature. Era la combinazione di vincoli, in ordine di gravità tecnica:
- Stack legacy non versionato. Niente Git, niente staging, niente backup automatici, e zero appetito del cliente per un upgrade major dello stack prima della consegna
- Runtime fuori supporto. Versione del linguaggio in end-of-life da anni, non più coperta da quasi nessuna libreria moderna
- Deploy manuali. Modifiche fatte direttamente in produzione, nessuna repo, nessun changelog. Lo sviluppatore precedente aveva lasciato l’azienda da mesi e nessuno aveva mai messo mano alla codebase
- Integrazione con il sistema di autenticazione interno fatta in modo non riproducibile. Configurazione disallineata tra ambienti, nessun pattern documentato
- Due settimane. Hard deadline collegata a un evento commerciale del cliente
Singolarmente, ogni vincolo è gestibile. Insieme, in due settimane, con un team di due persone e mezzo, significava una sola cosa: debito tecnico significativo consegnato come prodotto finito. Codice scritto a manina sopra una base che non potevamo refactorare, niente test perché non c’era staging, niente possibilità di rollback perché niente versioning, e tutto questo lasciato a un cliente che non aveva un dev interno a cui passare il know-how.
La decisione
Ho fatto due cose la stessa sera. Una telefonata di venti minuti col senior dev del team per allineare la lettura tecnica (mi confermava i miei dubbi: in due settimane si può fare, ma si paga dopo, sia in termini di sicurezza che di costi di mantenimento). Una telefonata di un’ora col responsabile IT del cliente, lui stesso non sviluppatore ma persona competente, per spiegargli i tre punti che secondo me rendevano il progetto, così come era impostato, una scelta che gli si sarebbe ritorta contro nel medio periodo.
Il primo: runtime e CMS fuori supporto. Non si trattava solo di funziona ancora, si trattava di funzionerà ancora tra sei mesi quando l’antivirus aziendale ti spara il primo alert su una vulnerabilità non patchata. Il loro reparto IT aveva una policy di compliance interna che, applicata letteralmente, avrebbe imposto di disabilitare il portale entro novanta giorni dalla scoperta di vulnerabilità sui componenti obsoleti.
Il secondo: il codice editato direttamente in produzione. Senza repo, senza staging, ogni nostra release sarebbe stata una scommessa. Il giorno che un loro junior IT avesse cambiato una riga via accesso diretto, il nostro lavoro sarebbe potuto smettere di funzionare senza spiegazione e nessuno avrebbe avuto modo di capire perché.
Il terzo: l’integrazione con l’autenticazione interna così come impostata era un debito di sicurezza, non una scelta. Le best practice sul bind sicuro contro directory aziendali sono codificate da anni in standard pubblici (vedi ad esempio RFC 4513): trasporto cifrato e meccanismi di bind robusti non sono opzionali. Sì ma è rete interna è la frase più costosa della storia dell’IT aziendale: vale finché non lo è più (un fornitore esterno collegato in VPN, un attacco MITM da un access point compromesso, un dipendente con un laptop infetto sulla LAN).
Il pacchetto alternativo
Non ho detto solo no. Ho proposto un’alternativa concreta, costruita con il senior dev nel weekend dopo:
- Tre sprint da due settimane invece che uno
- Sprint 1: upgrade dello stack a versioni in supporto, componenti obsoleti sostituiti o rimossi, codebase importata in repo Git con staging dedicato e CI/CD base
- Sprint 2: integrazione SSO con un meccanismo di bind sicuro appoggiato sui sistemi di identity interni del cliente, tre livelli di permessi gestiti via un pattern role-permission standard, audit log su tabella custom indicizzata
- Sprint 3: dashboard differenziata, QA, hand-off documentato, formazione di mezza giornata al loro responsabile IT
Costo totale: circa 3.5x rispetto al preventivo originale, ma con tre cose: una codebase manutenibile, un’integrazione SSO sicura, una documentazione che il cliente avrebbe potuto passare a chiunque internamente. La proposta includeva anche, gratuitamente, una review trimestrale per i primi tre trimestri post-consegna per intercettare debt che si fosse riformato.
Il responsabile IT del cliente ha apprezzato la conversazione (sue parole: finalmente uno che mi spiega perché, non uno che mi dice solo che si può fare). Ha portato la proposta al loro CFO. Il CFO ha bocciato il budget 3.5x.
Il progetto è andato a un altro fornitore che ha consegnato la versione come richiesta in due settimane. Sei mesi dopo, primavera 2024, il responsabile IT ci ha richiamato. Il portale aveva avuto problemi seri di sicurezza che il fornitore precedente non era riuscito a chiudere; il loro pen test annuale aveva flaggato issue rimaste aperte. Volevano sapere se eravamo ancora disponibili. Abbiamo accettato, ricominciando dal piano dei tre sprint che gli avevo proposto sei mesi prima, a un costo nettamente più alto perché nel frattempo lo stack era ulteriormente arretrato e c’era lavoro di bonifica da fare prima ancora di poter costruire sopra.
Quello che ho imparato a dire no
Tre cose, in ordine di importanza pratica.
Il no si dice meglio quando lo motivi sul futuro del cliente, non sul presente del fornitore. Non lo facciamo perché non ce la facciamo è una scusa fragile e suona da preventivo basso. Non lo facciamo perché tra sei mesi ti costa più di quanto ti costa farlo bene oggi è una conversazione tra adulti che si rispettano. Funziona se è vera, e se hai i numeri sul tavolo per dimostrarla. La famosa regola di Patrick McKenzie su Kalzumeus sull’allineamento incentivi-cliente vale qui in pieno: il fornitore che è disposto a perdere un contratto per dirti la verità tecnica è il fornitore che ti tornerà utile a lungo termine.
Il no si dice presto. Aspettare il giorno della firma a esprimerlo è una scortesia organizzativa: il cliente ha già allocato budget, comunicato la deadline interna, fatto promesse al suo board. Dirlo entro 24 ore dalla richiesta lascia spazio a tutti per riposizionarsi. Quella telefonata di un’ora la sera stessa non era educazione, era rispetto operativo per il loro processo.
Il no non è uno stato finale, è l’inizio di una contro-proposta. Dire no a così, sì a colà è un atto di consulenza, non di rifiuto. Il cliente che ha firmato due settimane dopo con un altro fornitore non è andato perché Romiltec era arrogante, è andato perché il suo CFO ha valutato il rischio in modo diverso da come lo proponevo io. Sei mesi dopo, però, è tornato. E quando è tornato non c’era trattativa: ha accettato il piano, gli sprint, il prezzo aggiornato, perché aveva pagato sulla sua pelle quello che gli avevo descritto a novembre.
Sopra Romiltec ho costruito una software house in cui il no qualificato è una delle valute più importanti che spendiamo coi clienti. Vale per i preventivi che decliniamo (capita ancora, anche con fame meno feroce di tre anni fa). Vale per le feature che proponiamo di ridiscutere durante uno sprint quando sentiamo che la rotta sta deviando. Vale per le tecnologie che rifiutiamo di adottare anche quando il cliente le chiede esplicitamente (l’esempio classico è il no, non installiamo il plugin builder gigante che vuoi tu, perché in produzione su carico vero ti spacca i CWV: lo abbiamo detto in più occasioni nel 2024, e l’effetto netto è sempre stato positivo nel medio termine).
Quel novembre 2023 è stato la prima volta che ho detto no a un cliente con un assegno in mano. È stata anche la prima volta che ho capito che dire no è più strategico che dire sì, quando il sì costerebbe a entrambi più di quanto vale il contratto.