Requisiti, sistemi e soluzioni. Come aiutare i business analyst a comprendere le vere esigenze del cliente, mettendo in discussione processi e abitudini consolidate per suggerire soluzioni alternative e cogliere nuove opportunità di sviluppo
Supponiamo che si stia lavorando a un progetto per un Comune su come migliorare il modo in cui in autunno vengono ripulite le strade dalle foglie. Viene detto che si intende usare macchine soffiatrici più moderne al posto delle scope utilizzate attualmente. Da dove si inizia? Tutto dipende dall’esperienza accumulata e dalla conoscenza disponibile su sistemi simili. Il cliente, nel nostro esempio il Comune, ha un punto di vista focalizzato su una soluzione, ma non ha spiegato qual è il problema. La richiesta è “macchine più moderne per soffiare le foglie”. Ma perché le vogliono? Quali sono i vantaggi che il Comune vuole ottenere da questa soluzione? Se siete capaci di rispondere a questa domanda, siete sulla buona strada per scoprire il vero problema da affrontare. E una volta scoperto il vero problema, forse si aprirà la strada anche a un ventaglio di possibili soluzioni – di solito migliori – che fino a quel momento non erano state prese in considerazione.
Un modo efficace per scoprire il vero problema è iniziare con la soluzione che il cliente ha chiesto e usarla come base per scoprire il vero problema. Si può iniziare facendo uno schizzo approssimativo per rappresentare la soluzione richiesta dal cliente, disegnandolo con lui e usando la sua terminologia. Se non si è sicuri delle proprie capacità di disegno, si potrà annotare l’immagine con le parole del cliente. “Ciascun spazzatore di foglie ha un programma giornaliero delle aree da ripulire. Voglio che usino macchine soffiatrici nuove per soffiare le foglie in mucchi. Quindi probabilmente dovranno spazzare le foglie in mucchi ordinati. Quando hanno abbastanza mucchi di foglie, telefonano alla sede centrale e comunicano che le foglie sono pronte per essere raccolte dai camion. Quindi all’arrivo del camion, le foglie saranno messe nei sacchi, che saranno caricati e conferiti al produttore di fertilizzanti”.
Una volta stabilite le linee di comunicazione, è possibile porre alcune domande per sondare più in profondità. Analista: «Perché volete che utilizzino un nuovo tipo di soffiatrici»? Cliente: «Altri Comuni li usano e vogliamo essere aggiornati. E vogliamo accelerare il tempo necessario per preparare i mucchi di foglie che i conducenti possano raccogliere». Analista: «Perché occorre essere più veloci»? Cliente: «Non vogliamo che il ritiro delle foglie venga ritardato. Il tempo è imprevedibile, e se piove e c’è vento, le foglie rendono i marciapiedi molto scivolosi e fanno cadere i pedoni: abbiamo già avuto molti incidenti». Analista: «Quindi dobbiamo fare tutto il possibile per accelerare la rimozione delle foglie dai percorsi ed evitare incidenti». Cliente: «Questo è ciò che dobbiamo fare». Parlando con il cliente in termini di ciò che ha chiesto, si inizia ad avere una migliore comprensione di ciò di cui ha veramente bisogno.
Analisi della situazione
Per capire di più sulle esigenze del cliente, è spesso una buona pratica dare un’occhiata a come il lavoro viene svolto. Occorre scoprire chi sono le persone impegnate nell’ambito del progetto. Chi sono i dipendenti comunali che attualmente spazzano le foglie, chi sono i loro manager, quali altre parti dell’organizzazione sono coinvolte, qual è l’area geografica, quale tecnologia usano attualmente per la rimozione delle foglie, quali sistemi software e hardware hanno. Tutte domande su come le cose funzionano o non funzionano. Ci sono un numero infinito di domande che si potrebbero porre. E per questo, serve un modo per sapere quali domande fare e quanto lontano si può andare. Si può provare a testare la comprensione del problema, vedendo se si riesce a rispondere a queste tre domande: Si riesce a identificare l’ambito del sistema su cui bisogna investigare? Si riesce a identificare le parti interessate in questo sistema? Si riesce a comprendere perché il Comune vuole realizzare questo progetto? Alla fine, si è capito che bisogna fare tutto il possibile per accelerare la rimozione delle foglie dai sentieri ed evitare incidenti. Avere un punto di vista sulla “situazione attuale” permette di capire l’organizzazione, le ragioni del cambiamento e le modifiche da adottare. Se si conosce a fondo l’organizzazione, si potrà accedere alla vista “How Now” in maniera più rapida.
Il punto di vista “What Now”
Si può mettere alla prova la propria comprensione del vero problema o della reale opportunità di business, concentrandosi sul punto di vista “What Now”. Questo punto di vista non riguarda il modo in cui il lavoro viene svolto, ma cosa dovrebbe essere fatto ora, indipendentemente da come lo si fa. Questo passaggio è spesso indicato come il punto di vista essenziale e si concentra sulle regole e sulle procedure che dovrebbero essere eseguite e sui dati che dovrebbero essere ricordati, indipendentemente da come viene svolto il lavoro.
Il punto di vista “Future What”
Il cliente ha comunicato le regole attualmente adottate. Tuttavia, si potrebbe essere in grado di suggerire regole nuove e migliorate che sarebbero più vicine a ciò di cui il cliente ha bisogno per risolvere il problema. Vale la pena fermarsi qui per fare una riflessione: se il cliente non adotta nuove regole di business innovative, è sicuramente responsabilità dell’azienda? Questo è vero, ma il problema è che il cliente è di solito troppo vicino al punto di vista “How now” per identificare e chiedere qualcosa di diverso. Tuttavia, una volta che l’analista presenta i suggerimenti, è responsabilità dell’azienda scegliere tra le alternative. Il compito dell’analista è identificare i miglioramenti in grado di aumentare la capacità dell’azienda di risolvere il problema reale. Un buon modo per farlo è guardare ogni evento di business e pensare a come migliorarlo in futuro.
Per esempio, sappiamo che l’obiettivo generale è che dobbiamo fare tutto il possibile per accelerare la rimozione delle foglie ed evitare incidenti. Quali cambiamenti potremmo suggerire per rendere più probabile il raggiungimento dell’obiettivo? Invece di soffiare le foglie, poi spazzarle e quindi metterle nei sacchi, potremmo aspirare le foglie direttamente nei sacchetti? Supponiamo che il dipendente possa inserire un sacco direttamente sulla macchina aspiratrice (un po’ come se fosse un aspirapolvere) e quindi far passare le foglie direttamente nel sacco. Quando è pieno, il dipendente potrebbe sigillarla e aggiungerla al mucchio di sacchi pieni e quindi procedere inserendo un altro sacco.
A conti fatti, questo potrebbe essere un cambiamento radicale di processo e potrebbe non esserci una macchina adatta a fare questo tipo di lavoro, ma il punto vero è mettere in discussione ciò che si sta facendo al momento e vedere cosa si potrebbe fare (aspirare invece di soffiare) per avvicinare il cliente alla soluzione del vero problema. Inoltre, quando la pila di sacchi è abbastanza grande da riempire un camion, il caposquadra potrebbe inviare un messaggio alla sede centrale per il ritiro. Non solo, invece di consultare le previsioni meteo o uno studio sulle foglie che cadono, si potrebbe prevedere il momento esatto in cui le foglie inizieranno a cadere? Se la risposta è sì, allora potremmo aspirare le foglie dagli alberi o essere lì quando iniziano a cadere e catturarle prima che si accumulino. Adottare un punto di vista “Future What” permette di immaginare regole di business nuove per risolvere il vero problema.
Il punto di vista “Future How”
Quando si adotta il punto di vista “Future How”, si entra nel campo delle soluzioni alternative al problema. Si confrontano più idee e soluzioni, dando vita a ciascuna e utilizzando un metodo per testare ciascuna soluzione. In questo modo si identifica la soluzione migliore per raggiungere l’obiettivo e cogliere l’essenza del problema.
James & Suzanne Robertson
Vere autorità nel mondo della system analysis, hanno aiutato centinaia di aziende a migliorare le tecniche dei requisiti e a rendere più efficace lo sviluppo dei sistemi. I loro corsi e seminari di business analysis e progettazione sono molto apprezzati per l’approccio innovativo. Membri di primo piano dell’Atlantic Systems Guild, James e Suzanne Robertson sono coautori di “Mastering the Requirements Process” e dell’approccio Volere alle tecniche dei requisiti.
Suzanne Robertson presenterà a Roma per Technology Transfer il seminario “Mastering the Requirements Process” il 20-22 aprile 2020 e James Robertson terrà, sempre a Roma, il seminario “Business Analysis Agility” il 23-24 aprile 2020.
