Errori e come migliorare la gestione dei requisiti di prodotto in azienda

Tutte le principali organizzazioni di standard, certificazione e regolamentazione menzionano la necessità e l’importanza di requisiti ben definiti nel processo di sviluppo del prodotto.

Infatti ci sono numerose fonti che si dedicano ai requisiti e alle migliori pratiche.

Tuttavia, anni di esperienza hanno dimostrato che le aziende lottano ancora non solo con la scrittura, ma anche con la gestione dei requisiti e l’integrazione nel processo di sviluppo del prodotto.

Errori e soluzioni per una migliore gestione dei requisiti

Di seguito sono elencati i 5 errori più grandi che si posso osservare nell’area della gestione dei requisiti e dell’ingegneria dei requisiti in molte aziende.

Elicitazione E la Mancanza di comunicazione adeguata

Negli anni abbiamo visto la lotta con i requisiti iniziare proprio all’inizio dei progetti. Ci sono molte ragioni per cui le cose possono avere un inizio difficile, non ultima la mancanza di comunicazione e comprensione tra le parti interessate.

Una volta sono stato coinvolto in un’organizzazione che aveva revisionato il processo interno di sviluppo del prodotto per affrontare le discontinuità tra ciò che i team di vendita e marketing richiedevano e ciò che sentivano su ciò che i team di progettazione stavano offrendo.

Il primo progetto che hanno avviato con il nuovo processo ha comportato quasi lo stesso problema di prima che lo sviluppo del processo organizzativo fosse rivisto. Questo è stato solo perché non hanno affrontato prima il problema alla radice: errore di comunicazione.

La soluzione era implementare un documento prerequisito sulle “esigenze degli stakeholder“. È qui che tutte le parti interessate possono vedere le loro richieste con parole proprie.

Oltre a cogliere le richieste nelle stesse parole degli stakeholder, dobbiamo includere una misura di accettazione. Questa è una descrizione di come potrebbe apparire o sentire l’utente finale. Quindi riconduciamo questi desideri o bisogni ai requisiti misurabili degli stakeholder.

La creazione di questo documento prima dell’inizio del lavoro sui requisiti effettivi aiuterà i nostri stakeholder a vedere come i loro concetti originali vengono tradotti in un requisito più formale per gli stakeholder.

Utilizzo non specificato di requisiti correlati

La stragrande maggioranza dei miei progetti nel corso degli anni non è stata isolata.

Tutti gli ingegneri possono vedere tutti i documenti del progetto se lo desiderano e sapere dove andare per trovarli. Questo ambiente aperto e trasparente è ben accolto e fornisce un contesto in cui gli elementi sono all’interno del grande schema di un progetto.

Uno degli svantaggi di questa situazione è che nelle prime fasi di sviluppo, alcuni team pianificano di condividere le risorse di sistema senza discutere e integrarsi realmente con i proprietari del sottosistema.

Molto spesso abbiamo scoperto che questo era il risultato di conversazioni in corridoio o riunioni improvvisate tra i reparti che non venivano registrate o comunicate correttamente. Il problema sorge quando la risorsa deve cambiare ma il secondo team non formale che stava pianificando di utilizzare quella risorsa non è stato tenuto al passo con i cambiamenti.

Ecco un semplice esempio: gli ingegneri meccanici hanno bisogno di un sensore di temperatura dell’aria in una determinata area del sistema. Il gruppo di computer ha un dispositivo standard che entra in quell’area e uno dei loro ingegneri ha detto che ha sensori integrati.

I “ragazzi meccanici o mechanical guys” indagano e decidono che questo soddisfa le loro esigenze, quindi lo includono nei loro piani di progettazione. Sei mesi dopo, durante l’abbassamento dei costi, il dispositivo viene sostituito e nessuno ne parla ai meccanici e non lo scoprono fino al collaudo.

I processi possono essere implementati per ridurre al minimo questi problemi e ora ci sono strumenti che ti permetteranno di integrare questi controlli nel tuo software di gestione dei requisiti. La nostra soluzione consisteva nell’implementare un controllo tra i team per tutti i requisiti che intendete utilizzare, e non solo quelli all’interno del vostro sottosistema o area di responsabilità.

Nell’esempio sopra, il nostro team meccanico avrebbe segnalato tale requisito e se fosse stato modificato o modificato, sarebbe stato informato. La linea di fondo è assicurarsi di disporre di un metodo in atto per tenere traccia delle funzioni condivise o complementari poiché possono verificarsi errori di comunicazione.

Letture consigliate => I 20 migliori strumenti di gestione dei requisiti

Progettazione secondo il requisito

Un tema ricorrente per le aziende giovani o inesperte è disegnato dai requisiti.

I team si concentrano sull’aspetto del dispositivo e non su ciò che il dispositivo deve fare. È normale che le persone inizino a specificare le dimensioni dello schermo, il numero di pulsanti, i flussi di lavoro e gli altri elementi prima che siano state definite le esigenze specifiche del dispositivo.

I progetti possono e diventeranno requisiti, ma sotto forma di documentazione progettuale e non come requisito individuale ad alti livelli.

Ad esempio, alcune parti interessate nell’organizzazione possono specificare che un dispositivo avrà un touch screen capacitivo. Questo potrebbe essere un esempio di un progetto in base al requisito. Le specifiche delle prestazioni, il flusso di lavoro e i requisiti ambientali possono tutti giocare in una decisione per i sistemi di controllo come questo.

Tuttavia, in questo caso, tali decisioni di progettazione vengono rimosse agli ingegneri dal requisito specifico all’interno di un documento di alto livello. Il modo migliore per gestire questi elementi è dividere la caratteristica richiesta in requisiti funzionali e di design.

Dal nostro esempio sopra possiamo porre le domande sul perché il touch screen è richiesto dal punto di vista delle prestazioni e allo stesso tempo sviluppare i documenti del concetto di design per i loro requisiti estetici e di flusso di lavoro.

Le specifiche tecniche guideranno gli ingegneri sulle prestazioni e su ciò di cui hanno bisogno, e la grafica concettuale e gli studi sul flusso di lavoro risolvono problemi più formativi come la sensazione e il flusso di processo.

Evitare i cambiamenti

Ogni organizzazione in cui sono stato si è tormentata per le modifiche alle specifiche dopo che qualcosa è stato firmato.

Il problema è che queste stesse organizzazioni non vogliono aspettare il documento completo dei requisiti in primo luogo, quindi i documenti di alto livello vengono scritti contemporaneamente al lavoro di progettazione.

Non importa quanto sia bravo il tuo team, non può progettare e costruire qualcosa quando non puoi o non vuoi dire loro quale sarà.

La verità è che le cose cambiano sempre nel percorso di completamento di un progetto. In pratica, dovremmo imparare ad accettare i cambiamenti e prepararci ad essi. Le esigenze dei clienti cambieranno e impariamo cose come ingegneri e designer. Tutto questo ci dà maggiori informazioni e conoscenze per costruire un progetto migliore.

Sfortunatamente, per questo tipo di problemi, non esiste una scorciatoia o una soluzione rapida. Stabilire e mantenere la tracciabilità tra i diversi livelli di specifiche è l’unico modo per sapere quali elementi sono interessati quando qualcosa cambia, e soprattutto quando tali modifiche interessano più team.

Uso di Word ed Excel

Nel corso degli anni, ho visto che quasi tutte le organizzazioni utilizzano per impostazione predefinita Word ed Excel per supportare il processo dei requisiti a un certo punto. Word ed Excel sono un modo semplice ed economico per iniziare a scrivere i requisiti.

Quasi tutti nell’organizzazione sanno come utilizzare questi strumenti.

Tuttavia, molto rapidamente il versionamento dei documenti inizia a diventare un vero problema e le matrici di tracciabilità, spesso mantenute in Excel, diventano una combinazione inestricabile di colonne con riferimenti a documenti scollegati. Mantenere sincronizzati sia i documenti di Word che le matrici di Excel è un compito faticoso.

Senza nemmeno affrontare la conformità agli standard, se prevedi di apportare modifiche al tuo progetto (cosa che dovresti), allora la tracciabilità è un must, ed è allora che un sistema di gestione dei requisiti come Visure Requirements diventa necessario per renderlo un compito accessibile e facilitare il fardello.

Lo strumento di gestione dei requisiti diventa l’unica fonte di verità, per mantenere tutti i dati accessibili e interconnessi.