Settembre 2023, martedì pomeriggio, screen share alle 14:30. Un editore italiano di taglia media: tre testate verticali, una redazione centrale, un workflow editoriale che funziona da anni su WordPress multisite. Sullo schermo c’è il loro caporedattore digital, dietro di lui si vede una libreria con i numeri rilegati di una rivista di settore. Apre la richiesta del progetto in due frasi: vogliono pubblicare più velocemente, e per farlo vogliono un bottone pubblica subito che bypassi il workflow di approvazione editoriale quando l’autore è “fidato”. Mi chiede una stima di tempi e costi per costruirlo. È una cattiva idea, e io lo so dal secondo in cui finisce di parlare. Questo post di Workshop racconta cosa ho detto in quella call, perché ho perso il preventivo e cosa è successo sei mesi dopo.
La richiesta in dettaglio (e perché tecnicamente è una cattiva idea)
La proposta del cliente era questa: aggiungere al loro WordPress un meccanismo di whitelist autori basato su un campo utente custom. Un autore con flag trusted salta i due step di approvazione (revisione caporedattore + revisione legal) e pubblica diretto. La motivazione era operativa: i loro tre giornalisti senior conoscono lo stile, hanno fonti dirette, e in pratica i loro pezzi passano sempre la revisione. Il workflow di approvazione, secondo loro, era un collo di bottiglia inutile su quella fascia di redattori.
Il problema non è tecnico nel senso di “non si può fare”. Si fa in mezza giornata, è un hook su transition_post_status con un check sul ruolo utente. Il problema è strutturale, e la differenza è importante.
Primo: il workflow editoriale non esiste solo per la qualità del pezzo, esiste per la responsabilità legale del direttore. In una testata italiana il direttore responsabile firma quello che esce, e se esce una diffamazione paga lui (oltre al giornalista, in solido). Bypassare l’approvazione significa togliere al direttore la possibilità di vedere il pezzo prima della pubblicazione. Tecnicamente possibile, organizzativamente un boomerang.
Secondo: la whitelist autori è uno stato che si degrada nel tempo. Oggi i tre senior sono affidabili, fra dodici mesi entra un nuovo senior che è stato messo in whitelist da un caporedattore in fretta, fra ventiquattro mesi l’azienda non si ricorda più chi ha messo chi in whitelist, e l’audit log della whitelist nessuno lo guarda. Ogni eccezione che costruisci nel codice diventa debito che paghi a un costo crescente.
Terzo: in due mesi, quando il primo pezzo controverso sarà uscito senza revisione, qualcuno chiederà conto al sistema di chi l’ha lasciato passare. La risposta sarà “il flag trusted dell’autore”. A quel punto disabiliteranno il flag, scriveranno una procedura interna per rimetterlo, e il bottone pubblica subito sarà tornato esattamente al workflow originale, ma con un altro layer di codice da mantenere e un incident report sul tavolo del direttore.
Sono i tre motivi per cui in call ho pensato: questa cosa, costruita, gli dura due mesi.
La versione di me di un anno prima
Qui sta il punto che voglio fissare in questo post. Un anno prima, da CTO dipendente in una software house, avrei gestito quella call diversamente. Non perché non vedessi i tre problemi sopra (li vedevo, li avrei messi in un commento sul ticket Jira), ma perché il mio lavoro era far entrare il progetto, non far uscire il cliente dalla porta. Avrei detto qualcosa tipo: certo, si può fare, però vi consiglio una variante più pulita con un audit log e un timeout sul flag. Avrei aggiunto due settimane di lavoro alla stima per coprire l’audit log. Avrei chiuso il preventivo. Tre mesi dopo, in produzione, sarebbe successo esattamente quello che avevo previsto, e il mio nome non sarebbe stato menzionato perché formalmente la richiesta era arrivata dal cliente.
Quella non è onestà tecnica, è copertura. È il modo in cui un’agenzia software ben gestita protegge i propri ricavi a breve, e in dodici anni di carriera l’ho visto fare con una frequenza che mi imbarazza ancora un po’ ricordare.
In Romiltec, a tre mesi dalla fondazione, ho deciso che il modello deve essere un altro. Lo chiamo, internamente, onestà radicale: se la richiesta del cliente è una cattiva idea, glielo dico in call, prima del preventivo, anche a costo di perderlo. Non con il tono del consulente che vuole apparire intelligente (“ah, in realtà la soluzione più elegante sarebbe…”), ma con il tono asciutto di chi sta proteggendo il cliente da un costo futuro che non vede ancora.
Cosa ho detto, in pratica
In quella call la conversazione è andata più o meno così. Ho lasciato finire il caporedattore, ho preso trenta secondi di pausa (che in screen share sono lunghi), e ho detto:
Posso costruirla, è mezza giornata di lavoro. Non lo faccio perché in due mesi vi pentite. Vi spiego perché in tre punti.
Ho elencato i tre motivi sopra, in versione più corta. Niente moralismo, niente “e poi sapete il direttore responsabile…” in tono didattico. Tre fatti tecnici e organizzativi, due minuti totali. Alla fine ho aggiunto: quello che si può fare, e che secondo me risolve davvero il vostro problema, è ridurre il tempo di approvazione da due ore a venti minuti, lavorando sulla notifica al caporedattore e su un’app mobile per approvare in mobilità. Se vi interessa quello, faccio io il preventivo.
Il caporedattore mi ha ringraziato, ha detto che ne avrebbe parlato col direttore, abbiamo chiuso la call dopo pochi minuti. La sera mi è arrivata una mail cortese: grazie per il punto di vista, abbiamo deciso di andare avanti con un’altra agenzia che ci ha confermato la fattibilità del bottone. Restiamo in contatto. Preventivo perso.
Il post-call (cosa ho pensato dopo)
Il primo pensiero, lo dico onestamente, è stato: ho fatto una stupidaggine. Romiltec ha tre mesi di vita, il pipeline non è solido, ogni preventivo perso è cassa che non entrerà fra novanta giorni. Il dev senior con cui avrei lavorato sul progetto era già sotto-occupato per il mese successivo. E un editore italiano di quella taglia non è un cliente che capita ogni settimana sul calendario.
Il secondo pensiero, dopo cena, è stato più sobrio: se avessi accettato, avrei costruito una cosa che in due mesi avrebbe dato un incidente al cliente, il cliente avrebbe associato l’incidente a Romiltec, e per recuperare la fiducia avrei dovuto ricostruire da zero il workflow originale gratis. Il preventivo perso a settembre era un costo certo (cassa non entrata). Il preventivo accettato sarebbe stato un costo probabile più alto (lavoro gratis a dicembre + reputazione). Su due mesi di orizzonte la matematica torna; su sei mesi torna ancora di più.
Il terzo pensiero, qualche giorno dopo, è quello che mi è rimasto: l’onestà radicale non è una scelta etica, è una scelta di portafoglio. È il modo in cui una software house piccola riduce il rischio di ritrovarsi clienti scontenti che pesano nei mesi successivi. I clienti che restano sono autoselezionati: sono quelli che apprezzano il fatto che li protegga dalle loro stesse richieste sbagliate.
Sei mesi dopo
A marzo 2024 (sei mesi esatti dalla call di settembre) mi è arrivata una mail dallo stesso caporedattore. Tre righe: Rocco, ti ricordi la cosa di cui parlammo a settembre? Avevi ragione. Vorremmo riprendere il discorso, questa volta con la versione che avevi proposto tu. Quando hai venti minuti?
Era successo esattamente quello che avevo descritto in call. L’altra agenzia aveva costruito il bottone, in produzione era andato bene per qualche settimana, poi un pezzo controverso era passato senza la revisione del direttore, era successa una cosa spiacevole dal punto di vista legale, il bottone era stato disabilitato, e il workflow era tornato al punto di partenza. Più, ovviamente, il debito di codice da rimuovere e la conversazione interna sul perché era stato costruito.
A quel punto l’editore aveva due opzioni: rifare con la stessa agenzia (improbabile, fiducia rotta) o riaprire la conversazione con qualcuno che a settembre li aveva avvertiti. Ha scelto la seconda. Il preventivo che ho fatto a marzo 2024 era per la versione riduci il tempo di approvazione, non bypassarlo che avevo proposto in call sei mesi prima. Margine simile a quello del bottone iniziale, ma su un perimetro di lavoro più sano e con un cliente che adesso considerava Romiltec un advisor tecnico, non un fornitore.
Cosa porto a casa
Provo a condensarlo in tre regole operative, senza moralismi.
Regola uno: in una call di scoping, se la richiesta tecnica del cliente è una cattiva idea, lo dico prima di parlare di tempi e costi. Mai dopo. Una volta che sei in trattativa sul prezzo, sembra una tattica. In apertura sembra un’opinione tecnica, che è quello che è.
Regola due: la formulazione conta. Posso costruirla, non lo faccio perché in due mesi vi pentite, vi spiego perché in tre punti funziona. In realtà non andrebbe fatta così, la prassi sarebbe… non funziona, perché suona come pedanteria di consulente. La forma asciutta è una forma di rispetto: il cliente capisce che stai prendendo sul serio il suo problema, non che vuoi correggere il suo brief.
Regola tre: dopo aver detto di no a una cosa, proporre una versione alternativa che risolve il problema vero. Senza l’alternativa, il no è solo perdita di preventivo. Con l’alternativa è advisory, e il cliente ti riconosce un valore anche se sceglie un altro fornitore quel giorno. Sei mesi dopo si ricorda chi gli aveva detto la verità.
L’onestà radicale è il tag che do a questa pratica, e in Romiltec è una delle cose su cui i dev senior vengono allineati nei primi mesi. Non vendiamo lavoro che sappiamo già che si romperà. Non aggiungiamo settimane di stima per coprire una richiesta sbagliata. Diciamo no, e ecco perché in call, e accettiamo il costo di breve. In quasi tutti i casi che ho misurato finora, il costo di breve si recupera nei sei-dodici mesi successivi: clienti che tornano, referenze che arrivano, conversazioni di scoping che partono da un rapporto già più maturo. È un investimento con un payback period non immediato, ma che regge sotto carico, ed è uno dei pochi vantaggi competitivi reali che una software house piccola può costruire contro le agenzie più strutturate.
Quel preventivo di settembre 2023 lo metto, mentalmente, fra le cose meglio investite del primo anno di Romiltec.