C'è una concezione generale tra molti utenti e clienti aziendali che quando sembra completo, è quasi completo. Come probabilmente saprai, questo è lontano dalla verità. Si può avere un bell'aspetto, ma senza backend e alcuni utenti pensano che renderlo bello sia l'80% del lavoro, non il 20% ( o l'altro 80% ).
Innumerevoli sviluppatori possono raccontare storie horror di questo: ottenere un mockup delle pagine fatte in Microsoft Word usando le schermate di qualche altro strumento e il cliente dice "quindi, ce l'hai quasi fatta?"
È necessario stimolarlo in modo che tutte le parti vengano eseguite al termine. Cercare di fare prima tutto il back-end e poi tutto il front-end porterà l'utente finale a pensare che non stai facendo nulla e a chiederti perché vieni pagato quando non c'è nulla da mostrare. D'altra parte, front end prima e troverai l'utente finale che sta apportando cambiamenti assurdi e consumando tutto il nostro tempo.
Il caso peggiore con un "uno prima e l'altro" è quando si arriva all'altra parte, si scopre che non si adatta affatto al design.
Quindi, costruisci entrambi. Mostra i progressi nel front-end, fai funzionare il back-end con ciò che stai costruendo. In molti casi è una buona idea fornire build incrementali e assicurarsi che tu stia facendo ciò che il cliente vuole (questo diventa Agile). Andare troppo a lungo senza "avanzamenti visibili" può danneggiare la relazione con il cliente (questo è per entrambi i casi di "tutto sembra fatto in anticipo" e "nulla viene fatto fino alla fine" - è difficile per il cliente vedere il quadro scritto o i test unitari o la sanificazione dei dati come avanzamento).
Joel ha scritto di questo in The Iceberg Secret, Revealed :
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.
Le persone che non sono programmatori stanno solo guardando lo schermo e vedendo alcuni pixel. E se i pixel sembrano costituire un programma che fa qualcosa, pensano "oh, cavolo, quanto potrebbe essere più difficile farlo funzionare davvero?"
Il grande rischio qui è che se prima deridi l'interfaccia utente, presumibilmente in modo da poter avviare alcune conversazioni con il cliente, tutti penseranno che hai quasi finito. E poi, quando passerai il prossimo anno a lavorare "sotto le coperte", per così dire, nessuno vedrà davvero quello che stai facendo e penseranno che non è niente.
Questo è nuovamente ribadito nel post del blog. Non far sembrare la Demo Fatto che ha questo utile grafico:
Nota qui le due opzioni generalmente riflettono il 'get the ui done' (e quindi l'aspettativa è che presto lo farai) e 'get the backend' (e quindi il cliente è preoccupato che tu non abbia rispettato la scadenza).
L'aspetto di "fatto" dovrebbe corrispondere a quanto "fatto" è.
Ogni sviluppatore di software lo ha sperimentato molte volte nella sua carriera. Ma gli strumenti di desktop publishing portano allo stesso mal di testa per gli scrittori di tecnologia: se mostri a qualcuno una bozza approssimativa che è perfettamente formattata e formattata, la vedono come più fatta di quanto desideri. Abbiamo bisogno di una corrispondenza tra dove siamo e dove gli altri percepiscono che siamo.
Questo articolo evidenzia anche un punto importante sul tipo di feedback che ricevi con diversi livelli di doneness dell'interfaccia utente. Se hai qualcosa che sembra completo, hai maggiori probabilità di ricevere feedback su "potresti cambiare il carattere" rispetto a "questo layout non funziona - ci sono troppe schede".
Per coloro che stanno combattendo con questo nel mondo Swing Java, c'è un aspetto chiamato Napkin che lo rende in modo che l'interfaccia utente non sembri completa (anche se lo è).
La chiave qui è farlo in modo che non sembri fatto. Avere l'aspetto dell'interfaccia utente completo è un segnale per molti utenti aziendali che l'applicazione è completa (anche se si tratta di poche pagine statiche senza alcuna logica dietro o qualcosa incorporato in un builder di interfacce).
Ulteriori letture (e collegamenti dall'articolo):
