Cosa fare con una richiesta cliente stupida?

Question

Ho vinto l'offerta per un progetto e ora il cliente (che è esso stesso del dipartimento IT) vuole che io architetti / realizzi la soluzione in un modo molto particolare. Sono sicuro che l'applicazione non funzionerà in questo modo per problemi di prestazioni. E non sarà facilmente scalabile.

Questo particolare cliente / utente non sa NIENTE sulla piattaforma e sulla lingua che userò (ASP.NET / SQL Server). La sua unica conoscenza è in Cobol e cercare di fargli capire il mio POV lo sta solo facendo arrabbiare.

Mi ha contattato. Era la persona che mi ha selezionato come vincitore nell'offerta. È lui che approverà i miei assegni. È il mio unico contatto con questa azienda.

Non mi sento a mio agio nel fornire una soluzione che so fallirà e non voglio essere conosciuto come lo stupido programmatore che lo fa fallire. Conosco le loro reali esigenze e modelli di utilizzo per questa applicazione perché in passato ho realizzato progetti per loro.

D'altra parte, farlo a modo suo prolungherà il mio contratto più tempo (quindi, più guadagni finanziari) al fine di risolvere i problemi modificando il codice.

Dovrei dimettermi dal progetto sapendo che probabilmente perderò questo client per sempre?

O & # 8230;

Devo prendere la pillola e trarre vantaggio finanziario da un progetto esteso e assumere solo la cattiva fama come costo?

Answer 1

Lo stai guardando da una prospettiva completamente sbagliata. Questa non è una richiesta stupida da parte di un cliente che non sa nulla della tecnologia. È un vincolo di progettazione che ritieni possa comportare rischi nel progetto.

Quindi fai tutto ciò che fai quando riscontri dei rischi in un progetto: definiscilo, valutalo e consiglia una strategia di mitigazione.

• Definisci il rischio. Dire che causerà "problemi di prestazioni". e "non sarà facilmente scalabile" non sta definendo il rischio. Devi specificare esattamente cosa intendi. Cosa non si esibirà e perché? Quali cambiamenti di scala incontreranno questi problemi?
• Valuta il rischio. Ok, quindi pensi che ci sia un problema. Quanto è cattivo? Quanto puoi essere certo che questi problemi di prestazioni accadranno effettivamente? Quale sarà l'impatto sugli utenti se lo fanno? Dici che il programma non può essere ridimensionato: la crescita in scala espone il difetto di progettazione anche nelle carte? Ancora più importante, come lo sai? Qui è dove prendere il tempo per costruire e confrontare un prototipo può farti risparmiare molte discussioni inutili.
• Consiglia una strategia di mitigazione. Qual è il modo giusto per implementarlo? Perché è nel modo giusto? Ancora, come lo sai? Ancora una volta, la prototipazione è tua amica.

Un paio di cose verranno fuori da questo esercizio.

In primo luogo, potresti scoprire che mentre hai ragione su ogni particolare, quando li metti tutti insieme non importa. Sì, questo programma non funzionerà bene o si ridimensionerà bene, ma se nessuno dei suoi casi d'uso previsti si imbatterà in questi problemi, non potrebbe valere la pena risolverli.

In secondo luogo, c'è un mondo di differenza tra dire a qualcuno " Questo non si esibirà, lo so solo " e dicendogli "ho confrontato i casi d'uso che ci aspettiamo e sembra che questo approccio comporti un tempo di risposta di quattro o cinque secondi per transazione dell'utente".

Terzo, se sai quali condizioni faranno fallire il software, e esprimi queste preoccupazioni al cliente, e il cliente dice "Vogliamo davvero che funzioni così", hai scaricato la tua responsabilità. Se fallisce perché il cliente sceglie di non mitigare il rischio che hai identificato, nessuno può indicarti e dire che è stata colpa del programmatore.

Soprattutto, l'evidenza supera l'opinione . Hai incorniciato l'intera domanda come un caso della tua opinione rispetto a quello del cliente. Questa è una proposta persa. Ciò che devi fare è inquadrarlo come " ecco un problema che dobbiamo risolvere. & Quot; E per inquadrare la domanda in questo modo, devi dimostrare l'esistenza del problema e, per questo, hai bisogno di prove.

Alla fine, è il cliente che decide se mitigare o meno un rischio, non tu. Sta a te dargli le migliori informazioni possibili per supportare la sua decisione. E devi chiarire, senza essere un coglione, che è una sua decisione.

Ho scoperto, in più di un'occasione, che una semplice e-mail focalizza perfettamente l'attenzione:

  

Ho rivisto il progetto e penso che qui ci sia un rischio che dobbiamo discutere. [Approccio A] è molto sensibile al volume delle transazioni e sono preoccupato che avremo abbastanza utenti da incorrere in problemi.

     

Ho eseguito un piccolo test usando [Approccio B], ed è molto meno sensibile; nel mio semplice prototipo, sono stato in grado di ottenere da esso transazioni X al secondo. Questo ha senso, perché [confronto tecnico di come i due approcci gestiscono le cose].

     

Sono particolarmente preoccupato per questo perché [descrivi come il programma fallirà se funziona male].

     

Questo mi sembra un problema significativo. Se fossi in me, userei [Approccio B], perché [descrivi come questo approccio mitigherà il rischio].

     

Ma tu hai molta più familiarità con [Approccio A] di me, e rimanderò felicemente alla tua guida su questo argomento. Cosa pensi che dovremmo fare?

Questo messaggio dice molto chiaramente " Se ignori ciò che ti sto dicendo, ecco come il progetto fallirà e avrò la documentazione che dimostra che mi hai detto di farlo in questo modo. " Inoltre, in realtà non dice .

Answer 2

Penso che dovrai sederti con lui e fare alcune domande di chiarimento.

Avrai bisogno del PERCHÉ che vuole averlo implementato in quel modo particolare. Devi dimostrare di voler offrire una soluzione funzionante che soddisfi le esigenze aziendali.

È possibile che ci siano alcune preoccupazioni di fondo, questioni che devono essere affrontate, poiché hai affermato che potrebbe non avere familiarità con le tue tecnologie proposte e ha bisogno di rassicurazioni.

Fallimento che assicura che le cose siano completamente documentate e firmate.

Answer 3

Opzione 1: vattene, hai già una brutta relazione ed è improbabile che migliori.

Tuttavia, non farlo perché vuoi prolungare un contratto, nel migliore dei casi furbo e nel peggiore dei casi disonesto, ma se hai bisogno del contratto ...

Opzione 2: chiedigli di documentare le sue scelte e le ragioni dell'architettura e di firmarle come specifiche. Aggiungi una clausola al contratto dicendo che non garantisci prestazioni e / o scalabilità usando le specifiche che ha prodotto e poi implementalo a modo suo. Inviagli una presentazione del tuo approccio e ragionamento preferiti.

Se il progetto fallisce (potrebbe essere giusto), puoi sempre sottolineare che glielo hai detto e che hai offerto un'alternativa.

Assicurati di implementare la sua architettura in buona fede, cioè non farlo fallire deliberatamente. Fai i primi test che dimostrano il tuo punto e assicurati che sappia che stanno fallendo. Forniscigli chiari avvertimenti scritti durante il ciclo di vita del progetto che sta andando fuori strada.

Buona fortuna. Considera seriamente l'opzione 1. Vale la pena provare un cuore a cuore con il ragazzo.

Answer 4

È possibile creare un piccolo prototipo come un'applicazione per dimostrare che ha torto e che hai ragione? Parlare è molto più semplice se hai prove concrete.

Answer 5

Odio essere la polizia del servizio clienti, ma parlando di questo come una "richiesta stupida da parte del cliente" è probabilmente una cattiva idea a meno che non lo sia (nel qual caso dovresti andartene senza fare domande). Penso che un termine migliore sarebbe "richiesta non informata del cliente".

Considerato ciò, ricorda che probabilmente il tuo cliente ha un vero bisogno e dovresti riconoscerlo (verbalmente a loro). È solo mascherato dalla loro idea (scarsamente informata) di una soluzione. Indaga un po 'e cerca di ottenere ciò che stanno realmente cercando, quindi proponi una soluzione che ritieni migliore e spiega perché sarebbe meglio. E farlo in modo tale da non mettere in discussione la competenza del cliente. Nessuno vuole lavorare con nessuno che li faccia sentire stupidi.

Answer 6

È difficile suggerire passi specifici da fare poiché non conosco i dettagli qui, ma ecco i miei pensieri:

Se lo costruisci ciò che vuole (e non ciò di cui ha bisogno ) e sai che la soluzione è sbagliata, allora sei complice del fallimento di il progetto. Se sai che non funzionerà e non si ridimensionerà e lo costruirai comunque, allora non sorprenderti se finirai per essere il ragazzo "fall" " per il fallimento del progetto e non ottenere più soldi per farlo bene la prossima volta.

Se il ragazzo si arrabbia, potrebbe essere per molte ragioni, una delle quali potrebbe essere che non capisce la tecnologia e questo lo disturba. Ma non conosco la situazione, quindi chi lo sa? Personalmente preferirei arrabbiare il ragazzo e proporre la giusta soluzione e insistere sulla soluzione giusta piuttosto che lasciare che le sue emozioni guidino la barca.

Potrebbe essere il cliente e potrebbe essere in possesso dell'assegno, ma ciò non lo rende intelligente o giusto. I clienti hanno sempre torto, nonostante il vecchio adagio. Ora, puoi avvicinarti a lui nel modo sbagliato o nel modo giusto e potrebbe reagire allo stesso modo ad entrambi. Ma tu vuoi avvicinarti a lui nel modo giusto, indipendentemente.

Se, alla fine, insiste sul fatto che tu lo fai a modo suo e non può sostenere la sua strada con null'altro che affermazioni ed emozioni, mi allontanerei educatamente dal lavoro. I soldi non ne valgono la pena, onestamente. Potrebbe essere arrabbiato con te, ma puoi dormire bene sapendo che tu non hai sprecato i soldi della sua compagnia per una cattiva soluzione al problema.

• Sii onesto.
• Ascolta quello che ha da dire.
• Non lasciare che le sue emozioni offuschino il tuo giudizio.
• Alla fine, fai la cosa giusta.

Almeno, è quello che farei.

Buona fortuna!

Answer 7

Ascolta e impara . Sii sinceramente interessato ai pro e ai contro dell'approccio dei tuoi clienti.

Dichiara il tuo approccio al problema in modo che il cliente possa capire assicurati di documentare anche i pro e i contro del tuo approccio.

Quindi discuti in entrambi i modi di fare cose con il cliente, ma non in un modo "il tuo approccio è stupido e io ho ragione", ma sii sinceramente interessato ai benefici che il suo approccio potrebbe portare .
Se vedi un problema nel suo approccio, chiediglielo . Ma non in un modo 'questo non funzionerà', ma piuttosto essere curioso 'come sarà questa scala'. Non limitarti a indovinare la sua idea, invece conosci i fatti e le cifre "fatti in questo modo, non ci saranno problemi con troppo traffico in questi e questi casi"?

Potresti persino imparare qualcosa. Fai del tuo meglio! Alla fine, potresti doverlo codificare a modo suo, e sarà meglio se davvero capisci le insidie ??!

Answer 8

Fondamentalmente sei solo tu che puoi rispondere a questa domanda. Conosci meglio il tuo cliente e la tua situazione e se riesci a trovare un modo per farlo funzionare, è la tua chiamata.

Personalmente, rifiuterei il progetto. Se vogliono tenerti, spiega perché non puoi accettare il progetto secondo i requisiti stabiliti.

Dì loro che se vogliono tu attuare il progetto, allora assumono la tua competenza, non quella del loro ragazzo nel dipartimento IT .

Answer 9

Se non ti senti a tuo agio, vai via. Siamo stati calunniosi nel fornire una soluzione specifica per i clienti, nonostante i nostri migliori auguri e le migliori raccomandazioni e in futuro non ci ha causato fine al dolore.

Se si tratta di un problema finanziario e tu " hai bisogno di " il business, quindi affronterei sicuramente il progetto da un punto di vista del time-boxing.

Dì loro cosa è possibile ottenere in che tipo di tempistiche. Assicurati di essere pagato in modo modulare mentre raggiungi traguardi diversi. Almeno in questo modo, ti dà l'opportunità di andartene in futuro se diventa un non-vincitore per te.

Un'altra opzione potrebbe essere quella di mostrare loro quanto sarebbe più costoso farlo a modo loro.

Answer 10

Se hai bisogno del cliente, anche lui ha bisogno di te (probabilmente di più). Dopotutto, è lui che ti ha selezionato. È lui che ha bisogno di risolvere un problema.

Prendi una posizione che non ti sarà dettato dalle sue indicazioni su "come" fare un lavoro - che cosa fare è sicuramente la sua chiamata. È probabile che vedrai sciogliersi del ghiaccio.

Answer 11

Consiglierei di provare alcune tattiche di deviazione con lui. Fagli sapere quali sono le tue preoccupazioni con i suoi metodi e offrigli qualche altra soluzione che soddisfi sia i tuoi bisogni che i suoi. Cerca di evitare di essere aggressivo (non dire che ha torto), ma dici che pensi che ci sia una soluzione migliore che integri entrambe le opzioni.

Prova a praticare "judo verbale". Essere conflittuali non ti farà guadagnare punti con lui, e lo renderà più sicuro che stai solo diventando difficile. Accordati con lui, costruisci un rapporto sulle idee comuni e poi guidalo delicatamente lungo il percorso verso la tua soluzione.

Answer 12

Disegna un contratto che contenga le tue preoccupazioni e che le faccia pagare i soldi anche in caso di fallimento a causa di una decisione sbagliata del cliente. Quindi fallo firmare.

Assicurati di eseguire quel contratto da un avvocato esperto, perché è facile sbagliare leggermente in modo che un tribunale ti risolva, se il male peggiora e devi fare causa per i soldi.

Rendi il cliente consapevole di quella parte del contratto prima della firma, forse riconsidererà.

Oppure, invece di affrontare tutti questi problemi, come altri hanno suggerito: cauzione, vai via, o meglio: corri. Piu 'veloce che puoi. A meno che non sia davvero un sacco di soldi, non ne varrà la pena venderlo per questo.

(Modifica: dannazione, Simon mi ha battuto di qualche secondo.)

Answer 13

Proponi la tua soluzione e spiega (con l'aiuto di presentazioni / documentazione ) perché è la migliore. O addirittura ne fa un prototipo.

Il tuo cliente dovrebbe capire, se lo dimostri, di avere una leadership tecnica in quel campo e di fidarti di te.

Answer 14

Salvo il progetto a meno che non avessi fame. Come consulente, sento che l'unico valore che apporto al cliente è la conoscenza che possiedo (e che non lo fanno, altrimenti non mi assumerebbero). Per lavorare su qualcosa che "conosco" fallirà violerebbe il Codice Etico del consulente (se ce ne fosse uno).

Farei del mio meglio per convincere il cliente che la sua strada probabilmente fallirà, e quindi farei del mio meglio per individuare qualcun altro che faccia il lavoro per lui.