Il Mestiere di Business Analyst
Il Business Analyst
Quando un progetto va male, il primo a pagarne le conseguenze è il project manager. In realtà, il problema è molto più vasto. Quasi sempre, analizzando le cause del fallimento di un progetto si scopre che i requisiti erano scadenti, inconsistenti o addirittura sbagliati. La responsabilità della raccolta dei requisiti non è sempre del project manager, anzi nelle organizzazioni evolute questa è una responsabilità specifica del Business Analyst il quale avrebbe dovuto lavorare con il cliente e il team di progetto per tradurre i desiderata del cliente in requisiti tecnici finalizzati a produrre una soluzione.
Ruolo del Business Analyst
Il Business Analyst è la figura professionale che traduce i desiderata degli utenti in requisiti tecnici per gli sviluppatori delle applicazioni informatiche, facendo in modo di soddisfare le aspettative degli utenti. Secondo IIBA, il Business Analyst è “Responsabile di identificare le esigenze di business dei suoi clienti e stakeholder, per determinare le soluzioni di problemi di business.”
Documentare i requisiti
In pratica, deve documentare i requisiti che l’utente esprime o non esprime spontaneamente. I requisiti possono rappresentare funzionalità, attributi o caratteristiche di prodotti e servizi interni o esterni alla propria organizzazione. Di solito, sono iniziative per risolvere un problema o cogliere una opportunità evidenziato dall’utente a beneficio dell’organizzazione a prescindere dalle innovazioni tecnologiche. Il Business Analyst ha il compito di identificare il risultato atteso, piuttosto che individuare come fare per realizzarlo. Il documento che si produce è uno studio che contempla tutti gli aspetti di una iniziativa progettuale: convenienza, regolamenti, utenti e caratteristiche funzionali e non funzionali. Descrive prima lo stato attuale (as is) e poi lo stato desiderato (to be), evidenziando il gap da colmare per passare dallo stato “as is” allo stato “to be”. Questa visione possono averla molto chiara solo coloro che effettivamente raccolgono i requisiti. Una volta consolidato il documento può essere condiviso con il team di progetto e con il Project Manager responsabile di tradurlo in un piano di lavoro e di attuarlo.
Analisi Strutturata
Per analisi strutturata si intende l’arte di modellare l’applicazione che andiamo a definire. In Business Analysis, spesso le parole non sono sufficienti per rappresentare bene una relazione. Rendono meglio l’idea degli schemi grafici basati su simboli convenzionali come una freccia di collegamento per indicare un flusso o un rombo per uno snodo decisionale. Il modello che ne nasce, sia pure per sintesi di alto livello, riesce a dare una visione completa della richiesta dell’utente. Ciò che non entra nel modello è sicuramente di importanza secondaria. Ovviamente ogni modello rappresenta un aspetto del problema, perciò si parla di: modelli di business; modelli di processi; modello dati e modelli di workflow.
Analisi Object-Oriented
Per la Business Analysis un modello è un’astrazione di processi e dati necessari per costituire un sistema. Pertanto, un sistema rappresenta un insieme di oggetti messi insieme con la finalità di soddisfare una esigenza di business. Per il Business Analyst, l’analisi O-O è un tool di pianificazione vitale per disegnare la gerarchia delle funzioni di business, di processi e sotto-processi di una organizzazione.
Piano di collaudo
In Business Analysis l’analisi dei test è funzionale a raccordare gli sviluppatori dell’applicazione con i promotori dell’iniziativa o semplicemente gli utenti. La prima cosa che i test devono dimostrare è che è stato soddisfatto il requisito espresso dall’utente. Il Business Analyst disegna i test di collaudo sulla base degli scenari che descrivono la versione del modello “as is” e poi del modello “to be”, in modo da evidenziare le peculiarità delle deliverable da produrre.
Supporto alla transizione
Di solito, un progetto termina con la consegna della deliverable. Ma non è proprio sempre così. Il Business Analyst deve valutare la capacità dell’utente di utilizzare correttamente, a pieno, la nuova applicazione nel primo periodo. Il rilascio di un’applicazione richiede un minimo di formazione agli utenti da parte del team di progetto. Il Business Analyst non si sostituisce ai formatori, ma vigila sull’efficacia della formazione erogata e su come viene recepita, affinché non ne soffra l’applicazione appena rilasciata.
Competenze Tecniche del Business Analyst
Quali competenze tecniche deve avere un Business Analyst? Questo è un bel dilemma. Un vecchio sistemista potrebbe rispondere “la massima competenza”. Un giovane rampante potrebbe dire “nessuna”. In realtà, la verità sta in mezzo. La competenza tecnica dipende principalmente dal progetto e dal settore di industria, senza ignorare che un buon Business Analyst deve avere una buona cultura di base per navigare tra utenti disincantati e tecnici che troppo spesso parlano per acronimi.
Business Process Re-engenering
Il Business Analyst deve avere la massima competenza nel ridisegnare i processi. Spesso gli viene chiesto di individuare le aree di miglioramento di un processo esistente. La prima difficoltà è accertarsi di aver compreso il processo esistente, poi viene la parte propositiva che deve avere al sua valenza. E’ necessario rivedere i processi, esaminando ogni passo per individuare le giuste aree di miglioramento. Tutto ciò è frutto di molto lavoro di analisi, prima di poter passare alla fase propositiva dei cambiamenti.
Conclusione
Questi sono solo alcuni spunti sul mestiere del Business Analyst. Troppo ancora c’è da dire o scrivere. In questa fare è importante partire con il piede giusto, senza schiacciare quello del Project Manager. Entrambi avranno molto da fare e se collaborano diventa tutto più facile.
Se sei interessato al Mestiere del Business Analyst e desideri conseguire una certificazione, con noi hai due grandi possibilità, entrambe valide e molto economiche:
PMI PBA-Prep
Certificazioni IIBA (CBAP, CCBA e ECBA)
