Relazione tra sviluppatori e clienti

Essere sempre in contatto diretto con il cliente. Sempre. Sempre.

Racconterò un esempio che abbiamo affrontato in precedenza. Il prodotto che era già esistente era della versione 2.0 in cui è possibile scrivere il proprio CSS (un compito pesante!). Durante l'implementazione della V2.0 (eoni fa), hanno scritto il CSS, per rispecchiare il loro marchio interno, in colore verde. (Motivo: lo schema predefinito era in magenta!)

2 anni fa, quando ci siamo imbarcati per aggiornarlo alla versione 6.0, il prodotto stesso ha scelto Microsoft (!) blu come schema predefinito.

Come previsto, il cliente non era disposto a lasciar andare il proprio colore verde. Anche internamente, c'era un conflitto. I BA hanno convenuto che il marchio interno non era necessario e possiamo andare con il blu predefinito (!) Blu. Ma no, l'ultimo stakeholder ha continuato a insistere per mantenere il colore verde o NON lo facciamo affatto.

Che cosa abbiamo fatto noi sviluppatori?

Organizzato un incontro con lo stakeholder finale. Iniziata la riunione seguendo le seguenti linee -

You know what, I am upset that we are to lose out the internal branding color. I cannot tell how much I am upset that we are about to lose the internal branding which you have built and stood for in so many years. But, unfortunately we are now at a stage where we need to make some hard decisions and I am hoping that you would help us (developers) with it.

Abbiamo quindi elencato tutte le grandi funzionalità di esecuzione dell'aggiornamento.

1. Schede di ancoraggio (ooh, così adorabile!)
2. Trascina e riordina le colonne in un browser Web (ah, è fantastico!)
3. ...
4. ...
5. ...
6. ...

E poi abbiamo elencato cosa ci sarebbe mancato?

1. Il colore del marchio interno andrebbe perso

Ho inserito una bella citazione come

You can lose battles to win wars!

E poi, abbiamo lasciato la decisione per loro di fare. Inutile dire che hanno accettato il colore della Microsoft e tutto andava bene.

Nulla di tutto ciò sarebbe stato possibile se non fossimo stati in contatto diretto. Perché è tu lo sviluppatore che può vendere le straordinarie funzionalità della nuova tecnologia, non la BA.

PS: ora che Wanted è stato rilasciato, puoi sostituire la citazione come "Ne uccidiamo uno, e forse salviamo mille "

Gli sviluppatori dovrebbero assolutamente essere in contatto con i clienti! Anche se un analista di business scrive una specifica formale, è sempre utile avere accesso al cliente per porre domande specifiche o ottenere un feedback immediato su una funzione su cui si sta lavorando. Gli analisti di business sono molto utili, ma non vorrei mai lavorare esclusivamente attraverso di loro per i requisiti. Inoltre, non vorrei mai aspettare più di una settimana o due per mostrare una funzionalità a un cliente. Anche se apportano modifiche, è sempre più facile fare un piccolo cambiamento più vicino al tempo di sviluppo piuttosto che accumulare tutte le modifiche alla fine del progetto.

Le nuove metodologie di software sono anche orientate a avvicinare il cliente e i team di sviluppo del software. Uno dei principi principali di Agile / Scrum è che il cliente sia nel team e sia sempre disponibile per le domande. I team Agile anche dimostrano il loro software dopo ogni sprint o iterazione. Agile è stato creato partendo dal presupposto che il software cambia e che i team devono essere "agili" e adattarsi ai mutevoli requisiti aziendali.

Inizia sempre con la prospettiva del cliente. E.g, Domanda: Perché cambiare qualcosa che funziona? Risposta: Perché la tecnologia rischia di non essere più supportata e nel prossimo futuro potremmo non essere in grado di trovare sviluppatori facili nella tecnologia.

Evita l'impulso di cambiare qualcosa perché sei innamorato di una nuova tecnologia. Solo perché guidano uno Scarabeo VB del 1967 e sei innamorato di una Prius, non significa che vedono la necessità di cambiare. Concentrati sui loro bisogni, non sui tuoi desideri.

Ci sono 2 lati.

1. È una grande idea essere in contatto diretto con il tuo cliente. Hai un'esperienza inestimabile su come si comportano gli utenti nella vita reale, i loro punti deboli, le cose che vogliono nel software e le cose che puoi fare per ottenere ripetizioni.

2. È anche molto importante avere un ragazzo dell'adattatore in tutta questa faccenda. Supponiamo che tu stia facendo il software di account di qualche governo. agenzia non ti piacerebbe ri-utilizzare parte o tutto questo software per un altro governo. agenzia anche, forse uno che si trova in uno stato diverso? Ovviamente lo faresti, ed è qui che entra in gioco il tecnico dell'adattatore. È suo compito mappare questo software ai requisiti e ai punti deboli di un'altra entità correlata e chiedere agli sviluppatori di fare le personalizzazioni.

Penso che entrambi gli approcci siano necessari e complementari.

Penso che sia importante, ma qui ci sono alcuni casi in cui è meno:

1. Lo sviluppatore è un utente tipico o molto esperto che lavora in un dominio particolare.
2. Stai creando la parte dell'app che il client ha poca o nessuna interazione.
3. Lo sviluppatore non ha forti capacità di social / comunicazione a questo punto. Non esercitarti sui tuoi clienti, ma lavoraci su.
4. Ci sono altri membri del team per riprendere il gioco.

Mi ricorda una citazione, "I programmatori preferiscono scrivere programmi per aiutare a scrivere programmi piuttosto che scrivere programmi." Non mi sono mai sentito così. Sono più simile al gatto a cui piace far cadere il mouse occasionale sulla soglia di casa per mostrarti cosa ho fatto in modo da ottenere l'attenzione.