Business ↔ IT: la riunione di allineamento, con sottotitoli

Business e IT parlano entrambi italiano. Usano le stesse parole, a volte le stesse slide, e quasi mai intendono la stessa cosa. Ogni riunione di allineamento è una conversazione tra due lingue che si somigliano solo in superficie, come spagnolo e portoghese, o come == e === in JavaScript.

Per documentare il fenomeno abbiamo trascritto una riunione. I personaggi sono inventati, le frasi purtroppo no.

Personaggi e interpreti

• DOTT. BRAMBILLA, Chief Vision Officer, laurea in Scienze delle Patatine. Già noto ai lettori per aver chiesto «solo un altro if».
• ING. FERRETTI, sviluppatrice backend, dodici anni di reperibilità notturna, un'unica tazza con scritto it works on my machine.
• GIADA, Product Owner e interprete simultanea non ufficiale. Le sue traduzioni sono tra parentesi quadre.

Una sala riunioni al quarto piano. Martedì pomeriggio. Sul proiettore, una slide intitolata «Q4: Sinergie 360°». Il caffè è finito.

Scena I — «In tempo reale»

BRAMBILLA: Allora, la nuova dashboard delle vendite deve essere in tempo reale.

FERRETTI (illuminandosi): Quindi uno stream di eventi, Kafka, aggregazioni a finestra, WebSocket verso il browser, latenza sotto il secondo…

GIADA: Dottore, ogni quanto la guarda, questa dashboard?

BRAMBILLA: Il lunedì mattina. Prima del comitato.

GIADA: [Traduzione: «in tempo reale» significa «aggiornata il lunedì alle 8».]

Nota del traduttore. In informatica "tempo reale" ha almeno tre significati, con costi molto diversi. Hard real-time: una scadenza mancata è un guasto (il controllo dell'airbag, il freno di un treno). Soft real-time: una scadenza mancata peggiora il servizio (una videochiamata che scatta). Near real-time: dati con qualche secondo o minuto di ritardo (uno stream di eventi). Poi c'è il batch notturno, che costa una frazione delle altre soluzioni e, per la dashboard di Brambilla, va benissimo. La domanda giusta non è «quanto veloce?», ma «che decisione prendi con questo dato, e quando?».

Scena II — «Sempre disponibile»

BRAMBILLA: E il sito non deve mai andare giù. Mai.

FERRETTI: Quanti nove?

BRAMBILLA (dopo una pausa): Tutti.

GIADA: [Traduzione: «non vorrei che andasse giù durante la campagna di Natale».]

Nota del traduttore. "Sempre" non esiste. Esiste una percentuale, e ogni nove in più costa circa dieci volte tanto, perché richiede ridondanza, più regioni cloud, rilasci senza interruzioni e persone reperibili di notte:

E c'è un dettaglio che nessuno dice in riunione: le disponibilità in serie si moltiplicano. Se una pagina dipende da cinque servizi, ognuno al 99,9%, la pagina è disponibile al 0,999⁵ ≈ 99,5%, cioè quasi due giorni di indisponibilità all'anno. Il "mai" di Brambilla si ottiene solo se anche il provider di pagamenti, il CDN e il DNS sono d'accordo.

Scena III — «È solo un campo in più»

BRAMBILLA: Mi serve anche la data di nascita del cliente nella scheda. È solo un campo in più, no?

FERRETTI (guardando il soffitto): La tabella clienti ha 400 milioni di righe.

GIADA: [Traduzione per il Dottore: «è un campo in più». Traduzione per l'ingegnera: «è una migrazione dello schema, una nuova versione dell'API, l'app mobile vecchia da gestire, un dato personale per il GDPR e un report da aggiornare».]

Nota del traduttore. Su una tabella grande, aggiungere una colonna in modo ingenuo può bloccarla per minuti o ore. Il modo sicuro si chiama expand and contract: si aggiunge la colonna vuota e opzionale, si aggiorna il codice per scriverla, si riempiono i dati esistenti a piccoli blocchi, e solo alla fine la si rende obbligatoria.

-- 1. expand: colonna nullable, nessun lock lungo
ALTER TABLE clienti ADD COLUMN data_nascita DATE NULL;
-- 2. il codice nuovo scrive la colonna; l'app vecchia la ignora
-- 3. backfill a blocchi, di notte, con calma
UPDATE clienti SET data_nascita = ... WHERE id BETWEEN 1 AND 100000;
-- 4. contract: solo quando tutti i client sono aggiornati
ALTER TABLE clienti ALTER COLUMN data_nascita SET NOT NULL;

Quattro passi, tre rilasci, una revisione privacy. «Solo un campo».

Scena IV — «Cancellate i dati del cliente»

BRAMBILLA: Il cliente Bianchi ci ha chiesto di cancellare i suoi dati. Fatelo sparire.

FERRETTI: Dal database principale? Dalle repliche? Dai backup degli ultimi 35 giorni? Dai log? Dal data warehouse? Dalle email di marketing già programmate? Dal file Excel che il commerciale si è scaricato a marzo?

BRAMBILLA: …Basta che non compaia più nella lista.

GIADA: [Traduzione: il business ha chiesto un soft delete, la legge chiede una cancellazione vera.]

Nota del traduttore. "Cancellare" in informatica ha almeno tre livelli: nascondere (un flag deleted_at), eliminare la riga, ed eliminare il dato ovunque, comprese le copie. Il diritto alla cancellazione del GDPR (articolo 17) riguarda il terzo livello, ed è proprio quello che nessuno ha progettato. Il trucco usato per i backup si chiama crypto-shredding: si cifrano i dati di ogni cliente con una chiave sua, e per "cancellare" anche i backup si distrugge la chiave.

Scena V — «Quando è pronto?»

BRAMBILLA: Quanto ci vuole?

FERRETTI: Circa tre settimane. Se l'integrazione con il gestionale va liscia.

BRAMBILLA (scrivendo): Quindi il 30.

GIADA: [Traduzione: l'ingegnera ha dato una stima, il dottore ha sentito una scadenza. E «se l'integrazione va liscia» è sparito mentre lo scriveva.]

Nota del traduttore. Una stima è una distribuzione di probabilità, non un numero. «Tre settimane» di solito è la mediana: il 50% di probabilità di finire prima e il 50% di finire dopo. Una frase più onesta sarebbe: «P50 tre settimane, P90 sei». E l'integrazione con il gestionale di solito si rivela un file CSV caricato via FTP alle tre di notte. Vale la legge di Hofstadter: ci vuole sempre più tempo del previsto, anche tenendo conto della legge di Hofstadter.

Scena VI — «Mettiamoci l'IA»

BRAMBILLA: E poi mettiamoci l'IA. Il CEO ne ha parlato al convegno.

FERRETTI: Per fare cosa?

BRAMBILLA: L'IA.

GIADA: [Traduzione: è settembre 2025. Ogni piano strategico deve contenere la parola "IA", come nel 2015 doveva contenere "big data" e nel 2018 "blockchain".]

Nota del traduttore. Per l'IT "mettiamoci l'IA" si traduce in domande molto concrete: quale problema risolve, quanto costa per ogni richiesta (i modelli si pagano a token), quanta latenza aggiunge, come si misura se risponde bene (le eval), cosa succede quando sbaglia con sicurezza, e quali dati del cliente stiamo mandando a un servizio esterno. Se la risposta alla prima domanda è «il CEO l'ha chiesto», le altre cinque diventano ancora più importanti.

Scena VII — L'IT parla, il business ascolta

Brambilla chiede un aggiornamento sul bug di ieri. Ferretti risponde. Giada traduce nella direzione opposta.

FERRETTI: Probabilmente è un problema di cache. GIADA: [Non sappiamo ancora cos'è.]

FERRETTI: In staging funziona. GIADA: [In produzione no.]

FERRETTI: C'è un workaround. GIADA: [Non lo sistemeremo mai davvero.]

FERRETTI: È un edge case. GIADA: [Succede a un cliente su diecimila. Purtroppo è il cliente più grande.]

FERRETTI: Quella libreria è deprecata. GIADA: [Funziona, ma ci vergogniamo un po' a usarla.]

FERRETTI: Ci serve uno sprint di refactoring. BRAMBILLA (sentendo «due settimane senza fare niente»): Assolutamente no. GIADA: [Cambiare le gomme mentre l'auto è in corsa costa di più che fermarsi ai box.]

FERRETTI: Dipende. GIADA: [Siediti, ti spiego per quaranta minuti.]

BRAMBILLA (alzandosi): Perfetto. Allora siamo allineati.

GIADA (a parte, al pubblico): Non lo siamo mai stati.

Sipario.

Dietro le quinte: perché le lingue sono due

Non è stupidità da una parte né pedanteria dall'altra. Sono due domini con vocabolari diversi, e l'ingegneria del software ha un nome preciso per questo. Nel 2003 Eric Evans, in Domain-Driven Design, introduce due idee:

• Ubiquitous language: un vocabolario comune, definito insieme da business e tecnici, usato nelle riunioni, nella documentazione e nel codice. Se il business dice "pratica", nel codice c'è una classe Pratica, non RequestEntityDTO.
• Bounded context: la stessa parola può avere significati diversi in contesti diversi, ed è normale. "Cliente" per le vendite è chi potrebbe comprare, per la fatturazione è chi ha una partita IVA, per la logistica è un indirizzo di consegna. Il problema nasce quando si finge che sia un'unica cosa.

Quando la traduzione salta, i danni sono reali. Il caso più famoso è quello del Mars Climate Orbiter, nel 1999. Il software di un fornitore produceva valori di impulso in libbre-forza per secondo, mentre quello della NASA si aspettava newton per secondo. Stessi numeri, unità diverse: la sonda è entrata nell'atmosfera di Marte troppo in basso ed è andata persa. Nessuno aveva sbagliato i calcoli. Avevano sbagliato la lingua.

Qualche rimedio pratico, testato sul campo:

1. Numeri al posto degli aggettivi. Non "veloce", ma "p95 sotto i 300 ms". Non "sempre disponibile", ma "SLO al 99,9% mensile". Non "presto", ma "P50 il 30, P90 il 15 del mese dopo".
2. Chiedere a cosa serve. «Cosa fai con questo dato, e quando?» trasforma il "tempo reale" in un batch notturno nove volte su dieci.
3. Esempi concreti. Una tabella di casi concreti chiarisce più di qualsiasi frase (ne abbiamo parlato nella cronaca degli if).
4. Un glossario vivo. Una pagina con le parole del dominio e la loro definizione, aggiornata quando cambiano. Noiosa da scrivere, preziosa da avere.
5. Un interprete. Product Owner, analisti, tech lead: le persone che parlano entrambe le lingue sono la risorsa più sottovalutata di un'azienda.

Frasario d'emergenza

Morale ingegneristica: un requisito non è una frase, è un accordo su un significato. Finché business e IT non usano le stesse parole con lo stesso senso, ogni riunione di allineamento è solo un'altra occasione per non capirsi in modo cortese.

Alla prossima storia di bit. Sottotitoli inclusi. 🎬