Nella figura precedente, le prime due fasi sono dedicate all’esplorazione dello spazio del problema: la “comprensione del problema aziendale” e la “comprensione del contesto”.
Per quanto riguarda la “comprensione del problema aziendale”, l’obiettivo è cercare di capire il più possibile il problema e continuare finché non si ha la sensazione di averlo compreso a fondo.
È probabile che questo inizi a un livello piuttosto alto con gli stakeholder aziendali senior (cioè, verosimilmente, coloro che controllano il budget e hanno proposto il progetto). Poi ci si aspetta di passare a una comprensione più granulare del problema parlando con gli eventuali utenti di ciò che si prevede di costruire e con gli operatori qualificati coinvolti. Questo processo dovrebbe aiutarti a conoscere i punti dolenti delle varie persone in azienda.
Questo punto di vista viene poi convalidato con una gamma più ampia di stakeholder e si raccolgono le idee di un ottimistico stato “to‑be”. Una domanda interessante da porre agli stakeholder è: “Come vorreste che fosse la soluzione se poteste agitare una bacchetta magica?”
Un aspetto fondamentale è convalidare sempre ciò che ti viene detto; un ottimo metodo è imparare dai ricercatori etnografici e osservare ciò che accade realmente in questi contesti aziendali. Dopo aver accolto le diverse prospettive, questo ti aiuta a superare i potenziali pregiudizi.
La comprensione del problema aziendale da una serie di prospettive è solo un aspetto. È necessario comprendere anche i dati pratici e i vincoli ingegneristici — e lo si può fare in parallelo. Al livello più semplice, si tratta di stabilire quali dati sono disponibili e di comprendere i sistemi esistenti in cui la soluzione prevista dovrebbe inserirsi.
Mentre raccogli e assimili queste informazioni, è anche una buona idea iniziare a mappare queste conoscenze per progettare un prototipo di soluzione. Alcune domande utili in questa fase potrebbero essere:
- Come si possono costruire elementi utilizzando modelli o approcci di AI esistenti o comunemente conosciuti (inclusi quelli generativi)?
- Quale elaborazione o logica dovrebbe essere applicata ai risultati di questi algoritmi per renderli utilizzabili?
- Come si possono combinare diverse fonti di dati o output di modelli per migliorare la soluzione?
A questo punto, con una migliore comprensione del contesto, può essere utile tornare da alcuni stakeholder aziendali con domande pratiche sul modo in cui svolgono le loro attività, che potrebbero essere utili per la soluzione, come ad esempio:
- Quali sono le ipotesi che i professionisti qualificati fanno nel loro ruolo nell’esecuzione di tali compiti?
- Esistono regole empiriche che gli operatori qualificati utilizzano per svolgere il loro lavoro?
Lo sviluppo della soluzione sarà senza dubbio un processo iterativo, con l’aggiunta di aggiornamenti man mano che si rendono disponibili nuove informazioni. Tuttavia, è una buona idea presentare qualcosa ai principali stakeholder il prima possibile, per identificare eventuali malintesi e garantire la raccolta di feedback, costruttivi o meno. È proprio quando si dispone di un progetto concreto da condividere che possono emergere feedback reali e pratici (e gli ovvi “intoppi”).
Con ulteriori iterazioni e una volta creata una versione più matura della soluzione, è prevista una fase di controllo formale per ottenere un feedback sulla soluzione attualmente proposta (“Convalidare il valore della soluzione”), con l’elemento chiave di convalidare il valore che questa soluzione offre.
.webp "GFT Blog: Overview")