Come gestire frequenti cambiamenti dei requisiti?

Sto affrontando una situazione piuttosto stressante (secondo me) nel mio attuale posto di lavoro.

Abbiamo iniziato a sviluppare un nuovo progetto, ottenere alcuni requisiti, implementarlo e quindi mostrare a qualcuno che puoi chiamare un "consulente aziendale" (persona che conosce i requisiti aziendali ma non utilizzerà il programma). Quella persona dovrebbe valutare l'applicazione dal punto di vista dei clienti, testarla ecc.

Ecco come appare il 'processo':

1. consulente aziendale parla la sera con il mio capo per ore o due su Windows Messenger
2. il giorno dopo ricevo e-mail con copia di quella conversazione. Dovrei scegliere le attività da quella, controllare i bug segnalati (che spesso non sono bug, solo scarsi test e dimenticare gli stabilimenti passati)
3. Ho implementato le modifiche, l'implementazione è stata accettata e poi in una o due settimane risulta che non è ciò che vogliono (hanno parlato con alcuni potenziali clienti che hanno visto il software per 5 minuti e ha suggerito le modifiche) - Devo fare nuove modifiche

Non fraintendetemi, capisco che a volte i requisiti cambiano. Ciò che mi sconvolge è la frequenza con cui si verificano i cambiamenti nel mio posto di lavoro e la facilità con cui la "gestione" è due che offrono nuovi requisiti o talvolta cambiamenti fondamentali alle funzionalità esistenti.

Allo stesso tempo stiamo lavorando a scadenze strette e ho l'impressione che invece di andare avanti con il nostro software stiamo eseguendo delle cerchie.

Chiedo consiglio a voi come affrontare questa situazione? Questa è una situazione normale e io sono solo ipersensibile al riguardo?

Se possibile, prendi la conversazione che ti è stata inviata per e-mail e trasformala in un documento di requisiti. Elenca le attività che puoi ricavare da essa e ordinale in base a ciò che ritieni essere la priorità e assegna una stima a ciascuna. Quindi chiedi quali funzionalità desiderano per la prossima versione.

Fondamentalmente, forzare una sorta di circuito di feedback in cui la direzione è consapevole di cosa costruirai. Scrivi i tuoi documenti dei requisiti fino al momento in cui ricevono il messaggio.

Carte della storia

Penso che la tua situazione sia adatta per presentare storie utente . Sono davvero utili nel fornire un modo continuo e interattivo per il tuo manager di stabilire le priorità e può anche buttarle via quando torna all'idea una settimana dopo e si rende conto che non è praticabile.

Nel mondo reale, i requisiti cambiano abitualmente. Tra i lati positivi, lo scoprirai prima di terminare la creazione del software e spedirlo - hai un ciclo di feedback stretto da parte dell'utente diretto del software, il che è davvero fantastico.

Sembra che il problema più grande qui sia il modo molto ad hoc di gestire il cambiamento. Hai ciò che agile / Scrum considera un "proprietario del prodotto", che fornisce feedback, ma il processo è scarsamente documentato e sconsiderato.

Probabilmente vuoi guardare i modelli in Scrum e la loro visione di ciò che è un efficace proprietario del prodotto , per aiutarti a informare i tuoi prossimi passi.

Quindi, invece di avere questo processo ad hoc, mira a spostarti in un mondo in cui hai una relazione più stretta e più utile con il "consulente aziendale" e dove tutti sono sulla stessa pagina in merito agli esiti dei cambiamenti di cui stanno discutendo .

Il tuo attuale processo rende troppo facile per queste persone fare brainstorming di idee senza dover riconsiderare le risorse e il denaro che questo consumerà. Se vogliono tutte queste funzionalità, devono avere un po 'di "skin nel gioco".

Prendi quell'e-mail della conversazione e inseriscila in una sorta di applicazione di tracciamento di funzionalità / bug anche se è solo un foglio di calcolo. Invia le nuove aggiunte al consulente aziendale e chiedi a lui / lei di firmare su ogni articolo o fornire correzioni. Insieme alla firma, dovrebbero dare la priorità (quali vuoi prima?).

Dopo l'approvazione, rispedisci il tuo programma quando gli articoli saranno completati per il test e inducili a impegnarsi in un momento per eseguire il test / approvazione del completamento.

So che creare questo tipo di documentazione non è il motivo per cui sei diventato un programmatore, ma puoi rischiare di buttare via questi elenchi o continuare a buttare via il tuo codice guadagnato.

Respingere. I responsabili devono vedere quanto costano queste richieste.

Le modifiche ai requisiti non sono sempre sbagliate. La cosa fondamentale è ricordare il tuo cliente. Probabilmente il tuo capo è il tuo cliente in questo caso. Devi informare il tuo capo che ritieni che queste costanti modifiche ai requisiti limitino la tua capacità di produrre il prodotto che gli è più utile. È del tutto possibile che l'azienda tragga vantaggio da te reagendo costantemente ai cambiamenti. Se è così, questo è il loro modello di business e non stai facendo nulla di male, anche se in quel caso ti consiglio di correre per le colline!

Le persone frustrate dalle modifiche ai requisiti sono spesso valutate dal modo in cui gestiscono ciascuna modifica. Questa metrica del "numero di modifiche sufficientemente gestite" è probabilmente la fonte del tuo vero problema. Valuta la possibilità di discutere metriche migliori con il tuo capo. Quando mi trovo di fronte a requisiti in costante cambiamento, mi sforzo di scrivere contenuti che mi consentano di adattarmi a requisiti in costante cambiamento. Invece di eseguire una simulazione e analizzare i dati ogni giorno, scriverò strumenti che rendono il processo di esecuzione della simulazione e analisi dei dati più economico, e raccolgono i frutti nel tempo. Se è ancora troppo folle, potrei persino scrivere uno strumento per scrivere strumenti!

Il processo potrebbe trarre vantaggio da alcuni principi agili, come bloccato nelle iterazioni. Penso che una settimana sia ragionevole con cambiamenti così rapidi che stai descrivendo. 2 settimane potrebbero funzionare meglio alla fine.

Una volta identificati i requisiti abbastanza importanti, Project Ownerfai firmare la persona che è in ruolo e bloccali per un periodo di una settimana mentre li costruisci. Assegna abbastanza lavoro per te a dove sarai occupato e lascia che i poteri siano a conoscenza della tua allocazione. cioè se alla settimana puoi produrre un lavoro di 16 punti e hai 16 punti di lavoro, allora sei completamente utilizzato per quella settimana. (Il concetto dei punti deriva da un flusso di lavoro agile)

Se si verificano cambiamenti nel mezzo della settimana, pronuncia queste parole magiche:

Posso fare [questa nuova funzione], [questa nuova modifica], [ecc], ma cosa non vuoi fare ?

Cioè, sei una risorsa limitata, puoi solo prendere così tanto lavoro. Se arriva un nuovo oggetto di lavoro, ti è permesso di essere la risorsa limitata che sei e assegnare punti al nuovo oggetto e rilasciare / cambiare altri oggetti al posto di questo nuovo cambiamento in arrivo. Dai la priorità al tuo elenco di iterazioni insieme al proprietario del progetto e dovresti essere più bravo a gestire i cambiamenti.

Se i requisiti cambiano più frequentemente, potrebbe essere necessario negoziare una maggiore stabilità nel proprio ambiente.

La frase "Modifica dei requisiti" viene talvolta abusata dalle persone IT. Quello che stai descrivendo è in effetti una modifica dei requisiti, ma ciò può essere dovuto al fatto che uno o più dei seguenti (non conosco abbastanza il tuo caso, quindi i seguenti potrebbero o meno essere applicabili):

1. L'ambizione della direzione di rendere felice l'utente finale il più rapidamente possibile e mostrare rapidi progressi.

2. Mancanza di analisi dettagliate. Ricorda che gli analisti devono porre domande sul perché non solo su cosa. Gli analisti devono "pensare" con l'utente finale a una "soluzione" non solo per prendere ordini.

3. Mancanza di un processo formale per la verifica e la conferma dei requisiti, seguito dall'approvazione.

4. Chiedere alla persona sbagliata di svolgere uno o più ruoli per i quali non sono necessariamente formati per ruoli di analista aziendale o analista di sistemi.

5. Prototipazione limitata.

6. Il presupposto / la paura che debba essere fatto rapidamente e, in caso contrario, la colpa è dell'IT.

A meno che uno non affronti correttamente tutto quanto sopra, il rapporto tra IT e utente aziendale / finale sarà stressante. Si noti che ciò non implica che il punto precedente sia conclusivo. Ci sono altri fattori che portano a situazioni stressanti simili alla tua situazione, ma penso che questo elenco dovrebbe farti andare avanti.

Penso che dovresti affrontarlo da alcune direzioni:

1. Chiedere a tutti gli stakeholder (incluso l'intero team di sviluppo) di incontrarsi (offline / online) con il consulente aziendale e cercare di comprendere insieme il dominio, la visione e quindi fare brainstorming.

2. Formalizzare i requisiti / le storie degli utenti, classificando ognuno:
   a. Priorità (urgenza / importanza)
   b. Scadenza (quanto ben definita - compresa e concordata dalla maggioranza degli stakeholder *)
   c. Complessità (stima approssimativa)
   
   Nella scelta del requisito / storie utente su cui lavorare successivamente, sono stati presi in considerazione tutti e tre i fattori. Se il requisito ha una bassa maturità, aggiungi prima una missione di ricerca, in cui contatta tutti i portatori di interessi, indaga il ragionamento alla base del requisito e definisci meglio il requisito (scrivi casi d'uso e / o crea wireframe e presentali) prima di agire su di essa.

3. Prova a pensare a qualche passo avanti durante la progettazione prima di ogni implementazione: progetta un'architettura flessibile che abbia spazio per accogliere i cambiamenti.

4. Prova ad adattare un processo di sviluppo agile, ad esempio SCRUM o Kanban: questo ti fornirà un kit di strumenti per lo sviluppo di un prodotto con requisiti mutevoli.

Dovresti anche considerare di chiedere ai moderatori di spostare questa domanda su PM.stackexchange.com (segnalandolo), anche se questa domanda si adatta qui, si adatterebbe meglio lì.

(*) Titolari di palo per accordo: business, marketing, project management, sviluppo e QA.