> ## Content Index > Fetch the complete content index at: https://bitstales.eu/llms.txt > Use this file to discover other available public pages before exploring further. # Il riunionone: come una lista di clienti da chiamare diventò un progetto da sette mesi (e poi tornò una query) - URL: https://bitstales.eu/it/riunionone-requisiti-semplici/ - Published: 2025-09-18T18:20:00.000Z - Updated: 2025-09-18T18:20:00.000Z - Description: Mezz'ora in sala Everest, a turno dalla parte del business e dei tecnici: l'AI chiesta al posto di una lista, i «già che ci siamo», i «se un domani», un Gantt da sette mesi. Poi una domanda stupida, sette righe di SQL e una riga di cron. - Author: Vittorio - Tags: Business, Software Engineering, Communication, #it Giovedì 18 settembre 2025, ore 9:52\. Nel calendario lampeggia un invito: **«Allineamento requisiti – Progetto Riattivazione Clienti»**. Dalle 10:00 alle 10:30, sala Everest. Quattordici partecipanti, di cui sei «facoltativi»: verranno tutti, perché c'è il vassoio delle brioche. Allegati: nessuno. Descrizione: «come da accordi». In questa riunione entri due volte, a turno. Un po' sei il **business**: hai un problema e devi farlo capire. Un po' sei il **tecnico**: devi costruire la soluzione. La settimana scorsa avevamo [messo i sottotitoli](https://bitstales.eu/it/business-it-due-lingue/) a una riunione come questa, per tradurre le due lingue. Oggi la cronometriamo, minuto per minuto, per vedere come un bisogno piccolo diventa un progetto enorme. Spoiler: nessuno è in malafede, ed è proprio questo il problema. ## 9:55 · Tu, business: il bisogno vero Sei responsabile commerciale. Ogni lunedì mattina fai la stessa cosa: apri il gestionale, scorri la lista dei clienti e per ognuno guardi la data dell'ultimo ordine. Se è più vecchia di due mesi, copi nome e telefono su un foglio. Alla fine consegni il foglio ai commerciali, che passano la settimana a chiamare: «Tutto bene? Le serve qualcosa?». Funziona: tanti, chiamati in tempo, tornano a ordinare. Però ti costa tre ore, ogni lunedì. Il bisogno vero, quindi, sta in una riga: *il lunedì mattina voglio la lista dei clienti che non ordinano da 60 giorni, con il telefono, senza perderci tre ore.* Solo che nella mail di convocazione non hai scritto questo. Hai scritto: «Ci serve una dashboard predittiva sul churn dei clienti, basata sull'AI». Perché? Perché alla fiera di settore, a giugno, tre relatori su tre hanno detto «AI». Perché *churn* (l'abbandono dei clienti) suona molto meglio di «quelli che non ci comprano più». E soprattutto perché sai, per esperienza, che se chiedi «una lista» finisci in fondo alla coda, mentre se chiedi «una piattaforma» ti danno budget, sponsor e la sala Everest. Hai appena fatto la prima mossa che complica tutto: invece di descrivere il **problema**, hai chiesto una **soluzione**, quella che avevi già in testa. Nei forum tecnici questa cosa ha un nome, [problema XY](https://xyproblem.info/?ref=bitstales.eu): hai il problema X, immagini che la soluzione sia Y e chiedi aiuto su Y. Tutti lavoreranno benissimo su Y, e nessuno saprà mai niente di X. ## 10:01 · Tu, tecnico: il cervello parte da solo Adesso sei dall'altra parte del tavolo. Senti «dashboard», «predittiva», «AI», e prima che il proiettore finisca di scaldarsi il tuo cervello ha già riempito la lavagna: ```yaml # lavagna, ore 10:03 — "Customer Reactivation Platform" v0.1 servizi: - api-gateway - auth-service # SSO + MFA, ovviamente - ingestion-service # legge gli ordini da Kafka - kafka # tre broker, "per la resilienza" - data-lake - feature-store - churn-model # l'AI richiesta - model-registry - notification-service # mail, push, SMS, "un domani WhatsApp" - dashboard-frontend team: 3 stima: "7 mesi, sprint zero escluso" ``` Non lo fai per cattiveria. Lo fai perché l'ultima volta che hai consegnato «una cosa semplice», quella cosa è diventata il cuore dell'azienda e per quattro anni l'hai mantenuta senza nessuno accanto, con i commenti in tre lingue. Lo fai perché un'architettura grande ti protegge: se qualcosa va storto, nessuno potrà dire che non l'avevi previsto. E lo fai, diciamolo sottovoce, perché «Kafka» sul CV pesa più di «una query». In sala Everest nessuno lo dirà mai ad alta voce. Ecco la seconda mossa che complica tutto: hai preso sul serio la soluzione proposta dal business, invece di prendere sul serio il business. ## 10:06 · Tu, business: «già che ci siamo…» Torni al tuo posto. Vedi la lavagna piena di riquadri e frecce e provi una sensazione nuova: ti stanno prendendo sul serio. E quando ti prendono sul serio, viene voglia di chiedere di più. - «Già che ci siamo, si può esportare in PDF?» - «Già che ci siamo, un'app per l'iPhone?» Lunedì l'hai aggiornato a iOS 26, quello con il nuovo effetto «vetro liquido», e ti sembra un peccato non usarlo. - «Già che ci siamo, una notifica quando un cliente diventa a rischio.» - «Già che ci siamo, una vista per la direzione, con i grafici.» - «Già che ci siamo, multilingua: un domani apriamo in Germania.» A te ogni «già che ci siamo» costa una frase. A chi deve costruirlo costa settimane. In sala nessuno ha in mano il cartellino del prezzo, e senza prezzo tutto sembra gratis. È il gemello del problema XY: lì nascondevi il bisogno sotto una soluzione, qui lo seppellisci sotto gli extra. ## 10:10 · Tu, tecnico: «e se un domani…» Rispondi con la stessa moneta. «E se un domani i clienti diventano dieci milioni?» Oggi sono 3.200 e crescono del 4% all'anno: a questo ritmo, per arrivare a dieci milioni servono circa duecento anni. Ma l'architettura, giustamente, deve essere pronta. «E se un domani cambiamo gestionale?» Ecco un livello di astrazione. «E se un domani i commerciali vogliono la lista sull'orologio?» Il frontend sarà *headless*. Il «se un domani» è il «già che ci siamo» dei tecnici: un'assicurazione contro un futuro immaginario, pagata oggi con soldi veri. Nel 1998 Ron Jeffries, uno dei padri dell'Extreme Programming, la mise giù così: [«implementa sempre le cose quando ti servono davvero, mai quando prevedi soltanto che ti serviranno»](https://ronjeffries.com/xprog/articles/practices/pracnotneed/?ref=bitstales.eu). Da lì viene la sigla YAGNI, *You Aren't Gonna Need It*: non ti servirà. Quasi sempre è vero. E quando non lo è, aggiungere la cosa dopo costa meno che mantenerla per anni senza usarla. ## 10:15 · Tutti e due: la stima La persona della sicurezza chiede del GDPR, e fa bene: ci sono di mezzo nomi e numeri di telefono. Chi fa da project manager proietta un diagramma di Gantt: sette mesi, tre team e uno «sprint zero» per decidere come fare gli sprint. Il costo ha più cifre del budget annuale delle macchinette del caffè. Silenzio. Tu, business, pensi: «Tutto questo per tre ore il lunedì?». Ma non lo dici, perché ormai la dashboard predittiva è diventata un progetto, e i progetti non si smontano a voce. Tu, tecnico, pensi: «Sette mesi è ottimistico». E non lo dici neanche tu. ## 10:18 · La domanda stupida In fondo al tavolo c'è chi è in azienda da due settimane: l'unica persona nella stanza senza una reputazione da difendere né un CV da gonfiare. Alza la mano, a metà. «Scusate, forse è una domanda stupida. Ma alla fine, con la lista, cosa ci fate?» Tu, business, rispondi senza pensarci: «La stampo e la do ai commerciali, il lunedì mattina. Chiamano». «E adesso come la fate?» «A mano. Ci metto tre ore.» «E se il lunedì alle sette trovaste un file Excel già pronto nella cartella condivisa?» Pausa. Lunga. «…Sarebbe perfetto, in realtà.» In tre domande sono spariti l'AI, il data lake, l'app con il vetro liquido e i dieci milioni di clienti del ventitreesimo secolo. È la versione da riunione di un vecchio attrezzo della Toyota: Taiichi Ohno, il padre del suo sistema di produzione, insegnava a chiedere «perché?» cinque volte di fila, finché non si arriva alla causa vera di un problema. Per i requisiti spesso ne bastano due o tre, con una variante. Non «perché?», che mette le persone sulla difensiva, ma **«cosa ci fai, dopo?»** e **«come lo fai adesso?»**. Non sono domande tecniche e nemmeno di business. Riguardano quello che succede *dopo* il software, che è l'unica cosa che conta. ## 10:20 · Tu, tecnico: sette righe Apri il portatile. Il gestionale gira su PostgreSQL, con una tabella `clienti` e una tabella `ordini`. Scrivi: ```sql SELECT c.ragione_sociale, c.telefono, c.commerciale, max(o.data) AS ultimo_ordine FROM clienti c JOIN ordini o ON o.cliente_id = c.id GROUP BY c.id HAVING max(o.data) < current_date - 60 ORDER BY c.commerciale, ultimo_ordine; ``` Riga per riga: per ogni cliente (`GROUP BY`) prendi la data dell'ultimo ordine (`max`), tieni solo quelli fermi da più di 60 giorni (`HAVING`, che è il `WHERE` dei gruppi) e ordina per commerciale, così ognuno trova i suoi clienti tutti vicini. Chi non ha mai ordinato non compare, ed è giusto così: quello non è un cliente da riattivare, è un contatto da attivare. Altra riunione, altra sala. L'ho provata davvero, su un database di prova con PostgreSQL 17: 3.200 clienti e circa 57.000 ordini. Risultato: 322 clienti da chiamare, in 32 millisecondi. Dall'altra parte, sette mesi di Gantt. Poi la lista deve arrivare da sola. Basta una riga di `cron`, il programma di Unix che esegue comandi a orari fissi: ```bash # ogni lunedì alle 7:00 0 7 * * 1 psql -d gestionale --csv -P csv_fieldsep=';' -f /opt/report/dormienti.sql > /srv/condivisa/da-chiamare-$(date +\%F).csv ``` L'opzione `--csv` di `psql` esiste [da PostgreSQL 12](https://www.postgresql.org/docs/release/12.0/?ref=bitstales.eu). Il punto e virgola come separatore è per Excel: quando è configurato in italiano, di solito si aspetta quello, e con le virgole ti mette tutto nella prima colonna. Ma il dettaglio più insidioso dell'intero progetto è la barra prima di `%F`. Nel crontab il simbolo `%`, [se non è preceduto da una barra rovesciata](https://man7.org/linux/man-pages/man5/crontab.5.html?ref=bitstales.eu), diventa un a capo, e il comando si spezza in silenzio. Ecco, adesso anche tu hai la tua «complessità»: sta tutta in un carattere. Totale: un pomeriggio, test compresi. ## 10:24 · Perché è così difficile da accettare Dovrebbe finire qui, con un applauso. Invece arrivano le resistenze, da tutte e due le parti. Tu, business, pensi: *«Tutto qui? Sembra poco»*. Ed è comprensibile: siamo abituati a misurare il valore di una cosa con quanto è costata. Se si fa in un pomeriggio, sembra valere un pomeriggio. Un progetto da sette mesi, invece, si può raccontare alla direzione, mettere in una slide, festeggiare al go-live. Ma fai il conto: tre ore per una cinquantina di lunedì all'anno sono circa 150 ore, quasi un mese di lavoro restituito. E la lista arriva tutte le settimane, non solo quando hai tempo. Il valore non sta nelle righe di codice ma in quello che cambia il lunedì mattina. Tu, tecnico, pensi: *«Non è scalabile. Non è elegante. Non è da CV»*. E sotto, più in profondità, c'è un pensiero meno confessabile: se il lavoro richiede un pomeriggio, a cosa servo io? Servi esattamente a questo: a trovare la versione da un pomeriggio. Nel 1980, ricevendo il premio Turing, Tony Hoare lo disse meglio di chiunque. Ci sono due modi di progettare il software: [«uno è renderlo così semplice che ovviamente non ci sono difetti, l'altro è renderlo così complicato che non ci sono difetti ovvi»](https://dl.acm.org/doi/10.1145/358549.358561?ref=bitstales.eu). E subito dopo aggiunse: «Il primo metodo è molto più difficile». Difficile davvero, e non solo nel software. Nel 1657, nella sedicesima delle sue *Provinciali*, Blaise Pascal si scusava così: [«Ho fatto questa lettera più lunga solo perché non ho avuto il tempo di farla più corta»](https://quoteinvestigator.com/2012/04/28/shorter-letter/?ref=bitstales.eu). La frase circola anche con il nome di Mark Twain, che non c'entra. Fare semplice richiede tempo, e soprattutto coraggio: in sala Everest ci sono voluti diciotto minuti e qualcuno che non avesse paura di fare una domanda ingenua. Una precisazione, per non buttare via anche le preoccupazioni giuste: semplice non vuol dire sciatto. La query va nel versionamento come se fosse importante, perché lo è. Il file va in una cartella che vedono solo i commerciali (la persona della sicurezza annuisce). E qualcuno scrive tre righe su cosa fa il report e chi chiamare se il lunedì il file non c'è. Se un giorno i clienti diventeranno davvero dieci milioni, riscriverai tutto, con i soldi guadagnati nel frattempo. ## 10:29 · Tutti e due: finisce in orario Per la prima volta nella storia della sala Everest, la riunione finisce in orario. Avanzano brioche. Chi fa da project manager archivia il Gantt in una cartella che si chiama «Futuro», e nessuno ha il coraggio di cancellarla. ## Fra tre mesi, scommettiamo Fra qualche mese, scommettiamo, tu, business, tornerai con una richiesta nuova: «Si potrebbe aggiungere l'ultimo prodotto che hanno comprato? Così i commerciali sanno cosa proporre». Nota la differenza: questa richiesta non arriva da una fiera, arriva dall'uso. I commerciali avranno chiamato trecento clienti e scoperto cosa manca davvero. È un bisogno vero, e nessuno avrebbe potuto progettarlo a settembre. E tu, tecnico, lo aggiungerai in mezz'ora: ```sql WITH ultimo AS ( SELECT DISTINCT ON (c.id) c.ragione_sociale, c.telefono, c.commerciale, o.data AS ultimo_ordine, p.nome AS ultimo_prodotto FROM clienti c JOIN ordini o ON o.cliente_id = c.id JOIN prodotti p ON p.id = o.prodotto_id ORDER BY c.id, o.data DESC, o.id DESC ) SELECT * FROM ultimo WHERE ultimo_ordine < current_date - 60 ORDER BY commerciale, ultimo_ordine; ``` [DISTINCT ON](https://www.postgresql.org/docs/17/sql-select.html?ref=bitstales.eu#SQL-DISTINCT) è una specialità di PostgreSQL: per ogni cliente tiene solo la prima riga secondo l'ordinamento, cioè l'ordine più recente. Il pezzo `o.id DESC` serve a decidere quando ci sono due ordini nello stesso giorno. Stessi 322 clienti, una colonna in più. È così che crescono i sistemi che funzionano. Nel 1975 John Gall, pediatra, pubblicò un libro ironico sui sistemi intitolato *Systemantics*. Dentro c'è una frase che gli informatici oggi chiamano «legge di Gall»: [«Un sistema complesso che funziona risulta invariabilmente evoluto da un sistema semplice che funzionava»](https://en.wikipedia.org/wiki/Systemantics?ref=bitstales.eu). Vale anche al contrario: un sistema complesso progettato da zero non funziona, e non lo si aggiusta a forza di toppe. Bisogna ricominciare da un sistema semplice che funziona. Per esempio, una query di sette righe. ## Il kit anti-riunionone Da stampare e portare alla prossima convocazione con quattordici partecipanti e nessun allegato. **Se sei tu a chiedere (business)** - Racconta cosa fai oggi, non cosa vorresti comprare. «Ogni lunedì perdo tre ore a…» vale più di «ci serve una piattaforma». - Porta un esempio del risultato che vuoi: anche un foglio scritto a mano, anche la foto di una lavagna. - Di' cosa succede dopo: chi lo usa, quando e per fare cosa. - Per ogni «già che ci siamo», chiedi quanto costa. Se nessuno lo sa, non è gratis. - Accetta la versione brutta che funziona da venerdì. Quella bella arriverà, se serve. **Se sei tu a costruire (tecnico)** - Prima di toccare la lavagna, chiedi «cosa ci fai, dopo?» e «come lo fai adesso?». - Spesso la soluzione è il processo che esiste già, automatizzato. Parti da lì. - Conta i dati, davvero. Tremila righe non sono big data, e spesso non lo sono neanche tre milioni. - Per ogni «se un domani», chiedi: quando? Quanto è probabile? Quanto costerebbe aggiungerlo dopo? - Proponi la versione che puoi consegnare questa settimana, e trattala come codice vero: versionata, documentata in tre righe, con i permessi giusti. **Per tutti e due** - La domanda stupida è quella che costa di più non fare. - Se una riunione sui requisiti finisce senza che nessuno abbia visto un esempio del risultato, non è finita: è solo rimandata. ## 15:40 · Il prossimo invito Nel pomeriggio arriva un altro invito, per domani: «Allineamento requisiti – Progetto Export Fatture». Dalle 10:00 alle 11:30, sala Everest, diciassette partecipanti, nessun allegato. Prima di accettare rispondi con una riga sola: «Mi mandate un esempio del file che vi serve, e cosa ci fate dopo?». Dodici minuti dopo arriva un foglio Excel con quattro colonne e una risposta: «Lo carichiamo sul portale della banca, il 5 di ogni mese». La riunione viene annullata. Da qualche parte, in una cartella che si chiama «Futuro», un diagramma di Gantt piange in silenzio. Fonti - [The XY Problem](https://xyproblem.info/?ref=bitstales.eu) e Meta Stack Exchange, [What is the XY problem?](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem?ref=bitstales.eu) - Ron Jeffries, [You're NOT gonna need it!](https://ronjeffries.com/xprog/articles/practices/pracnotneed/?ref=bitstales.eu) (4 aprile 1998) - Taiichi Ohno, *Toyota Production System: Beyond Large-Scale Production*, Productivity Press (1988; ed. originale giapponese 1978), il capitolo sui cinque perché - C. A. R. Hoare, [The Emperor's Old Clothes](https://dl.acm.org/doi/10.1145/358549.358561?ref=bitstales.eu), Communications of the ACM 24(2), 1981 (lezione per il premio Turing 1980) - Quote Investigator, [If I Had More Time, I Would Have Written a Shorter Letter](https://quoteinvestigator.com/2012/04/28/shorter-letter/?ref=bitstales.eu) (Pascal, *Lettres provinciales*, XVI, 1657) - John Gall, *Systemantics* (1975); voce [Systemantics](https://en.wikipedia.org/wiki/Systemantics?ref=bitstales.eu) su Wikipedia - PostgreSQL, [note di rilascio della versione 12](https://www.postgresql.org/docs/release/12.0/?ref=bitstales.eu) (`psql --csv`) e documentazione di [SELECT DISTINCT ON](https://www.postgresql.org/docs/17/sql-select.html?ref=bitstales.eu#SQL-DISTINCT) - [crontab(5)](https://man7.org/linux/man-pages/man5/crontab.5.html?ref=bitstales.eu), il simbolo % nei comandi - Apple Newsroom, [New versions of Apple's software platforms are available today](https://www.apple.com/newsroom/2025/09/new-versions-of-apples-software-platforms-are-available-today/?ref=bitstales.eu) (15 settembre 2025)