it-swarm-eu.dev

Risorsa / consulenza per decidere un processo di progettazione?

Ho discusso con i miei colleghi su quale sia il processo migliore da utilizzare quando progettiamo app Web. Le nostre fasi di sviluppo stanno funzionando bene, ma penso che ci sia spazio per i cambiamenti nella fase di raccolta di progettazione/requisiti.

Sento che dovrebbe esserci una fase per la raccolta dei requisiti, quindi una fase di wireframing, quindi lo sviluppo in concomitanza con la progettazione grafica. Altri dicono che lo sviluppo dovrebbe iniziare immediatamente.

Ci sono risorse o studi là fuori che possono spiegare perché dovresti usare un processo piuttosto che un altro? Sto facendo fatica a cercare di convincere gli altri perché le fasi extra all'inizio ci aiuteranno a lungo termine.

7
wajiw

Avere subito lo sviluppo richiede seriamente problemi. L'ho fatto una volta e me ne sono pentito seriamente.

Il problema principale con questo approccio IMO è che l'organizzazione inizia a impegnare immediatamente le risorse di programmazione e diventa molto riluttante a apportare le necessarie modifiche all'interfaccia utente in seguito perché, vedi, il software funziona "abbastanza bene".

A volte, le regolazioni dell'interfaccia utente sono minori, come ad esempio modificare il layout della pagina o migliorare il flusso di lavoro. Ma a volte, le necessarie modifiche all'interfaccia utente possono essere così estese da richiedere la demolizione della maggior parte dell'interfaccia utente già in atto.

Un esempio è l'aggiunta del supporto per annulla/ripristina. Questa funzione è molto difficile da aggiungere dopo il fatto. È necessario che l'utente possa fornire un feedback visivo all'utente sull'azione annullata. Se alcune delle interazioni avvengono all'interno delle finestre di dialogo o tramite i menu e le modifiche che queste interazioni influenzano non sono visibili sullo schermo, è necessario annullare una buona parte dell'interfaccia utente per renderla più intuitiva.

Ecco solo due motivi per cui l'interfaccia utente dovrebbe essere progettata per prima:

  • Risparmia denaro. Non avere prima capito l'interfaccia utente è quasi una garanzia che un po 'di lavoro verrà svolto due volte. Almeno.

  • Obbliga le parti interessate a comprendere l'ambito del progetto e richiede loro di firmare in anticipo la progettazione dell'interfaccia utente. Ciò contribuirà evitare la featuritis incoraggiando le parti interessate a esercitare moderazione quando si richiedono funzionalità.

Spero che questo possa essere d'aiuto.

7
Hisham

Ciò che generalmente utilizziamo su progetti più grandi in cui lavoro sembra essere efficace (sebbene sia più utilizzato nel nostro negozio Web che nei progetti IT più ampi). Comincio con l'analisi dei bisogni e la raccolta dei requisiti e nient'altro.

Quando ottengo una bozza approvata di requisiti di alto livello (sono un ragazzo UX/PM), di solito ho requisiti che si concentrano su ciò che l'app deve fare, ma non sono la migliore risorsa da completare requisiti tecnici, quindi lo passo sul nostro responsabile dello sviluppo, che esegue requisiti tecnici dettagliati, tra cui pseudo-codice e simili.

Mentre quelli vengono fatti, faccio un primo taglio di wireframe e una specifica di interazione. Sto iniziando a fare più prototipi lo-fi in questa fase, in quanto mi consente di ottenere feedback dalle parti interessate senza modelli dettagliati. Mi permette anche di rivisitare i miei wireframe e apportare eventuali modifiche in base al prototipo lo-fi. Una volta finalizzati i wireframe, la progettazione tecnica dettagliata di solito va d'accordo e possiamo anche finalizzare il pezzo di interazione.

Solo a questo punto in genere dedichiamo del tempo a comps visivi e solo dopo che è stato firmato costruiamo un prototipo ad alta fedeltà. La cosa buona è che, a questo punto, abbiamo completato diversi round di feedback iterativo, ottimizzazione e infine approvazione.

Il nostro prototipo ad alta fedeltà è una rappresentazione abbastanza accurata di come funzionerà la nostra app finale, quindi costruire l'app completa è una fase relativamente breve. Ovviamente, hai quindi bisogno di potenzialmente test alfa, beta e prod e cicli di ottimizzazione, quindi ...

Spero che sia di aiuto.

2
jameswanless

Dato che hai anche chiesto risorse ... Ecco una risorsa che consiglierei di leggere: un libro chiamato Come si progetta? . Forse lo troverai un po 'troppo generale per le tue esigenze, ma l'ho trovato utile quando ho cercato personalmente un buon processo di progettazione/sviluppo.

Fornisce una breve descrizione (per lo più visualizzata) di molti processi di progettazione, a partire da quelli molto generali. I processi di progettazione specifici per la progettazione e lo sviluppo del software (totalmente applicabili alla progettazione di applicazioni Web) occupano la seconda parte, ma consiglierei di controllare anche la prima.

http://www.dubberly.com/articles/how-do-you-design.html

(Il libro sembra essere in "beta" dal 2005 e forse non sarà mai finito ... O forse mi manca qualcosa ed è già pubblicato. Comunque, PDF è gratuito da scaricare.)

2
Anton Strogonoff

Dato che chiedi esplicitamente gli studi (+1 solo per quello!):

Non ho trovato uno studio conclusivo sull'intero processo (ad esempio dicendo "Il 27% delle risorse del progetto speso per la progettazione è ottimale".)

Tuttavia, ad es. Codice completo cita molti studi a supporto di una solida fase di progettazione. Sebbene provenga dallo sviluppo desktop, gli studi sono acquisiti da una vasta gamma di progetti e sono applicabili allo sviluppo web.

La principale linea di attacco è il costo degli errori del progetto: gli errori commessi durante la fase di progettazione costano di più, specialmente se rilevati in ritardo.

(E no, non avere una fase di progettazione non significa che non si possano commettere errori di progettazione. È un peccato, vero?)

2
peterchen
1
ThomPete

Basandoti solo sull'esperienza personale ... non vuoi iniziare un vero e proprio sviluppatore dall'inizio. Né vuoi aspettare di fare qualsiasi progetto o sviluppo fino al termine dei wireframe. La chiave è che tutto deve muoversi in parallelo in modo collaborativo.

Inoltre, ci sono tonnellate di dipendenze ... particolari ambienti di sviluppo, agili contro cascata, complessità del progetto, ecc.

0
DA01