Un approccio semplice ma efficace

Il mercato delle soluzioni software è in continua evoluzione. Le novità di oggi potrebbero essere obsolete domani. Per stare al passo è necessaria una collaborazione stretta e ottimale tra lo sviluppo e le unità operative. Ecco due esempi che mostrano cosa significa nella pratica.

Business, sviluppo ed esercizio, dall’inglese Business, Development e Operations, rappresentano la base del moderno sviluppo di prodotti nell’IT. Con il cosiddetto approccio BizDevOps si cerca di colmare le lacune tra business e IT.

Poco più di dieci anni fa si è affermato il cosiddetto modello DevOps. Per quanto riguarda l’IT, sono state colmate alcune lacune tra lo sviluppo e l’esercizio. L’obiettivo era riuscire a rilasciare il più velocemente possibile i nuovi software sviluppati e le nuove funzioni.

Ma c’era spesso ancora un problema. Generalmente le richieste delle unità operative venivano formulate senza coinvolgere l’IT e quindi spesso le idee e le richieste delle unità specializzate non potevano essere soddisfatte dall’IT. Di conseguenza, veniva meno il vantaggio in termini di velocità ottenuto grazie alla collaborazione più stretta tra l’esercizio e lo sviluppo.

Per rimediare a questo problema è stato sviluppato il modello BizDevOps. Il business, ovvero le unità specializzate insieme a Vendite, collaborano con l’IT per portare le visioni aziendali nelle soluzioni digitali. Vorrei spiegarvi come funziona questo approccio nella pratica con due esempi.

Per cominciare un esempio di cosa è meglio non fare: quando un paio di anni fa ho assunto il ruolo di product owner, mi sono ritrovato subito sulla scrivania richieste di altri manager prodotti che dovevano essere implementate nella mia applicazione. I manager prodotti mi avevano assicurato che le richieste erano state specificate ed elaborate per mesi e che quindi non ci sarebbe dovuto essere nessun problema. Essendo alle prime armi, ho accettato e ho integrato le richieste nella nostra pianificazione dello sprint.

Per farla breve, le richieste sono state respinte dai presenti. Le specifiche sul tavolo non avevano senso perché i richiedenti non conoscevano i nostri sistemi. Non è quindi rimasto nulla da fare se non pianificare qualcosa insieme agli sviluppatori in modo da riuscire a creare qualcosa di utile.

Ma ecco un esempio in cui le cose sono andate meglio: ho tratto i miei insegnamenti da questa prima esperienza nel mio nuovo ruolo. Prima di inserire una richiesta nella pianificazione dello sprint, ne parlo con i nostri sviluppatori indipendentemente dall’entità della richiesta. Non mi presento a questi colloqui con una richiesta definitiva. Il più delle volte si tratta piuttosto della vision legata all’obiettivo della richiesta. Questo ci permette di risparmiare tempo e denaro e di ridurre lo stress. Idealmente i colloqui durano solo dieci minuti: delineo la richiesta e presento una proposta di soluzione, gli sviluppatori se ne occupano subito ma presentano una loro proposta che permette di raggiungere lo stesso obiettivo in modo più semplice ed efficiente.

Considero il BizDevOps un approccio o una guida che può essere impiegata in diversi modelli agili. Non importa se si tratta di Lean, SAFe, Scrum o Kanban. L’importante è che tutte le parti siano coinvolte nella ricerca di una soluzione.