Il progetto del cliente fermo da mesi, e voi in mezzo

Il cliente vi ha firmato il preventivo a gennaio, l'acconto è fatturato, e ogni volta che vi chiama per sapere a che punto siamo girate la domanda a chi sviluppa e tornate da lui con la stessa risposta di tre mesi fa, cioè che manca poco. Intanto il cliente lavora col programma di prima, e la telefonata del lunedì la ricevete voi, non chi scrive il codice.

Quando succede, quasi mai è colpa di chi scrive il codice, e quasi mai è colpa vostra: è che all'inizio nessuno si è seduto col cliente a mettere per iscritto cosa deve fare il prodotto il primo giorno che lo usa, chi lo usa e per quando gli serve, e senza quel foglio ogni riunione aggiunge una funzione che in quel momento sembra indispensabile, la consegna si sposta di un mese, e in mezzo ci state voi.

Le due domande da fare a chi sviluppa

La prima non è «quanto manca», perché quella la fate già ogni settimana. È: cosa fa il prodotto il primo giorno che il cliente lo apre? Non tutto quello che farà, ma cosa succede il lunedì mattina nel suo ufficio, chi apre cosa, e quale foglio smette di esistere: l'ordine che arriva dal negozio online e finisce nel gestionale senza che nessuno lo ricopi, o la scheda che il tecnico chiude in cantiere e arriva in ufficio da sola. Se chi sviluppa ve lo scrive in dieci righe, il progetto è più avanti di quanto sembri e da quelle dieci righe si vede cosa manca davvero; se la risposta è la lista delle funzioni «in arrivo», quelle dieci righe non le ha mai scritte nessuno, e la consegna continuerà a spostarsi finché qualcuno non le scrive.

La seconda è: quanti utenti lo usano, e cosa succede il giorno che raddoppiano? Un prodotto pensato per l'ufficio del cliente, tre persone e un computer, e uno che i suoi tecnici aprono dal telefono in cantiere sono due prodotti diversi, e se non è stato deciso all'inizio si scopre quando il cliente lo usa davvero e si blocca, cioè con il vostro nome sopra. Se vi rispondono con dei numeri il lavoro sta in piedi e va solo finito; se vi rispondono «si vedrà», è da lì che bisogna ripartire, prima di aggiungere qualsiasi altra funzione.

Cosa rispondere al cliente, intanto

Una data, ma solo dopo quel foglio. Finché non c'è scritto cosa deve fare il prodotto per dirsi finito, qualsiasi data che gli date è un'altra promessa che non dipende da voi, e la prossima telefonata sarà uguale a questa. Con il foglio davanti invece la risposta la date voi senza girarla a nessuno, «il primo giorno fa queste cose, per queste persone, ed è pronto per quella data», e se poi la data non regge si vede subito dove si è inceppata, invece di scoprirlo dal cliente. Se volete dargli qualcosa da leggere, la stessa cosa scritta per lui sta qui.

Cosa ho visto succedere, nelle due direzioni

Su una piattaforma di cui sono il responsabile tecnico sono arrivato che lo sviluppo andava avanti da un anno e non la usava ancora nessuno. La cosa scomoda da dire, e l'ho detta, era che finirla non conveniva: rimettere in ordine quello che c'era sarebbe costato più che ripartire con le idee chiare, e il tempo che restava non bastava per fare tutte e due le cose. Quello che si è salvato di quell'anno non è il codice, sono le decisioni: in dodici mesi avevano provato parecchie strade e ne avevano scartate altrettante, e sapere già cosa non funzionava ci ha fatto risparmiare mesi. Prima della prima riga di codice ci è voluto un mese e mezzo di sola progettazione, e l'infrastruttura l'abbiamo dimensionata sul numero di utenti che ci aspettavamo invece di aggiustarla di corsa dopo: la piattaforma è in produzione da febbraio 2026, e quel dimensionamento regge ancora.

Con un'agenzia è andata nell'altra direzione. Mi hanno chiamato per finire il lavoro di un altro sviluppatore, con gli obiettivi già decisi, e lì finire conveniva, perché quello che c'era stava in piedi e mancava un pezzo preciso. L'ho consegnato, e alla consegna ho scritto cosa avrei cambiato, non solo nel codice ma anche nel modo in cui il prodotto si presentava, e il secondo lavoro me l'hanno affidato loro. Le due strade sono tutte e due buone: quello che le distingue è il foglio, non la bravura di chi ha scritto il codice prima.

Quando conviene farlo leggere a qualcuno da fuori

Se le due domande non hanno risposta e chi sviluppa è la stessa persona che dovrebbe darla, siete nel punto in cui un secondo paio d'occhi costa meno di un altro mese: un tecnico che legge quello che c'è, il codice e il foglio se esiste, e vi dice se conviene finirlo o ripartire e da cosa, in modo che al cliente la data la diate voi. È il lavoro che faccio per le agenzie, e lo faccio dietro le quinte: il cliente resta vostro, la consegna è vostra, e lui vede solo voi. Il lavoro esce diviso in fasi, ognuna con il suo obiettivo e il suo prezzo, e la prima fase è quasi sempre solo leggere.

Se avete un progetto di un cliente fermo da mesi, scrivetemi da quanto è fermo, cosa dovrebbe fare il primo giorno e quanti utenti sono previsti, e vi dico se conviene finirlo o ripartire, in modo che al cliente possiate dare una data.