Conduzione delle sessioni di acquisizione dei requisiti
L'Architetto di soluzioni di solito conduce sessioni per l'acquisizione dei requisiti. L'obiettivo di queste sessioni è trasformare le esigenze generali in requisiti implementabili. Se lo stesso Architetto di soluzioni viene coinvolto nella fase di prevendita, può già conoscere le esigenze del cliente e i fattori di successo. In caso contrario, deve assicurarsi di essere ben informato prima della prima sessione. Queste informazioni devono essere usate durante la discussione con i partecipanti.
Con il tempo e l'esperienza, sarà più facile individuare una metodologia preferita per questi incontri. È importante essere preparati ad adattarsi alle mutevoli esigenze dei progetti o dei clienti specifici. Arrivare a queste sessioni con un piano, modelli e risultati desiderati, ma senza essere troppo rigidi per evitare di soffocare la conversazione, la creatività e le soluzioni.
Che aspetto ha un requisito
Il modo specifico con cui viene documentato un requisito di un progetto può essere indicativo di una scelta metodologica. Tuttavia, a livello generale, i requisiti devono indicare chi, cosa e perché. Questi parametri possono essere acquisiti nelle storie utente oppure possono essere requisiti di voci, ma devono essere verificabili e affidabili. Un buon requisito tiene presenti i seguenti fattori:
Chi ha bisogno del requisito
Di cosa ha bisogno il cliente
Perché il cliente fa una determinata scelta
i requisiti o le storie più estesi devono essere suddivisi in parti gestibili. Nella varie metodologie vengono usati termini diversi per queste parti, ad esempio negli approcci agili in genere vengono chiamate epiche. Indipendentemente dal nome, l'Architetto di soluzioni deve essere assicurarsi che questo processo abbia luogo.
Definizione delle priorità
Ogni progetto ha una quantità limitata di tempo e risorse disponibile per l'implementazione dei requisiti. L'Architetto di soluzioni, insieme al team di progetto e spesso al cliente, deve dare la priorità all'elenco/backlog dei requisiti.
Poiché i progetti di applicazioni aziendali si prestano bene alle distribuzioni incrementali, i team spesso danno la priorità a un prodotto minimo funzionante (MVP, Minimum Viable Product). Un MVP identifica i requisiti necessari per la pubblicazione iniziale. Gli elementi rimanenti vengono quindi inseriti in iterazioni o sprint futuri.
L'Architetto di soluzioni dovrebbe usare gli obiettivi aziendali chiave identificati per valutare i requisiti. La priorità dovrebbe essere data ai requisiti che contribuiscono a raggiungere questi obiettivi. Questo approccio consente anche di identificare un distacco rispetto agli obiettivi chiave se viene individuato un requisito chiaramente importante, ma che non aiuta a raggiungere gli obiettivi chiave.
Attuabilità
L'Architetto di soluzioni dovrebbe valutare i requisiti per assicurarsi che siano attuabili. Cercare i requisiti che, sebbene interessanti, non sono realizzabili per una serie di motivi, ad esempio quelli che richiedono:
Dati non disponibili.
Aggiornamenti di altri sistemi impossibili da eseguire nel tempo a disposizione.
L'Architetto di soluzioni dovrebbe porsi la domanda: "C'è qualcosa che può impedire il completamento di questi requisiti?"
Gestione dei partecipanti
Le aspettative dovrebbero essere stabilite prima delle sessioni per garantire la partecipazione delle persone interessate. È necessario che siano coinvolte persone esperte nelle aree di interesse. Un approccio più mirato e produttivo consiste nell'organizzare un maggior numero di sessioni brevi e specializzate. È opportuno coinvolgere persone diverse nella gestione delle varie parti di un processo perché consente di ottenere un quadro completo di come funzionano le singole parti. Con questo approccio spesso si evita di dover tornare su alcuni argomenti per integrarli con le informazioni mancanti.
Estendere l'invito ai dirigenti può essere utile perché spesso forniscono informazioni decisive. D'altro canto, la presenza di un senior manager può influire sulla partecipazione del personale. In molti casi, il personale sarà più silenzioso e attenderà le risposte del responsabile per evitare di dire cose sbagliate. Per risolvere questo tipo di scenari negativi, è possibile organizzare un follow-up separato o chiedere al responsabile di non partecipare a tutte le sessioni.
Lavoro preliminare per le sessioni
Prima della sessione, l'Architetto di soluzioni dovrebbe cercare di ottenere quante più informazioni possibili sulla soluzione corrente e sui suoi processi. Queste informazioni possono essere studiate in anticipo per formulare una serie di domande da usare per mantenere viva la discussione. In questa fase di preparazione i partecipanti possono anche raccogliere documenti ed esempi da portare alle sessioni.
Inoltre, è importante ricordare di raccogliere i dati del team di prevendita. Evitare di ripetere ai clienti informazioni già discusse. Controllare la disponibilità di registrazioni demo per aumentare le conoscenze.
Promozione della chiarezza dei requisiti
Spesso, la dichiarazione iniziale del requisito di un utente aziendale non corrisponde al requisito reale. Per individuare questo requisito, l'Architetto di soluzioni dovrà condurre qualche indagine per guidare l'utente o per comunicare con gli altri. L'architetto di soluzioni deve imparare a chiedere il perché delle cose senza indispettire l'utente o farlo sembrare
incapace di svolgere il proprio lavoro. La vera ragione di queste domande è arrivare al problema centrale, in base al quale progettare la soluzione migliore.
Per raccogliere queste informazioni, è utile avere a portata di mano alcune domande frequenti:
Il cliente può descrivere una giornata di lavoro tipo su quel processo?
Chi altro è coinvolto nel processo?
Da dove vengono queste informazioni?
Il cliente può spiegare perché è necessario questo processo?
Per arrivare a definire i requisiti e i bisogni reali, è possibile iniziare con domande aperte e quindi passare a domande sì/no per confermare di aver capito correttamente. L'esempio seguente è un semplice scambio tra un Architetto di soluzioni (SA) e degli utenti aziendali:
Utente: abbiamo bisogno di un report stampato di tutte le transazioni scadute negli ultimi 30 giorni.
SA: a chi è destinato il report?
Utente: viene usato dai responsabili.
SA: come verrà usato il report? È necessario creare un report o semplicemente vedere le transazioni scadute dell'ultimo mese?
Responsabile: leggiamo il report solo una volta al mese, quindi basterebbe questo.
SA: cosa si osserva quando si esaminano i dati?
Responsabile: cerchiamo tutte le transazioni superiori a 50.000 dollari, quindi le analizziamo più approfonditamente.
SA: quindi, sarebbe utile se il sistema presentasse solo le transazioni scadute superiori a 50.000 dollari per la revisione?
Responsabile: sì, sarebbe fantastico.
Requisito rivisto: i responsabili hanno bisogno di esaminare mensilmente le transazioni scadute superiori a 50.000 dollari.
Se l'Architetto di soluzioni non avesse posto queste domande, il team avrebbe creato un report cartaceo. Chiedere sempre il perché, finché non si è certi di aver capito esattamente l'esigenza.
Risoluzione dei requisiti in conflitto
Spesso gli utenti aziendali creano requisiti in conflitto. È essenziale che il cliente possa affidarsi a qualcuno in grado di dirimere queste questioni. L'Architetto di soluzioni può offrire idee e compromessi per risolvere il problema, ma non dovrebbe essere coinvolto nelle politiche aziendali.
Sostegno del proprio punto di vista
Un Architetto di soluzioni deve saper respingere rispettosamente i requisiti che reputa inappropriati. Parte di questa responsabilità è riuscire a comunicare chiaramente la visione della soluzione ideata e aiutare il cliente a capire in che modo potrà contribuire a raggiungere gli obiettivi prefissati. I nuovi architetti di soluzioni spesso hanno problemi in questa fase perché si mostrano troppo condiscendenti. Quando si presenta la propria visione al cliente, evitare di mostrare scarsa considerazione per le sue idee.
Esercizio - Pianificazione delle sessioni per l'acquisizione dei requisiti
Esaminare i team della banca Woodgrove e scegliere quali di essi raggruppare e quali no per la raccolta dei requisiti. Spiegare i motivi delle decisioni.