Come gestire e stimare i requisiti non strutturati ricevuti dai clienti


21

Molte volte durante la fase di offerta di un progetto ricevo i requisiti di un sistema software dai nostri potenziali clienti in un formato non strutturato da varie fonti [e-mail, documenti di Word, Excel]. Di solito sono un gruppo di ragazzi di "sviluppo prodotto" dalla parte del cliente che escogitano queste "soluzioni proposte" ai problemi aziendali che hanno. Sebbene siano esperti nel settore aziendale, molte volte non hanno le soluzioni giuste.

Questo risulta in

  • più versioni dello stesso requisito
  • mescolando due requisiti in uno
  • alcune versioni del requisito in seguito, i requisiti che sono stati combinati insieme vengono nuovamente separati, ciascuno portando con sé alcune delle nuove aggiunte

Come lavorate con tali requisiti che entrano e li classificano in casi d'uso adeguati e prima che inizi lo sviluppo? Quali strumenti possiamo usare per tracciare la storia di un particolare requisito, dalla prima volta che è stato concepito fino al momento in cui viene cristallizzato in un caso d'uso adeguato? Stimare il lavoro rispetto ai requisiti ricevuti in questo modo è un incubo che finisce per commettere errori nel comprendere correttamente il requisito e stimare lo sforzo contro di esso correttamente.

Una volta vinto il progetto, i clienti hanno riflettuto maggiormente sulle loro esigenze e sono stati in grado di articolarlo correttamente. Quello che succede in questo caso è che alcune funzionalità vengono eliminate, altre migliorate, altre prendono una svolta completamente nuova. Questo in sostanza può annullare alcune delle stime dell'oggetto di lavoro che sono state fatte prima che il progetto fosse vinto. Sarei interessato a sapere se esiste un sistema con cui possiamo costruire un albero di un requisito particolare e come ogni ramo ha portato a una stima diversa.

Suggerimenti, strumenti, trucchi per rendere questa attività più gestibile? Sto solo cercando di ottenere alcune informazioni da qualcuno più esperto di me nella gestione dei requisiti e nella stima dello sforzo.


1
Qualcuno del tuo team lavora con i ragazzi dello "sviluppo prodotto" per fare analisi dei requisiti (ad es. Un analista aziendale)?
Deco,

Sì, lo faccio in tutti i casi in cui non abbiamo un budget in BA.
user20358

Risposte:


17

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.


4

Vorrei considerare questo come un processo iterativo. Il primo passo è raccogliere i requisiti. Il passaggio 2 è di ordinarli. Il passaggio 3 è di assegnarle le priorità. Il passo 4 è la suddivisione di ciascuno in bit abbastanza piccoli per stimare lo sforzo. Il passaggio 5 consiste nel fondere questi bit in un bucket di sforzo globale (diciamo 84 giorni-persona). Il passaggio 6 è mappare lo sforzo sulle risorse (84 persone-giorni / 2 sviluppatori = 42 giorni).

Quindi adesso sei bloccato tra il passaggio 1 e il passaggio 2. Hai dei requisiti, ma non li hai nella forma che ti serve.

Supponi di avere più versioni dello stesso requisito. Sono essenzialmente gli stessi? In tal caso, scegli quello che sembra essere il più chiaro e usalo. Se variano nei dettagli, scegli quello che sembra essere il più logico e usa quello. Quindi inviare un messaggio al client chiedendo loro di verificare il requisito. Potrebbe essere necessario andare avanti e indietro e il numero di volte per ottenere il requisito giusto. Non arrenderti o scoraggiarti. Molti progetti sono falliti a causa di scarsi requisiti.

Utilizzare il progetto Microsoft per mantenere sincronizzati il ​​lavoro e la pianificazione con le mutevoli esigenze. Se il client richiede una modifica, specifica il lavoro aggiuntivo, inseriscilo nel tuo modello e informa della nuova data. Non farti risucchiare nel credere che puoi semplicemente attirare nuovi sviluppatori a intervalli casuali per recuperare il gioco. La pianificazione deve tenere conto del tempo di accelerazione ogni volta che viene aggiunta una nuova risorsa. Sarai in grado di modellarlo correttamente solo prestando attenzione a ciascun progetto e imparando da esso. Supponiamo che tu abbia portato Bob a bordo del progetto X dopo che stava andando avanti per 4 mesi. Quanto è stato produttivo nel 1 ° mese? Il 3?

È necessario rivisitare settimanalmente il modello di progetto, apportando aggiornamenti ove necessario. Tenere un registro storico delle modifiche. Questo ti aiuterà a fornire stime migliori in futuro.

Doug

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.