Quanto tempo devi metterci tu: il ruolo del cliente in un progetto software

Nei preventivi software c'è una voce che non compare mai: le ore che dovrai metterci tu. Non per dimenticanza — semplicemente non sono ore che fattura il fornitore, quindi nessuno le scrive.

Eppure sono quelle che fanno la differenza tra un progetto che finisce in tempo e uno che si trascina per mesi. Ho visto progetti tecnicamente più difficili chiudersi prima, solo perché dall'altra parte c'era qualcuno che rispondeva.

Questo articolo mette in fila quel tempo: quanto è, quando serve e come organizzarlo senza far saltare le giornate.

Chi costruisce il software conosce il mestiere di costruire software. Non conosce il tuo: non sa che i clienti del nord pagano a 90 giorni e quelli del sud a 30, che quel fornitore va gestito a parte, che la bolla si stampa in tre copie perché una resta all'autista.

Sono le eccezioni a fare un gestionale, e le eccezioni stanno in testa a chi lavora, non nei documenti. L'unico modo per farle uscire è parlare con quelle persone. Se quel tempo non c'è, il software viene costruito sulle ipotesi di chi lo scrive: e le ipotesi si scoprono sbagliate al collaudo, quando correggerle costa dieci volte di più.

All'inizio, per raccontare come lavorate davvero. È il momento più denso: due o tre incontri da un paio d'ore, più il tempo per recuperare esempi veri — un ordine tipo, una fattura complicata, il file che usate adesso. Sembra tanto, ed è il tempo che fa risparmiare tutto il resto.

Durante, per rispondere alle domande. Arriveranno dubbi che nessuno poteva prevedere: cosa succede se un articolo non è disponibile, chi può annullare un ordine già confermato. Sono domande brevi, ma se restano ferme tre giorni il lavoro si ferma con loro. Mettere in conto mezz'ora a settimana, con una persona che ha davvero il potere di decidere, cambia il ritmo del progetto.

Al collaudo, per provarlo sul serio. Non guardare due schermate e dire «bello». Prendere dieci casi veri della settimana scorsa, compresi i due che sono andati storti, e rifarli dentro il software nuovo. Sono tre o quattro ore, e sono quelle che evitano le sorprese del primo giorno.

Al rilascio, per stare vicino a chi lo usa. Le prime due settimane servono più domande del solito. Se nessuno in azienda ha il tempo di rispondere, le persone tornano al vecchio metodo — e a quel punto il software c'è ma non lo usa nessuno.

Su un progetto di media dimensione, il tempo dell'azienda si concentra in poche settimane e poi si dirada. Serve soprattutto che sia prevedibile: un'ora fissa in calendario ogni settimana vale più di cinque ore trovate all'ultimo momento.

Il singolo fattore che più accorcia i tempi è avere una persona sola che fa da ponte. Non deve essere tecnica, non deve essere il titolare: deve conoscere il processo, essere raggiungibile e avere il mandato di decidere le cose piccole senza convocare una riunione.

Quando invece le risposte arrivano da tre persone diverse, e ognuna dice una cosa leggermente diversa, il fornitore si ferma e aspetta. Quell'attesa non è colpa di nessuno, ma finisce comunque nel calendario del progetto.

Capita, ed è legittimo: ci sono periodi in cui l'azienda non può staccare nessuno. In quel caso ci sono due strade oneste. La prima è spostare l'inizio di qualche settimana, aspettando il momento giusto. La seconda è ridurre il progetto: fare la metà delle cose richiede la metà delle decisioni, e un primo pezzo piccolo si porta a casa anche in un periodo pieno — è uno dei motivi per cui conviene partire da un MVP più piccolo di quanto sembri sensato.

Quello che non funziona è cominciare sperando che il tempo si trovi strada facendo. Non si trova: si accumula come ritardo, e alla fine costa a entrambi.