che condensa i requisiti aziendali in specifiche tecniche [chiuso]

Dalla mia esperienza, non avrei speso un singolo minuto di sviluppo. Neanche un piccolo pezzo di codice. In questa fase, in cui il cliente non sa cosa vuole, è molto importante fare un buon lavoro di consulenza . È importante per loro quanto lo è per te.

Dietro ogni progetto, c'è un bisogno (a volte non è ovvio) relativo al business del cliente. Quindi, per chiarire bisogno , devi prima imparare il business il più possibile. Quindi sarai in grado di guidare il cliente verso una soluzione funzionale.

Durante l'apprendimento, fai attenzione al momento di differenziare ha bisogno e desidera . Quale esigenza del cliente potrebbe o non potrebbe essere uguale a quella richiesta dal cliente?

Durante l'analisi, se il cliente non prende decisioni, prendile tu stesso. Come consulente il tuo compito è dare consigli e condurre il processo.

Come ha sottolineato @Ewan, è più facile per i clienti prendere decisioni se c'è qualche scelta da fare. Offrire diverse alternative (esponendo i loro pro / contro), rende più facile il processo decisionale. Creare prototipi è un buon modo per fornire una panoramica di ciò che hai in mente per loro. Il cliente avrà il primo contatto (e sentimenti) su come stanno andando le cose. Facendo questo esercizio di "creatività" vedrai rapidamente le luci e le ombre del progetto prima che diventino un problema.

Cerca di ottenere il maggior numero di feedback possibile dall'utente finale . Così tante volte la persona che chiamiamo "il cliente", non è chi utilizzerà il sistema . In tale situazione, riceverai un feedback migliore dal vero utente finale. Ti forniranno preziosi consigli su ciò di cui hanno bisogno. Identificare bene chi può fornire le giuste risposte alle tue domande ti aiuterà a soddisfare le aspettative del cliente.

Una volta che hai raccolto una buona serie di requisiti, inseriscili nel prototipo. Metodologie agili come SCRUM funzionano bene in questa fase. Fare sprint sul prototipo.

I prototipi verranno scartati / modificati lungo gli sprint. Puoi anche "guidare" il cliente a quello che fa per te. ;-). Alla ricerca di un accordo win-win.

Cerco di impedire ai manager di avviare lo sviluppo prima che i requisiti ben definito e misurabili siano stati firmati. In caso contrario, a partire da requisiti non definiti è destinato a fallire male. Un sacco di soldi e tempo saranno sprecati (senza alcuna garanzia di recuperarli) perché qualcuno ha deciso di implementare "il caos". Il caos e l'incertezza in cui vive il nostro cliente tanto amato e confuso.

È scioccante vedere le aziende i cui dipendenti fanno il loro lavoro ma non sono in grado di spiegare (ragionevolmente) a come . È scioccante anche vedere quanti Project Manager non si preoccupano di questo problema, dicono semplicemente "si a tutti" o "iniziamo e vedremo cosa succede".

Infine, @Ewan ha nuovamente indicato il punto più importante.

Get the customer to sign off on the ones they want and implement.

Non dimenticare di definire chiaramente quali requisiti e condizioni devono essere soddisfatti per poter dire che il progetto è stato eseguito . Le condizioni di accettazione

Non c'è bisogno di dire perché.

Scrivi un documento che proponga 2 o 3 soluzioni sulla falsariga di:

"Per ottenere 'x principale di alto livello' proponiamo 'Soluzione tecnica y' che farà 'cosa soluzione techincal fa'"

Consenti al cliente di disconnettere quelli che desidera e implementare.

È difficile consigliare senza poter giudicare con precisione la musica dell'umore.

In entrambi:

The business users and management aren't doing their jobs and are just kicking the can down the road for the devs to deal with (and so they can kick the devs when things go wrong).

o

They're really not sure what they want and need to be guided by the dev team.

Naturalmente, il secondo scenario è più preferibile. Puoi cablare dei disegni e rotolare nella sporcizia con esso fino a quando non hai un piano di sorta.

Se ti viene distribuito il primo scenario, è assolutamente chiaro che le cose che uccidono i progetti più e più volte sono requisiti lanosi e non hanno il concetto di "fatto". Certo, il progetto verrà fatto alla fine ma quanti soldi saranno stati bruciati prima di allora?

A un certo punto, gli sviluppatori hanno bisogno di una serie di requisiti in cui possono sviluppare un'applicazione e successivamente verificare se soddisfa i requisiti o meno. E poi vanno e costruiscono un'applicazione che soddisfa i requisiti.

Ed è davvero una buona idea avere requisiti in cui un'applicazione che soddisfa i requisiti sia vantaggiosa per il business: -)

Qualcuno deve creare questi requisiti. I proprietari dell'azienda non possono. Gli sviluppatori non vogliono. Gli sviluppatori hanno cercato di far sì che i proprietari del business creino i requisiti ma non ci sono riusciti. Tuttavia, qualcuno ha bisogno di creare questi requisiti.

Puoi provare a trovare qualcuno in azienda e farne il suo lavoro. Non come gli sviluppatori all'inizio, cercando di chiedere dei requisiti ma fallendo, ma scegliere una persona e farne un lavoro a tempo pieno. Se il team di sviluppo ritiene di poter creare i requisiti, consigliarlo alla società e assegnargli il lavoro e l'autorità per farlo.

In ogni caso, sarà compito di qualcuno creare i requisiti. E bisogna chiarire che se il team di sviluppo crea i requisiti, i requisiti sono ciò che otterrà l'azienda e, se non gli piace, devono assicurarsi che i requisiti vengano modificati. È meglio farlo prima che inizi il lavoro di sviluppo.

E non è necessario dare alle persone scelte. Puoi dire loro che ciò che è nei requisiti è ciò che accadrà e possono firmarlo o lamentarsi e i requisiti possono essere modificati.

Se ritieni che un prototipo sia troppo lucido e confonderai il cliente, basta tratteggiare. Puoi avere più versioni se ritieni che ciò possa aiutare il cliente.

Ciò soddisferà la necessità del management di fare cose senza creare un mucchio di codice che getterai via (se sai cosa è giusto per te.)

Il cliente deve anche sapere che devono pagare per questo tipo di cose. Altrimenti, c'è poco incentivo a farli muovere sul progetto. Può essere utile agli incontri se si riescono a restringere quelli che sono realmente coinvolti nel progetto e il processo decisionale senza che molte persone lancino i loro suggerimenti inutili che rallenteranno solo le cose.

Facciamo un esperimento mentale: immagina di voler costruire una casa da zero, e non sai nulla della costruzione. Come descrivi i requisiti per il costruttore? Anche se fosse possibile, sarebbero probabilmente affermazioni vaghe come "Voglio essere sicuro di avere un sacco di spazio nell'armadio" e "Voglio una cucina moderna" . Ovviamente non ci si può aspettare che sappiano tutti i dettagli: l'architetto che disegna i piani ti farà molte domande e prenderà le decisioni da solo secondo le migliori pratiche del settore.

Questo è il punto in cui ti trovi: qualcuno ha deciso di volere qualcosa, ma hanno difficoltà a spiegare esattamente quello che vogliono per te. È il tuo lavoro lavorare insieme a loro per capirlo.

Se c'è una risorsa disponibile e hai principi di alto livello, inizia a scomporre quei principi in user story. Da lì puoi trovare una lista di compiti da fare. Fai suggerimenti lungo il percorso, ma assicurati di comprendere prima di tutto le esigenze aziendali dell'aggiornamento. Le prestazioni sono scadenti? È insicuro? Il design è obsoleto? Spetta a te gestire molti dei dettagli di cui i tuoi utenti finali non sono a conoscenza. Documenta le scelte che hai fatto e perché e chiedi agli utenti aziendali (o alla persona applicabile) di firmare. Ora hai i requisiti!

Ricorda che uno sviluppatore non ha bisogno di essere codificato tutto il tempo: dovrebbero pianificare anche una parte significativa del tempo. Alcune delle competenze software più importanti che uno sviluppatore può derivare da questo processo di prendere vaghe "idee di business" e trasformarle in un progetto di lavoro, che produce un prodotto che si adatta alle esigenze aziendali.

Costruire un prototipo è una grande idea per ottenere un feedback specifico che porterà a requisiti migliori. Mantieni la luce e semplice: ci sono strumenti là fuori (ecco uno ) che ti permettono di costruire modelli di lavoro senza scrivere una singola riga di codice .

Also a basic prototype can often be misinterpreted by business users ...

Certo che può: ecco perché la comunicazione è così essenziale. Spiega che si tratta di un prototipo più e più volte. Slap una filigrana che dice 'DRAFT' su di esso, qualunque cosa. Gli utenti business, specialmente quelli che non sono esperti di tecnologia, avranno un tempo incredibilmente difficile semplicemente dandoti dei requisiti, specialmente se non c'è niente da vedere. Se riesci a trovare rapidamente un prototipo con cui giocare, sarà più facile per loro dire "Preferisco questo oltre quello" quando lo vedi.