Trattare con la cultura cliente / sviluppatore non corrisponde a un progetto agile

Uno dei principi dell'agile è ...

Collaborazione con i clienti sulla negoziazione del contratto

... un altro è ...

Individui e interazioni su processi e strumenti

Ma per come la vedo io, almeno quando si tratta di interazione con il cliente, c'è un problema fondamentale:

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

Potrebbe essere un po 'una generalizzazione, sì. Probabilmente, ci sono domini aziendali in cui ciò non è necessariamente vero, ma sono pochi e distanti tra loro. In molti domini, tuttavia, il cliente tipico è:

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

D'altra parte, nell'ideale , i software engineer che si esercitano in agilità sono:

1. Le persone che pensano molto alla qualità;
2. Le persone che apprezzano come un po 'di lavoro iniziale può risparmiare un sacco di sforzi lungo la linea;
3. Pensatori analitici esperti.

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

Qual è il modo migliore per affrontare questo?

In molti domini, tuttavia, il cliente tipico è:

• Interessato alle preoccupazioni operative quotidiane - tattiche a corto raggio ... non strategia;
• Riguardava solo la soluzione immediata;
• Pensatori generalmente monodimensionali, non astratti;
• Principalmente interessato a "portare a termine il lavoro" invece di trovare una soluzione duratura e di qualità.

E per essere sinceri, di solito hanno buoni motivi per pensare in questo modo. Prima di tutto, gestiscono un'azienda, che dovrebbe generare entrate oggi e domani, non in un futuro lontano. In secondo luogo, non sono esperti tecnici: non sanno cosa sia possibile e cosa no e quali siano le conseguenze di specifiche scelte architettoniche / progettuali / di implementazione. Questo è quello che sappiamo.

Quindi la risposta è - quasi sorprendente - comunicazione .

È necessario comunicare molto, educarsi a vicenda, per far comprendere l'un l'altro il punto di vista dell'altra parte almeno a un livello base. È necessario spiegare loro le conseguenze a breve e lungo termine di possibili alternative. E devi usare un linguaggio che capiscono .

• Se dici "questo sarebbe un trucco, che rende il codice meno leggibile ed estensibile" , dicono "sì, qualunque cosa" .
• Se dici "questa sarebbe una soluzione a breve termine, che renderebbe lo sviluppo e la manutenzione a lungo termine più costosi e aumenterebbe il rischio di introdurre bug" , dicono "ah ah, consideriamo" .
• E se dici "questa soluzione ti costerebbe $ 100 ora, ma introduce $ 500 di debito tecnico che sei tenuto a rimborsare con gli interessi prima o poi; OTOH questa altra soluzione ti costa $ 400 ora e non lascia alcun debito tecnico; scegli quello che voglio " , dicono " ora stiamo parlando! " .

OTOH ci possono insegnare una cosa o due sulla prospettiva aziendale. Azienda vuole usabile e abbastanza buono - quasi 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 da molti come triste, ma è una realtà aziendale. Per me, se sono riuscito a risolvere il problema dei miei clienti, e vedo che ha reso la loro vita visibilmente più semplice, sono felice come loro. OTOH se sono riuscito a implementare il design perfetto che avevo in mente, ma la società fallisce la settimana successiva, non è certo una vittoria per nessuno, vero?

Un imprenditore sensibile capirà - se li spieghi usando la propria lingua - perché è importante mantenere pulito il software, scrivere unit test, refactoring ecc. Anche se questi non sembrano contribuire direttamente a breve termine, essi sono essenziali per la manutenzione a lungo termine. E i clienti sensibili si preoccupano della manutenibilità a lungo termine della loro attività, quindi sicuramente sono disposti a investire in essa quando vedono il valore generato dal loro investimento. Tuttavia, sia le loro risorse che il tuo tempo sono limitati, quindi devi dare la priorità e concentrarti sulle cose più importanti. Ma è importante solo se è importante per entrambi .

Potresti voler refactificare il modulo A perché il codice qui dentro è semplicemente orribile, e hai una stupenda idea su come refactificare il codice in modo che sia conciso, elegante e pulito, usando un modello di progettazione che hai appena letto. Tuttavia, se quel modulo non è stato toccato per anni e funziona in modo affidabile, molto probabilmente starai meglio concentrandoti sul modulo B, che verrà esteso la prossima settimana con una nuova funzionalità molto importante e contiene tonnellate di bug già.

Come si vedono i tuoi clienti:

• Ho un progetto che devo completare al più presto
• Conosco le esigenze della mia azienda
• Devo risolvere il problema in modo da non interferire con le attuali pratiche commerciali
• Ho un budget limitato per farlo.

D'altra parte, vedono il tuo gruppo come:

• Ragazzi che non capiscono che stanno succhiando soldi dal mio budget.
• Non capisco le esigenze della nostra attività
• Vuoi ridisegnare tutto, anche se renderà più difficile implementarlo sul business.
• Vuoi avere una soluzione intelligente e intelligente quando tutto quello che ho il budget è funzionale ed efficace.

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

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

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

Sì. A volte è vero. Ci sono anche casi in cui i clienti non sanno cosa e come vogliono (cioè i requisiti non sono chiari). Comunque, se sei agile, ottieni il risultato dopo ogni sprint (diciamo 2 settimane) e hai l'opportunità di ottenere il feedback dei clienti e assicurarti che siano tutti sulla stessa pagina. Questo aiuta a identificare e risolvere tempestivamente i problemi che aiuteranno internamente a creare fiducia.

Inoltre c'è 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 .

Qual è il modo migliore per affrontare questo?

Come ho già detto, non esiste una bacchetta magica in grado di risolvere tutti questi problemi . Devi impegnarti di più con i tuoi clienti in modo che ci sia una buona comprensione di ciò che fanno gli altri. Promuovere la visita del sito, aprire feedback ecc.

Assicurati che il proprietario del prodotto e i portatori di interesse partecipino alle dimostrazioni di sprint e forniscano suggerimenti preziosi per migliorare il prodotto .

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

Con buy-in, intendo ottenere una percentuale garantita di rappresentanti di un cliente alla settimana o al mese. Questa percentuale varierà a seconda del progetto.

Ovviamente hanno il loro lavoro quotidiano, quindi non dipende solo dal rappresentante del cliente stesso, ma dipende dalla loro gestione trovare il tempo per loro.

Quindi ottenere un accordo dalla direzione lato cliente è la chiave di questo problema

Ricorda che l'agile non significa che il cliente sia coinvolto in standup quotidiani o in alcuni degli altri aspetti quotidiani dell'agile. Agile, dal punto di vista del cliente, riguarda la comunicazione. Ciò non significa che stiano comunicando con gli ingegneri i dettagli dell'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 nei tempi previsti? Hanno requisiti in evoluzione che devi adattare?

Agile aiuta te e i tuoi clienti a rispondere a queste domande.