Dopo aver mappato, definito e validato tutti i requisiti di un prodotto digitale, è il momento di priori utilizzarli perché, almeno di norma non si può fare tutto insieme.

Nella metodologia dello user story mapping si prende letteralmente un pennarello, ci si avvicina al muro o alla lavagna in cui ci sono tutti i vari posti coordinati in senso logico e per i vari livelli di profondità e si inizia a tracciare una o più linee per dividere quelli che sono poi i rilasci di progetto.

La definizione dei rilasci di un progetto e quindi poi la priori dei requisiti, si basano in realtà su tantissimi fattori che possono dipendere di caso in caso, ad esempio un budget limitato, un tempo specifico, oppure la necessità di uscire con una versione bella del prodotto entro il giorno x, oppure la volontà di fare un test di mercato soltanto con alcune funzionalità specifiche.

E veramente core.

Questo è, diciamo in effetti, ci porta a parlare di quello che è il concetto di m w p, ovvero di minimo product che in effetti rappresenta l'antitesi del concetto del progetto completo.

Da un lato c'è la versione completa di un progetto e posto che in realtà ne possa esistere una, visto che di norma un progetto digitale è mutevole nel tempo e per definizione diciamo, non termina mai e dall'altra parte c'è la versione minima per poter mettere sul mercato qualcosa di economico, rapido, efficace e che ci permette di poi di dichiarare e prendere, raccogliere dati, prendere decisioni e continuare questo processo, diciamo nel vero modo dello spirito, della metodologia l'esempio, potrebbe essere appese, diciamo quello che che io faccio molto spesso è quello della routine mattutina, che va ad esempio dallo svegliarsi fino ad arrivare al posto di lavoro.

Nel migliore dei casi, diciamo e ti racconto la mia per prenderti un caso reale, io mi sveglio alle sei e trenta, vado a fare una camminata, torno, mi faccio una doccia e mi vesto, faccio colazione con un buon caffè, mi lavo i denti, preparo il pranzo e quindi lo zaino con tutte le cose del lavoro.

Porto il cane a fare una passeggiata e poi prendo l'auto e vado al lavoro.

Quindi questo è il caso, diciamo um migliore dove riesco a fare tutto e tra virgolette è la versione completa della mia routine e quindi la versione completa del mio progetto.

Ma che cosa succede quando in realtà la sveglia non la sento e mi alzo tardissimo, cosa che purtroppo non succede così tanto di rado? E quindi che che cosa succede? In effetti quando le risorse e in questo caso le mie risorse di tempo che ho a disposizione scarseggiano? Però in realtà l'obiettivo rimane sempre lo stesso, ovvero quello di arrivare preparato e in tempo al lavoro eh beh, ovviamente non vado a camminare e molto probabilmente salto la colazione, il pranzo spesso me lo ordino al lavoro perché ovviamente non ho il tempo di prepararlo e il cane a volte lo porto con me perché ho la fortuna di poterlo fare, così gli faccio fare magari una passeggiata fuori l'ufficio al volo e quindi recupero del tempo.

Quello che succede ovviamente per uscire dall'esempio è che si eliminano tutti quei passaggi e quelle attività che non sono strettamente fondamentali rispetto al raggiungimento dell'obiettivo, perché nel momento in cui ci sono diciamo delle scarse risorse, comunque l'obiettivo molto spesso rimane lo stesso.

E ovviamente questo è quello che bisogna fare in questa fase, a meno che tu non stia elaborando dei requisiti di progetto digitale e diciamo che per qualcuno o per qualche realtà che può permettersi di fare tutto.

Quindi nella prima versione, però in generale dal punto di vista proprio um pratico, ma anche rispettando quelli che sono anche i canoni giusti di come si affronta la realizzazione di un progetto digitale.

Quindi nel novantanove percento dei casi è, diciamo è molto raro, è molto difficile che ci sia un caso in cui, um, diciamo ti venga commissionato un lavoro dove si fa tutto e quindi una fase di pzione, anche se magari una versione ridotta, una fase, un po' più leggera.

Comunque in generale va sempre fatta.

Come si possono però priori le funzioni e i requisiti di progetto e soprattutto in quei casi in cui il tavolo, e quindi le persone che sono state coinvolte fanno fatica a a dire no, questo lo facciamo.

Poi focalizziamoci su quest'altro e che perché non è una cosa molto facile da fare, soprattutto se le persone di progetto e sono molto diciamo all'interno appunto di quello che è il progetto e quindi in qualche modo se ne sono innamorate.

In realtà c'è un metodo um che utilizza una matrice di priori e diciamo che si basa sulla falsariga di quella che è la matrice di eisenhower e in realtà ha due assi con dei significati specifici e mi sposto su fim così ti mostro la matrice e te la racconto okay? E l'ultimo pezzo è appunto questo, ovvero la fase cinque della periodizzazione lo attivo e come puoi vedere c'è una matrice fatta di um appunto quattro quadranti e con due asti sull'asse orizzontale vedremo sulla sinistra basso impatto e sulla destra alto impatto che cosa significa? Che cosa significa impatto si intende impatto nei confronti degli obiettivi di progetto.

Chiaramente impatto può significare obiettivi di progetto legati a il cosa vogliamo portare sul mercato il cosa i nostri studenti ci stanno chiedendo e se è economicamente sostenibile.

Quindi obiettivi di progetto diciamo in modo olistico a trecentosessanta gradi e um chiaramente sull'asse orizzontale e andremo a posizionare i requisiti andando a fare appunto questa analisi, quindi di cercando di decidere cosa può, diciamo in qualche modo avere un alto impatto per il business e cosa in realtà magari ha un un impatto minore o più basso.

Um invece nell'asse orizzontale si parla di esport dove per fort si intende ad esempio il tempo che ci vuole per realizzarlo anche in funzione di quelle che sono le risorse di progetto, quindi le persone che sappiamo di poter coinvolgere e il costo.

E quindi in realtà se sta in alto una funzionalità è sicuramente più semplice da realizzare rispetto a quelle che andremo a posizionare più in basso.

E questo questa matrice crea in effetti quattro quadranti e in alto a destra.

E per capirci ci sono ci sono quelle funzionalità che hanno un basso e un alto impatto.

Quindi tutte quelle funzionalità che tecnicamente dovrebbero rappresentare, almeno in modo indicativo, quelli che sono i primi rilasci e quindi quelle che tecnicamente dovrebbero essere le prime che andiamo a realizzare.

E la tendenza, e questo lo dico perché molto spesso succede.

La tendenza è che le persone del progetto, nel momento in cui fanno fatica a decidere in modo naturale all'interno della mappatura dello story mapping, di tracciare quindi effettivamente una linea.

Immaginate una linea immagino una linea come questa dove andiamo in qualche modo a decidere cosa c'è sopra il primo rilascio, cosa c'è sotto sono i prossimi rilasci.

Nel momento in cui non si riesce a fare questa cosa è molto probabile che anche di fronte a una matrice del genere, che comunque semplifica e rende un po' più strutturato il lavoro e il dialogo anche su cosa fare prima e cosa fare dopo si tenderà a mettere praticamente tutto quanto quassù.

Quindi ci sarà una situazione in cui i post-it saranno praticamente tutti quanti quassù e quindi diciamo, la tendenza sarà quella di cercare di rendere tutto quanto primo rilascio, una tecnica e un modo per evitare.

Questo è che è impossibile.

Quindi è non è contemplato il fatto di mettere due post-it e quindi due funzionalità due requisiti due user story nello stesso posto, quindi al massimo possono stare una a fianco all'altra.

Questo perché è impossibile o molto improbabile che due cose abbiano lo stesso impatto per il business e lo stesso export dal punto di vista di realizzazione.

Quindi non ci possono essere due cose una sopra l'altra o paritarie.

Facendo così, anche se questa matrice la allarghiamo al massimo si renderà comunque evidente che ci sono delle cose che saranno più in alto a destra e quindi saranno probabilmente le cose principali e delle altre cose che rappresenteranno i futuri rilasci del progetto.

In basso invece ci sono quelle funzionalità e ci finiscono quelle funzionalità che hanno un impatto molto alto per i business, ma hanno magari un fort molto complesso, quindi molto costose anche dal punto di vista, ad esempio di tempo e di costi.

E questa cosa rappresenta questa parte rappresenta le funzioni tra virgolette a lento rilascio, quelle che in qualche modo vanno pianificate e che probabilmente prima di metterle in cantiere hanno bisogno di essere magari contro validate, perché potrebbero essere dei costi molto alti e quindi prima di lanciarsi in questo in questo diciamo in queste funzioni anche anche perché magari hanno dei tempi molto lunghi per essere poi elaborate, è bene essere sicuri che siano veramente necessari.

E in alto a sinistra ci sono quelle che tecnicamente hanno un basso impatto, quindi un impatto minore, ma è forte.

Molto basso, per capirci, sono quelle funzionalità night web, ovvero quelle cose che se ci sono ci fa piacere.

Se non ci sono nessuno ne sente la mancanza.

Ecco, una cosa importante è che nelle prime fasi di progetto è bene evitare di mettere troppe funzionalità web rispetto a quelle che invece sono importanti per i rilasci.

Quindi quelle che tecnicamente stanno in alto a destra perché altrimenti si rischia di focalizzare troppo l'attenzione su delle cose che se non ci fossero, nessuno ne sentirebbe la mancanza a scapito a discapito di quelle che invece in realtà sono veramente importanti.

E purtroppo in basso a sinistra ci sono quelle che hanno un basso impatto rispetto al business, un alto fort e molto probabilmente sono quelle da rimandare o addirittura eliminare.

Perché rimandare e non del tutto eliminare, quindi almeno non nella prima fase, eliminare perché le lasciamo lì, in una sorta di backlog, in una di ice box, lì in attesa, come se fosse un parcheggio e aspetteremo che in qualche modo il progetto andrà avanti e e che in qualche modo il mercato ce le chiede.

Quindi nel momento in cui il mercato inizierà a chiederle, probabilmente l' forse rimarrà forse lo stesso, però l'impatto che avrà rispetto al business potrebbe essere maggiore.

E quindi piano piano spostarsi verso destra e chiaramente questa non è una matrice che in qualche modo risolve tutti i problemi di un progetto.

Dal punto di vista di privatizzazione, però è un modo diciamo strutturato per cercare di incanalare il dialogo e ed evitare di diciamo di mettere sul piatto e quindi anche all'interno, diciamo del dialogo e quelle che sono poi le le proprie attività di tipo soggettivo, cercando di rendere quanto più oggettivo appunto il confronto per arrivare poi ad ad avere un diciamo un quadro strutturato per capire cosa si fa subito, cosa si fa dopo e cosa probabilmente non si farà mai, a meno che il mercato in qualche modo non ce lo chiede.