Come convincere il management a buttare via un prototipo?

Adoro la prototipazione come un modo rapido ed efficace per mettere un'interfaccia utente di fronte a un utente.

Molte volte, tuttavia, il management mette i loro becchi sulla strada e il prototipo viene trascinato dando calci e urlando allo sviluppo del flusso principale.

Come gestite il management nel non farlo?

Utilizza uno strumento come Microsoft SketchFlow o realizza il tuo prototipo in un'altra lingua o piattaforma, rendendo quasi impossibile l'integrazione nello sviluppo principale.

C'è anche un saggio di joelonsoft su come mostrare schermate e prototipi, in cui fa apparire aspetti non implementati e non lavorati apparentemente rotti / non implementati, chiarendo dove il lavoro deve ancora essere fatto.

Corollario importante due. Se mostri a un non programmatore uno schermo che ha un'interfaccia utente bella al 100%, penseranno che il programma è quasi finito.

...

Cosa puoi fare al riguardo? Una volta compreso il segreto dell'iceberg, è facile lavorarci sopra. Comprendi che qualsiasi demo che fai in una stanza buia con un proiettore sarà interamente incentrata sui pixel. Se puoi, costruisci la tua UI in modo tale che le parti non finite sembrino non finite. Ad esempio, utilizzare scarabocchi per le icone sulla barra degli strumenti fino a quando la funzionalità non è presente. Durante la creazione del servizio Web, è possibile prendere in considerazione l'idea di escludere le funzionalità dalla home page fino a quando tali funzionalità non vengono create. In questo modo le persone possono guardare la home page passare da 3 a 20 comandi man mano che vengono costruite più cose.

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

Non prototipare con codice funzionante. Prototipo con matita e carta o un equivalente software .

Usare i Mockup è come disegnare, ma poiché è digitale, puoi modificare e riorganizzare facilmente. I team possono elaborare un progetto e iterarlo 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.

Scrivere codice spazzatura è una falsa economia.

Come altri poster hanno suggerito, è possibile ottenere questo risultato utilizzando strumenti specifici per i modelli.

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

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

Per una funzionalità dell'interfaccia utente, assicurati di non sviluppare nulla sul server, non toccarlo affatto. Sviluppa di nuovo simulazioni / falsi integrati.

Se devi impegnarti a 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 è un prototipo.

Ho scoperto che gli autori più probabili di far trasformare i prototipi in codice di produzione sono i venditori. 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 facciano eliminare le cose che indicano che si tratta di un prototipo. Devi mantenere la tua posizione: probabilmente non dovrebbero comunque fuorviare i clienti.

La tua direzione 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 codice scadente, non dovresti avere problemi. A poco a poco, si crea il software, senza compromessi.

Quindi se la direzione inizia a forzarti a ridurre la qualità, devi chiederti il ​​perché. Sono passivi? debole? disperato? Nessuna di queste cose è una buona ragione per restare in giro per un'azienda.

Abbastanza semplice davvero. Di 'loro che finirebbero per perdere il loro cliente preferito se finissero per mettere questo casino con errori per lo spettacolo.

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

Infine: per favore non dire che il prototipo ha specifici bug A, B e C. Quindi verrai costretto a correggere quel bug e il management affermerà che hanno incanalato energia per rendere pronta la produzione del software.

Probabilmente con questi bonus di prestazione e future assegnazioni di azioni in questi giorni, ascolteranno.

Evitare il problema in primo luogo. NON FINITARLO. Voglio dire, non farlo sembrare bello o come se fosse adatto agli 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 di base funziona. Se ci metti sopra lo stile del sito esistente o lo pulisci eccessivamente, presumeranno che puoi semplicemente "collegarlo". La gestione è come Pakleds di Star Trek. Vogliono solo che tu "facciamolo andare". Più sei pronto a farlo sembrare, più sono pronti a pensare che sia.

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

Attualmente sto lavorando su una base di codice che non ha due ma un triplo stack-whammy di Rails, .NET e Java. Il motivo per cui abbiamo preso di mira i Rails è stato il fatto che un prototipo è stato realizzato in Rails e il miglior cane dell'azienda ha detto "fallo andare". Dobbiamo dire di no a volte. Finché non lo facciamo sempre, dovrebbero prenderci sul serio.

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

Non preoccuparti.

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

Passare da un prototipo a un'interfaccia utente più "perfezionata" non dovrebbe essere altro che una serie di passaggi del tutto giustificabili. Dovevi aggiungere un secondo pulsante. Hai ricevuto feedback dagli utenti che hanno trovato l'ordine confuso. Il gruppo di standard dell'organizzazione ha dettato una modifica minore. Dovevi cambiare la dimensione di una casella di testo per l'internazionalizzazione.

Nessuno di questi motivi è "beh, era solo un prototipo". Nella progettazione dell'interfaccia utente o nel codice o per iscritto, NIENTE può finire per vivere per sempre. E quelli che non tutti dovrebbero avere ottime ragioni per ucciderli.

E alla gestione probabilmente non importa.

Realisticamente, se il motivo per cui non hai semplicemente inserito la tua IU nel codice esistente era "Ho dovuto riscriverlo nel nostro framework corretto", questo dovrebbe essere un motivo sufficiente. E se non lo fosse, dovresti probabilmente avere una discussione sul framework dell'interfaccia utente stessa, ma questa è un'altra domanda.

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

Quindi dici alla tua direzione che stai scrivendo un prototipo, scegli le tecnologie che funzionano meglio per te, per questa area problematica, e poi scrivi il software nella piena consapevolezza che andrà in produzione.

Sfuggi al tedio di "le applicazioni devono essere in Java 1.6 utilizzando il Web (inserisci costosi motori J2EE a scelta delle gestioni)" e inutili standard di denominazione ecc.

I miei linguaggi prototipo attuali preferiti sono "php" (che si adatta totalmente agli ambienti di produzione pesanti - basta chiedere a Facebook) e la combinazione molto elegante di Groovy / Java con Tomcat o Jetty.

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

Il vantaggio principale 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 veramente l'azienda nella progettazione. Una volta che si rendono conto che possono dire cose come "il campo non dovrebbe essere nella schermata principale" e hey presto! eccolo nella schermata principale della prossima demo che si aprono e vengono coinvolti nella progettazione portando anni di preziosa esperienza commerciale nel progetto.