I requisiti cresceranno e cambieranno. Non penso che nessuno possa discuterne.
Come raccogliere ed elaborare le richieste in arrivo .
Nella mia esperienza, aiuta a raccogliere requisiti se esiste un gruppo singolo o molto piccolo di clienti che funge da filtro per la consegna di requisiti nuovi o aggiornati a un piccolo gruppo di pianificatori di sviluppo. Chiunque dalla loro parte può proporli o scriverli, ma la consegna dovrebbe avvenire solo in pochi. Meno persone sono coinvolte nello scambio da una parte all'altra, meglio è.
Lo scopo di filtrare attraverso un gruppo più ristretto di persone non è quello di scartare o diminuire lo sforzo e le informazioni che gli altri mettono, anche se duplicati o apparentemente non importanti in superficie, ma limitare i punti di fallimento: informazioni perse o mal gestite. Segue un principio simile allo scopo dell'incapsulamento e delle interfacce: proteggere i dati privati e stabilire un protocollo comune per la gestione di richieste simili. Vorrei ribadirlo: l'invio di duplicati è ok. Come pianificatore, ciò che mi dice che cosa stanno parlando o proponendo è importante. Salva o registra tutto.
Come tenere traccia e organizzare i requisiti
A breve termine, passa a bassa tecnologia
Ovviamente ci sono soluzioni a bassa tecnologia che possono essere efficaci in larga misura nell'organizzazione e nel monitoraggio dei requisiti in arrivo: lavagne, sticky, posterboard, che cosa hai. Questi possono essere ottimi per la pianificazione a breve termine. Sono altamente visibili, accettano la notazione a mano libera e sono facili da "riconfigurare".
A lungo termine, utilizzare uno strumento software ricercabile, ordinabile e collegabile
Per sforzi a lungo raggio, un qualche tipo di software sarebbe prezioso. Esistono strumenti di gestione dei requisiti specializzati: Porte, Clearcase / Clearquest e molti altri. Questi strumenti altamente specializzati sono ottimi in quello che fanno, ma spesso sono eccessivi. A volte anche un semplice vecchio foglio di calcolo è più che adeguato. Personalmente trovo i sistemi di tracciamento dei problemi generali abbastanza utili per raggiungere questo obiettivo, e in questo momento il mio preferito è Redmine, ma altri sono sicuro che andrebbe bene anche.
Con un sistema di tracciamento dei problemi, chiunque scegli di consentire può creare un "nuovo problema" o un requisito e aggiungere qualsiasi dettaglio che ritenga opportuno includere. Possono osservare il problema e fornire feedback a qualsiasi azione intrapresa con esso. Puoi ri-categorizzarlo, regolare la priorità, riscrivere il corpo, allegare informazioni supplementari, associarlo ad altri "problemi", promuovere a un livello superiore funzionalità o "caso d'uso" o storia o qualsiasi terminologia adatta al tuo sistema, fino alla nausea. In altre parole, puoi fare molto per creare un elenco correlato di requisiti tracciabili, ordinabili, prioritari e attenti alla storia. Inoltre, essendo abbastanza configurabile immediatamente e open-source, se lo strumento non è esattamente ciò di cui ho bisogno o che desidero in qualsiasi momento, posso cambiarlo abbastanza facilmente per adattarlo meglio alle esigenze del mio processo.
Una nota finale sugli strumenti, alcune persone con cui ho parlato hanno molto successo usando file di testo semplici in un sistema di gestione delle modifiche e di versioning. Ovviamente ottengono i vantaggi delle versioni storiche. Utilizzano inoltre il sistema operativo di base e strumenti supplementari per trovare, collegare e catalogare i requisiti. Non sono in grado di aggiungere altrettante meta informazioni strutturate e correlate, ma non sentono di averne bisogno e per i loro sforzi non aggiungono abbastanza valore. Questo potrebbe essere o non essere il tuo caso. Il vantaggio è che potenzialmente sono pochi software in meno nello stack di sviluppo da gestire e mantenere.
Requisiti di kickoff per lo sviluppo post contratto / post progetto
L'aspetto finale della domanda è come gestire i requisiti dopo l'inizio di uno sforzo. Penso che ci siano due pensieri principali su questo, e parte del modo in cui li gestisci dipende dalla natura del tuo rapporto con il cliente: in primo luogo, se sotto contratto a un valore fisso, i requisiti che insorgono dopo l'aggiudicazione del contratto possono essere incorporati. L'implicazione è che possono cambiare l'ambito dello sforzo, quindi il tasso o la fattura saranno più alti quando quegli articoli extra vengono consegnati e accettati; a meno che un importo equivalente di sforzo non sia rimosso dalla proposta accettata. Se si intende cambiare l'ambito di applicazione, è necessario assicurarsi che il cliente comprenda e accetti le conseguenze, altrimenti dovranno essere presentate le domande tardive.
In secondo luogo, per i nuovi requisiti che insorgono dopo che il contratto è stato assegnato e il contratto è più orientato verso un tempo e uno sforzo materiale (qualunque cosa sia necessaria per completare il lavoro svolto), puoi e dovresti essere un po 'più flessibile se il il cliente insiste per includerlo durante quel particolare passaggio. Verrai pagato indipendentemente dal fatto che tu lo includa o meno, a condizione che tutto ciò che dici che farai venga completato.
Se non hai familiarità con loro, potresti voler esaminare un approccio Kanban e metodi Agile. Queste tecniche possono aiutare a focalizzare l'attenzione sulle preoccupazioni immediate, senza necessariamente perdere di vista gli obiettivi di sviluppo a più lungo termine.
Presentare le opzioni come scenari "what if" e dare al cliente una scelta e una decisione
In entrambi i casi, una stima "what if" è una buona strategia da utilizzare quando si negozia con il cliente e il proprio team. Costruire un confronto fianco a fianco delle attività, dei loro costi e del programma come previsto, con una colonna che mostri le stesse informazioni per gli approcci alternativi. Microsoft Project è probabilmente un buon candidato per farlo poiché puoi costruire stime diverse basate su una serie di attività sostanzialmente simili.
Tuttavia, anche un foglio di calcolo di base è spesso altrettanto efficace per dimostrare in che modo modifiche o inclusioni specifiche potrebbero influire sul costo e sulla pianificazione. Un elenco in questo caso è probabilmente altrettanto efficace di un albero nel dimostrare le differenze. Lo strumento e il metodo scelti per costruire questi scenari dipendono in gran parte dalle dimensioni del progetto e del personale (ma anche il software A triplo come MS Project ha i suoi limiti di utilità e capacità).
Considera questi scenari ipotetici come elementi di lavoro interni e salvali per la durata del progetto. Erano dimostrazioni fondamentali nel processo decisionale e negoziale. Potrebbe anche essere necessario rivederli o ripeterli per un giro successivo di what ifs.
Quando si preparano scenari ipotetici, una spiegazione supplementare di pro e contro da una prospettiva tecnica o di implementazione (in termini semplificati) potrebbe essere utile per aiutare a giustificare il motivo per cui un'alternativa avrebbe un impatto così significativo.