Il gestionale che avete pagato e che non arriva mai

Avete pagato un gestionale, magari un acconto e poi una fattura ogni tanto, e ogni volta che chiedete a che punto sta vi rispondono che manca poco, ve lo dicevano anche tre mesi fa, e intanto le scadenze le segnate ancora sull'agenda e le fatture le fate con il programma di prima.

Quando succede, quasi mai è colpa di chi scrive il codice: è che all'inizio nessuno si è seduto con voi a mettere per iscritto cosa deve fare il programma il primo giorno che lo usate, chi lo usa e per quando vi serve, e senza quel foglio ogni settimana si aggiunge un pezzo che in quel momento sembra indispensabile, e voi intanto continuate a lavorare come prima.

Le due domande da fare a chi lo sta scrivendo

La prima non è «quanto manca», perché a quella la risposta la sapete già. È: cosa fa il programma il primo giorno che lo usiamo? Non tutto quello che farà un giorno, ma cosa succede lunedì mattina quando in ufficio si accende il computer, chi apre cosa, e quale foglio smette di esistere. Se ve lo scrivono in dieci righe il programma è più avanti di quanto sembri, e da quelle dieci righe si vede anche cosa manca davvero; se la risposta è un elenco di cose che «ci saranno», quelle dieci righe non le ha mai scritte nessuno, ed è per questo che la fine si sposta ogni settimana.

La seconda è: quante persone lo usano, e cosa succede il giorno che sono il doppio? Un programma fatto per tre persone in ufficio e uno fatto per trenta, con i tecnici che lo aprono dal telefono in cantiere, sono due programmi diversi, e se nessuno l'ha deciso all'inizio lo si scopre quando è tardi, cioè quando lo usate davvero e si blocca. 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 cosa.

Cosa ho visto succedere

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. È per questo che ripartire quasi mai vuol dire buttare via tutto: si butta il codice, si tiene quello che si è capito.

Prima della prima riga di codice ci è voluto un mese e mezzo di sola progettazione, cioè cosa deve fare il programma, chi lo usa, e come si tengono insieme clienti, ordini e scadenze, e i computer che lo tengono acceso li abbiamo scelti sul numero di persone che ci aspettavamo, invece di aggiustarli di corsa dopo. La piattaforma la usano tutti i giorni da febbraio 2026, e i computer scelti allora bastano ancora.

Cosa decidere

Se siete in questa situazione, la prima cosa è farvi rispondere alle due domande per iscritto da chi sta scrivendo il programma, anche in dieci righe: non serve un documento da studio, serve un foglio che fra sei mesi permetta a tutti e due di dire se il programma fa quello che c'è scritto oppure no.

Con quel foglio davanti la strada si vede subito. Se le risposte ci sono e il lavoro è solo indietro, si finisce, e si finisce con una data, perché adesso c'è scritto cosa deve fare per dirsi finito. Se le risposte non ci sono, ogni mese che passa aggiunge pezzi a una cosa che non è mai stata progettata, e vi costa quello che state già pagando più il lavoro che intanto fate a mano: in quel caso conviene fermarsi, tenere quello che si è capito, e ripartire da come lavorate voi e da quando vi serve.

Se invece siete l'agenzia che sta in mezzo, fra il cliente che chiede e chi scrive il codice, la stessa cosa vista da lì l'ho scritta a parte.

Se avete un gestionale in lavorazione da mesi e volete sapere se conviene finirlo o ripartire, scrivetemi da quanto è in lavorazione, cosa dovrebbe fare il primo giorno che lo usate e quante persone lo useranno, e vi dico se conviene finirlo o ripartire, e da cosa.