Non dovresti mai mentire a un cliente. Del resto, in genere non è una buona idea mentire a nessuno, ma questa è una questione etica più ampia da considerare ulteriormente in un luogo diverso.

Cercare di dire che è "impossibile per la programmazione" fare la probabile scelta indovinare risulterebbe così ovviamente sbagliata che non dovresti nemmeno andarci. Se il cliente può ipotizzare lo scenario dai dati a portata di mano, è possibile che un programma venga scritto per giungere alle stesse conclusioni.

Nel mio lavoro, quando mi imbatto in situazioni simili, normalmente implementerò ciò che il cliente desidera, ma lo aiuterò anche a capire che potrebbero essere necessarie ulteriori misure per ridurre gli errori. In questo scenario il cliente suggerisce qualcosa che migliorerà la produttività del flusso di lavoro. Questo può aiutare a risparmiare tempo sfogliando una finestra di dialogo dell'elenco clienti per selezionare manualmente quello specifico. D'altra parte, una volta che è stato effettuato il commit per inviare la transazione, la programmazione potrebbe notare che è stata utilizzata la scelta del campo compilato automaticamente e che l'importo totale è grande e quindi visualizzare una conferma "sei sicuro" che mostra i dati pertinenti. Un rapido clic di conferma difficilmente interrompe affatto il flusso di lavoro.

Quindi, in conclusione, lavora con il cliente per trovare buone soluzioni invece di provare a dare il tuo giudizio su ciò che è giusto o sbagliato nelle sue idee.

Non è professionale mentire ai propri clienti per proteggerli dal farsi del male. Il tuo cliente non è un bambino, è un adulto e ci si aspetta che sia autorizzato a prendere le proprie decisioni nella vita. Compresi quelli che costeranno loro reputazione, denaro o la loro azienda.

Pensaci se fosse professionale / etico farlo. Vorresti che il tuo medico ti mentisse sui rischi del fumo per "proteggerti da te stesso"? Vorresti che il tuo meccanico ti mentisse sui rischi di non aggiustare il tuo watchamacallit rotto per "proteggerti da te stesso"?

Penso che vorresti che fosse una tua decisione informata. E penso che il tuo cliente vorrà lo stesso.

Il modo professionalmente / eticamente corretto di farlo sarebbe informare accuratamente il cliente di tutti i rischi. Quindi lascia che sopporti questi rischi e lascia che prendano una decisione informata. Non hai il compito di effettuare valutazioni del rischio o decisioni aziendali. È il loro lavoro. Non vuoi che ti dicano come programmare, non dirgli nemmeno come fare il loro lavoro.

Prepara una dichiarazione in cui sia chiaro che vedi quel rischio, in termini semplici in modo che può capirlo. Se vuoi sottolineare l'importanza di questo rischio, puoi provare a farglielo sottoscrivere. Invitali a scrivere qualcosa come "Ho letto e compreso questo rischio, lo voglio comunque implementato".

Se l'unico rischio è che l'azienda perda denaro, questo è tutto ciò che puoi o dovresti fare. Probabilmente è un barattolo di vermi completamente diverso se l'imprenditore sta rischiando qualcosa che non gli appartiene (ad esempio la salute del cliente), ma questa è una domanda diversa e dovrebbe andare da un professionista legale.

Questa non è la tua chiamata da fare. Forse il cliente ha dipendenti ben preparati che hanno insegnato a prestare attenzione. Forse l'errore non è così catastrofico come immagini (ad esempio, la mia banca mi dà 12 ore per annullare qualsiasi transazione che effettuo e trasferimenti insolitamente importanti possono richiedere diversi giorni per essere cancellati). Non dare per scontato che il tuo cliente sia stupido al punto che devi proteggerlo da se stesso.

Informare il tuo cliente del problema è stata una buona cosa da fare. Meglio ancora, potresti suggerire soluzioni che secondo te possono ridurre il rischio. Ad esempio, puoi suggerire che il programma presenti un elenco in cui i clienti sono ordinati per rilevanza, ma l'utente deve ancora fare clic sulla prima riga per confermare. Ma dovrai lasciarlo decidere.

Alla fine, non puoi vendere un'arma a qualcuno e assicurarti che non si sparino sul piede. Vendere armi scadenti non è una ricetta per la sicurezza.

Assolutamente, positivamente, non mentire mai a un cliente. Punto. L'unica eccezione è proteggerti da azioni deliberatamente dannose (per te) da parte del cliente, ma in tal caso faresti meglio a terminare la relazione poiché non puoi fidarti di loro.

cliente che non ha accettato il mio consiglio e ho rifiutato i loro soldi perché non potevo assumermi la responsabilità. Hanno abbandonato sei mesi dopo.)

Gli utenti commettono errori tutto il tempo. Devono disporre di processi aziendali per gestire questo tipo di errore. Chiedere cosa sono e come si inserisce il cambiamento.

Inoltre, incoraggerei caldamente l'opzione "primi 3" o "primi 5" o "migliori qualunque cosa il cliente voglia". Quando chiedi informazioni sulle loro pratiche commerciali per correggere questi errori, suggerisci che la tua comprensione della neurologia e psicologia umana suggerisce che dare una sola opzione comporterà un aumento del tasso di errore poiché il suggerimento principale non sarà sempre quello giusto, ma più spesso è giusto più persone presumeranno che sia giusto. In altre parole, migliore è la tua prima ipotesi, più spesso riceverai errori perché le persone si fidano anche quando è sbagliato.

No, non va bene mentire, perché la tua reputazione è importante. Custodiscilo con la tua vita. La reputazione ha a che fare con le cose che fai, ma anche con le cose che permetti al tuo cliente che potrebbero costare te in seguito, in termini di responsabilità professionale.

Puoi " essere costretto a fare il lavoro. Ricordalo.

Puoi anche specificare le condizioni in base alle quali sarai disposto a fare il lavoro. In questo caso, hai una funzione ad alto rischio che il tuo cliente vuole che venga eseguita in un certo modo. In una certa misura, va bene. Il tuo cliente non sta chiedendo nulla di illegale o non etico, solo stupido. Quindi ecco cosa fare:

• Requisiti funzionali. TU documenti la funzionalità specifica che il cliente richiede, come la intendi tu.
• Valutazione del rischio. Ancora una volta, TU documenta i potenziali rischi che prevedi che il cliente possa incontrare una volta che questo sistema sarà operativo
• Rinuncia. Questa è la parte importante . Prima di eseguire il lavoro, chiedi al tuo cliente di firmare una rinuncia di responsabilità per tutto ciò che va storto a seguito dell'implementazione dei requisiti di funzionalità che hai delineato nella prima fase. Dovrebbe indennizzare - in particolare: tu, per nome; tutti gli altri nella tua azienda che lavorano su questo pezzo, per nome; l'azienda; la tua compagnia di assicurazioni (presumo che tu abbia un'assicurazione!) contro qualsiasi reclamo legale. Fai esaminare la tua rinuncia da un avvocato e assicurati che sia a tenuta. Non eseguire il lavoro a meno che il cliente non si disconnetta.

Se salti questi passaggi critici, potresti essere aperto a molte esposizioni finanziarie come risultato.

Hai già spiegato i rischi al cliente e il cliente ha insistito affinché tu facessi le cose a modo suo.

Fallo a modo suo. In questo caso, segui la regola d'oro: chi ha l'oro fa le regole. Il cliente paga per i tuoi servizi e finché paga, i tuoi servizi sono ciò che ottiene. Questa relazione transazionale termina nel momento in cui il cliente smette di pagare.

Sei l'appaltatore del cliente. Non sei la baby sitter o il genitore del cliente. I clienti hanno il diritto di ignorare le tue obiezioni e prendere le loro decisioni sbagliate. Obiettivo per la cronaca ed entrare in modalità CYA documentando la tua obiezione.

NON mentire mai al cliente per qualsiasi motivo, perché se la tua bugia viene mai documentata, ti perseguiterà ovunque tu vada. La tua credibilità personale e professionale verrà colpita e questo avrà un impatto sulla tua capacità di guadagnarti da vivere.

Proteggere le persone da se stesse non vale la pena, soprattutto se il risultato sarà che sarai incolpato di tutto ciò che va storto. E più ti difendi, più sembri losco, non importa quanto siano validi o validi i tuoi argomenti. Non sei un missionario, non sei un benefattore, non hai il compito di salvare anime e di certo non vuoi finire come un martire, in particolare un martire per una causa a cui non credi in. Lascia perdere.

Non mentire loro. Di 'loro che puoi fare quello che vogliono che tu faccia, ma non lo vuoi fare. Spiega loro il motivo e suggerisci soluzioni diverse, più a prova di errore (o a prova di pigro).

Conoscendo il mio cliente, non ascolterà le mie argomentazioni.

Forse stai usando un linguaggio che non possono capire. Suppongo che siano focalizzati sull'economia, quindi profitti, rischi e commissioni sono argomenti che capirebbero.

1. Usa il loro flusso di lavoro effettivo, il flusso di lavoro che richiedono e il flusso di lavoro che suggerisci.
2. Stimare il tempo per elaborare, ad esempio, 1000 transazioni e moltiplicarlo per lo stipendio del Joe medio.
3. Calcola i risparmi dei loro e tuoi miglioramenti rispetto al flusso di lavoro effettivo.
4. Stima la probabilità di false supposizioni e plausibilità di una transazione sbagliata.
5. Stima la perdita finanziaria derivante dalla transazione sbagliata: denaro sprecato, reputazione danneggiata, contraente perso, ...
6. Moltiplica la perdita finanziaria per la sua probabilità e 1 000 (dimensione del campione)
7. Confronta i salvataggi del passaggio 3 e le perdite del 6. Sottolinea che le perdite stimate sono le perdite minime prevedibili.
8. Fai tutto scritto e costringerli a firmare la dichiarazione "Ho letto e compreso". Discuti con il tuo avvocato preferito su come formulare l'affermazione di essere a prova di avvocato creativo.
9. Fai in modo che accetti che ti assumi la responsabilità del funzionamento della funzione come richiesto, ma non ti assumi alcuna responsabilità per il risultati della funzione.
10. Se vogliono ancora avere questa funzione scadente e ha rovinato i loro affari, se lo sono meritato. E hai una carta per difenderti.

Non mentire, piuttosto concorda con il bisogno di efficienza del cliente e suggerisci salvaguardie di implementazione per l'azione:

• aggiungi la transazione a una coda, dando all'utente il tempo di riflettere e modificare o eliminare la transazione

• supportano l'annullamento lineare, come si troverebbe nei prodotti finanziari transazionali

Idealmente, i clienti coglierebbe questi scenari e avrebbe stabilito protocolli per affrontarli. Quando non lo fanno, un architetto dovrebbe vederli e sviluppare protocolli funzionali. Quando uno sviluppatore coglie la scappatoia, non c'è davvero altra scelta che alzare una bandiera, progettare una poltrona o semplicemente costruire quella dannata cosa.

Sono d'accordo con tutte le risposte "non mentire al cliente", ma ho una soluzione forse diversa: potresti, senza impegnarti troppo nello sviluppo, tenere traccia delle decisioni prese? Con che frequenza viene accettata l'impostazione predefinita? Per quantità di trasferimento, per ora del giorno, per utente, ecc. Ciò potrebbe fornire loro un modo per prendere decisioni lungo la strada: modificare il software o aumentare la formazione, ecc.

Puoi Non li eviti di prendere decisioni sbagliate sull'argomento, ma puoi fornire loro informazioni sufficienti che possano dire: a) se la loro decisione non funziona come si aspettano eb) quali errori sono dovuti agli utenti e quali sono gli errori a causa dell'algoritmo di scelta predefinito.

Solo un pensiero.

Spiega le tue preoccupazioni con il design dell'interfaccia utente suggerito. Salvarsi dai propri errori spiegandoli e aiutandoli a risolvere il problema in modo diverso fa probabilmente parte del tuo lavoro di esperto. Salvarli da se stessi mentendo è meno utile in molti modi. Il più grande è che non li induce in quanto è pericoloso, quindi potrebbero semplicemente trovare qualcun altro per implementare la loro cattiva idea.

Se sono in gioco vite e pensi che il tuo cliente farà qualcosa questo metterà seriamente in pericolo altre persone (o l'ambiente, o qualsiasi altra cosa), quindi forse bloccarle mentre contatti un'autorità. Se si danneggiano solo da soli, allora fai del tuo meglio per spiegare il potenziale di danno.

Come esempio di come risolvere questo problema in un modo che è meno probabile che porti a cattiveria:

invece di visualizzare solo una migliore corrispondenza con la più alta probabilità secondo la tua euristica, fai apparire i primi 3 .

Potresti o potresti non voler mostrare un qualche tipo di "livello di confidenza" nella tua ipotesi, come la selezione A: 95, la selezione B: 44, la selezione C: 33. Potresti volerlo evidenziare quando la seconda possibilità più alta è vicina alla più alta, come A: 45, B: 40, C: 30. (IDK se vuoi ridimensionarli a probabilità percentuali o mostrarli come punteggi indipendenti dalla tua euristica.)

As @bishop fa notare, mettere in coda la transazione per un breve periodo consentirà un annullamento, poiché è facile rendersi conto di aver fatto clic sulla cosa sbagliata mentre la fai clic se stai operando in parte in automatico -pilot.

PS, questa parte della risposta è un workarou nd per questo caso specifico e non fa parte della risposta del caso generale.

Non mentirei mai al cliente. Invece dovresti dare loro un'alternativa. La migliore alternativa a cui posso pensare sarebbe che l'utente digiti il ​​nome del client invece di premere semplicemente "ok". Ciò costringe l'utente a usare piuttosto il proprio cervello e impedisce una sorta di errore di clic. Puoi anche dare loro una pagina di conferma dopo che hanno digitato il nome del cliente dove fa clic su "ok" e dare loro la possibilità di cambiare la loro risposta, se necessario. Ecco un elenco per te, anche se un diagramma di sequenza funzionerebbe molto meglio.

Processo:

1. L'utente fa clic su una pagina che decide quale client è più probabile
2. La pagina presenta il nome del client all'utente, ma l'utente deve digitare il nome del client per continuare. Facoltativamente, possono fare clic su "No" (o un pulsante con un altro testo) per inserire un diverso nome client del programma non era corretto. Se fanno clic su no, digitano manualmente il nome del client, il sistema lo confronta con un client esistente o solleva un'eccezione se nessun client corrisponde e gestisce questa eccezione con garbo.
3. Dopo aver digitato il nome, il client fa clic "ok".
4. Questo porta il cliente a una pagina di conferma, che gli dice a quale cliente sta inviando denaro. Fanno clic su "ok" qui e il denaro viene inviato.

Non mentire al cliente. Spiega loro quali sono le tue paure riguardo a questa funzione.

Se ritieni che sia appropriato, potresti decidere di rifiutarti personalmente di implementare questa funzione. Sì, è la scelta del cliente che lo voglia o no, ma è anche una tua scelta come programmatore se vuoi svilupparlo. Ovviamente dovrai considerare attentamente i termini del contratto se scegli di rifiutare di fare ciò che il cliente vuole in questo caso.

Nel discorso "non solo code monkeys", Martin Fowler ha sostenuto che i programmatori dovrebbero avere di più riguardo alle conseguenze del loro lavoro.

Se i programmatori avessero un'organizzazione di appartenenza professionale più forte, come fanno professioni come avvocati, medici, architetti e ingegneri, saremmo in una posizione più forte per rifiutare alcune richieste sul base che sono contrari agli standard professionali.

Questa domanda si basa direttamente sulla CS e sull'etica. Questa è probabilmente una risposta scadente per il posto di lavoro, ma una buona risposta se questa domanda è stata posta su stackoverflow o CS. Affermo che la domanda non si adatta bene al posto di lavoro e la risposta è adatta alla domanda. Di conseguenza, la risposta si applica alla domanda esatta posta ma ha una portata molto limitata alle domande che sembrano corrispondere.

Hai ragione quando dici che l'ipotesi non sarebbe accurata al 100%. Diciamo d'altra parte che possiamo fare meglio della maggior parte degli umani quasi tutto il tempo. (Se questo non è il caso, il resto di questa risposta è una sciocchezza totale.)

Per affrontare la situazione hai bisogno di una funzione di fiducia che dica quanto è buona la tua ipotesi. Questa non è una cosa banale da ottenere, ma quasi sempre esiste. L'idea è di sapere con sicurezza quanto sia affidabile la tua ipotesi in ogni caso specifico. Se la tua ipotesi è sufficientemente affidabile, visualizza l'ipotesi. Se l'ipotesi è altamente affidabile, seleziona l'impostazione predefinita in modo che OK funzioni da solo. Se la tua ipotesi è inaffidabile, non visualizzarla.

Per motivi che implicano responsabilità, preferisco impostare l'affidabilità per mostrare all'80% e affidabile per impostazione predefinita dal 99% al 99,9%. Presupposto: l'1% dell'inserimento manuale dei dati non è corretto. Inoltre, codenoir è molto corretto riguardo alla rinuncia. Non devi essere responsabile per le decisioni sbagliate dell'utente. Anche se puoi essere molto meglio degli umani quasi sempre, non puoi permetterti di assumerti la responsabilità. Le persone non tollerano l'errore della macchina in tribunale tanto quanto l'errore umano.