Affrontare la mancata corrispondenza tra cliente e sviluppatore in un progetto agile

11

Uno dei principi dell'agile è ...

Collaborazione del cliente per la negoziazione del contratto

... un altro è ...

Individui e interazioni su processi e strumenti

Per come la vedo io, almeno per quanto riguarda l'interazione con il cliente, c'è un problema fondamentale:

Il modo in cui il cliente pensa è diverso da come un ingegnere del software pensa

Potrebbe trattarsi di un po 'di generalizzazione, sì. Probabilmente, ci sono sono domini aziendali in cui questo non è necessariamente vero --- questi però sono pochi e lontani tra loro. Tuttavia, in molti domini, il cliente tipico è:

  1. Interessato a preoccupazioni operative quotidiane - tattiche a corto raggio ... non necessariamente strategia;
  2. Comprensibilmente, riguarda solo la soluzione immediata;
  3. Pensatori pratici, non pensatori astratti;
  4. Molto più interessato a "portare a termine il lavoro" piuttosto che considerare come la soluzione supporterà le preoccupazioni future.

D'altra parte, nell'ideale , gli ingegneri del software che praticano l'agilità sono:

  1. Le persone che pensano molto alla qualità;
  2. Individui che apprezzano il modo in cui un po 'di lavoro in anticipo può risparmiare un sacco di sforzi su tutta la linea;
  3. Esperti, pensatori analitici.

Quindi sembra esserci una discrepanza culturale che tende ad inibire la "collaborazione con i clienti".

Qual è il modo migliore per risolvere questo problema?

    
posta Eric Smith 23.03.2012 - 08:21
fonte

5 risposte

27

In many domains though, the typical customer is:

  • Interested in daily operational concerns--short-range tactics ... not strategy;
  • Only concerned with the immediate solution;
  • Generally one-dimensional, non-abstract thinkers;
  • Primarily interested in "getting the job done" as opposed to coming up with a lasting, quality solution.

E per essere sinceri, di solito hanno buone ragioni per pensare in questo modo. Prima di tutto, gestiscono un'impresa, che dovrebbe generare entrate oggi e domani, non in un futuro lontano. In secondo luogo, non sono esperti tecnici: non sanno cosa è possibile e cosa no, e quali sono le conseguenze di specifiche scelte architettoniche / di progettazione / implementazione. Questo è ciò che noi conosciamo.

Quindi la risposta è - difficilmente sorprendente - comunicazione .

Devi comunicare molto, educarti a vicenda, far capire a vicenda il punto di vista dell'altra parte almeno a un livello base. Devi spiegare loro le conseguenze a breve e lungo termine delle possibili alternative. E devi utilizzare il linguaggio che comprendono .

  • Se dici "questo sarebbe un trucco, il che rende il codice meno leggibile ed estensibile" , dicono, "sì, qualunque sia" .
  • Se dici "questa sarebbe una correzione a breve termine, che renderebbe più costoso lo sviluppo e la manutenzione a lungo termine e aumenterebbe il rischio di introdurre bug" , si dice "a ha , consideriamo ".
  • E se dici "questa soluzione ti costerà $ 100 ora, ma introduce $ 500 di debito tecnico che dovrai restituire prima o poi con interesse; OTOH questa altra soluzione ti costa $ 400 ora e non lascia alcun problema tecnico debito, scegli quello che vuoi ", loro dicono " ora stiamo parlando! ".

OTOH possono insegnarci una o due cose sulla prospettiva del business. Business vuole utilizzabile e abbastanza buono - difficilmente perfetto - soluzioni . E sanno probabilmente meglio di chiunque altro che "perfetto è il nemico del bene". Quindi è necessario tenere presente che il nostro compito è fornire soluzioni ai problemi dei nostri clienti, piuttosto che produrre software tecnicamente perfetto. A volte questi due convergono allo stesso, ma più spesso no. Questo può essere visto come triste da molti, ma è la realtà aziendale. Per me, se sono riuscito a risolvere il problema del mio cliente, e vedo che ha reso la loro vita visibilmente più facile, sono felice come loro. OTOH se sono riuscito a realizzare il design perfetto che avevo in mente, ma la compagnia va in bancarotta la settimana seguente, non è quasi una vittoria per nessuno?

Un sensibile imprenditore capirà - se le spieghi usando la sua lingua - perché è importante tenere pulito il software, scrivere test unitari, refactoring ecc. Anche se questi non sembrano contribuire direttamente a qualcosa nel breve termine, sono essenziali per la manutenzione a lungo termine. E i clienti sensibili si preoccupano della manutenibilità a lungo termine della loro attività, quindi sono sicuramente disposti a investire su di essa quando vedono il valore generato dal loro investimento. Tuttavia, sia le risorse che i tempi sono limitati, quindi è necessario dare la priorità e concentrarsi sulle cose più importanti. Ma è importante solo se è importante entrambi di te.

Potresti voler rifattorizzare il modulo A perché il codice è semplicemente orribile, e hai una stupenda idea di come rifattorizzare il codice per essere conciso, elegante e pulito, usando un modello di design di cui hai appena letto. Tuttavia, se quel modulo non è stato toccato per anni, e funziona in modo affidabile, è molto meglio concentrarsi sul modulo B, che verrà esteso la prossima settimana con una nuova funzionalità molto importante, e contiene un sacco di bug già.

    
risposta data 23.03.2012 - 09:17
fonte
4

Come si sono visti i tuoi clienti:

  • Ho un progetto che ho bisogno di fare al più presto
  • So che la mia attività ha bisogno di
  • Ho bisogno di risolvere il problema in un modo che non interferirà con le attuali pratiche commerciali
  • Ho un budget limitato per ottenere questo risultato.

D'altra parte, vedono il tuo gruppo come:

  • Ragazzi che non capiscono di succhiare denaro con il mio budget.
  • Non capisco le esigenze della nostra attività
  • Vuoi ridisegnare tutto, anche se renderà l'implementazione più difficile sul business.
  • Vuoi avere una soluzione intelligente e intelligente quando tutto il mio budget è funzionale ed efficace.

Il tuo problema principale sembra essere nessuno dei due sta capendo di cosa hanno bisogno dall'altra parte.

    
risposta data 23.03.2012 - 17:19
fonte
3

Bene, innanzitutto, Agile non è la soluzione per tutti i problemi che hai nel tuo progetto.

How the customer thinks is fundamentally different to how a software engineer thinks

Sì. A volte è vero. Ci sono anche casi in cui i clienti non sanno cosa e come vogliono (ad esempio, i requisiti non sono chiari). Che cosa mai, Se sei agile ottieni il risultato dopo ogni sprint (ad esempio 2 settimane) e ottieni l'opportunità di ottenere feedback dai clienti e assicurarti che siano tutti sulla stessa pagina. Questo aiuta a identificare e risolvere tempestivamente i problemi che contribuiranno a creare fiducia all'interno.

C'è anche un detto, gli utenti sono come bambini pazzi, quindi quando chiedono una pistola e sai che non è sicuro, potresti prendere in considerazione l'idea di dare una pistola giocattolo per calmarli .

What's the best way to address this?

Come ho già detto ci sono nessuna bacchetta magica che può risolvere tutti questi problemi . È necessario impegnarsi maggiormente con i clienti in modo che ci sia una buona comprensione di ciò che fanno gli altri. Promuovi la visita del sito, apri feedback ecc.

Assicurati che il proprietario del tuo prodotto e gli stakeholder partecipino alle demo di sprint e forniscano suggerimenti preziosi per migliorare il prodotto .

    
risposta data 23.03.2012 - 08:42
fonte
1

Se non hai acquistato dal cliente, Agile può essere quasi impossibile.

Acquistando, intendo ottenere una percentuale garantita di un rappresentante del cliente per settimana o mese. Questa percentuale varierà in base al progetto.

Ovviamente hanno il loro lavoro diurno, quindi non è solo per il rappresentante del cliente stesso, è compito della loro gestione trovare il tempo per loro.

Quindi ottenere un accordo dalla direzione da parte del cliente è la chiave di questo problema

    
risposta data 23.03.2012 - 11:04
fonte
0

Ricorda che agile non significa che il cliente sia coinvolto negli stand up quotidiani o in altri aspetti quotidiani dell'agile. Agile, dal punto di vista del cliente, riguarda la comunicazione. Ciò non significa che comunicano con gli ingegneri sui dettagli di implementazione.

I clienti collaborano con il proprietario del prodotto per ottenere e fornire un feedback costante. L'argomento è funzionalità, ma non come sono implementate. Stai offrendo le funzionalità appropriate? Sei in orario? Hanno requisiti mutevoli a cui devi adattarti?

Agile aiuta te e il tuo cliente a rispondere a queste domande.

    
risposta data 23.03.2012 - 13:37
fonte

Leggi altre domande sui tag