di Blaise Palopoli

Ciao  a tutti, mi  chiamo Blaise e sono Product Owner in ambito insurance da poco più di due anni. Oggi lavoro con un team di delivery di epiche finalizzate all’ottimizzazione del prezzo dell’assicurazione. L’argomento che vorrei condividere con voi oggi mi è molto a cuore: si tratta della distanza tra business e IT. 

In fondo un Product Owner è esattamente il ponte tra business ed IT, e credo che uno degli obiettivi di un buon PO sia quello di accorciare il più possibile questo ponte.

Quello che vorrei fare con questo articolo è illustrare le problematiche che un approccio che separa IT e Business comporta, i benefici che l’abbattimento di tale barriera possa generare, e qualche piccolo accorgimento per cominciare a scardinare questa mentalità, ancora troppo spesso radicata in noi.

Se riguardiamo i principi dell’Agile (cosa che penso dovremmo fare più spesso invece di litigare sul fatto che sia meglio Safe, Scrum o XP…)  troviamo interazioni ed individui, apertura al cambiamento, collaborazione. Nelle strutture dove non combattiamo la barriera tra IT e Business diventa molto difficile da smantellare ed è difficile essere agili.

Quante volte abbiamo visto il nostro team di sviluppo non esprimere al meglio le loro potenzialità ? Quante volte abbiamo avuto l’impressione di non riuscire a coinvolgere le persone del team? Di non farli sentire a bordo di progetti? Quante volte il team di sviluppo si sente un mero esecutore di decisioni prese da altri? Non solo, mi è capitato di vedere Product Owner che si sentono dei semplici ‘spostatori di post-it’ e di non sentire nessuna responsabilità nella visione del prodotto.

Queste problematiche sono complesse e legate a tanti fattori, ma, in maniera iterativa incrementale, si può cominciare a fare qualcosa per risolverle. Di seguito qualche spunto che ho applicato e che ha dato ottimi risultati:

●Chiedere al referente di business di raccontare al team il valore dell’epica che si lavorarà nelle prossime iterazioni; chiedere di raccontare come è nata l’idea, come è stata sviluppata, fino alla definizione dello Use Case che il team è portato a lavorare.

●Pretendere che il business partecipi alle demo: non c’è niente di più deprimente e controproducente di una demo deserta.

Fare quello che chiamiamo «retro testing». Dopo un periodo di tempo abbastanza lungo, al fine di avere chiari i benefici di un’epica rilasciata, far raccontare al referente di business i benefici che hanno portato gli sviluppi fatti. Per esempio: dopo l’integrazione di questo nuovo servizio, la soddisfazione dei nostri clienti è aumentata di X, portando numeri e prove (tanto loro avranno già dovuto preparare con ogni probabilità questi indicatori per il management, quindi questo non comporta lavoro aggiuntivo).

●Prendere dei momenti dedicati per raccontare come sta andando la società nella sua interezza: questo crea un senso di appartenenza incredibile.

Parlare spesso con gli stakeholder, per capire le loro idee, i loro problemi ed insieme trovare soluzioni! Questo permetterà al PO di diventare parte integrante del processo di definizione di visione del prodotto.

Si tratta quindi di intensificare i momenti in cui il team respira il business; le cose poi verranno da sé. 

Nel nostro caso questi spunti hanno portato tantissimo valore, in termini di coinvolgimento e reattività del team; addirittura ora è lo stesso team che propone miglioramenti (non tecnologici, ma per cambiare la vita al cliente) al business. Si crea una sinergia e un entusiasmo contagiosi,  che ci stupiscono ogni giorno di più.