Nel mio ultimo articolo su questo blog sostenevo che bisogna mettere al centro i problemi che si vogliono risolvere, non le tecnologie che si vogliono adottare, anzi, di per sé, non si dovrebbe neppure voler adottare una tecnologia, ma trovare le tecnologie corrette a partire dal problema, ma questa è tante volte solo teoria: in pratica, molto spesso si parte avendo già in testa delle tecnologie, e non è neppure sbagliato, se comunque si mantiene il focus sul problema.

Ho fatto cenno anche ad un framework concettuale che può essere utilizzato nei progetti del tipo “ICT/AI for good”. Questo framework, in realtà, può essere utilizzato in qualsiasi progetto ICT/AI che semplicemente abbia la pretesa di avere un effetto positivo; personalmente e come azienda, sono gli unici progetti che mi interessano.

Le fasi del framework

Cosa prevede quindi questo framework per progetti ICT/AI? Non si tratta di colpi di genio, ma solo di ragionevolezza (e scusate se è poco!). Suggerisce in sostanza di strutturare il progetto secondo queste fasi:

1. Esplorazione
2. Design
3. Implementazione
4. Valutazione

Qui sento subito “ribollire” lo spirito che anima alcuni miei amici, innamorati, come me, delle tecniche agili: se si vuole essere agili (e vogliamo, perché in questo modo aumentano significativamente le probabilità che il progetto vada a buon fine) non dobbiamo considerarle come fasi separate eseguite una volta sola in stretta sequenza, ma come fasi eseguite ciclicamente. Ci sarebbe molto da dire a questo proposito, ma ora mi interessano altre considerazioni, quindi abbandono questo interessantissimo tema.

Esplorazione: cosa significa esplorare il problema?

Il framework suggerisce diverse attività fondamentali durante la fase di esplorazione:

Individuare ed ingaggiare i “portatori di interesse” (stakeholder)

Le persone e le organizzazioni che hanno un interesse nel problema che vogliamo affrontare (il problema, appunto, non le tecnologie) hanno una sensibilità ed una visione, oltre che una conoscenza, molto più approfondita della nostra e sono imprescindibili per capirlo meglio e, in definitiva, per il successo del progetto. Qualche tempo fa, mi è stato proposto un progetto di AI avanzata che doveva servire a supporto delle cooperative di pesca dell’Adriatico: ho aderito con entusiasmo ed ho chiesto di incontrarne almeno una: la freddezza con cui sono stato accontentato avrebbe dovuto mettermi sull’avviso, ma, comunque, non ci volle molto, una volta individuato l’interlocutore, per capire che il “portatore di interesse” … non aveva alcun interesse nella cosa. Facile immaginare che il progetto sia finito male.

Definire il problema

Una buona definizione di un problema dovrebbe descrivere il problema nelle sue caratteristiche essenziali, senza troppi dettagli e sicuramente senza riferimento alle tecnologie che si pensa di potere o dovere utilizzare; inoltre, dovrebbero essere individuati i dati necessari e menzionati esplicitamente gli stakeholder (almeno quelli “chiave”, quelli cioè che possono determinare il successo o il fallimento del progetto); cosa molto importante, bisognerebbe che contenesse almeno un’idea abbastanza chiara, se non una vera e propria definizione formalizzata, di cosa si intende per successo del progetto, qualcosa che, alla fine dovrebbe permettere di dire appunto se l’obiettivo è stato raggiunto o no.

Determinare se l’AI o la specifica tecnologia che si pensa di adottare porti un effettivo vantaggio rispetto alle tecnologie tradizionali con cui il problema viene affrontato

Proprio ieri, sono stato a visitare un possibile cliente; abbiamo parlato di tecnologia, ovviamente, ma avevo chiesto in anticipo che mi facessero visitare la linea produttiva, proprio per avere l’occasione di “esplorare” il problema. Ad un certo punto, intelligentemente, uno dei miei interlocutori mi ha chiesto quale fosse il reale vantaggio di utilizzare le reti neurali ed il machine learning per quel problema invece che le tecniche di computer vision tradizionali: è stato un momento chiave dell’incontro, durante il quale ho fatto appunto questa disamina e spiegato, spero in modo efficace, come e perché il ML, in questo caso, non sempre, batte le tecniche tradizionali.

Applicare il principio “Do not (cause significant) harm”

Preoccuparsi che oltre a risolvere il problema in esame il nostro approccio non causi dei danni (significativi) a nessuno. Questo è un principio di natura etica e qualcuno potrebbe anche pensare di non applicarlo, ma attenzione: se il nostro progetto causa dei danni significativi a qualcuno, questi potrebbe agire contro il progetto e magari anche, a torto o a ragione, farlo fallire.

Domande chiave della fase di esplorazione

In conclusione, alla fine della fase di esplorazione dovremmo essere in grado di rispondere (almeno) a queste domande:

• Qual è il problema specifico che vogliamo affrontare?
• Chi sono gli stakeholder (almeno quelli “chiave”, che comunque vanno individuati)?
• Abbiamo accesso o possiamo acquisire i dati necessari?
• Quali vantaggi porta la tecnologia proposta?
• Cosa ci indicherà se il progetto ha avuto successo o no?
• La soluzione che abbiamo in mente causa dei danni significativi a qualcuno? Questi danni possono essere mitigati?

Conclusione: pronti per il design

Solo a questo punto potremo affrontare efficacemente la seconda fase, quella del “design” della soluzione … ma di questo ne parleremo una prossima volta.