Doing the job of the customer?
Summary: I spoke about how XP is about having a productive conversation with the customer, to help them learn about what they really need, using working software as a focus. One reaction was “why should we do the job of the customer, when they *should* know what they want?” My answer is that they can’t possibly know what they want right from the start; learning what is really needed is a process. We do it because it’s the job of software development to make this process happen.
Lo scorso venerdì ho fatto una presentazione su Extreme Programming al Codemotion. Ho parlato di come i metodi agili abbiano al centro la conversazione fra sviluppatori e clienti; una conversazione che permette ai clienti di scoprire quello di cui hanno veramente bisogno, grazie anche al prodotto che viene sviluppato iterativamente e permette di aggiustare il tiro ad ogni iterazione.
Una reazione è stata: “Perché dobbiamo fare noi il lavoro del cliente? Perché facciamo tutto questo per il cliente quando negli altri campi dell’ingegneria non si fa?”
La mia risposta è che non sono convinto che negli altri campi dell’ingegneria sia poi così diverso da quello che si fa nel software, e comunque se anche fosse non mi interessa. Quello che mi importa è che il cliente *non ha altra maniera* di scoprire quello che gli serve veramente se non attraverso una conversazione focalizzata su un prodotto sviluppato in iterazioni successive. Per cui noi questo facciamo: la ragione per cui sviluppiamo software è per soddisfare i bisogni del nostro cliente.
Se potessimo ottenere lo stesso risultato applicando qualche formula o processo che non richieda tutto questo impegno da parte di tutti, lo faremmo. Ma non c’è! Questo è il semplice dato di fatto.
Il nostro business, nello sviluppo software, consiste nel fare felici i clienti… non lo percepisco come un problema. E’ impegnativo, d’accordo, ma è giusto così.
March 24th, 2013 at 12:11
Sono d’accordo con Matteo. Sono sicuro che anche gli ingegneri e gli architetti facciano lo stesso con i loro clienti.
Infatti, per quella che è la mia esperienza, i team, agili e non, che pretendono che il cliente fornisca i requisiti senza nessun aiuto da parte del team di sviluppo finiscono per produrre software di valore limitato, se non inutile.
Io sono del parere che per essere dei programmatori seri (o professionali, se preferite) si debba essere in grado di conversare con i clienti nel loro linguaggio, e si debba fare in modo di capire il dominio del business cosicché si possano fare le domande giuste per capire che software si debba produrre. Chi non è in grado di fare questo non si può considerare un programmatore esperto, indipendentemente dalle conoscenze tecnologiche.
March 25th, 2013 at 17:04
Come ho scoperto recentemente, la ristrutturazione di una casa e’ un processo abbastanza agile. Inizi con un progetto… poi man mano che lo definisci scopri che devi spostare muri, finestre scale… allora magari fai un passo indietro e pensi ad un altra soluzione.. cosi’ per due o tre volte sul progetto.
Una volta iniziato chiaramente non puoi “rifattorizzare” un muro ma ogni giorno c’e’ qualche sorpresa sui lavori e devi prendere decisioni su due piedi per spostare di qualche cm una finestra, alzare un muro, cambiare il verso di una porta ecc.
Infine devi gestire gli ordini per far si che i sanitari arrivino subito dopo che il tetto e’ stato rifatto, e le piastrelle arrivino prima della fine della posa dei sanitari, ma non troppo prima che poi intralciano… ecc.ecc..
March 25th, 2013 at 17:05
Ah dimenticavo… standup quotidiani in situ! :D
March 29th, 2013 at 15:46
Il discorso regge ed è sensato finché non entra in gioco l’economia.
Ovvero quando il cliente si lamenta che vengono fatti pochi progressi, senza considerare per l’appunto che “noi stiamo facendo il suo lavoro”.
March 31st, 2013 at 18:04
Sì Tommaso, hai centrato il problema. Se siamo d’accordo che il cliente (di solito) non sa che cosa gli serve veramente, allora la cosa più sciocca che possiamo fare è *fare tutto quello che ci chiede* senza fare domande.
Invece domande dobbiamo farne tante, per essere sicuri che quello che facciamo sia in linea con i reali obiettivi. Dobbiamo fare saltare fuori le assunzioni nascoste e fare qualcosa per verificare se sono valide.
E poi tutto questo lavoro dobbiamo farlo *insieme* al cliente. Non possiamo fare diversamente da quello che ci chiede, solo perché pensiamo di saperla più lunga. Anzi, decidiamo insieme al cliente, in base a quello che sappiamo finora, quale sembra essere la maniera migliore di raggiungere l’obiettivo di business.
E….. non ti dico che sia facile. :-)
Un libretto molto utile per approfondire questi temi è Impact Mapping di Gojko Adzik (http://www.impactmapping.org/). Io nel mio piccolo ho già parlato di queste cose; oltre che quest’anno al Codemotion, anche a Better Software nel 2011 (http://matteo.vaccari.name/blog/archives/628).