Risolvere il giusto problema di business è cruciale per lo sviluppo di software e prodotti. Ecco come lavorare con i vostri utenti in maniera più Agile e proattiva per essere sicuri di comprendere le reali esigenze e progettare le migliori soluzioni
Qualunque sia la cosa sulla quale si sta lavorando in un determinato momento, è quasi certamente composta da molti pezzi, a volte moltissimi. Ciascuno dei pezzi interagisce con altri pezzi per ottenere un risultato prezioso. Ciò significa che è necessario organizzare tutti i pezzi in modo che tu e i tuoi colleghi possiate lavorare su sezioni pertinenti del problema più ampio e, allo stesso tempo, tenere traccia di come i pezzi più piccoli lavorano insieme all’interno di ciascuna sezione. L’obiettivo è capire e risolvere il vero problema di business del vostro utente. Il Business Event è lo strumento migliore che sia stato inventato per aiutare a farlo. Prima di tutto però occorre essere più reattivi verso i vostri utenti e il loro lavoro “reale” e comunicare in maniera più precisa con gli sviluppatori scrivendo le giuste storie.
Cos’è un evento di business?
Un evento di business è qualcosa che accade e quando accade provoca una risposta pre-pianificata da parte dell’azienda, o come lo chiameremo qui, “il lavoro”. Una categoria di eventi di business sono le cose che succedono all’interno di un sistema adiacente. Si tratta di comprendere come lavorare con i vostri utenti in maniera più Agile per essere entrambi sicuri di scoprire il “vero” problema a cui dare soluzione. Ogni evento produce un flusso di dati per il lavoro. Un evento di business è un avvenimento significativo, non è solo un clic del mouse. In molti casi, è una richiesta di un servizio fornito dalla tua azienda e il risultato è la fornitura del servizio o del prodotto.
Per esempio, nell’evento di business nel quale il cliente decide di pagare una bolletta, il sistema adiacente, in questo caso il cliente, è il luogo in cui si verifica l’evento. Il flusso di dati, causato dall’evento, è il pagamento del cliente. Questo flusso è solitamente chiamato “flusso di dati di attivazione” perché innesca una risposta dal lavoro. In questo caso, la risposta sarebbe accettare il pagamento, registrarlo e inviare una ricevuta di conferma. Tutto ciò sarebbe stato fatto secondo le regole di business del lavoro. Si noti che queste regole potrebbero essere eseguite da persone, tecnologia o da una combinazione di entrambe.
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 parti coinvolte e fare le 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 metodo per sapere quanto lontano si può andare. Si tratta di identificare i segmenti di clienti (o utenti) e di impiegare un approccio Iterativo per scoprire il vero problema e alimentare progressivamente le giuste storie per l’attività di delivery. In questo modo è possibile individuare le giuste necessità e risolvere il problema.
Definire lo spazio della soluzione
Dopo aver esaminato le diverse risposte a un evento di business, coinvolgendo tutte le parti interessate, occorre definire i requisiti. Come primo passo per identificare i requisiti in dettaglio, è possibile delineare l’ambito dello spazio della soluzione prescelta. Per farlo, si utilizzano gli eventi di business, prima per identificare i blocchi funzionali della soluzione e poi per dare priorità al lavoro di creazione della soluzione. Avere la capacità di guardare lo stesso problema da diversi punti di vista significa essere focalizzati nel trovare le idee più innovative, in modo da semplificare le operazioni di pianificazione e rispondere ai cambiamenti in modo creativo.
Tenere traccia degli eventi di business
Ogni volta che si conferma che un nuovo evento di business è rilevante per l’ambito del lavoro, il business analyst ne tiene traccia, aggiungendo l’evento al diagramma del contesto lavorativo. Ogni volta che si scopre un nuovo evento di business e si accetta che rientri nell’ambito del lavoro che si sta studiando, dovrebbe essere aggiunto al diagramma del contesto lavorativo. Ogni evento di business rappresenta una parte limitata di funzionalità che si può studiare indipendentemente dagli altri eventi, monitorando passo dopo passo come i singoli eventi si adattano al tutto. Man mano che il numero di eventi di business aumenta, un elenco di eventi aiuta a gestire e definire le priorità delle indagini. Naturalmente, un proprio elenco di eventi sarebbe notevolmente più lungo. Un evento di business rappresenta una parte significativa e indipendente di funzionalità a cui è possibile assegnare la priorità in modo da lavorare sempre sugli eventi che producono il massimo valore. Gli eventi di business aiutano anche a organizzare le analisi. Si possono distribuire gli eventi nel team e, considerata l’indipendenza degli eventi, non è indispensabile che i membri del team abbiano un’eccessiva interazione.
Lavorare con un team di sviluppo Agile
Gli eventi di business sono molto efficaci per i team Agile. Un evento di business (o correttamente, la risposta all’evento di business), è una parte a sé stante del problema con un risultato ben definito. Ha anche input e output chiari. Questo lo rende non solo un’unità conveniente da studiare per renderne espliciti i requisiti, ma rappresenta anche un’unità concreta da sviluppare. Come abbiamo visto, l’ambito è determinato dalla raccolta di eventi di business e, per ciascuno di questi, si raccomanda di scrivere una storia di eventi di business. Questa è una storia nel senso convenzionale di ruolo-funzione-risultato. Ne parleremo più avanti. Per ogni storia di un evento di business, gli sviluppatori, con l’aiuto del business analyst, possono definire i dettagli della risposta all’evento di business, scrivendo una serie di storie funzionali, che rappresentano una ripartizione della funzionalità. Possono essere ulteriormente suddivisi dagli sviluppatori scrivendo le attività dettagliate necessarie per implementare la storia funzionale. Nel nostro caso, la storia di business risultante è: “Come cliente, posso effettuare un pagamento, in modo che il mio fornitore possa registrare il mio pagamento e darmi una ricevuta”. Con questo approccio, gli sviluppatori possono derivare le storie funzionali (functional story), dalla storia di business (business story). In questo esempio, le storie funzionali per questa storia di business potrebbero essere qualcosa di simile a: “Individua l’account del cliente”, “Registra il pagamento”, “Emetti la ricevuta”. In caso di modifiche o domande alla business story o alle functional story, i business analyst, i proprietari dei prodotti e gli sviluppatori hanno un linguaggio di comunicazione comune.
James e Suzanne Robertson
James Robertson è consulente, docente, autore e project leader. Il suo lavoro nell’area della business analysis e della raccolta dei requisiti è apprezzato in tutto il mondo. Insieme a Suzanne Robertson, è co-autore di “Mastering the Requirements Process”, “Requirements-Led Project Management” e dell’approccio “Volere” per l’engineering dei requisiti. Vere autorità nel mondo della system analysis e tra i fondatori dell’Atlantic Systems Guild, un think thank conosciuto in tutto il mondo per le tecniche innovative di systems engineering. Entrambi 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.
James Robertson presenterà a Roma per Technology Transfer il seminario “Business Analysis Agility” il 10-11 giugno 2021 e Suzanne Robertson terrà il seminario “Mastering the Requirements Process” il 13-15 ottobre 2021.
