Programmazione orientata agli oggetti in WordPress: comprendere le aspettative dei clienti
Mentre continuiamo a portare avanti la discussione sulla programmazione orientata agli oggetti in WordPress, è importante assicurarci di non superare noi stessi quando si tratta di creare un prodotto per qualcun altro.
Molto spesso è facile:
- ascolta cosa dice un cliente,
- costruire qualcosa in base a ciò che abbiamo sentito,
- consegnarlo a detto cliente.
Ma c’è molto di più. Ci ho ballato un po’ nei post precedenti di questa serie; tuttavia, voglio iniziare a approfondire cosa significa ascoltare:
- Cosa dice un cliente,
- Sviluppare una serie di requisiti,
- E poi crea dei circuiti di feedback intorno a questo.
In definitiva, vogliamo assicurarci che le persone per le quali stiamo lavorando e le soluzioni che stiamo costruendo siano davvero soluzioni e non ostacoli o ostacoli su cui devono saltare.
Inoltre, non credo sia sufficiente che un cliente si goda semplicemente l’esperienza del prodotto finale, ma anche lavorare con colui (o quelli) che costruisce la soluzione.
Detto questo, diamo un’occhiata a cosa significa ascoltare quello che dicono e andare da lì.
Comprendere le aspettative dei clienti
Ogni volta che leggi libri o altro materiale su questo tipo di cose, spesso una delle due parti diventa il "cattivo ragazzo". Non sempre, ma a volte fa:
- il cliente sembra ignorare di cosa sta parlando,
- o fa sembrare lo sviluppatore un idiota per comportarsi come qualcuno che sa di più sull’argomento in questione.
Che ne dici di una terza opzione in cui il cliente ha un’idea chiara di ciò che vuole, gli sviluppatori sono disposti ad ascoltare e lavorare insieme al cliente per costruire qualcosa?
Certo, ci saranno dei chiarimenti lungo il percorso, e ci saranno dei termini che dovranno essere definiti, e qualche "ricalibrazione" del calendario di sviluppo potrebbe anche farne parte.
Ma la linea di fondo è questa: nessuna delle parti dovrebbe lavorare contro l’altra. Invece, si tratta di lavorare insieme per la soluzione. Certo, richiede comunicazione (in cui gli sviluppatori non sono sempre bravi, nella mia esperienza, ma non c’è motivo per cui non possa essere migliore).
Cosa dice un cliente? (Cosa dice lo sviluppatore?)
Ogni volta che vi incontrate, probabilmente state pensando la stessa cosa perché ognuno di voi parla una lingua diversa e ognuno di voi pensa che quello che l’altro dice sia gergo.
E non è sbagliato.
I clienti hanno un modo per parlare di ciò che vogliono e gli sviluppatori hanno un modo per parlare di come consegneranno.
I termini che utilizziamo
Ma ci può essere un obiettivo comune.
Cerca una descrizione del problema che sta cercando di essere risolto. Cerca di farlo in parole povere in modo che il design sia in linea con l’obiettivo e la funzionalità della soluzione.
Non credo che funzionerà per tutti, ma questa è la prima cosa che consiglio di fare ogni volta che ti siedi con il tuo cliente.
Come vedrai più avanti in questi post, aiuta a sviluppare alcune frasi che puoi usare all’inizio della tua dichiarazione di lavoro a cui puoi fare riferimento ogni volta che hai una decisione da prendere.
In altre parole, tu (e loro) potete chiedere:
Ciò su cui sto lavorando contribuisce all’obiettivo comune?
Ed è qui che puoi determinare la serie di requisiti fondamentali.
"Deve…"
Quando si tratta di acquistare qualcosa, costruire qualcosa, richiedere qualcosa, volere qualcosa o qualsiasi altra cosa, è abbastanza facile iniziare la frase dicendo "Voglio che…"
Ma c’è una grande differenza tra "Voglio che faccia [fare qualcosa]" e "Ne ho bisogno [per fare qualcosa]", e quando lavori nel software, è generalmente sicuro dire che le cose che sono necessarie sono fondamentali all’applicazione. E le cose che si desiderano sono ciò che viene dopo che è stata creata la base dell’applicazione.
Cioè, è una conversazione su "must-have" e "want-to-have". Ed è importante avere conversazioni in modo da poter arrivare a quella dichiarazione finale dell’obiettivo comune dell’applicazione.
Una volta che è a posto, puoi iniziare quindi a pianificare il tuo software in base al problema del cliente. Ed è qui che entra in gioco la raccolta dei requisiti.
Requisiti in via di sviluppo
Ciò che tu e il cliente avete una solida comprensione di ciò che deve essere costruito, allora è il momento di mettere insieme i requisiti.
Questa parte può essere più divertente di quanto sembri. Lo so, lo so: suona come un compito o un compito, giusto? Ma non lo è. Invece, sta prendendo quello che vogliono, quello che hai capito, traducendolo in un linguaggio comune e poi scrivendo un documento che spieghi cosa farà il software.
A seconda della tua esperienza, però, questo può essere noioso. E per noioso, intendo una delle parti peggiori del tuo lavoro. Inoltre, i requisiti cambiano sempre, giusto?
Non sempre.
Se ti prendi del tempo per capire cosa vogliono dall’inizio, allora i requisiti non devono essere un documento di 50 pagine che delinei come ogni singolo modulo deve funzionare.
Molti libri lo documentano dicendo che è così che deve essere. Ma in quasi un decennio in questo modo, non ho mai avuto un arco di tempo così lungo e i clienti in genere sono stati incredibilmente grati di vedere un breve elenco che può essere modificato tramite e-mail o Google Docs, firmato e quindi indicato come il progetto si sposta inoltrare.
Ne parlerò di più in futuro, ma qualunque sia la brutta esperienza che hai, la paura o la trepidazione che hai non devi sederti. E continueremo a parlarne attraverso questa serie.