Se parliamo di requisiti e specifiche, saremo tutti d’accordo nel dire che solitamente le gare con i relativi documenti di capitolato rientrano in quella categoria di attività che chiameremo qui semplicemente “fumose”.

Documenti diversi che raccontano aspetti simili di una stessa vicenda spesso andando in contraddizione tra loro; ecco quindi che possiamo fare le “richieste di chiarimento” per provare ad avere risposte a specifiche e requisiti che spesso non sono nemmeno nella testa di chi la gara la sta richiedendo perché sappiamo bene che molte volte si lavora di copia/incolla da documenti riciclati.

Il dramma delle gare è che in ogni caso, dovrai rispondere e per fare ciò devi necessariamente aver capito qualcosa riguardo all’argomento in questione e in base al tuo livello di comprensione dovrai uscire con un’offerta.

Da qualche anno all’interno della mia azienda propongo un workshop di gruppo che utilizziamo per comprendere come team i contenuti di una gara, condividere le possibili azioni e strategie, riflettere e poi decidere sul da farsi.

Il presupposto è appunto quello di lavorare come team e non individualmente o come persone coinvolte alla gara che nei ritagli di tempo producono documentazione.

Lo scopo principale è quello di confrontarsi sui requisiti e le specifiche oggetto delle gara perché proprio da questi partiremo per comprendere e confezionare la nostra offerta. Dato che ognuno di noi è diverso, se leggiamo in quattro un capitolato, troveremo requisiti più o meno utili in base alla nostra percezione del tema, della fattibilità, delle attitudini e altro ancora. In questo senso quindi il nostro workshop parte dal presupposto che le persone al tavolo conoscano la gara e abbiano letto i documenti di capitolato che tipicamente vengono anticipati rispetto alla data dell’incontro.

Gli utilizzatori determinano i requisiti

Nella prima fase del workshop lavoriamo alla veloce definizione delle user personas, gli utilizzatori del sistema e proviamo rapidamente a mappare il flusso di processo legato ad essi.

La mappatura delle persone avviene di solito con il metodo AEIOU dove ogni lettera ci ricorda un elemento chiave associato all’utilizzatore:

• Action – Cosa fa?
• Environment – Dove si trova?
• Interaction – In che modo si muove e con cosa interagisce? (strumenti, sistemi, …)
• Object – Cosa utilizza?
• Users – Interagisce con altre persone o altri sono inseriti nel suo processo di lavoro?

Il processo chiarisce i requisiti

Questo semplice canvas per il mapping delle Personas ci permette velocemente di riflettere sui potenziali utilizzatori e a partire da ciascuno di essi andiamo poi a fare un veloce disegno di processo per ragionare sulle azioni e sul suo flusso di lavoro.

Mappare il processo in base agli utenti aiuta a focalizzarsi sui requisiti e su quello che realmente serve fare all’utente nella sua normale attività.

I requisiti raccontano una storia

Una volta che il team è d’accordo su queste bozze di processo, ci occupiamo dello user story mapping, termine tecnico del mondo agile per indicare la definizione dei diversi requisiti necessari per traguardare il progetto.

Partiamo con una breve fase di lavoro individuale in cui ognuno scrive in silenzio quelli che secondo lui sono gli attori e gli elementi chiave del progetto e successivamente li condividiamo senza dibattito iniziando a popolare una mappa di affinità, un utile strumento della famiglia dei canvas che aiuta a raggruppare e trovare affinità e similitudini tra i vari requisiti tracciati.

Segue quindi un momento di confronto all’interno del quale ragioniamo meglio sui raggruppamenti e proviamo a dare un nome alle varie aree. Questi nomi diventeranno gli elementi portanti del nostro user story mapping, quelli che tecnicamente vanno a formare la backbone di progetto ovvero la lista dei macro argomenti che già da soli dovrebbero permettere di inquadrare il tipo di progetto.

Se la mia backbone contenesse: scelta ristorante, scelta cibo, ordine, pagamento e tracking consegna dovrebbe essere già chiaro a tutti che stiamo lavorando ad un’applicazione per la consegna a domicilio del cibo.

Una volta definiti gli elementi della backbone si provano ad approfondire i requisiti specifici. In questo caso usiamo 3 colori per indicare: in verde requisiti facili e già coperti dalle nostre soluzioni, in giallo i requisiti da sviluppare da zero e in rosso i requisiti da fare ma particolarmente complessi o onerosi da diversi punti di vista.

In questo modo centriamo almeno due diversi obiettivi: condividiamo il tipo di requisiti in modo da essere tutti informati e sfruttiamo la mappa di calore ottenuta con i tre colori per identificare facilmente le complessità all’interno dei requisiti richiesti; questo ci permetterà di scegliere e decidere insieme con maggiore cognizione di causa.

A questo punto ci chiediamo se manca qualcosa. Domanda jolly che ti permette di guardare velocemente dall’alto per comprendere se nella fretta non abbiamo perso qualche requisito chiave, in quel caso lo aggiungiamo dove necessario ripercorrendo sia il processo che la backbone di narrazione.

Tutto il lavoro fatto fino ad ora mette il team in condizione di avere un’idea comune di quello che si sta ipotizzando e di quali sono i requisiti e le esigenze che si andranno a risolvere rispondendo alla gara. Tutto avviene alla luce del sole in un clima di co-creazione che aiuta le persone a non nascondersi dietro al tipico “non avevo capito…” o “pensavo avessimo deciso una cosa diversa…”

Chiudiamo il nostro workshop con una fase di stima veloce dei diversi requisiti e il loro posizionamento all’interno di un release plan che ci permette di comprendere cosa possiamo rilasciare rapidamente e cosa invece diventerà parte dei problemi da gestire.

Con queste stime alla mano e con il piano di rilascio condiviso chiudiamo il nostro workshop lasciando che le persone titolate a farlo confezionino l’offerta.

Quello che ho raccontato fin qui non è fantascienza: il workshop che ho descritto può durare da 4 ore all’infinito e molto dipenderà dal grado di complessità della gara. Potete fare tutto subito in un’unica sessione da 4-6 ore o spezzettare i diversi temi e trattarli in momenti specifici. L’importante è che il team di lavoro sia abbastanza piccolo, 4-6 persone, e che tutte le persone utili siano coinvolte al tavolo in modo da sfruttare al meglio il tempo di tutti.

Questo articolo è presente sul numero 5 2023 della rivista Agile Italia Magazine