Articoli

«
Cos’è
_
la
_
business
_
analysis
_
e
_
quanto
_
è
_
importante
_
nei
_
progetti
_
tecnologici
»

Sviluppo app · Trasformazione digitale

Come svolgere una corretta analisi dei requisiti e che qualità deve avere un Business Analyst per la buona riuscita di un progetto tecnologico come la trasformazione digitale di un’azienda o lo sviluppo di una app.

Secondo la guida BABOK dell’International Institute of Business Analysis, l’analisi aziendale (Business Analysis) è  “l’insieme di attività e tecniche utilizzate per operare come collegamentoi fra i diversi stakeholder al fine di comprendere la struttura, le politiche e le operazioni di un’organizzazione, e poter consigliare soluzioni che le permettano di raggiungere i propri obiettivi”.

In altre parole, la Business Analysis  traduce le esigenze di un’organizzazione nei requisiti tecnici per soddisfarle, soprattutto nell’ambito delle soluzioni tecnologiche come la trasformazione digitale o lo sviluppo di applicazioni.

L’analista aziendale (Business Analyst) è una figura professionale in grado di capire il modello di business, il piano strategico e operativo di un’organizzazione, e tradurlo in requisiti tecnici e funzionali precisi. Pertanto, deve saper comprendere come funziona l’attività, i suoi processi e i ruoli dei vari professionisti, individuare aree o possibilità di miglioramento e definire le soluzioni necessarie, con un occhio attento alla fattibilità tecnica ed economica della proposta.

Il Business Analyst può essere un professionista che si dedica esclusivamente a questa funzione, o lavorare in un’area diversa e ricoprire l’incarico solo in determinati momenti o per progetti specifici. In effetti, non è tanto importante il ruolo del singolo all’interno dell’organizzazione, ma la sua capacità di raggiungere gli obiettivi di analisi aziendale. In molti casi i profili che se ne occupano sono analisti di sistemi, consulenti IT, ingegneri, analisti di processo, project manager, ecc.

La Business Analysis (BA) è un insieme di metodi volti a minimizzare l’incertezza insita in ogni piano di sviluppo tecnologico e i conseguenti rischi: è proprio in questa capacità di “stabilizzare” al massimo il progetto prima della sua implementazione che risiede la sua grande importanza.

Le qualità del Business Analyst

L’analista aziendale deve possedere un ottimo pensiero analitico orientato alla risoluzione dei problemi, una conoscenza trasversale dell’azienda, soprattutto delle relazioni e interdipendenze fra i vari reparti, una grande capacità di comunicazione e negoziazione, dato che in molte occasioni si troverà a fare da intermediario fra le diverse aree per favorirne l’incontro su un terreno comune e, naturalmente, una conoscenza approfondita delle tecnologie disponibili e delle loro principali caratteristiche e applicazioni.

Cualidades del Business Analysis

In un’“organizzazione tipo”, è piuttosto comune che si generino tensioni fra i reparti quando si cerca di lanciare un progetto tecnologico; l’esempio più classico sono gli attriti fra i settori di Marketing, Innovazione e Sistemi. I primi due finiscono per sovrapporsi in alcune responsabilità quando la digitalizzazione riguarda la comunicazione o lo sviluppo del prodotto, mentre il reparto Sistemi limita l’impatto delle soluzioni individuate perché si concentra su stabilità, funzionamento e sicurezza dei sistemi (di solito il suo concetto di innovazione è condizionato da una forte avversione per i rischi). Il Business Analyst deve saper misurare, soppesare e mettere in ordine di priorità le preoccupazioni e gli obiettivi dei vari rami dell’azienda, per poi offrire soluzioni equilibrate che fungano da punto d’incontro.

Investire su un’analisi accurata avrà ripercussioni molto positive sul budget finale del progetto, permettendo di ridurre al minimo incertezze, errori e deviazioni. Non è raro, infatti, che si presentino descrizioni, analisi dei requisiti o proposte molto approssimative, piene di generalizzazioni, inesattezze o informazioni vaghe, in cui si danno per scontati numerosi aspetti che invece andrebbero chiariti nel dettaglio. Con questi presupposti, si finisce per dover ripetere gli stessi processi un’infinità di volte perché è necessario definirli in corso d’opera, e quindi tornare a più riprese sulle varie parti fino a far combaciare la realtà con delle aspettative che non erano state delineate né concordate in un documento.

Curiosamente, quando si parla di tecnologia, la fretta non fa che rallentare tutto. Una pianificazione dettagliata e una buona documentazione sono fondamentali per favorire la comprensione globale di un progetto da parte di tutti i reparti e gli stakeholder interessati.

Un’analisi dei requisiti poco attenta genera un’innovazione caotica

Pantalla login

Poniamo un caso abbastanza tipico, la richiesta per una piattaforma di gestione online, in cui chiamiamo “Login” la prima schermata che l’utente si troverà davanti. L’analisi dei requisiti non approfondisce né spiega granché, dando per scontato che una pagina di login non debba contenere altro che un campo per lo username e uno per la password.

Iniziamo con l’implementazione e dalle Risorse Umane ci fanno notare che sarebbe complicato creare nuovi username e password, dal momento che ne esistono già per altri strumenti, e chiedono se non sia possibile mantenere le stesse credenziali. Sarebbe senz’altro la cosa più logica, ma apre le porte all’integrazione con un terzo strumento o sistema che dovrà essere analizzato per verificare che disponga delle API, ecc.

E non finisce qui: qualcuno ci chiede cosa fare se un utente perde la password, e in questo caso si prospettano diverse soluzioni di recupero (di nuovo, altro tempo e altra integrazione), qualcun altro fa presente che sarebbe bello sapere già in questa schermata a cosa si sta accedendo e inserire un tutorial o un on-boarding al primo login, che guidi l’utente passo a passo e ne favorisca la comprensione (e quindi altre idee, altro sviluppo, altre risorse necessarie)…

Alla fine, una funzionalità molto standard e apparentemente semplice può arrivare ad assorbire cinque volte le risorse preventivate, solo perché si era dato per scontato che fosse semplice, senza andare oltre. Se applichiamo quest’esempio a tutte le altre funzionalità, alcune delle quali sono decisamente più complesse, le varianti finiscono per essere la norma e l’implementazione del progetto sprofonda nel caos più completo, senza nessuno che sappia quando né come uscirne. Per questo molti progetti tecnologici si impantanano, si prolungano, a volte neanche arrivano a vedere la luce, e tutto per un’analisi dei requisiti inadeguata o debole.

Come funziona un buon processo di Business Analysis?

Dipende dalla natura e dimensione del progetto, ma esiste uno schema di base da applicare in quasi tutte le occasioni:

Definire l’esigenza dell’azienda:

Si deve valutare l’area, il processo, le risorse (soprattutto a livello di profili e ruoli professionali), gli strumenti attualmente coinvolti, la documentazione, ecc., per poi individuare gli obiettivi per la buona riuscita del progetto. È essenziale avere una visione del tutto chiara di tali obiettivi, che sia condivisa con il team.

Definire la portata della soluzione:

Significa studiare e definire le ipotesi e le limitazioni che possono influire sul progetto, come gli aspetti legali, i limiti tecnici o economici, e così via.

Analisi dei requisiti:

Una volta compresa l’esigenza e la portata della soluzione, si passa a elaborare l’analisi dei requisiti, il documento che conterrà le proposte dei vari stakeholder per lo strumento. Non si tratta di un semplice elenco di caratteristiche: comprende la definizione dei requisiti e descrive il comportamento della soluzione in modo piuttosto dettagliato, per consentire il relativo sviluppo; stabilisce inoltre un ordine di priorità per le caratteristiche, mette in luce eventuali incompatibilità, incoerenze, ecc. e indica come limarle affinché la soluzione, così com’è descritta, non solo risponda in modo efficace al suo obiettivo, ma risulti completamente fattibile.

Pianificazione del progetto:

Il Business Analyst e il Project Manager (in alcuni casi può trattarsi della stessa persona) dovranno quindi occuparsi di una pianificazione dettagliata del progetto, che soddisfi i requisiti permettendo di stanziare le risorse necessarie e di calendarizzare le fasi previste per la sua realizzazione.

Una volta partito il progetto, il Business Analyst deve garantire la sua consulenza agli stakeholder coinvolti, fornendo chiarimenti sull’interpretazione dei requisiti al momento della loro implementazione e realizzando valutazioni ex novo per quelli eventualmente emersi in corso d’opera.

Al giorno d’oggi sono davvero pochi i progetti che, una volta implementati, non richiedono ulteriori interventi.  La maggior parte necessitano di una qualche forma di manutenzione, come gli aggiornamenti obbligatori per stare al passo con l’evoluzione dei sistemi operativi o dell’hardware su cui funzionano, la manutenzione del back-end o dei sistemi del progetto, ma non basta: fin dal primo momento in cui entrano in produzione, si deve elaborare una road map organizzata delle versioni “target” aggiornate nel corso del tempo. Tali versioni assicureranno una BA continua sul progetto, che individui i miglioramenti da apportare con i relativi requisiti e dia loro un ordine di priorità per organizzare gli sviluppi futuri.

In definitiva, la BA è paragonabile al progetto stilato da un architetto prima e durante la costruzione di un edificio, e per tutto il tempo in cui viene utilizzato. Certo, è vero che si può costruire senza un architetto, ma l’esecuzione sarà molto più rischiosa e incerta.

Arquitectura proyecto Business Analysis

Avere a disposizione gli strumenti, le planimetrie, il budget, e soprattutto avvalersi dell’occhio esperto di un professionista prima di iniziare l’opera assicurerà la fattibilità dei lavori e migliorerà notevolmente il risultato finale.

Schema di base del documento di analisi dei requisiti

Quello che segue è uno schema molto essenziale dell’analisi dei requisiti. Tale strumento dovrebbe per lo meno comprendere le sezioni seguenti per consentire uno studio e un’elaborazione corretta della proposta:

1. Titolo del progetto.

2. Data del documento. Un aspetto fondamentale, dal momento che a volte queste analisi rimangono per qualche tempo in stand-by: nel riprenderle, è importante poter collocare le informazioni nel giusto contesto temporale, perché le circostanze o le tecnologie potrebbero essere cambiate.

3. Autore/Responsabile del progetto, posizione e dati di contatto.

4. Descrizione generale. Si definisce la portata generale, il contesto del progetto e l’attività in cui sarà implementato, perché è stato previsto, dove e come si utilizzerà, ecc. Serve ad aiutare chi non sa nulla del progetto, dell’azienda né del settore, a entrare in argomento con una certa cognizione. Evitare generalizzazioni o ambiguità. Un’analisi dei requisiti deve essere quanto più concreta e diretta possibile, evitando qualunque dubbio e incoerenza.

5. Obiettivo principale del progetto. A cosa serve la soluzione?

6. Destinatari e utenti del progetto. Definizione dei destinatari/utenti del progetto e descrizione del loro ruolo relativamente alla piattaforma. È importante contestualizzare ogni tipologia di utente (in modo che chi non conosce l’azienda possa farsi un’idea della loro funzione). È molto utile allegare uno schema dei rapporti fra i vari utenti (se ci sono gerarchie, interrelazioni, ecc.).

7. Aree o reparti in cui sarà implementato. Spiegazione delle aree o reparti in cui si userà lo strumento e dei processi su cui interverrà la soluzione.

8. Requisiti funzionali. Ogni funzionalità deve essere illustrata nel modo più dettagliato, organizzato e ordinato possibile. A ognuna si assegnerà un titolo e una definizione precisa di cosa deve fare lo strumento nell’ambito di questa funzionalità. Ad esempio, se parliamo di una raccolta dati (modulo), dobbiamo indicare esattamente i campi che deve includere.

È importante evitare generalizzazioni, che possono dar luogo a interpretazioni discordanti. Ad esempio, non è sufficiente parlare di “mappa di navigazione che indica il percorso dal punto di partenza”, perché una mappa può offrire o meno la navigazione visiva, quella vocale, l’ottimizzazione dei percorsi, punti intermedi, percorsi alternativi consigliati, ecc. In questi casi, è molto meglio specificare quello che sembra scontato, piuttosto che lasciare campo libero all’interpretazione. Se ci sono aspetti sconosciuti, indicarli chiaramente in modo che sia possibile proporre alternative. 

9. Canali. Indicare se la soluzione si userà su dispositivi desktop, portatili, mobili, wearable, ecc., così sarà più semplice selezionare le tecnologie e l’architettura tecnica indicata per soddisfare i requisiti.

10. Requisiti tecnici. In questa sezione si indicano i requisiti tecnici, su cui si può essere più o meno precisi: bisogna valutare se esiste o meno una tecnologia adatta allo scopo, o se si deve aspettare che sia il tecnico o il fornitore a proporla in base ai requisiti funzionali. Se presenti, si devono riportare anche i requisiti in materia di sicurezza, collocazione della soluzione, ecc.

11. Interdipendenze e integrazioni tecniche. Indicare se ci sono interdipendenze con altre piattaforme, ad esempio, se si desidera condividere informazioni con il CRM, l’ERP o implementare servizi o librerie di terzi. In tal caso, si dovrebbe indicare la tecnologia di queste piattaforme e fornire informazioni sulle rispettive API, per poter studiare la complessità dell’integrazione.

12. Scadenza per l’esecuzione. Indicare se esiste una data limite entro cui lo strumento deve essere operativo.

13. Budget. A scelta, si può specificare l’eventuale budget assegnato al progetto. È un dato che normalmente non si rivela al fornitore, tuttavia comunicarglielo può aiutarlo a comprendere le dimensioni del progetto e proporre alternative per adattare i requisiti al budget disponibile, o semplicemente scartarlo se ritiene che non sia realizzabile per ragioni di costo, facendo risparmiare tempo e lavoro a tutte le parti coinvolte.

risus fringilla sed pulvinar Lorem massa Donec mattis