Introduzione

Perché sto scrivendo un manuale di analisi nell'era dell'AI

Il codice non è più il collo di bottiglia. La domanda "giusta" sì però, ed è per questo che apro una serie di capitoli su come si analizza il lavoro prima di provare ad automatizzarlo.

Negli ultimi due anni ho visto molte organizzazioni comprare AI o tecnologia in genere. Ne ho viste poche analizzare il lavoro che volevano automatizzare. Ma comprare tecnologia e analizzare il lavoro non sono la stessa cosa, e la seconda è quella che decide l'esito della prima.

Il pattern si ripete con una regolarità ormai ciclica: è stato lo stesso per l'acquisto dei primi pc, poi per i gestionali, per vari software. Possiamo dire quindi che non è più aneddotica. Arriva una direttiva — dobbiamo fare qualcosa con l'AI — e se va bene si sceglie un caso d'uso plausibile, si costruisce, si dimostra, e poi il progetto si spegne lentamente. Nessuno lo dichiara fallito ma nessuno lo usa davvero: viene semplicemente usato sempre meno, finché smette di essere argomento di riunione.

Quando si va a vedere cosa è andato storto, quasi mai è un problema tecnologico o di modello. È che nessuno aveva lavorato sul vero obiettivo analizzando nel suo complesso cosa dovesse risolvere o in cosa dovesse aiutare quello strumento.

1. Il punto cieco

Ora disponiamo di un'abbondanza di materiale su come si costruisce: modelli, prompt, orchestrazione, RAG, valutazione, agenti, governance. Ed è materiale buono. Ma è tutto a valle di una decisione che quasi nessuno documenta: cosa vale la pena automatizzare, e come si fa a saperlo prima di averlo costruito.

Quel vuoto ha una ragione storica. La discovery come la conosciamo — interviste, jobs-to-be-done, test di usabilità — è nata per prodotti che hanno un precedente d'uso. Presuppone che esista un comportamento da osservare e un utente in grado di raccontarlo. È una disciplina tarata sul miglioramento di qualcosa che già accade.

L'AI rompe questo presupposto in due punti. Introduce capability che non hanno precedenti: nessuno può raccontarti l'ultima volta che ha usato una cosa che non esiste. E introduce sistemi che agiscono, non che suggeriscono: sposta l'errore dal piano della risposta sbagliata al piano dell'azione sbagliata.

Serve quindi un'analisi che regga anche quando l'oggetto dell'analisi non esiste ancora. È questo che provo a mettere per iscritto.

2. Cosa intendo per "analisi"

Non intendo la raccolta dei requisiti. Non intendo un documento da far firmare. Non intendo un framework con un acronimo.

Intendo il lavoro di ricostruire come le cose accadono davvero: chi fa cosa, con quali strumenti, in che ordine, quali decisioni vengono prese e da chi, dove il processo ufficiale e il processo reale divergono, e quanto costa quella divergenza. Anche quando si progettano idee nuove, anzi, soprattutto.

In ogni organizzazione esistono due processi sovrapposti. Uno è quello descritto nelle procedure, nelle slide, nei diagrammi di flusso. L'altro è quello che le persone eseguono il lunedì mattina, fatto di fogli Excel paralleli, messaggi che sbloccano approvazioni, copia-incolla ripetuti, telefonate che servono perché due sistemi non si parlano.

Il primo processo è quello che ti raccontano. Il secondo è quello che automatizzerai. Se non li distingui, stai progettando per un'organizzazione che non esiste.

L'analisi, fatta bene, produce una cosa sola: la capacità di dire di no a un'idea sbagliata prima di averla pagata. Tutto il resto — mappe, personas, backlog — è strumentale a quello.

3. Perché adesso conta di più, non di meno

L'obiezione ricorrente è che con l'AI si costruisce così in fretta che tanto vale provare. È un'obiezione seria e ha tre risposte.

Il costo di costruire era un filtro. Non lo è più.

Quando sviluppare costava caro ed era lento, il costo stesso faceva da selezione: le idee deboli morivano in fase di stima. Oggi quel filtro non c'è. Passa tutto, e passa in fretta. Il che significa che il filtro va ricostruito da qualche altra parte, prima: nell'analisi. Non è nostalgia di processo, è aritmetica, è costruire un business plan. Se togli il vincolo che selezionava, devi introdurre un criterio che selezioni.

L'automazione amplifica, non corregge. E questo è il vero costo.

Un processo mal progettato che viene automatizzato non diventa un processo migliore. Diventa un processo sbagliato più veloce, più scalabile e più difficile da mettere in discussione perché adesso c'è un sistema che lo esegue e un budget che lo giustifica. L'automazione è un moltiplicatore: applicata a un numero negativo, restituisce un numero più negativo.

Un sistema che agisce ha un margine d'errore diverso.

Finché l'AI suggerisce, l'errore è filtrato da una persona. Quando l'AI esegue, l'errore diventa un'azione compiuta su dati reali: un ordine emesso, un prezzo modificato, una comunicazione inviata. È la ragione per cui il perimetro va progettato prima e non dopo, e per cui l'analisi del lavoro precede l'architettura del sistema. Qualcuno potrebbe parlare di guardrail, ma questo è un altro tema.

4. Due errori simmetrici, e i primi due capitoli

I capitoli che aprono questo manuale nascono dai due errori che vedo più spesso. Sono simmetrici: uno sta a monte, l'altro a valle, e sono la stessa cosa vista da due distanze diverse.

Il primo è definire la strategia prima di aver capito il campo di gioco. Si sceglie una direzione — un mercato, una tecnologia, una funzionalità, senza aver osservato le dinamiche reali del sistema in cui si opera: chi sono i giocatori, quali vincoli esistono, quali mosse hanno già fatto gli altri e perché. Il risultato sono iniziative che consumano risorse senza modificare nulla.

Il secondo è chiedere alle persone di immaginare come si comporteranno con qualcosa che non hanno mai visto. È l'errore specifico dei progetti AI, perché la capability è nuova per definizione. Le persone rispondono immaginando una versione idealizzata di sé, e tu raccogli un consenso che non si traduce in alcun comportamento.

In entrambi i casi si sostituisce l'osservazione con una narrazione — la propria nel primo caso, quella dell'intervistato nel secondo. E in entrambi i casi il rimedio è lo stesso: tornare su terreno verificabile, cioè su ciò che le persone fanno già oggi.

5. Come è fatto questo manuale

Ogni capitolo è un articolo autonomo. Non c'è una metodologia da adottare in blocco: se un capitolo ti serve e gli altri no, prendi quello.

La struttura è ricorrente, e cerca di essere operativa più che concettuale:

• Un problema specifico, descritto nel modo in cui si presenta davvero.
• Un metodo, con le condizioni in cui funziona e quelle in cui no.
• Un test di prontezza: come capire se puoi già applicarlo o se ti manca ancora qualcosa.
• Una checklist da usare mentre lavori, non da leggere e basta.
• Le trappole ricorrenti, con come suonano quando le stai facendo.

Gli articoli escono qui sul blog man mano che li scrivo. Quando il quadro sarà completo diventeranno un manuale vero e proprio, ordinato e rivisto. Nel frattempo l'obiettivo è renderli leggibili in qualsiasi ordine.

6. I capitoli

7. A chi serve

A chi deve decidere dove mettere un budget di innovazione e non vuole scoprire tra otto mesi di averlo messo nel posto sbagliato. A chi fa analisi, product o consulenza e si trova a lavorare su capability senza precedenti. A chi costruisce e vorrebbe che quello che costruisce venisse usato.

Non serve a chi cerca conferme. Buona parte del metodo consiste nel definire in anticipo cosa ti farebbe cambiare idea, e poi andarlo a cercare davvero.

---

Capitolo 1

Gameplay prima della strategia

Prima di definire una strategia bisogna capire il gioco in cui si sta giocando.

Molte organizzazioni saltano questo passaggio. Partono direttamente dalla strategia — dobbiamo fare questo, dobbiamo entrare in quel mercato, dobbiamo sviluppare quella funzionalità — senza aver compreso il contesto, le dinamiche e le regole del sistema in cui operano.

Non è pigrizia. È che la strategia è la parte visibile e narrabile del lavoro: si presenta in un consiglio, si mette in una slide, si comunica. L'osservazione del campo non produce niente da mostrare finché non è finita. Così si comincia da dove si può parlare, invece che da dove si può capire.

1. La strategia arriva dopo la comprensione del campo

La strategia non nasce nel vuoto. Prima bisogna osservare:

• chi sono i giocatori coinvolti;
• quali sono gli interessi in gioco;
• quali vincoli esistono;
• quali opportunità emergono;
• quali mosse stanno già facendo gli altri.

Non puoi scegliere la mossa migliore se non sai quale partita stai giocando.

Vale la pena notare che questi cinque punti non sono opinabili. Sono fatti, o almeno lo sono abbastanza da poter essere verificati. È il primo indizio che l'analisi del campo è un lavoro di osservazione, non di ideazione.

2. Guardare il "gioco attuale"

Il termine gameplay viene usato qui come metafora: significa osservare ciò che accade realmente, non ciò che le persone dichiarano che dovrebbe accadere.

Le domande da porsi sono quattro:

• Cosa stanno facendo oggi le persone?
• Quali comportamenti si ripetono?
• Quali decisioni vengono prese realmente?
• Quali strumenti, processi e abitudini guidano il lavoro quotidiano?

Il comportamento reale rivela quasi sempre più della strategia ufficiale. Se un'azienda dichiara di puntare sulla qualità del servizio ma il 70% del tempo del suo customer care se ne va a correggere errori di fatturazione, la strategia reale — quella che consuma le risorse — è un'altra.

Questa è anche la ragione per cui il campo si osserva a livello di comportamento e non di dichiarazione. È lo stesso principio che regge le interviste di discovery, ed è il tema del capitolo 3: le persone descrivono male ciò che fanno, ma lo fanno con grande coerenza.

3. La sequenza delle mosse conta

Una fotografia del presente non basta. Un campo di gioco è una sequenza, e va letto in tre momenti.

Il momento più trascurato è Prima. Quasi ogni processo assurdo che troverai in un'organizzazione è stato, in un certo momento, la soluzione ragionevole a un problema reale. Il problema è sparito, la soluzione è rimasta. Se non ricostruisci l'origine rischi di rimuovere un controllo che sembra inutile e che invece era l'unica cosa che teneva insieme due sistemi.

Una buona strategia nasce dalla comprensione della sequenza, non da un piano astratto.

4. Il problema delle strategie premature

Molte aziende fanno "strategia" troppo presto:

• scelgono una soluzione prima di capire il problema;
• investono in progetti perché "bisogna innovare";
• imitano competitor senza capire il loro contesto;
• definiscono obiettivi senza comprendere le dinamiche del mercato.

L'imitazione merita una nota a parte, perché è l'errore più costoso e il più difficile da riconoscere dall'interno. Copiare la mossa di un concorrente significa assumere che il suo campo di gioco sia il tuo: stessa struttura di costi, stessi clienti, stessi vincoli normativi, stessa posizione di partenza. Quasi mai è vero. E una mossa giusta eseguita da una posizione sbagliata è una mossa sbagliata.

Il risultato di tutto questo sono iniziative che consumano risorse ma non cambiano il campo di gioco. Non falliscono in modo netto — sarebbe più utile. Restano in vita quel tanto che basta a occupare budget e attenzione.

5. Applicazione pratica

Il metodo è in tre tempi, e l'ordine non è negoziabile.

1. Osserva il sistema

• clienti
• concorrenti
• processi
• incentivi
• vincoli

Gli incentivi sono il fattore che viene omesso più spesso e che spiega più cose. Se il commerciale è premiato sul fatturato firmato e non sul margine incassato, nessuna strategia di redditività reggerà al primo trimestre. Le persone non seguono la strategia: seguono l'incentivo.

2. Comprendi il gioco

• Cosa determina il successo?
• Quali mosse creano vantaggio?
• Quali mosse sono inutili?

La terza domanda vale quanto le prime due. Identificare le mosse che non producono vantaggio — quelle che tutti fanno perché tutti le fanno — libera risorse più in fretta di qualsiasi nuova iniziativa.

3. Solo dopo scegli la strategia

A questo punto la scelta è quasi noiosa. Se hai fatto bene i primi due passaggi, le opzioni residue sono poche e la migliore è spesso evidente. Quando la scelta strategica sembra difficile e appassionante, di solito è il segnale che il campo non è stato osservato abbastanza.

Il collegamento con l'AI

Il principio è vicino al modo in cui si costruiscono prodotti digitali oggi.

Molte aziende chiedono: "Quale tecnologia dobbiamo usare?"

La domanda corretta è quasi sempre: "Quale problema reale stiamo cercando di risolvere, e come si comportano oggi le persone che lo vivono?"

Prima il campo di gioco. Poi la strategia. Poi la tecnologia.

È un principio particolarmente rilevante nell'era dell'AI, per una ragione asimmetrica: chi parte dagli strumenti rischia di automatizzare processi sbagliati, e l'automazione non corregge un processo, lo amplifica. Chi capisce il gioco può invece ridisegnare il modo in cui il lavoro viene svolto — che è l'unica cosa che sposta davvero il campo.

Il rischio cresce quando il sistema non si limita a suggerire ma esegue. Un errore di analisi, in quel caso, non produce una risposta sbagliata: produce un'azione sbagliata su dati reali.

Test di prontezza: hai capito il gioco?

Prima di scrivere qualsiasi documento di strategia, prova a rispondere a queste domande senza usare condizionali e senza usare la parola "generalmente".

• So elencare i giocatori reali, inclusi quelli che non compaiono nell'organigramma
• So dire quale incentivo governa il comportamento di ciascuno
• So descrivere cosa fanno oggi le persone, con un episodio concreto e recente
• So ricostruire perché il processo attuale è nato così
• So indicare almeno una mossa diffusa nel settore che non produce vantaggio
• So dire cosa determina il successo in questo campo, e come si misura
• Ho scritto cosa mi farebbe cambiare idea sulla lettura che ho fatto del campo

Se più di due caselle restano vuote, non ti serve una strategia. Ti serve un'altra settimana di osservazione.

Trappole ricorrenti

Continua il manuale