Competenze del Business Analyst

Competenze del Business Analyst

Il Business Analystgrande comunicatore – deve avere una enorme competenza nella raccolta e gestione dei requisiti di progetto, per comprendere a pieno le aspettative degli stakeholder e favorire il successo del progetto.

Con l’avvento di AGILE, il Business Analyst deve saper generare valore su larga scala, velocemente e senza frizioni con gli stakeholder, i quali gli possono creare parecchie difficoltà:

  1. Gli stakeholder gradirebbero che le decisioni fossero tutte condivise, ma non è sempre possibile. Questa criticità potrebbe mettere a rischio l’iniziativa, se non c’è un consistente sistema di qualità e un valido processo di change management. Con uno schema trasparente delle “Decisioni” è possibile mantenere tutti sintonizzati, gestendo anche gli eventuale feedback negativi.
  2. Gli stakeholder vorrebbero condividere ogni conoscenza, ma ad un certo punto i tempi del progetto non consentono di investire in troppe riunioni, specie se si è prossimi al traguardo. Fortunatamente le metodologie AGILE prevedono una serie di riunioni “timeboxed” alle quali si può anche assistere, senza esserne protagonista.
  3. Il Product Owner è una figura fondamentale nei progetti AGILE. Filtra tutte le istanze degli stakeholder, traducendole nel linguaggio consono al team di sviluppo, diventando la chiave di svolta per il Business Analyst. Il BA, dalle informazioni fornite dal Product Owner definisce e disegna e rivede la soluzione ideale, di volta in volta.
  4. Spezzettare i problemi complessi in tanti problemi più piccoli, in modo da affrontare un aspetto per volta, con discussioni mirate, assistiti dal Product Owner.
  5. Non sottovalutare la dislocazione degli stakeholder. A volte, gli stakeholder risiedono in altri edifici o in altre città, altre nazioni o continenti. Il ricorso alle conference call è inevitabile, ma attenzione all’efficacia della comunicazione, privata del linguaggio del corpo. Il rischio è che possono nascere delle incomprensioni o che elementi essenziali del progetto emergano più tardi rispetto alla schedulazione dei lavori.

In un contesto AGILE, per essere efficaci, ognuno dovrebbe poter esprimere liberamente idee, valutazioni o suggerimenti nell’affrontare qualsiasi problema del progetto. Ciò ridurrebbe notevolmente il bisogno di riunioni formali, portando meglio e prima il progetto al successo.

Una caratteristica di AGILE è l’AMBIENTE COLLABORATIVO insieme all’AUTOGESTIONE del Team di Sviluppo.

Inoltre, il team di sviluppo non può essere continuamente disturbato con richieste di informazioni o con la comunicazione di dettagli sui requisiti. L’approccio sano è che il team determini il lavoro da eseguire in un ciclo (sprint) e solo quando avrà mostrato i risultati, gli stakeholder potranno esprimere le loro osservazioni o suggerimenti per lo sprint successivo.

In questo contesto, il Business Analyst è responsabile di scoprire, sintetizzare e analizzare informazioni da tutte le fonti, utilizzando anche tool, processi, documentazione precedente e esperienza degli stakeholder coinvolti.

Di solito si parte da tecniche come Interviste, Analisi di Documenti, Focus Group, workshop, etc. per raccogliere i requisiti che consentano di disegnare il processo di cambiamento o la soluzione di un problema. Si può ricorrere al Data Mining per analizzare grandi masse di dati e con BIG DATA il futuro dell’analisi dei dati sarà sempre più avvincente e importante. Altro tool che arricchisce le competenze del Business Analyst saranno le tecniche di “Machine learning” per istruire algoritmi di modelli sofisticati per l’analisi dati e produrre risultati sempre più precisi.

Nei grandi progetti, il Business Analyst contribuirà alla diffusione delle Machine Learning, che al momento sono di due tipi:

  • Machine Learning Supervisionate – il BA istruisce un algoritmo per fare previsioni, fornendogli esempi di input e output noti.
  • Machine Learning Non Supervisionate – Il BA sceglie un algoritmo che indichi un percorso attraverso un dato insieme di input. L’algoritmo potrà formare delle categorie di dati (clustering) oppure cercare solo regole che descrivono i dati (association).

Il Business Analyst deve dimostrare tutta la sua competenza nell’adottare il tool giusto per disegnare un determinato prodotto sulla base di svariati fattori. La raccolta e la preparazione dei dati per il progetto e ciò che bisogna produrre è l’area in cui il BA può essere determinante.

Tipi di Requisiti

Nel mondo della Business Analysis è opportuno definire i vari tipi di requisiti (requirements).

Un requisito, in ambito Business Analysis è semplicemente una dichiarazione fornita da uno stakeholder su ciò che egli crede che occorra per risolvere un particolare problema o rispondere ad una specifica esigenza del business.

Una volta che uno stakeholder ha presentato un requisito, è compito del Business Analyst definire, sintetizzare, analizzare, confermare e mettere in priorità il requisito, poiché da quel momento fa parte del contesto di business analysis della gestione dei requisiti.

In pratica, lo stakeholder dichiara il suo problema di business o la sua esigenza e successivamente fornirà i dettagli nel corso del processo di gestione dei requisiti da parte del Business Analyst.

Sebbene molti requisiti vengano forniti a inizio progetto, è molto probabile che altri ne saranno forniti nel corso del progetto. Con l’approccio AGILE i requisiti vengono raccolti maggiormente nel corso del progetto, anche se alcuni possono essere noti fin dalla fase di avvio del progetto.

Conviene classificarli per categorie, per comprendere a fondo la natura dei vari requisiti.

Il Business Analyst deve comprendere i differenti tipi di requisiti: esigenze di business, descrizione del problema da risolvere, esigenze ambientali, etc.

Ruolo del Business Analyst

Il Business Analyst, quando affronta uno studio di fattibilità, analizza tutte le opzioni possibili.

Sarà coinvolto nel valutare se l’iniziativa è in linea con la strategia di business e se sarà profittevole dal punto di vista costi/benefici. La natura dei requisiti comporta una miriade di attività di analisi che possono sfociare in qualsiasi campo.

Di solito, si parte da una banale descrizione generale di ciò che bisogna produrre (esigenza di business o problema) e poi si approfondisce con gli stakeholder chiave per definire l’AMBITO (scope) del progetto con la soluzione da raccomandare, facendo particolare attenzione a ciò che le deliverable di progetto comprenderanno e ciò che sarà escluso). Le dichiarazioni iniziali degli stakeholder diventeranno sempre più complete, e alla fine costituiranno le specifiche di ciò che sarà implementato, compreso la transizione (passaggio in produzione della soluzione).

Si tratta di un viaggio dalla fase concettuale fino al livello di requisiti dettagliati e specifici.

Dichiarazione dell’Ambito

Un progetto tradizionale necessita di un perimetro ben definito, mentre in ambiente AGILE il perimetro viene definito nel corso del progetto in modo iterativo, lasciandosi guidare dal tempo, dal budget e dalle priorità di business. Comunque, anche con AGILE, è meglio disporre della definizione del perimetro e dell’ambito, sia pure ad alto livello.

In definitiva, l’ambito (SCOPE) descrive in modo chiaro cosa il progetto dovrà produrre.

Tipologia di Requisiti

I requisiti di business – dichiarazioni di alto livello che descrivono cosa gli stakeholder desiderano dalla prospettiva del business, si dividono in due grosse categorie:

  • Requisiti degli stakeholder – il desiderata degli stakeholder.
  • Requisiti della soluzione – come gli stakeholder vorrebbero che venissero implementati i loro requisiti. Alcuni potrebbero tecnicamente essere impraticabili.

I requisiti della soluzione a loro volta si dividono in due tipologie:

  • Requisiti funzionali – come la soluzione deve funzionare.
  • Requisiti non-funzionali – caratteristiche che dovrà avere il sistema.

Requisiti di transizione

I requisiti di transizione sono fondamentali per garantire la continuità del servizio o del sistema. Descrivono cosa bisogna avere in piedi per un certo periodo di tempo, finché non si stabilizza il nuovo sistema.

Conclusione

Il Business Analyst deve avere un quadro chiaro dei differenti tipi di requisiti e del livello di dettaglio necessario per identificarli e classificarli in categorie. Le sue competenze possono abbracciare molte discipline a secondo del contesto in cui opera.

L’obiettivo è raccomandare una soluzione fattibile tecnicamente, in linea con le strategie di business e possibilmente remunerativa.

Punta ad una Certificazione da Business Analyst, a qualsiasi livello:

IIBA-CBAP® Prep Online
IIBA-CCBA® Prep Online
IIBA-ECBA™ Prep Online

PMTSI - Logo