Il mio progetto agile ha davvero bisogno di un analista di business dedicato (BA)?

Un team a tutto campo che include giocatori in grado di comprendere i requisiti aziendali e trasformarli in una progettazione e implementazione software è molto efficace.

Ma di solito, nessuno copre ogni aspetto di un sistema complesso e sa tutto su tutti i requisiti aziendali. Ad esempio, chi ha una profonda conoscenza della finanza, della contabilità, della matematica finanziaria non sarà semplicemente ricettivo per alcuni flussi fisici o requisiti logistici di qualcuno specializzato in produzione, pianificazione della pianificazione MRP o sicurezza del prodotto.

Ed è qui che una BA dedicata può aiutare. Forse non ha un ruolo di implementazione, ma dovrebbe:

• avere una comprensione ampia delle relazioni tra le esigenze aziendali. Vedrà collegamenti nei requisiti aziendali che non sono ovvi per i colleghi più specializzati. Ad esempio, ci sono diversi tipi di prezzi che il cliente potrebbe voler seguire per un materiale in magazzino, e che il magazzino ha anche alcuni costi indiretti e il modo migliore per catturarli.
• come una sorta di integratore funzionale, aiuta a costruire un'architettura e un design che uniscano tutti questi requisiti, contribuendo infine a risolvere i requisiti in conflitto.
• prevenire i rischi, ad esempio identificando in una fase iniziale i requisiti mancanti che dall'esperienza sono comuni nei processi aziendali nell'ambito di applicazione.
• capisci l'importanza relativa delle diverse funzionalità e aiuta a definirle in ordine di priorità.
• soprattutto, identifica opportunità di miglioramento del business oltre la pratica corrente del cliente. Oppure se hai un prodotto che già consente tale cambiamento, quantificali e promuovi il cambiamento nel business del cliente ("vendi" il business case e ottieni supporto dagli utenti)
• parla il linguaggio del business, con gli stakeholder di livello superiore (il CFO del cliente non è interessato al vantaggio del livello ORM, ma sarebbe lieto di ridurre i costi di manutenzione che potrebbe aiutare a raggiungere).

Ma l'aspetto chiave per beneficiare di un BA, non è quello di usarlo solo in anticipo (sì: sarebbe molto orientato alla cascata) come una sorta di guru di pianificazione o come produttore di alcuni studi che nessuno avrebbe mai letto: devi coinvolgerlo in stretta collaborazione con il resto dell'intera squadra per tutto il progetto.

Inoltre, non sono sicuro di quanto il BA debba essere coinvolto nel lavoro quotidiano di una squadra del genere. Tuttavia, il valore aggiuntivo non è elencato in nulla che hai menzionato sopra.

A volte, il proprietario del prodotto diventa il BA, ma a seconda del dominio e dell'esperienza di quella persona, questo potrebbe non essere sufficiente. Un analista aziendale dedicato è la persona più competente per quanto riguarda il dominio aziendale. Qualsiasi BA è sicuramente da considerare uno stakeholder ed è solo una domanda su come aggiungerla al processo di sviluppo - sia come consulente per il proprietario del prodotto sia come partecipante regolare alle riunioni di pianificazione sprint.

Alcuni dei valori che il BA può aggiungere potrebbero essere:

• Assegnazione di priorità alle funzionalità in base alle entrate previste
• Precisazione di qualsiasi dominio e domande finanziarie
• Stakeholder che possono introdurre nuovi requisiti (come funzionalità per una migliore analisi dell'impatto del software sul business)
• Supporto per una migliore corrispondenza tra flussi di lavoro / processi di dominio e flusso di lavoro del software

Dipende molto dalle competenze dei membri del team e dai loro interessi in gioco. Un tipico progetto per noi le OP rappresentano di solito interessi commerciali e, mentre capiscono il loro prodotto e le loro priorità, di solito cercano di lanciare idee approssimative al team di sviluppo e chiedono che tutto sia fatto il più velocemente possibile. Il BA o Product Manager è colui che rallenta il loro lancio e mette le loro esigenze in forma di storia, sollecita le stime, assicura che la definizione di Ready sia soddisfatta prima di impegnarsi e costringe il ritmo a rimanere sostenibile.

Se i tuoi PO sono meglio allineati con il team, o se hai un master scrum abbastanza strong per forzare il processo, allora il BA / PDM potrebbe essere un lusso. Nella mia esperienza (principalmente di consulenza) avremmo ottenuto steamrolled senza uno.

L'idea di un analista aziendale in generale è di guardare l'azienda, i suoi processi, il flusso di entrate, la governance ecc. e determinare dove possono essere apportati miglioramenti.

Quando si tratta di creazione di software, questo può potenzialmente essere ridotto a specifiche richieste di funzionalità, ovvero il software deve consentire all'utente di elaborare X con le informazioni Y in modo che l'azienda possa ridurre il personale nel reparto Z.

Tuttavia! a mio avviso, spesso nella pratica non funziona bene.

Il processo quotidiano di creazione di software è piuttosto lontano dagli aspetti di alto livello finanziario / temporale e di movimento / governance di un'azienda che un analista si preoccuperebbe principalmente di se stesso.

"Non vendiamo tanti oggetti come previsto in Germania perché hanno uno strano sistema di carte negozio che non supportiamo"

non si traduce bene in:

"Aumenta il pulsante Acquista e inserisci un campo in più per la data di scadenza, ma solo quando l'IP si risolve in Germania o l'utente ha un indirizzo tedesco, ma non ha selezionato la selezione della lingua del Regno Unito"

Inoltre, avrà una serie di preoccupazioni più "business" come:

"Assumi un po 'di gente di lingua tedesca nel controllo del credito e negozia un accordo con una banca tedesca"

Troppo spesso vedi che i Project Manager vengono chiamati BA e stanno facendo la loro analisi chiedendo agli stakeholder "di che colore vorresti che fosse il pulsante".

Quindi la mia risposta è "Sì, il business ha bisogno di un BA e No, il tuo progetto agile no."