Ho avuto il piacere di collaborare con il team di Yom con un rapporto che in realtà è iniziato nel duemilaventuno e che è proseguito per anni insieme al team di base box quando il team di Yom venne da noi, in realtà aveva una piattaforma in una versione beta W P che utilizzava kajabi come motore di fondo che a tutti gli effetti è un software che permette di creare e di erogare, vendere corsi online con tutta una serie di vantaggi e anche di di limiti, in quanto un prodotto molto chiuso.

Dopo una prima iterazione di mercato, e quindi dopo aver consolidato anche alcuni processi e acquisito una fetta di mercato, appunto, il team di Yom decise di investire su una piattaforma proprietaria che permettesse di scavalcare tutta una serie di problemi e di limiti che kajabi purtroppo rendeva veramente complessi da gestire.

In realtà è un processo corretto per una start up si inizia leggeri, si valida il mercato, si ottengono i risultati e poi si scala, ci si evolve il Il lavoro di raccolta di diciamo dei requisiti di definizione di quelli che sono i requisiti è stato quindi divi- diviso in due fasi e quello che abbiamo fatto è stato una prima mappatura tramite un'attività di reverse e quindi, al contrario di tutto quello che era presente su kajabi, sia lato utente e che fruiva dei corsi.

Ma soprattutto diciamo anche lato back office, quindi di tutte quelle che erano le esigenze e le funzionalità per la gestione dei contenuti, il monitoraggio dei dati e che in qualche modo il team di Yom si aspettava perché ormai utilizzava già da più o meno un anno e quindi aveva bisogno di ricostruire questi processi all'interno di una nuova piattaforma, di una nuova casa tra virgolette.

E una seconda fase che ci ha visto anche cooperare in modo molto stretto con i clienti e per andare a pro- a progettare, diciamo la futura piattaforma e ci ha visto coinvolti in un'attività di user mapping, ma anche poi di definizione di tutto l'aspetto progettuale che adesso insomma, ti mostrerò um diciamo in modo molto più dettagliato.

Ecco, purtroppo io non ho delle immagini, il lavoro che facemmo di raccolta dei contenuti e quindi della parte di user stopping iniziale, del lavoro che abbiamo fatto di reverse generi.

Ma con me ho i flussi di navigazione e il diciamo il documento dei requisiti wind document che realizzammo come output finale di questa attività.

E la sfida più grande.

Qua puoi vedere il documento dei requisiti l'altro un documento dei requisiti lungo quarantaquattro pagine molto lungo e la sfida più grande nel corso del lavoro di mappatura e definizione dei requisiti è stata la presenza di attori diversi.

Poiché diciamo la piattaforma di home vedeva non soltanto l'utente finale, ma anche il collaboratore e il team degli admin e le aziende e quindi le aziende.

Quindi mondo B to b e e la parte dei dipendenti dell'azienda e quindi una versione diversa della piattaforma, qualora fossi diciamo un utente, ma al al di sotto di un'azienda, ad esempio gli insegnanti e quindi tutta una serie di esigenze e in qualche modo specifiche e diverse per tipologia di utente che andavano mappate da cima fondo.

E quindi questa cosa ci ha messo nella condizione di dover controvalore questi requisiti anche più di una volta, soprattutto coinvolgendo le persone principali.

Quindi non solo i clienti, ma anche qualche insegnante, qualche rappresentante di ogni cluster di utenza, per essere sicuri che in effetti non ci stavamo perdendo nulla.

Um, ovviamente questo lavoro ci ha portato poi a ad approfondire i requisiti andando a realizzare, ad esempio qui in questo caso quello che vedi è diciamo, un diagramma di flusso e chiaramente perché la diciamo la coesistenza di queste sezioni, funzioni e anche diverse categorie di utenti, diciamo in qualche modo ha alzato il livello della complessità e anche la il livello dell'entropia in modo non propriamente lineare, quindi in modo esponenziale.

E questo, diciamo questo approccio ci ha permesso di mappare non solo le funzionalità dal punto di vista, in qualche modo, come abbiamo visto anche nello user mapping, in modo diciamo tra virgolette, um di alto livello.

Ma um queste funzionalità poi sono state messe tutte in relazione l'una con l'altra per assicurarci di cercare di individuare dove ci fossero appunto questi incastri tra tipologie di utenza e quindi anche tra funzionalità simili ma diverse da questa esperienza, quello che mi porto dietro e che in generale posso raccontarti per permetterti anche di portarti a casa.

Un piccolo suggerimento, diciamo mi auguro di grande valore, è che il team di progetto che copartecipi alla stesura dei requisiti e alla definizione dei requisiti è davvero fondamentale.

Nel caso di Yom appunto, abbiamo potuto coinvolgere oltre le founder, chiaramente che sono oltre ad essere diciamo, le responsabili del progetto sono anche esperti in materia e quindi conoscono molto bene l'ambito per cui stanno lavorando e avere anche, appunto, come ti dicevo, un double check di chiave a rappresentanza di altre categorie di utenza.

E questo ci ha permesso di andare a approfondire davvero molto, diciamo i requisiti, coinvolgendo ovviamente anche da parte nostra chi si è occupato di prodotto, chi si è occupato di ux, chi di sviluppo, chi di comunicazione e andando quindi a mettere appunto intorno al tavolo tutte quelle professionalità e competenze per scrivere dei requisiti davvero solidi, aderenti alla realtà e non solo alla realtà, ovvero tutto il lavoro che è stato fatto di generi.

Quindi, per arrivare a dire Okay abbiamo, partiamo da qua, ma tutto il lavoro che è stato fatto poi a posteriori per capire dove volessimo arrivare nel diciamo nel periodo, nel breve periodo ma anche nel lungo periodo.

Inoltre, ovviamente la parte di validazione di questi requisiti, e quindi anche di stress test di questi requisiti è stata davvero fondamentale per assicurarci di procedere in effetti con poi le successive attività di quotazione definizione pianificazione dei rilasci e progettazione anche fino allo sviluppo, insomma, in modo più sicuro.

A tal proposito quello che abbiamo fatto, oltre a mappare tutta questa attività di architettura e di requisiti di progetto, è stato quello di cercare di individuare anche su questa attività tutti quelli che sono i corner case e quindi in qualche modo cercare di capire tutte quelle sfumature che potevano essere rilevanti per anche attività non propriamente legate all'esperienza di poi chi ne avrebbe utilizzato il servizio.

Quindi l'esperienza degli utenti, tutti quei requisiti non funzionali, quelle dinamiche, quelle specifiche che magari non hanno un impatto reale sul sul prodotto finale, ma che hanno un impatto sull'esperienza ad esempio di chi carica i contenuti di chi le gestisce, di chi visualizza i dati di chi li esporta, di chi li usa come li usa.

E quindi questo lavoro ci ha permesso di mappare in modo dettagliato non solo la parte diciamo visibile e per capirci, il che poi viene utilizzato da queste persone, ma anche il back office, che ovviamente andava strutturato per ricostruire una piattaforma da zero, ovviamente ambiziosa come questa