Come gestire le frequenti modifiche ai requisiti?

Se possibile, prendi la conversazione che ti viene inviata per e-mail e trasformala in un documento dei requisiti. Elencare le attività che è possibile ricavare da esso e ordinarle in base a ciò che si percepisce come priorità e assegnare una stima a ciascuna di esse. Quindi chiedi quali funzionalità desiderano per la prossima versione.

Fondamentalmente, forzare una sorta di ciclo di feedback in cui la direzione è consapevole di cosa si sta andando a costruire. Scrivi i tuoi documenti dei requisiti fino al momento in cui ricevono il messaggio.

Schede storia

Penso che la tua situazione si adatti bene all'introduzione di storie di utenti . Sono davvero d'aiuto 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 è fattibile.

Nel mondo reale, i requisiti cambiano di routine. Sul lato positivo, lo scoprirete prima di completare la costruzione del software e di distribuirlo - avete un ciclo di feedback molto stretto da parte dell'utente diretto del software, che in realtà è ottimo.

Sembra che il problema più grande qui sia il modo molto ad hoc con cui viene gestito il cambiamento. Hai ciò che Agile / Scrum considera un "product owner", che fornisce feedback, ma il processo è scarsamente documentato e scarsamente pensato.

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

Quindi, invece di avere questo processo ad-hoc, mirare a trasferirsi in un mondo in cui hai una relazione più stretta e più utile con il "consulente aziendale" e in cui tutti sono sulla stessa pagina in merito ai risultati delle modifiche stanno discutendo.

Il tuo attuale processo rende troppo facile a queste persone solo un brainstorming di idee senza protezione per le risorse e il denaro che questo consuma. Se vogliono tutte queste funzionalità, devono ottenere un po 'di "skin in the game".

Prendi l'e-mail della conversazione e inseriscila in una sorta di applicazione di tracciamento di funzionalità o bug, anche se si tratta solo di un foglio di calcolo. Invia le nuove aggiunte al consulente aziendale e chiedigli di firmare ogni articolo o fornire correzioni. Insieme all'abbonamento, dovrebbero dare la priorità (quali volete prima?)

Dopo l'approvazione, rispedisci la tua pianificazione su quando gli elementi saranno completati per il test e convincili a impegnarsi a tempo per eseguire il test / l'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 sudato codice.

Indietro. I responsabili devono vedere quanto costano queste richieste.

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

Le persone che sono frustrate dalle modifiche dei requisiti sono spesso valutate dal modo in cui gestiscono ogni cambiamento. Questa metrica di "numero di modifiche gestite in modo adeguato" è probabilmente la fonte del tuo vero problema. Considera di discutere di migliori metriche con il tuo capo. Quando affronto requisiti in costante evoluzione, mi sforzo di scrivere contenuti che mi consentano di adattarmi a requisiti in costante evoluzione. 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ù economici, e raccolgono i frutti nel tempo. Se è ancora troppo pazzo, potrei persino scrivere uno strumento per scrivere strumenti!

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

Una volta che sono stati identificati requisiti sufficientemente importanti, chiedi a loro la persona che si trova in Project Owner di ruolo e li blocchi 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. Ad esempio, se per settimana puoi produrre un lavoro di 16 punti e hai 16 punti di lavoro, allora sei pienamente utilizzato per quella settimana. (Il concetto di punti deriva da flusso di lavoro agile)

Se i cambiamenti arrivano nel mezzo della settimana, pronuncia queste parole magiche:

I can do [this new feature], [this new change], [etc], but what do you not want done?

Cioè, sei una risorsa limitata, puoi solo occuparti di così tanto lavoro. Se arriva un nuovo elemento di lavoro, ti è consentito essere la risorsa limitata che sei e assegnare punti al nuovo oggetto e rilasciare / cambiare altri elementi al posto di questa nuova modifica del coming-in. Ricalzializza la tua lista di iterazioni insieme al proprietario del progetto e dovresti essere più bravo nel gestire il cambiamento.

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

La frase "I requisiti cambiano" a volte viene abusata dalle persone IT. Quello che stai descrivendo è in realtà un cambiamento dei requisiti, ma ciò potrebbe essere dovuto al fatto che uno o più dei seguenti (non so abbastanza del tuo caso, quindi potrebbe essere o non sia applicabile):

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

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

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

4. Chiedendo alla persona sbagliata di eseguire uno o più ruoli non sono necessariamente formati per i ruoli di analista aziendale o di analista di sistema.

5. Prototipazione limitata.

6. L'ipotesi / paura che debba essere eseguita rapidamente e se non la sua IT da incolpare.

A meno che uno indirizzi correttamente tutto quanto sopra, la relazione tra IT e business / utente finale sarà stressante. Si prega di notare 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 questa lista dovrebbe farti andare.

Penso che dovresti avvicinarti a questo da poche direzioni:

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

2. Formalizza i requisiti / storie degli utenti, classificandoli ognuno:
   un. Priorità (urgenza / importanza)
   b. Maturità (quanto è ben definito - capito e concordato dalla maggioranza dei soggetti interessati *)
   c. Complessità (stima approssimativa)
   
   Quando si sceglie quale requisito / utente storie su cui lavorare in seguito, tenere conto di tutti e tre i fattori. Se il requisito ha una bassa scadenza, aggiungi una missione di ricerca prima di esso, in cui contatti tutte le parti interessate, analizza 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 esso.

3. Prova a pensare alcuni passi avanti durante la progettazione prima di ogni implementazione - progetta un'architettura flessibile che abbia spazio per adattarsi alle modifiche.

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

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

(*) Titolari delle azioni per accordo: affari, marketing, gestione dei progetti, sviluppo e controllo qualità.