Chi si prende il guadagno di produttività?

Poche settimane fa avevo scritto che con l’AI mi era tornato l’entusiasmo. Non ho cambiato idea: è ancora tutto lì. Ma c’era una parte che avevo tralasciato: l’entusiasmo lo provo quando costruisco qualcosa. Il problema arriva quando per lavoro devo fare un preventivo.

Per la realizzazione di un modulo software che un anno fa avrei stimato in dieci giornate, oggi probabilmente ne bastano sei, e lo so già mentre inizio a scrivere il documento. Poi arrivo alla casella del prezzo e mi fermo, perché è l’unico punto in cui quella differenza deve diventare un numero.

Quelle quattro giornate, di chi sono?

Meglio chiarirlo subito: niente studi, niente numeri e nessuna risposta in fondo. Solo il punto di vista di chi le stime le fa ogni settimana e da mesi si ripete la stessa cosa: nel nostro settore si parla quasi esclusivamente di strumenti AI, mentre della casella del prezzo non parla quasi nessuno.

Le quattro giornate che non esistono

La cosa che so per certo è che quelle dieci giornate non erano una misura. Erano una scommessa.

Dentro non c’era solo il tempo per scrivere il codice. C’era il tempo per capire cosa serve davvero, che non è mai quello che c’è scritto nella mail. C’era il tempo per litigare sulle specifiche. C’era il tempo per integrarsi con il gestionale che nessuno documenta da otto anni e di cui l’unica persona informata è andata in pensione. E c’era un margine, mai dichiarato in preventivo, per tutte le cose che ancora non si sanno quando il cliente chiede una stima.

L’AI ha accorciato una sola di queste voci: la scrittura del codice, che, a onor del vero, è anche la più divertente da raccontare e quella che mi costava meno.

Il resto è identico a prima. Il cliente cambia idea alla stessa velocità di un anno fa. Le credenziali dell’ambiente di produzione arrivano con gli stessi tempi biblici. Anche la review del codice rimane, ma, contrariamente a quello che si può pensare, quella su codice scritto da un agente è molto più impegnativa, perché capire se ha imboccato una strada sbagliata costa più tempo di prima.

Il tempo di scrittura del codice si è ridotto del quaranta per cento, e per un attimo ho creduto, ingenuamente, che l’intero progetto si sarebbe accorciato della stessa percentuale. Non è così: delle quattro giornate risparmiate ne restano una, forse due. Le altre non erano lavoro, erano incertezza, e l’incertezza non è minimamente calata.

Il conto che non torna

C’è un ulteriore pezzo del puzzle, più subdolo e difficile da raccontare.

Se il prezzo scende in proporzione alle giornate, scende molto più di quanto siano scesi i costi. Gli stipendi non sono scesi. L’affitto non è sceso. Le ferie, la formazione, i mesi in cui un progetto slitta e le persone restano in attesa: niente di tutto questo è scalato con le giornate. E la giornata che risparmio non è una giornata che smetto di pagare: è una giornata che devo riempire con altro lavoro, che prima qualcuno deve vendere.

Il paradosso, su cui inciampo ogni volta che devo fare un preventivo, è che uno strumento pensato per rendermi più efficiente finisce per fare l’esatto contrario sul piano economico: lo sconto che mi sembra più onesto, quello proporzionale alle giornate, avvicina il prezzo al costo e riduce il margine. E una soluzione equa, quella a metà strada che sembra la mossa della persona per bene, mi lascia comunque con un margine inferiore rispetto a prima dell’AI.

Chi fa il mio stesso mestiere si sarà già fatto due conti e potrà verificare da sé se si ritrova o meno nella mia stessa situazione.

Dove finisce il guadagno

La cosa utile che ho tirato fuori da questi mesi è che il guadagno non svanisce. Finisce in uno dei seguenti cinque posti, e i primi quattro sono tutti plausibili.

Può andare al cliente, come prezzo più basso. Può restare in azienda, come margine, ed è la strada che chiunque sceglierebbe senza pensarci troppo.

Può andare nel prodotto: stesso prezzo, ma dentro ci stanno i test veri, la documentazione, l’accessibilità e tutte le cose che per stare nei tempi si tagliano per prime e si rimpiangono sei mesi dopo. Oppure può andare nel tempo: stesso prezzo, ma consegna in tre settimane invece di sei. Questa, secondo me, è la più interessante di tutte, e spesso viene sottovalutata: per certi clienti consegnare prima vale molto più di uno sconto. E ha un vantaggio in più: una consegna anticipata finisce lì, mentre uno sconto diventa il punto di partenza della trattativa successiva.

E poi c’è la quinta, che è la più probabile ma che nessuno vorrebbe: in fumo. Riunioni in più perché “tanto c’è tempo”, rework su codice che nessuno ha guardato davvero, specifiche che variano in silenzio perché “tanto ci vuole meno”, stime tagliate e la stessa fretta di prima sulle spalle di chi scrive il codice. La quinta strada diventa inevitabilmente il default quando non si sceglie consapevolmente una delle altre quattro.

Il concetto che mi è rimasto in testa, di tutte le opzioni viste finora, è uno solo: non ridurre il prezzo, ridurre il tempo.

Tutte queste strade, però, hanno lo stesso limite: considerano solo me e il cliente, e lasciano fuori chi il guadagno lo produce davvero, cioè il team. Se comprimo le stime e tengo il prezzo, il guadagno lo scavalca. Sto parlando dello sviluppatore che oggi chiude in due giorni quello che un anno fa gli costava una settimana, ed è lui a rendere possibile quel margine più alto. Ma se il vantaggio resta tutto nel conto economico dell’azienda, lui non ne vede un euro, e nemmeno un’ora di lavoro in meno. E gli sviluppatori se ne accorgono, prima ancora dei clienti: sanno esattamente quanto tempo impiegano oggi rispetto a un anno fa, cosa che chi guarda solo il prezzo in fattura non può sapere.

Non ho la formula giusta per capire come ridistribuire questa quota al team: non so se debba tradursi in un bonus, in orari più flessibili, in tempo per la formazione o per il refactor rimandato da due anni, o in qualcos’altro a cui non ho ancora pensato. Ma so una cosa con certezza: se la quota che arriva al team è zero, il guadagno di produttività ha una scadenza corta, perché le persone che lo rendono possibile smettono, prima o poi, di essere disposte a produrlo.

Nero su bianco

Quando in azienda abbiamo iniziato a usare l’AI sul serio, la prima cosa che ho fatto è stata rileggere i contratti.

All’inizio pensavo che non dire niente avesse senso. Per un po’ mi sono raccontato che il silenzio fosse una posizione neutra: se nel contratto non c’è scritto che usiamo questi strumenti, non c’è scritto nemmeno che non possiamo usarli. Poi mi sono accorto che non ha senso. Il silenzio non è neutro: è una decisione rimandata, e prima o poi torna indietro come un boomerang. Così oggi nei contratti dell’azienda c’è scritto, in modo esplicito, che usiamo strumenti di intelligenza artificiale nello sviluppo. Il cliente lo sa prima di firmare, non lo scopre dopo.

La seconda cosa riguarda i confini: quale materiale del cliente può entrare in questi strumenti e quale no. Codice sorgente, documenti riservati e dati di produzione sono tre cose diverse, ma nella pratica quotidiana finiscono trattate come una sola. I dati di produzione, per cominciare, non devono entrarci mai. Per tutto il resto la regola più semplice che ho trovato è una sola: si lavora esclusivamente con account aziendali, mai con quelli personali.

La differenza non è formale. Con l’account aziendale è l’azienda a scegliere lo strumento e a centralizzarne l’uso, a negoziare condizioni che escludano l’addestramento dei modelli con i dati del cliente, e a rispondere di quello che ci passa dentro. Con un account personale nessuno sa cosa è stato condiviso, con chi e a quali condizioni, e nessuno può controllarlo. È una regola banale, ma è la base che tutela davvero sia il cliente che l’azienda.

Quando il cliente lo mette a fuoco

Anche se il cliente lo sa già dal contratto, quando se ne parla davvero le reazioni possibili sono tre, e le ho viste tutte.

C’è il cliente tecnico, che usa i miei stessi strumenti e vuole lo sconto, con buoni argomenti. Con lui la conversazione sta in piedi solo se la sposto sul rischio e sulla garanzia, perché sulle ore ha ragione lui.

C’è il cliente strutturato, la pubblica amministrazione o una multinazionale, che non mi chiede lo sconto: mi chiede la policy, il DPA e un elenco infinito di altri documenti. Arrivare con tutta questa documentazione già pronta vale più di qualsiasi sconto, e fa vincere gare che altri perdono per un allegato mancante.

E poi c’è il cliente che si sente fregato. Qui il problema non è l’AI: è che ci è arrivato da solo invece di sentirselo spiegare. Da un commento dimenticato nel codice, da un documento scritto in un italiano che non è il mio, da qualcuno che in call parla un secondo di troppo. Dirlo prima e con chiarezza costa sempre meno che farglielo mettere a fuoco dopo.

In caso di contestazioni, la frase che uso è sempre la stessa:

Le nostre stime sono già al netto degli strumenti che usiamo. Il prezzo riflette il risultato e il rischio che ci prendiamo, non le ore che ci mettiamo.

Non c’è una strada giusta

Dopo diversi mesi di grattacapi e ripensamenti, quello che mi sembra di aver capito è che il guadagno non va né regalato al cliente come sconto né nascosto come margine: va deciso insieme a lui. E i posti in cui farlo sono soltanto tre: il preventivo, il contratto e la conversazione diretta. Chi in nessuno dei tre ha cambiato qualcosa nell’ultimo anno ha già scelto la quinta strada, mandare il margine in fumo, senza accorgersene. Io due li ho già adeguati, il contratto e la conversazione. Il preventivo, invece, sto ancora cercando di capire come riformularlo.

Il motivo è che una strada giusta, valida per tutti, probabilmente non esiste: dipende dal rapporto che ho con il cliente, dal tipo di cliente, dal contratto e da quanto mi fido delle mie stime, che in questo momento sto ancora ritarando sull’uso degli strumenti AI.

In conclusione, l’entusiasmo è ancora tutto lì. E anche il preventivo: aperto sullo schermo, con il cursore che lampeggia sulla casella del prezzo. Prima o poi dovrò decidermi. Ma non oggi.