Come convinci il management a buttare via un prototipo?

Utilizza uno strumento come Microsoft SketchFlow o crea il tuo prototipo in qualche altra lingua o piattaforma, rendendo quasi impossibile per integrare nello sviluppo principale.

C'è anche un saggio joelonsoftware sulla visualizzazione di screenshot e prototipi, in cui gli aspetti non implementati e non funzionanti appaiono ovviamente interrotti / non implementato, chiarendo dove il lavoro deve ancora essere fatto.

Important Corollary Two. If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.

...

What can you do about this? Once you understand the Iceberg Secret, it's easy to work with it. Understand that any demos you do in a darkened room with a projector are going to be all about pixels. If you can, build your UI in such a way that unfinished parts look unfinished. For example, use scrawls for the icons on the toolbar until the functionality is there. As you're building your web service, you may want to consider actually leaving out features from the home page until those features are built. That way people can watch the home page go from 3 commands to 20 commands as more things get built.

Quindi, prova a creare i tuoi prototipi in Photoshop anziché in Visual Studio, o qualcosa del genere.

Non creare prototipi con codice funzionante. Prototipo con carta e penna o un software equivalente .

L'utilizzo di Mockups sembra un disegno, ma poiché è digitale, puoi modificare e riorganizzare facilmente. I team possono creare un design e iterarlo su di esso in tempo reale nel corso di una riunione.

L'uso della carta ha il vantaggio che i membri del team possono facilmente entrare e tutti capiscono che è solo un foglio di carta bianco. Questo lo rende meno prezioso.

Non compromettere mai la qualità del tuo codice.

La scrittura di codice spazzatura è una falsa economia.

Come altri posters hanno suggerito che puoi ottenere questo risultato utilizzando strumenti specifici per i mock up.

Tuttavia, ci sono diversi motivi per costruire prototipi. A volte puoi mostrare ciò di cui hai bisogno senza scrivere codice, ma spesso non è così. Uno stakeholder potrebbe volere che tu dimostri la fattibilità tecnica di una funzione.

Costruisci la cosa più snella che puoi per dimostrare la funzionalità / dimostrare il concetto. Lascia fuori qualcos'altro.

Per una caratteristica dell'interfaccia utente, assicurati di non sviluppare nulla sul server - non toccarlo affatto. Sviluppa nuovamente i mock / falsi integrati.

Se hai bisogno di fare sforzi per rendere l'interfaccia utente conforme allo stile del resto dell'applicazione, non preoccuparti. Se sembra abbastanza buono senza alcuno sforzo, cambia i colori per farlo risaltare, o forse anche una filigrana per mostrare che si tratta di un prototipo.

Ho scoperto che i responsabili più probabili della trasformazione dei prototipi in codice di produzione sono addetti alle vendite. Venderanno il tuo prodotto a un nuovo cliente - senza questa nuova funzionalità, il cliente non avrebbe firmato. Non puoi biasimarli, hanno obiettivi. Stai attento con loro; assicurati che non ti portino via le cose che indicano che si tratta di un prototipo. Devi stare in piedi - probabilmente non dovrebbero essere i clienti fuorvianti comunque.

La tua gestione potrebbe iniziare a costringerti a trasformare un prototipo in codice di produzione pezzo per pezzo, se hai seguito il mio primo consiglio di non scrivere mai un codice scadente, non ci dovrebbero essere problemi. A poco a poco, si crea il software, senza compromessi.

Quindi se la gestione inizia a costringerti a ridurre la qualità devi chiederti perché. Sono passivi? debole? disperato? Nessuna di queste cose è una buona ragione per restare in una compagnia.

Molto semplice davvero. Di 'loro che finirebbero per perdere il loro cliente preferito se finiscono per mettere questo pasticcio per show.

E sì, chiedi loro di rischiare se sanno davvero meglio.

Finalmente: per favore non dire che il prototipo ha bug specifici A, B e C. Allora saresti fatto per risolvere quel bug, e il management affermerà di aver canalizzato l'energia per rendere la produzione del software pronta.

Le probabilità sono con quei bonus sulle prestazioni e futuri stock grant in questi giorni, loro ascolteranno.

Includi il problema in primo luogo. NON FINALIZZARLO. Con questo voglio dire non farlo sembrare carino o come se fosse in sintonia con gli stili esistenti sul sito. L'obiettivo è semplicemente quello di ottenere la versione di lavoro più grezza possibile in modo da poter vedere che il flusso dell'interfaccia utente molto semplice funziona. Se metti lo stile del sito esistente su di esso o lo pulisci eccessivamente, si suppone che tu possa semplicemente "collegarlo". La gestione è come Pakleds di Star Trek. Vogliono solo che tu "ce la fai". Più sei pronto a farlo sembrare, più pronto penseranno che sia.

Se ciò non risolve il tuo problema, trova un lavoro presso almeno un'azienda con un marchio ben noto per un anno. Metti la tua email e il tuo numero su un curriculum online e combatterai i reclutatori con un bastone, che ti consentirà di dire loro "assolutamente no" con la fiducia di un dev che sa cosa stanno facendo e può ottenere un nuovo lavoro domani, dove si spera che la tua esperienza in materia sia presa più seriamente.

Attualmente sto lavorando su un codebase che non ha due ma un triplo stack-whammy di Rails, .NET e Java. Il motivo per cui abbiamo attaccato i Rails è stato il fatto che un prototipo è stato realizzato in Rails e il cane di punta della compagnia ha detto "Falla andare". A volte dobbiamo dire no. Finché non lo facciamo tutto il tempo dovrebbero prenderci sul serio.

Ma sì, qualunque cosa tu faccia con un prototipo, assicurati che inizi davvero brutto.

Non preoccuparti di questo.

Se ti siedi e lanci i controlli dell'interfaccia utente per un "prototipo", c'è esattamente zero ragioni per cui dovresti mai buttare via automaticamente quel progetto. Se è stato abbastanza buono da mostrare la gestione, allora è un buon punto di partenza quando codificare il programma "reale".

Passare da un prototipo a un'interfaccia utente più "raffinata" non dovrebbe essere altro che una serie di passaggi interamente giustificabili. Dovevi aggiungere un secondo pulsante. Hai ricevuto feedback dagli utenti che hanno trovato l'ordine confuso. Il gruppo di standard della tua organizzazione ha imposto un piccolo cambiamento. Dovevi cambiare la dimensione di una casella di testo per l'internazionalizzazione.

Nessuna di queste ragioni è "bene, era solo un prototipo". Nella progettazione dell'interfaccia utente o in codice o in scrittura, QUALSIASI COSA può finire per vivere per sempre. E quelli che non tutti dovrebbero avere ottime ragioni per ucciderli.

E la gestione probabilmente non gli interessa.

Realisticamente, se il motivo per cui non hai semplicemente inserito la tua interfaccia utente sul codice esistente era "dovevo riscriverlo nella nostra struttura corretta", questo dovrebbe essere un motivo sufficiente. E se non lo fosse, dovresti probabilmente avere una discussione sul framework UI stesso, ma questa è un'altra domanda.

Avevo questo problema fino a quando, ho capito che non era un problema, ma un modo per liberarmi dagli standard di sviluppo piuttosto obsoleti imposti alla maggior parte dei negozi.

Quindi dici alla tua direzione che stai scrivendo un prototipo, scegli le tecnologie che funzionano meglio per te, per quest'area problematica, e poi scrivi il software con la piena consapevolezza che entrerà in produzione.

Sfuggi alla noia di "le applicazioni devono essere in java 1.6 utilizzando Web (inserisci costoso motore J2EE di scelta gestionale)" e standard di denominazione inutili, ecc.

I miei attuali linguaggi di prototipo di scelta sono "php" (che è totalmente scalabile in ambienti di produzione heavy duty - basta chiedere a Facebook) e l'elegante combinazione di Groovy / Java con Tomcat o Jetty.

La combinazione groovy / java è ottima per lo sviluppo rapido. Groovy è bello da usare veloce per lo sviluppo, ma si comporta come una lumaca geriatrica, tuttavia è banalmente facile ricondurre le sezioni critiche per le prestazioni in puro Java. Matrimonio l'applicazione a Tomcat o Jetty significa non dover mai più trattare con EJB e altri orrori J2EE.

Il principale vantaggio di avere un prototipo funzionante rispetto a uno schizzo come proposto da diversi poster è il feedback degli utenti. I prototipi sono un ottimo modo per coinvolgere il business nel design. Una volta che si rendono conto che possono dire cose come "non dovrebbe quel campo essere sullo schermo principale" e hey presto! lì è sulla schermata principale alla prossima demo che aprono e vengono coinvolti nel design portando anni di preziosa esperienza di business nel progetto.