Risposta.

La storia di questa questione risale alle difficoltà classiche dell'interazione tra business e IT: l'opinione soggettiva, le impressioni personali e le emozioni distorcono spesso i requisiti e le priorità (ad esempio, ciò che è "critico" per uno può essere di poco interesse per un altro).

Problema: l'influenza dei fattori soggettivi porta a perdite di obiettività, conflitti e mancanza di trasparenza, il che influisce sulla qualità del sistema e sulla soddisfazione del cliente. Le preferenze implicite di un importante stakeholder possono portare l'inclusione di desideri non argomentati nei requisiti.

Soluzione:

Formalizzare il processo di raccolta dei requisiti attraverso questionari, matrici di priorità e interviste strutturate
Utilizzare metodologie per individuare veri bisogni (5 Why, Value chain analysis)
Coinvolgere diversi tipi di stakeholder e registrare tutti i punti di vista (stakeholder map)
Verificare il risultato tramite accordi documentati e group review
Applicare il test utente dei prototipi, per confrontare le aspettative con la realtà

Caratteristiche chiave:

Utilizzo di sessioni cross-funzionali e mappatura degli interessi
Introduzione di criteri di accettazione formalizzati per i requisiti
Monitoraggio costante delle variazioni delle aspettative degli stakeholder (stakeholder log)

Domande trabocchetto.

È sufficiente tenere una riunione generale per la raccolta dei requisiti con esperti aziendali per rimuovere tutti i fattori soggettivi?

No. Nelle riunioni, parte delle opinioni si perde a causa del dominio di partecipanti attivi, dettagli importanti spesso rimangono fuori. È necessario effettuare interviste individuali o in piccoli gruppi e poi sintetizzare i risultati.

Si può considerare l’opinione del product owner come unica fonte vera per tutti i requisiti?

No. Il product owner è una fonte importante, ma altri stakeholder (ad esempio, supporto, contabilità, sicurezza, utenti) possono rivelare sfumature critiche, la cui ignoranza porta a seri errori.

Si deve sempre fidarsi della priorizzazione dei requisiti fornita dal business senza ulteriori verifiche della sua validità?

No. La priorizzazione è spesso soggettiva e dipende dagli obiettivi aziendali attuali. È necessario giustificare le priorità attraverso matrici di value/risk, ROI, obiettivi strategici aziendali.

Errori tipici e anti-pattern

Seguire ciecamente l'opinione del partecipante più forte o di maggior prestigio
Ignorare l'opinione degli stakeholder "silenziosi"
Raccolta di requisiti non formalizzata ("a orecchio")

Esempio dalla vita reale

Caso negativo: L'analista concordava i requisiti solo con un rappresentante del business, ignorando completamente gli utenti e il personale tecnico.

Vantaggi:

Lavoro rapido
Comodo per lo stakeholder leader

Svantaggi:

Conflitti nascosti, resi, rifacimenti
Il sistema è scomodo per gli utenti finali

Caso positivo: L'analista ha sviluppato una mappa dei principali gruppi di influenza, ha condotto interviste con tutti, ha registrato le discrepanze e ha preparato un documento con le priorità basato su criteri oggettivi.