Requirement Change Management: il ciclo di vita di un prodotto!

Che cos’è il requirement change management?

 

Il requirements change management è una delle attività di project management, la quale è l’attività di progettazione, gestione e sviluppo di un certo prodotto (software, ad esempio) per tutto il suo ciclo di vita.

In particolare, il requirement change management ha a che fare con lo sviluppo dei requirement.

Un esempio semplificherà il concetto.

Supponiamo che una certa azienda richieda a Microsoft la possibilità di utilizzare una particolare nuova funzione di calcolo in Excel che legge dati da un plugin esterno, perché stima che tramite essa sia possibile migliorare significativamente l’efficienza lavorativa dei suoi team di analisti e consulenti e alleggerire considerevolmente dimensione dei file e memoria. A questo punto, il team di product management di Microsoft valuterà il requirement, valutazione fatta:

  • da un punto di vista di fattibilità (“comporta cambiamenti strutturali nell’architettura del prodotto?”, “questo calcolo può essere usato tra le funzioni pre-impostate?”, ecc)
  • da un punto di vista tecnico-analitico (“esistono funzionalità che soddisfano già la richiesta?”, ecc)
  • da un punto di vista di convenienza economica (“vale la pena investire sul progetto?” “quali benefici di lungo periodo apporta?” “la richiesta ha carattere prioritario?”)

Se Microsoft opta per lo sviluppo della funzionalità, inizierà tutto un percorso al termine del quale rilascerà una nuova versione di Excel (major, minor, service pack, a seconda della “radicalità” della modifica) che a differenza della precedente consentirà all’azienda di usare la nuova funzione di calcolo richiesta.

L’attività di requirements change management si suddivide nelle seguenti fasi:

  • Tracciabilità (dei requirement) à questa fase è spesso molto sottovalutata ma è in realtà il punto di partenza di tutto. La BU si interfaccia col cliente per capire per filo e per segno la richiesta.

Se conviene sviluppare i requirements, si procede con l’analisi.

  • Analisi à durante questa fase le BU che hanno interagito coi clienti sono pronte ad analizzare per filo e per segno come sono sviluppate le funzionalità e ogni comportamento che deve eseguire la funzionalità, come devono essere gestiti gli errori, come sarà strutturato il form della user interface e l’ambiente di design. Tutti le specifiche sulla funzionalità sono contenute in documenti di analisi detti SRS (l’acronimo sta per software requirements specifications), che conterranno:
  • Sviluppo à durante questa fase BU e sviluppatori interagiscono. Gli sviluppatori stimano l’effort della richiesta (solitamente in termini di giorni di lavoro). Sostanzialmente l’intervento degli sviluppatori serve per rispondere a domande del tipo “Questa modifica necessita di una modifica architetturale del prodotto?”, “E’ fattibile da un punto di vista ingegneristico?” ecc ecc. Gli sviluppatori programmeranno la funzionalità sotto forma di un codice che traduce l’esatto comportamento riportato nell’analisi. Dopodiché testeranno “via alfa” la funzionalità. Testare via alfa significa attraverso l’engine core, o, ancora più da dummy, tramite “quello che l’utente non vede”, e cioè i codici che stanno dietro i comandi che visualizzate nell’interfaccia del programma.
  • est and Construction (collaudo) à in questa fase BU e sviluppatori collaborano per valutare se il comportamento della funzionalità in sviluppo è coerente con quello atteso, preparando dei test cases che ricoprano il maggior numero di scenari teorici possibili. Tutti i test sono eseguiti su una versione del prodotto beta, cioè non ancora distribuita a nessuno e su cui accedano solo sviluppatori e analisti della BU. In pratica è una fase di “prova” dietro le quinte prima di esibire il prodotto sul palcoscenico agli spettatori (o clienti, come preferite voi…). Si dice che si “collauda” il prodotto.
  • Release à durante questa fase viene annunciata una data di rilascio della versione ufficiale del prodotto comprensiva dei nuovi requirement (release). Si intensificano i test per individuare il maggior numero di errori non gestiti e di “issue” in generale. Si va ad una vera e propria caccia di bachi, con tanto di paletta ammazza-insetti e si fa piazza pulita! Si fa debugging. Il debugging è diverso dal testing. Testing vuol dire testare i test cases e vedere che la macchina si comporta come previsto. Debugging vuol dire volutamente ricercare comportamenti non analizzati incorrendo in situazioni o errori non gestiti. In questo modo di li identificano e fissano, prima “via alfa” e poi “via beta”. In pratica gli sviluppatori sistemano la linea di codice che causa il bug, mentre gli analisti “certificano” testando dal lato designer che effettivamente ora è tutto perfettamente gestito. I bachi fissati sono ri-testati dal lato designer su nuovi pacchetti della versione beta del prodotto. Piano piano escono versioni beta con pacchetti aggiornati comprensive degli aggiustamenti e ci si avvicina a quella ufficiale. Spesso c’è il rischio, seppur di solito contenuto, che nel momento in cui gli sviluppatori sistemano la linea di codice, si “rovini” qualcosa in un altro punto del codice. In gergo si dice che in questi casi il codice “si spacca”, e si genera una regressione (ovvero si causa un baco che nelle versioni precedenti era già stato fissato o non esisteva proprio!). Per questo motivo l’attività di debugging va fatta con intelligenza: quando ormai tutti i bachi importanti sono stati fissati non ha più senso aggiungere “roba nel calderone” identificando bachi palesemente minoritari. Si rischia solo di 1) dare lavoro su lavoro da fare 2) avere una possibilità, seppur contenuta, di “spaccare” il codice generando una situazione peggiore di quella attuale 3) posticipare il rilascio.

Quando tutti i bachi sono stati fissati, gli sviluppatori distribuiscono alla BU la versione ufficiale di prodotto, cioè quella pronta alla vendita. Dopodiché la BU “delivera” la versione ufficiale, che in breve verrà installata su tutti i server, e congiuntamente informa i clienti e colleghi interni.

Ed ecco spiegato come funziona tutto il processo dalla richiesta del cliente fino alla messa in atto di tutte. Il cliente si ritroverà il nuovo prodotto, ovvero la nuova versione di Excel, comprensiva di ciò che aveva richiesto.

About the author

Laureato in Finanza, Intermediari e Mercati presso Università di Bologna, attualmente lavoro presso CRIF S.p.A. con il ruolo di Business Analyst nell'area di Management and Developing Product Credit Solutions

Related

JOIN THE DISCUSSION