Qual è la relazione corretta tra lo sviluppatore del software e il cliente commerciale?

È un po 'più complicato che nei tuoi esempi. Questo perché in molti casi, lo sviluppatore del software è un esperto di cose relative all'IT (ad es. Programmazione, progettazione di database ecc.), Ma il cliente aziendale è un esperto nel dominio del problema. In questi casi, la relazione corretta è quella di due esperti in diversi campi che lavorano insieme per creare una buona soluzione.

Comunque, come ogni buon artigiano, lo sviluppatore del software è obbligato ad avvisare il cliente quando i clienti vogliono cose che non sono appropriate. Se chiedi al tuo pittore e decoratore di tappezzare il bagno, è anche obbligato ad avvisarti che questo non funzionerà bene. Ma quando il cliente insiste ostinatamente sulla sua cattiva idea, va bene farsi firmare un modulo "sei stato esplicitamente avvisato" e attuare ciò che vuole (purché non ci siano rischi per la salute, rischi legali ecc.).

Sia negli esempi di medico che di ingegnere, il professionista è un consulente che si rifiuta di eseguire un servizio. In un negozio di informatica, non lo sei.

Siamo dipendenti, non consulenti, quindi siamo soggetti alla regola d'oro: colui che ci dà le regole d'oro. I programmatori che ignorano questo sono arroganti e folli. Ho sentito innumerevoli lamentele a proposito di uomini d'affari che sono stufi del personale IT che non spiegherà le loro decisioni a nessuno al di fuori del loro sacerdozio insulare e che respingono richieste che tutti, al di fuori della loro organizzazione, considerano perfettamente ragionevoli. Ho visto i responsabili IT licenziati su questo genere di cose.

Come dipendente, il tuo equivalente a un consulente che si rifiuta di eseguire un servizio è coperto da una citazione di Napoleon Bonaparte:

Every commander responsible for executing a plan that he considers bad or disastrous is criminal. He must point out the flaws, insist that it be changed and at last resort resign rather than be the instrument of the destruction of his own men.

Devi scegliere le tue battaglie. È quello che ti è stato chiesto di fare così atroce e immorale che preferiresti smettere? Altrimenti, allora spiega il problema agli stakeholder e negozia qualcosa di ragionevole, o fallo e basta.

E non andare a fare cose su cui non ti sei comprato. Le persone che lo fanno si chiamano "loose cannons".

Per inciso, ho lasciato un lavoro perché hanno ucciso un progetto e ho pensato che fosse una mossa davvero stupida. Un paio di mesi dopo che me ne sono andato, sono venuti per mettermi d'accordo con me e mi hanno chiesto di tornare come appaltatore per fare il progetto, ma ero già stato impegnato altrove.

I medici prestano giuramento di 'non nuocere' e sono legalmente obbligati a mettere l'interesse del paziente prima . Un medico che ha eseguito un'operazione inutile e dannosa (anche se il paziente lo richiedeva) si sarebbe presentato con una causa per negligenza e potrebbe perdere la patente.

Allo stesso modo, un ingegnere civile, responsabile di un progetto di costruzione, ha l'obbligo legale di assicurarsi che rispetti tutti i codici di costruzione applicabili. Come con il medico, un ingegnere che fa ciò che è suggerito nella domanda, probabilmente dovrà affrontare un'azione legale.

Questo è molto diverso dalla situazione di uno sviluppatore di software che viene invitato a fare qualcosa che sanno essere poco pratico. Non ci sono implicazioni legali nell'assumere un progetto, anche se sai che è essenzialmente uno spreco di denaro.

Detto questo, uno sviluppatore di software dovrebbe sempre fornire i suoi migliori consigli su qualsiasi progetto. Tuttavia, se le persone che pagano le bollette non sono disposte ad ascoltare e insistono su un comportamento imprudente, lo sviluppatore non ha alcun obbligo morale o legale di rifiutare.

Shouldn't the same apply to IT professionals when the IT professional is qualified to make the decision but his customer is not?

Secondo me SÌ!

Se hai una relazione lunga con il tuo cliente.

Il mio suggerimento in questa situazione sarà di avvertire il cliente in comunicazioni scritte e di conservarne una copia (e-mail, qualsiasi accordo). Se il cliente insiste, andare avanti e farlo (a volte è noto come disaccordo e commit). Assicurati solo che se succede qualcosa di brutto, dovresti essere in grado di difenderti correttamente.

La differenza principale è la licenza. Medici e ingegneri civili hanno licenze professionali e hanno bisogno di loro per svolgere il loro lavoro e guadagnarsi da vivere, e hanno anche la responsabilità personale legale per più cose.

Questo può mettere più pressione sui medici e gli ingegneri, quando sono spinti a fare qualcosa che potrebbe causare loro un rischio personale e professionale, ma dà loro più respingimento, dal momento che possono sostenere che non possono fare qualcosa a causa di professionisti etica, e che perderanno le loro licenze se lo faranno. Una minaccia per licenziare un ingegnere civile per essersi rifiutata di firmare un piano perde vigore quando la conseguenza della firma è che l'ingegnere perderà la sua patente e non sarà comunque in grado di lavorare sul campo.

Questo è collegato ai requisiti legali. Non posso prescrivere molti farmaci e se faccio certe cose a qualcuno che un medico può legalmente commetterei un crimine. Allo stesso modo, la maggior parte dei governi qui intorno non permetterà a un'azienda di costruire un ponte senza un ingegnere civile autorizzato che approvi il progetto.

Ci sono state proposte per licenziare programmatori, ma nessuno di cui sono a conoscenza è mai andato da nessuna parte. Probabilmente sarebbe necessario avere un requisito legale per far sì che i programmatori concessi in licenza lavorino per primi sui progetti, e ciò non accadrà presto. Ci sono organizzazioni professionali con codici etici paragonabili ai codici medici o ingegneristici, ma senza alcuna forza legale sono più come guide per i codici etici personali.

Non sto pensando alla dimensione etica, ma il corretto rapporto con il cliente / utente può essere abbastanza variabile a seconda del tipo di mercato. Dove lavoro, abbiamo un prodotto altamente tecnico e utenti altamente tecnici e il ricavo medio per cliente è piuttosto alto. Quindi i nostri confini aziendali sono un po 'sfocati: abbiamo clienti e rivenditori a valore aggiunto che fungono da consulenti, che assistono nella verifica del codice e possono persino inviare moduli da includere nel software. Stavamo vendendo un'applicazione per il mercato di massa che questo modello non avrebbe assolutamente senso.