L'approccio giusto per progettare un'applicazione Web (software di progettazione, non grafica)

Question

Recentemente ho ricevuto richieste da potenziali clienti per applicazioni Web molto complesse.
Volevano che scrivessi una specifica prima che inizino le opere "reali".
Le specifiche, come vedono, dovrebbero essere solo parole che descrivono l'app e DB.
Dove ho trovato l'approccio migliore è quello di "dipingere" o "costruire" un prototipo degli schermi che l'applicazione avrà (html è più facile quindi scrivere un libro, soprattutto se si utilizza WYSIWYG solo per questa fase ... gli standard non sono importante a questo punto).

Quando si dispone di uno schermo di fronte ai tuoi occhi, diventa immediatamente chiaro quali elementi dovrebbero essere (gallerie calendario/foto/ciò che i principali collegamenti, di ricerca di dialogo, ecc)

Quindi, mi sbaglio nel mio approccio? Oppure i clienti sono male informati sul modo corretto di fare le cose?

Answer 1

Mentre sono d'accordo sul fatto che è necessario avere un ampio accordo in merito all'ambito e al costo del sistema in costruzione, penso che sia comprensibile pensare che sia possibile speci care un sistema prima di inserirlo nel sistema. le mani del cliente. Come hai scoperto, il cliente molto spesso non sa cosa vuole fino a quando non lo vede. Un modo per affrontare questo è con i modelli, come sei abituato a fare. Li uso anche durante la progettazione e la pianificazione.

Molto spesso, tuttavia, è necessario portare il prodotto reale nelle mani del cliente per ottenere l'inevitabile feedback su ciò che funziona e cosa no. Farai meglio a farlo prima piuttosto che dopo, poiché i cambiamenti che si verificano in ritardo nello sviluppo sono molto più difficili e costosi, almeno nei metodi tradizionali. Utilizzando un metodo agile che fornisce software di lavoro precoce e spesso, unitamente a una pianificazione e documentazione sufficienti, si ottiene un feedback migliore dei clienti rispetto all'iterazione di una serie di specifiche per un prodotto che il cliente potrebbe scoprire che non desidera (o almeno desidera modo in cui hanno detto).

Suggerirei di aver bisogno di alcuni documenti che delineano, in generale, lo scopo del progetto. Basta così che tu possa essere d'accordo su cosa fa parte del sistema e cosa no. Se stai costruendo un'applicazione per la gestione dell'inventario, non dovrebbero aspettarsi di ottenere anche un sistema di gestione delle relazioni con i clienti, ad esempio. Quindi, applica tecniche dai metodi di sviluppo agili per, in modo leggero, traccia la funzionalità desiderata e ottenere un codice funzionante nelle loro mani il più presto possibile e su base regolare in seguito. Ciò richiederà la fiducia di tutte le parti, quindi potresti voler iniziare con piccoli progetti e scadenze e costruire tale fiducia.

Answer 2

Ognuno ha un approccio diverso allo sviluppo del software. Il tuo metodo è tanto valido quanto quello del tuo cliente. Tuttavia, poiché il tuo cliente è quello che ti paga, ti suggerisco di conformarti ai loro standard OPPURE di suggerire il tuo metodo e vedere come reagiscono.

Answer 3

La specifica è la parte più importante (la più lunga da fare) del progetto. Ti dice (e il tuo cliente) cosa stai costruendo e quello che ti pagano per.

Non c'è niente da fare con la costruzione e quindi trovare il cliente aveva un'idea diversa in mente. Le specifiche assicurano State leggendo tutti dallo stesso libro. Anche raggruppare alcune idee della GUI è una buona idea.

In conclusione, sia voi che il cliente dovete sapere cosa aspettarvi prima che il lavoro abbia inizio. Le schermate e i modelli devono essere parte di una specifica più ampia

Il tuo approccio sembra un po 'rotto per una grande applicazione. Le loro aspettative mi sembrano corrette.

Answer 4

Uso i prototipi di schermo in Balsamiq. Dimostra l'aspetto utente generale l'esperienza, senza ottenere lato monitorati con l'estetica del design

Answer 5

Potreste trovare i seguenti articoli utili nelle comunicazioni:

• The Iceberg Secret, Revealed
• Painless Functional Specifications - Part 2: What's a Spec?
• Painless Functional Specifications - Part 3: But... How?

Ricorda che puoi ancora prendere in giro l'HTML per te stesso se ti aiuta a pensare a il riposo. In larga misura, il design HTML sarà quindi la tua decisione.

Personalmente, sono un fan di FIT e Fitnesse per le specifiche. Rendono entrambi più facile tenersi aggiornati e includono alcuni test per verificare che il codice soddisfi le specifiche.

L'altra cosa da ricordare è che di regola il cliente non sa esattamente cosa vogliono, quindi anche con una specifica completa non lo consideriamo completamente risolto.

Answer 6

L'interfaccia utente non è la parte più importante dell'app, concentrandosi su questa parte così presto potrebbe portare a false ipotesi e imporre scelte basate sull'interfaccia, non sulla funzionalità.

Suggerisco di concentrarsi prima sulla funzionalità, al fine di concordare cosa si prevede di fare l'app, non come apparirà sullo schermo. L'interfaccia cambierà nel tempo, il client vorrà questo pulsante a sinistra non a destra, blu colorato, non giallo, questa casella di testo più grande e un font diverso, questi sono i dettagli per dopo, se fornisci un'interfaccia con le specifiche si rischia di discutere quei dettagli minori invece delle funzionalità importanti.

Dai un'occhiata a Applying UML and Patterns, penso che potrebbe essere utile. Anche uno dei libri della serie "Extreme Programming" è stato bello, vedrò più avanti quale sarà esattamente.

Answer 7

Si consiglia di dare un'occhiata alle risposte alla seguente domanda, anche se la domanda è per medie dimensioni, potrebbe ancora essere piuttosto complicato:

What are the basic questions to ask a person who wants his Medium sized website done?

Avete chiesto il cliente perché diagrammi o le schermate del prototipo sono scoraggiate? Possono avere le proprie ragioni per questo, come cercare di limitare la quantità di lavoro svolto prima che inizi il lavoro "reale". Come idea, non è così male supponendo che abbiano già fatto delle specifiche con altri prima e si sentano a loro agio con quel processo. Se questo è nuovo per loro, allora può valere la pena discutere perché vuoi avere quei prototipi, ad es. a volte le parole sono aperte all'interpretazione e questo è più facilmente risolto con un'immagine rispetto alle migliaia di parole che l'immagine mostra facilmente.

Answer 8

In primo luogo, la terminologia è errata. Nel titolo della domanda si chiede "Il giusto approccio a design un'applicazione web" - ma nota: il tuo cliente ti ha chiesto di scrivere specifiche per l'applicazione.

Le specifiche non sono uguali. È pericoloso cercare di identificarli.

Come ha detto un altro addetto stampa, una specifica è tale che sia tu che il tuo cliente conoscete che cosa state costruendo. Il design è l'arte di come per costruirlo.

Le specifiche generalmente non includono i modelli. In poche parole, includono dichiarazioni che descrivono esattamente cosa dovrebbe fare il software . Si noti che questo è molto diverso da come dovrebbe farlo. Per le applicazioni web, direi che i mock-up dovrebbero essere fatti in fase di progettazione. Quindi sì, per rispondere alla tua domanda, non sei corretto nel tuo approccio.

Suggerisco di guardare su this article su Wikipedia per ulteriori informazioni su quale sia una specifica.

Edit: Mentre ciò che ho detto è tecnicamente corretto, come sottolinea tvanfosson, è difficile a spec completamente fuori di un sistema prima di iniziare lo sviluppo. Vi consiglio di leggere lo his answer e di parlare con i vostri clienti dell'adozione di un approccio più realistico.