Come reagire quando la risposta del cliente è negativa alla consegna? [chiuso]

https://stackoverflow.com/questions/315097

10-07-2019
|

Domanda

Sono un programmatore junior. Dal momento che il mio supervisore mi ha detto di sedermi con il cliente, mi sono unito. Ho visto il volto insoddisfatto del cliente nonostante la riuscita (dal punto di vista del mio programmatore) la consegna del progetto!

Cliente: avresti potuto includerlo!
Noi: non era nelle specifiche!
Cliente: buon senso!

Come programmatore, come reagisci in questa situazione?

Soluzione

Che cosa dovresti fare per evitare questa situazione:

Specifica esplicitamente cosa verrà incluso e cosa non verrà incluso.

Il problema probabilmente dipende dalle parti non specificate della specifica:

Il cliente pensa che dovrebbero essere presenti elementi non specificati, ovvero impliciti.
Lo sviluppatore ritiene che non debbano essere presenti elementi non specificati.

Per specifiche future che hai, dovresti avere una dichiarazione catch all, che afferma esplicitamente che se qualcosa non è specificato in questo documento, può essere fatto dopo che la specifica originale è stata fatta ad un costo aggiuntivo.

Cosa fare nella situazione attuale:

Oltre a imparare dalle tue esperienze, dovresti scendere a compromessi con il cliente.

Esempio: farò questa funzione che ritieni sia di buon senso, ma per tutte le aggiunte / modifiche future dovrà essere specificata in modo esplicito.

vale a dire. dovrai fare un po 'più di lavoro, ma ne vale la pena in cambio della cattura di tutti i contratti esplicitamente indicati dal tuo cliente.

Specifiche errate?

Era necessariamente una cattiva specifica? No.

È impossibile menzionare tutto ciò che i tuoi clienti possono aspettarsi, quindi è fondamentale che questa dichiarazione catturi tutte le dichiarazioni di cui sopra dichiarate in modo chiaro ed esplicito nella specifica / contratto.

Altri modi per ridurre il problema:

Coinvolgi il cliente in anticipo, mostra loro i primi prototipi. Anche se non lo richiedono.
Cerca di non vendere al cliente un prodotto finale, ma piuttosto un servizio per lavorare sul suo prodotto.
Prendi in considerazione un modello di sviluppo agile o qualcosa di simile in modo che i compiti siano ben definiti, piccoli, pagati e indiscutibili.

Altri suggerimenti

Questo sarebbe uno dei tanti motivi per cui sono passato a una Sviluppo agile . L'unico modo, secondo me, di evitare con successo questo scenario è quello di essere onnisciente o coinvolgere pesantemente il cliente e rilasciare anticipatamente / rilasciare spesso per ottenere feedback il più presto possibile. In questo modo puoi sviluppare il software che il cliente desidera davvero, non il software che il cliente ti dice che desidera.

Cliente: avresti potuto includerlo!

Noi: non era nelle specifiche!

Cliente: buon senso !!

Noi: non tentiamo di andare oltre quanto specificato dal cliente - seguiamo le specifiche. È importante NON implementare funzionalità non specificate come è implementare funzionalità specificate. Non indovineremo mai i nostri clienti, che apprezzano il fatto che possano dipendere completamente da noi per implementare correttamente e completamente le specifiche in tempo e sotto budget.

Come altri giustamente sottolineano, la situazione è quasi sempre più complessa del semplice scambio che ho descritto sopra.

Tuttavia, quanto sopra è valido se l'implementatore ha una specifica con la firma del cliente su di esso che implementa essenzialmente un accordo che dice "una volta che il software implementa in modo dimostrabile tutte le funzionalità nella specifica, allora è considerato completo", e qualsiasi cosa addizionale è al di fuori delle specifiche e quindi al di fuori del contratto.

Anche il contratto stesso può avere qualche input qui - se non si dispone di un contratto firmato di quanto non contenga ciò che è nelle specifiche - tutto finora è stato fatto con una stretta di mano e l'intero affare (incluso pagamento) può andare in bagno in base a qualsiasi insoddisfazione su entrambi i lati.

Ma se hai un contratto e una specifica, e il cliente ha visto e firmato entrambi, non ha spazio per chiederti di andare oltre.

Ora, per quanto riguarda la questione se è necessario implementarlo:

INCREDIBILE! Hai consegnato un prodotto e avevano solo uno reclamo. Implementa la funzione, chiamala "omaggio" (assicurati di capire che stai lavorando al di fuori delle specifiche e del contratto e invia loro esplicitamente una fattura per il lavoro con lo sconto indicato in dollari) e fai firmare il progetto nel suo insieme .

Dimostrerà esplicitamente che il progetto è terminato, che sei andato ben al di là della call of duty e che ogni ulteriore "sorpresa" è al di fuori del contratto / delle specifiche, il che ti offre un buon livello di protezione oltre ciò che già (apparentemente) sì.

Se si tratta di un problema con l'interfaccia utente, sei in acque più oscure.

Le specifiche descrivono adeguatamente l'interfaccia utente? Ha dei modelli? Non criticherei un cliente per questo reclamo sull'interfaccia utente se le specifiche non descrivono molto da vicino il layout, l'utilizzo e includono i modelli.

Ad ogni modo, penso che tu possa capire la posizione del cliente - se non hanno giocato con i modelli dell'interfaccia utente, saranno delusi del risultato a prescindere - non c'è modo, psicologicamente parlando, che tu e il tuo cliente avrebbe potuto avere la stessa idea in mente (non importa il fatto che il buon senso non lo sia!).

Francamente se questa è la prima volta che il cliente ha pensato di verificare l'interfaccia utente prima che il lavoro sia finito, allora è almeno in parte colpa tua non spiegare loro i buoni processi di progettazione dell'interfaccia utente. Questa è una funzionalità chiave per la loro app, ed è strettamente accoppiata a ciò che hanno immaginato - nessuno può essere soddisfatto in una situazione del genere a meno che non abbiano "ampliato" la loro rappresentazione interna nel tempo per corrispondere a ciò che è la realtà.

Questa disconnessione viene risolta solo attraverso frequenti test utente e cliente, che ovviamente manca. Questo è un problema riguardante l'educazione e la comunicazione del cliente, non se le specifiche sono state soddisfatte o meno.

-Adam

Aspettati i cambiamenti dell'ambito dell'ultimo minuto: accadono sempre, quindi sii pronto.
Controlla i progressi frequentemente con il cliente - per ridurre al minimo le sorprese.
Contratto: specifica funzionale, più tempo e amp; Materiali con tappo iniziale (quindi il cliente sente il controllo). Quindi, quando arrivano le modifiche, rinegoziare il limite, se necessario.
Mai dicono che non possono avere ciò che vogliono. Possono ottenere quella risposta gratuitamente!
Sempre dai loro un po 'più di quello che hanno chiesto, quindi sanno che hai un atteggiamento positivo.
Si riferiscono al cliente come appartenente allo stesso team con loro. Non accettare di essere legalisticamente dipinto come un avversario.
Potrebbero pensare agli appaltatori come non leali, rispetto ai dipendenti. Mostra loro che ti dedichi al loro successo tanto quanto lo sono i loro dipendenti e farai il possibile.

Custodia classica ...

Non c'è una risposta definitiva a questo, ma tutto ruota attorno alla comunicazione. Dovrebbero essere state messe in atto misure preventive (come revisioni settimanali o qualcosa del genere).

Di sicuro, non puoi rifare il tutto gratuitamente.

Due modi: o per dire loro di ** scendere o di occuparsene.

Se scegli di trattare:

In primo luogo, empatia, rispetto per il cliente.
Dai un'occhiata a cosa può essere facilmente modificato.
Dai un'occhiata ai contratti.
Forse creare un nuovo accordo.
Non fare troppo.
Fagli vedere i progressi e il lavoro necessario.
Trova soluzioni alternative per le funzionalità mancanti (magari utilizzando altre fantastiche funzionalità o strumenti disponibili)

Usa il tuo buon senso, è così comune, non è nemmeno divertente.

Questo è uno dei molti svantaggi di un accordo di offerta fisso. Ogni volta che le esigenze aziendali o le priorità cambiano, o c'è anche un semplice malinteso, si traduce in qualsiasi cosa, da una situazione imbarazzante come questa a chiamare gli avvocati. Se hai un accordo in cui vieni pagato per i tempi di sviluppo, puoi sempre reagire a qualsiasi cambia e ricevi i pagamenti per tutto il tempo necessario per apportare tale modifica. Inoltre, avere un accordo a ore non impedisce di avere un piano o fare una stima.

Una volta che sei in un pickle di offerta fissa, tuttavia, le opzioni sono: 1) Fallo ad un costo aggiuntivo. 2) Fallo gratuitamente. 3) Non farlo.

L'opzione 3 è la peggiore e l'opzione 1 è la migliore. Se hai una buona relazione di fiducia e una comunicazione decente con il cliente, di solito è facile arrivare all'opzione 1. Se la relazione è cattiva, allora hai problemi più grandi. A quel punto, cerca solo di evitare i laywers.

Un punto finale: qualsiasi progetto che abbia qualcosa di noto come "La data di consegna" inevitabilmente si imbatte nel problema descritto. I progetti con tale data di solito comportano il ritiro in una caverna per diversi mesi per svilupparsi in clandestinità seguito da uno scatenamento del prodotto tutto in una volta di fronte agli stakeholder. Questo è brusco e lascia molto tempo alle aspettative dei clienti e al fatto che il prodotto reale si allontani. Se invece mostri versioni intermedie del prodotto e ricevi feedback ogni poche settimane, accadono due cose. Innanzitutto, ottieni un feedback migliore, riduci al minimo i malintesi e crea un prodotto migliore. In secondo luogo, non esiste un unico momento nel quale venga posta un'enorme quantità di aspettative. La differenza potenziale tra ciò che il cliente sta immaginando e ciò che esiste realmente è molto più piccola. Nessuna sorpresa.

Buona fortuna.

" come reagisci? "

Domanda 1: vuoi continuare questa relazione con questo cliente? Sul serio. Se hanno intenzione di affermare che le caratteristiche non specificate sono "buon senso", " questa potrebbe non essere una buona relazione da mantenere o migliorare.

Se vuoi disimpegnarti, allora è facile. Chiedi loro di evidenziare ogni parte delle specifiche che non hai rispettato e di giocare a quel gioco. Ottieni criteri di prova specifici per ogni caratteristica mancante. Tirare i denti. Sii conflittuale nel determinare cosa manca. Non chiedere perché. Basta chiedere tutti i dettagli in anticipo. È lento e spiacevole. Ma non li vuoi comunque.

Se vuoi impegnarti, beh, dovrai cambiare la relazione. Attualmente, hai un cliente aggressivo passivo. Non diranno ciò che vogliono, ma diranno ciò che non vogliono.

Questa potrebbe essere un'abitudine con loro; questo potrebbe essere il modo in cui vincono le concessioni. O questa potrebbe essere una specifica sciatta da parte loro.

Se vuoi la relazione, la tua reazione ha due parti.

a breve termine. Ottieni qualcosa di cui sono felici. Devono identificare cambiamenti specifici. Devi segnare ogni modifica con un "costo per fare" e "adatta con le specifiche".
- Alcune cose sono economiche e ben adattate. Fai quelli.
- Alcune cose sono economiche da fare, ma non conformi alle specifiche. Rifletti due volte su come abilitare una cattiva specifica per portare a rilavorazioni. In un certo senso, hai acquistato le specifiche da loro; potrebbe essere necessario aumentare anche i tuoi standard.
- Le cose costose che (purtroppo) si adattano alle specifiche sono un problema. Sei nei guai con questi e praticamente devi farli.
- Le cose costose che non si adattano bene alle specifiche sono lezioni apprese per tutti. Descrivi in ??dettaglio un piano per questi, inclusi riscritture e approvazioni delle specifiche.
a lungo termine. Assicurati di non essere di nuovo PA. Rivedi presto e spesso, usa le tecniche Agile. Comunicare di più, prototipare di più, rilasciare di più.

Bene, non è stato consegnato con successo. Da qualche parte lungo la linea c'è stata una cattiva comunicazione. Senza conoscere le specifiche suggerirei che questo non è un problema iniettato dallo sviluppatore e questo probabilmente non deve essere biasimato dal cliente - l'attività di raccolta dei requisiti era insufficiente. Questo è un classico esempio di ciò che accade quando il lato software non ha esperti di dominio o il processo di individuazione dei requisiti non fa tutto ciò che potrebbe ...

Se fossi in me correggerei il problema e capirei come evitare problemi simili in futuro.

Il modo in cui lo gestisci può benissimo determinare il futuro di questo contratto / business con il cliente. Assumersi la responsabilità e correggere il problema è un'enorme opportunità per la tua azienda.

EDIT: Questo è un buon momento per valutare come è successo per correggerlo. Alcune aziende scelgono di rinnovare totalmente tutto ciò che fanno, che credo sia un errore. Quindi lo sta ignorando. Incolpare le persone per il problema è anche un errore.

È un buon momento per esaminare come è successo, qual è il processo e forse come avrebbe potuto essere scoperto. Non vorrei apportare grandi cambiamenti alle regole o ai processi, ma inventare linee guida per i lavori futuri è una cosa grandiosa. La tua azienda ha avuto una chiara lezione su una mancanza. Perdere l'opportunità di correggere questo problema e correggere il processo sarebbe uno spreco di buone possibilità.

ZiG, ho dovuto affrontare questo problema in diverse occasioni nel mio attuale posto di lavoro. Il mio gruppo (3 sviluppatori) cerca di affrontare le cose in modo agile. Siamo abituati a ricevere richieste mid-stream e persino dell'ultimo secondo (che poi trattiamo caso per caso).

Tuttavia, chiariamo che le risorse (in particolare il tempo) sono limitate e se non è nelle specifiche non possiamo fare promesse. Se viene giudicato importante e non si adatta alla versione corrente, generalmente pianifichiamo una versione successiva. Se non è importante, viene inserito in un elenco.

Una cosa che ho scoperto è che puoi convincere gli utenti ad accettare le Specifiche S al momento T. Tuttavia, al momento T + N, far loro ricordare che hanno accettato le Specifiche S o far loro riconoscere che lo hanno fatto (con la documentazione che hai conservato, spero!) può essere più complicato di quanto dovrebbe essere.

Parlando dell'argomento e della domanda del PO:

Se sei un programmatore impiegato, spero che altre risorse siano nell'incontro con te. Forse "più alti". nell'organizzazione.

In tal caso, il tuo compito è rispondere alle domande DIRETTE e tenere sotto controllo le tue emozioni. Sì, potresti sentirti ferito perché non amano il tuo codice, ma mostrare qualsiasi emozione con i boss presenti non è una buona cosa. Piuttosto, cerca di sembrare neutrale e lascia che gli altri gestiscano la sessione.

Ora, se ti "appendono ad asciugare", allora consiglierei le seguenti domande:

a) " OK. Vedo. Perché esattamente secondo te questo è il buon senso includere questa funzione? Vorrei scoprire perché non l'abbiamo incluso. & Quot; (costringili a spiegare il loro processo di pensiero. Il buon senso per una persona è raramente buon senso per chiunque altro.)

b) " Beh, sono sicuro che potremmo includerlo nella prossima versione. Lascerò fino a XXX (i capi) per arrivare a un approccio reciprocamente piacevole " (cioè non parlare di costi o omaggi con i capi presenti. MAI.)

Ancora una volta, questo presuppone che tu sia un programmatore che LAVORA per un'azienda che ha consegnato il prodotto. Ora, se sei più di questo, ovvero SEI uno dei migliori, allora molti dei suggerimenti qui sono eccellenti.

Tuttavia, se sei il superiore o sei un programmatore consulente, quindi prima di tutto

a) Chiedere scusa per il processo che non ha soddisfatto questo requisito. Prometti di collaborare con il cliente per evitare che ciò si ripeta.

Quindi passiamo alle altre strategie. Non importa se addebitate la correzione o meno: le scuse sono l'azione più importante per il cliente. Ancora una volta, vale la pena ripetere: non ti stai scusando per la funzione mancata. Ti stai scusando per il processo di progettazione difettoso che lo ha lasciato scivolare. Di solito i clienti sono piuttosto accomodanti quando inizi in questo modo e poi cerchi una soluzione.

Saluti,

-Richard

Usa approcci simili a SCRUM per evitare questa trappola mortale: coinvolgi il cliente nel processo di sviluppo in anticipo, frequentemente e in comitati ristretti informali - > riduzione del rischio e maggiore agilità.

In termini di domanda letterale, come reagire, il modo migliore è di ignorare il tuo ego (" cosa ?! Dopo aver lavorato così duramente su questo e incontrato le specifiche?! ") e concentrarmi invece su alcuni attivi ascoltando e lavorando al consenso.

Cliente: avresti potuto includerlo!

Noi: non era nelle specifiche!

Cliente: buon senso !!

Noi: capisco che non sei felice che non siamo andati oltre i limiti delle specifiche. Vedendo come ti senti riguardo a questo, come possiamo renderti felice? Vediamo se esiste un processo che possiamo creare insieme che aiuterà tutti.

In sostanza, non vuoi trasformarlo in un " hai detto / ho detto " partita di morte. L'unico modo per risolverli riguarda gli avvocati e quindi nessuno vince. Se puoi essere d'accordo sul fatto che la specifica o il processo fossero in errore, lavora insieme per risolverli.

Questo approccio in realtà ha funzionato per me: aspetta che il ragazzo a cui non piace il tuo software vada e venga sostituito da quello a cui piace .

Ovviamente non puoi davvero fare affidamento su questo, ma se sei sicuro di aver fatto un buon lavoro e che il tuo software soddisferà davvero le esigenze aziendali delle persone che ti hanno assunto, paga aspettare. A volte la reazione iniziale del cliente non sarà la sua reazione finale, specialmente se puoi incorporare rapidamente le sue preoccupazioni.

Non provare a far sentire il cliente come se fosse colpa sua. Potrebbe essere colpa loro, ma farli sentire in quel modo non produrrà risultati costruttivi e potrebbe solo infastidirli.

Invece, dovresti capire che i clienti si lamentano solo del software che usano, nella maggior parte dei casi perché gli piace. Nessuno si lamenta del software che nessuno usa. È inevitabile che un cliente si lamenti del software consegnato, anche se consegni esattamente ciò che chiede. Quindi non sudare. Il software non viene mai eseguito.

Fallimento totale da parte del responsabile della raccolta dei requisiti, non c'è dubbio. Incapacità aggiuntiva della direzione del progetto di non iterare il risultato finale e di tenere riunioni di check-in con il cliente.

Tuttavia, hai una specifica approvata e ciò che hai consegnato corrisponde alla specifica. Pertanto, la tua azienda ha due possibilità: cancellare i costi in nome dello sviluppo del business ed effettuare le modifiche gratuitamente o addebitarle per la richiesta di modifica.

Se non è nelle specifiche, non è nelle specifiche. In quanto sviluppatore senza conoscenze specifiche del dominio, il "buon senso" è un concetto irrilevante. Settori diversi lavorano in modi diversi e un approccio potrebbe essere del tutto appropriato per un determinato dominio ma completamente inaccettabile nell'altro.

Scrivere buone specifiche è una forma d'arte. IMO, puoi adottare un approccio 'analista / programmatore' agile in cui esegui piccole iterazioni o scrivi e mantieni un specifica dettagliata e inequivocabile . Entrambi sono compiti altamente qualificati e sono ancora iterativi. Devi ancora evolvere le specifiche.

In entrambi i casi non è così facile come sembra ed entrambi richiedono la capacità di stabilire un buon rapporto di lavoro con il cliente.

Non puoi sapere cosa pensano i tuoi clienti nella sua testa. Questa situazione si verifica spesso con client che non hanno alcuna esperienza con il progetto di programmazione. Quello che ti suggerisco è semplicemente mostrargli che "buon senso" non è molto preciso come risposta in ingegneria (o programmazione se preferisci).

Mostragli altri esempi nella vita che gli mostreranno che non puoi costruire qualcosa che non sia scritto. Esempio: costruendo una nuova casa, il ragazzo che costruisce la casa ha bisogno di un piano con tutti i dettagli ... non metterà la spina elettrica opzionale perché nel soggiorno è più "buon senso". per avere un po 'di più ...

L'ho avuto una volta. E per fortuna non sono stato io a creare il design perché questo si è rivelato il problema.

È di vitale importanza che la comunicazione tra la vostra azienda e il cliente sia il più perfetta possibile. Assicurati di capirti. Poni domande e lascia che facciano domande. Non lasciare nulla di aperto nel design. Questo sarà il punto problematico alla consegna. E tenere incontri regolari durante il progetto (preferibilmente con un pre-rilascio).

Sfortunatamente molti sviluppatori sono cattivi nella comunicazione e molti clienti non sono consapevoli delle proprie esigenze. Ma se riesci a ridurre al minimo il divario, ti sei trovato un cliente felice (e di ritorno).

Questo è il motivo per cui io / i team con cui ho lavorato ho sempre usato un approccio in stile prototipo , ciò significa:

dopo aver raccolto i requisiti, mostri al client una versione iniziale e di base del software
il cliente dice " potresti averlo incluso " / " è buon senso "
cambi il tuo design per riflettere i desideri del cliente
iterare dal punto 1 fino al rilascio ufficiale

Devi avviarlo presto; dire al cliente, presto e spesso, che le specifiche / casi d'uso / storie utente sono un contratto che definisce ciò che verrà consegnato. in un ambiente agile ci sono molte possibilità per il cliente di osservare un certo "buon senso" caratteristica che vogliono e chiedono, che è uno dei vantaggi di un approccio agile, ma se inizi ad accettare "buon senso" aggiunte alla fine, ti stai preparando per infinite estensioni, probabilmente a tue spese.

Alcuni clienti si aspettano questo; più e meglio dici loro che non possono, più facili saranno gli eventuali argomenti.

Come ragazzo giovane, mi rendo conto che non puoi farlo - ancora - ma una delle lezioni difficili ma necessarie è che a volte devi licenziare un cliente.

Tu impari - tutto sta imparando e niente è personale.
Siamo esperti nella nostra zona e sappiamo meglio del cliente ciò di cui ha bisogno. E la prossima volta per il prossimo cliente suggeriremo in anticipo tutte le funzionalità utili e lo renderemo felice e gli faremo pagare di più perché siamo gli esperti e conosciamo meglio.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow