verifica dei requisiti dell'utente, howto?

Utilizza lo sviluppo iterativo che ti obbliga ad avere feedback frequenti al cliente / utente.

Aumenta anche la collaborazione tra sviluppatori e utenti rimuovendo intermediari (di solito inutili) come project manager o persino analisti aziendali (quest'ultimo può essere molto richiesto in domini aziendali molto complessi).

Questo è solo un paio di raccomandazioni. C'è molto da dire sull'argomento.

Ti consiglio vivamente di dare un'occhiata a Scrum . Che mi ha salvato la vita.

Inizia evitando di eliminare le sostanze intermedie come gli analisti aziendali, perché sono effettivamente addestrati in questo. Se non hai queste persone, accetta che almeno uno dei tuoi sviluppatori abbia bisogno di sviluppare questa abilità.

Successivamente, col passare del tempo, accumula una serie di istinti sui tipi di cose che spesso le persone chiedono in ritardo nei progetti, e li portano in conversazione all'inizio del progetto. "Lo sconto sarà sempre lo stesso per tutti gli ordini o varia in base al cliente?" "Ogni utente può vedere tutti i report o solo alcuni per supervisori?" "L'imposta sulle vendite è sempre la stessa o dipende da dove si trova il cliente?" e così via.

Inoltre, prova a scrivere il tuo codice in modo che sia isolato da questi tipi di modifiche in ritardo, perché alcuni arriveranno ancora in ritardo, a prescindere da cosa. Se nella gestione dei clic sono presenti logiche di business per i pulsanti, queste modifiche fanno davvero male. Se hai una logica di business in una classe specifica il cui nome ti rende facile trovarla, puoi sfruttare il polimorfismo per, ad esempio, avere ordini regolari e ordini urgenti e ogni ordine calcola le proprie spese di spedizione, quindi il cambiamento che hanno chiesto è molto meno doloroso.

Non puoi impedire modifiche in ritardo. Le leggi cambiano, i business driver (i clienti, le vendite promettenti, la grande idea che l'amministratore delegato ha nel leggere qualcosa sull'aereo) cambiano. Prevenire ciò che puoi e abbracciare il resto progettando il tuo codice per essere modificabile.

Devi solo assicurarti di soddisfare i criteri elencati qui. Ad esempio, se dice "la funzionalità x dovrebbe essere disponibile per tutti gli utenti", assicurati che sia vero.

All'inizio del processo di sviluppo questo sarà difficile ma più vicino alla scadenza più dovresti essere in grado di verificare.

Forse le cose che non hai ancora implementato, puoi verificare che siano nelle considerazioni di progettazione in modo da sapere che sono state prese in considerazione durante lo sviluppo iniziale.

Ricordo di essere stato in un incontro di lavoro e di avere uno degli analisti di business che diceva che dev'essere bello essere uno sviluppatore che ha sempre una specifica fissa su cui lavorare.

Nel mondo reale, ci sono alcune cose che sono di grande aiuto in questo. Il primo è accettare che questi dettagli dell'ultimo minuto siano un dato di fatto. l'unica specifica completa al 100% del prodotto finale è il codice sorgente. Se il cliente ha già questo, allora non hanno bisogno che tu lo scriva, vero?

La seconda cosa da fare è provare attivamente a eliminare i dettagli delle specifiche mancanti. ora potresti provare a far firmare al cliente 300 documenti Use Case e altri meccanismi contrattuali, ma alla fine, posso dire con sicurezza al 100%, il modo migliore è consegnare software ai tuoi clienti. Chiedi loro di esaminarlo, usarlo, incoraggiarli attivamente a cambiare le specifiche in base alle loro esigenze (e quando è opportuno caricarle per il lavoro). Anche quando sono implementate solo alcune delle funzionalità, il feedback dei clienti è fondamentale.

Il terzo, quando leggi le specifiche, pensa a cosa causerebbe la modifica di questo requisito e come potresti gestire le variazioni. spesso non è saggio sovra ingegnerare per modifiche che potrebbero non apparire, ma avere un piano, e altrettanto importante non progettare in difficoltà extra renderà la vita molto più facile - e i punti extra per mantenere la calma e avere fiducia quando dici 'possiamo gestirlo da ... e ci vorranno circa 4 giorni per fare'. ispirerà gli altri ad avere fiducia in te.

Penso che non devi dimenticare l'altro lato. Per qualsiasi utente è difficile produrre un elenco completo di dettagli di ciò che si desidera. Pensa a te stesso, pensi sempre a cose nuove.

È incredibilmente difficile trovare tutti i requisiti e i dettagli di qualcosa su cui hai solo una vaga idea. Non credo che nessuno possa.

Ho un libro qui degli anni '70 chiamato "perché i progetti software falliscono". Quando leggo sui blog e ricevo riviste IT, leggo sulla copertina "perché i progetti software falliscono". E quando paragono i contenuti del libro con quelli attuali ... nulla è cambiato. Sviluppo iterativo: sì molte varianti e aiuta a un certo livello. Ma dopo tutto questo tempo i contenuti delle riviste hanno le stesse copertine. Se non mi credi vai a scavare un po 'di magz dal passato e vedi come puoi copiare e incollare il testo sull'ora.

Questo problema non è risolvibile sul lato IT. Abbiamo inventato nuovi strumenti, processi, liste di controllo, schemi di analisi dei requisiti, casi d'uso (aziendali), framework di sviluppo, BPM, SOA, lo chiami e ancora lo stesso problema esiste ...

È necessario ottimizzare questo intorno a "specificatore dei requisiti". Quindi devi dare a quelle persone gli strumenti adeguati, qualunque cosa consenta loro di portare il loro livello più alto:

Quindi ad es. per queste persone: modelli specifici fuori dagli schemi, input da altri progetti e aziende che fanno lo stesso copiano i loro requisiti e le loro lezioni, portano persone che sono passate attraverso la terra e possono aiutare questa persona a specificare le cose che hanno causato i problemi più grandi e non sono "banali" ma possono essere appresi solo dopo averlo fatto (ad esempio consulenti tecnici senior che fanno le stesse cose in altre aziende), dare a queste persone strumenti per compositore, assicurazioni, banche, telco, ecc ...: non inventare i propri processi acquistare i processi generici fuori dalla scatola, ecc ... hanno BISOGNO di strumenti come lo sviluppatore ha bisogno di strumenti e schemi e strutture.

Non lo risolve ma migliora in modo significativo IMHO il miglioramento dovrebbe essere intorno a quell'area e non più tardi lungo la strada.

Proprio come uno sviluppatore queste persone cercano solo di fare il meglio che possono. Ma a differenza degli sviluppatori per il loro campo, la maggior parte delle cose che diamo per scontate dopo 30 anni non è nemmeno presente in quel campo. In generale i loro strumenti sono outlook, excel, word e una board. I loro processi sono sessioni di brainstorming. Un grande miglioramento può essere fatto in questo campo. Ovviamente il problema è soprattutto che sono seduti "fuori" dall'IT quindi anche i piani del CIO per migliorare la situazione in quel campo cadono nel vuoto ... ma questa è un'altra domanda: come "vendere" questo.

Devi far sapere agli utenti che più tardi un "requisito" è identificato nel progetto, più costerà. Possono decidere che non hanno davvero bisogno del cambiamento dopo tutto. Se insistono sulle modifiche, ma rifiutano i costi aggiuntivi / tempo di ritardo, hai un problema che deve essere negoziato. Questo non verrà risolto tramite la tecnologia o la pianificazione, ma dalla vendita e dalla gestione delle relazioni con i clienti.

Ottenere costantemente software funzionante di fronte a loro E richiedere loro di fare lo sforzo di usare / testare / valutare è la soluzione migliore. Non comprenderanno appieno contratti, specifiche, diagrammi e storie degli utenti.

Questo fa parte del test di Joel. Prendi qualcuno che puoi trovare per testare il software il più possibile durante l'intero processo di sviluppo.

Se vuoi veramente fare il lavoro giusto, prima di iniziare a lavorare sul codice o di progettare un'architettura, siediti con alcune delle persone che saranno gli utenti del tuo codice (non la loro gestione o qualsiasi altro stakeholder di livello superiore) e portali a mostrarti come fare il loro lavoro. Idealmente, in realtà, fare il lavoro per un giorno o due. Questo ti darà una comprensione del modo in cui funziona il sistema attuale e del tipo di persone che lo stanno facendo. Ti mostrerà anche le frustrazioni che hanno con il sistema attuale e le cose che stanno colpendo la loro produttività. Hai bisogno di ascoltare tutti i mali e i fastidi quotidiani, il che potrebbe significare che devi fare ciò che è necessario per assicurarti che il loro feedback si interrompa con te o il tuo team di progettazione, se l'idea di trasmettere le loro opinioni agli altri membri della loro organizzazione è probabilmente per inibirlo.

Per ogni gruppo di utenti è necessario avere qualcuno che lavorerà allo sviluppo di quella parte del software facendo la stessa cosa. Quindi puoi incontrarti e discutere di ciò che hai imparato nei ruoli che hai visualizzato per vedere se ci sono aree di crossover e come puoi rendere le cose più facili per tutti.

Non suggerisco che questo sostituisca altri processi di raccolta dei requisiti, ma è un supplemento che ti consente di capire di cosa hanno bisogno gli utenti reali dal tuo sistema. Qualunque sia il tipo di gestione che pensa di cui hanno bisogno, è probabile che i manager e gli analisti aziendali non saranno gli utenti effettivi del sistema, ma se riesci a far funzionare bene il sistema per quegli utenti, li renderà più produttivo, rendendo felici i manager e facendo apparire buona la tua azienda.