Quelle est la bonne relation entre le développeur de logiciels et le client professionnel?

Les professionnels de l'informatique sont des experts qui font confiance aux actifs informatiques d'une entreprise ou d'une organisation. En tant que professionnels de confiance, nous avons des responsabilités qui vont au-delà des choses qu'un client non informatique peut être censé comprendre ou connaître. Je pense donc que la bonne relation entre un professionnel de l'informatique et ses clients internes / externes ressemble plus à celle entre un médecin et un patient qu'à un serviteur et un maître. Ai-je raison?

Voici une analogie à laquelle réfléchir. Un patient insiste sur le fait que sa jambe doit être amputée. Son médecin n'est pas d'accord mais le patient ne peut pas être convaincu. Le médecin doit-il amputer la jambe juste pour satisfaire le patient?

Une autre analogie. Un client souhaite qu'un ingénieur civil construise un pont vers une conception dangereuse. Même lorsque l'ingénieur explique qu'il n'est pas sûr, le client ne le croit pas. L'ingénieur devrait-il quand même construire le pont?

Je pense que la bonne réponse dans ces deux analogies est NON. Le professionnel de la santé et le professionnel de l'ingénierie sont censés être en position de confiance et doivent exercer leur propre jugement, même face à la désapprobation du patient / client. La même chose ne devrait-elle pas s'appliquer aux professionnels de l'informatique lorsque le professionnel de l'informatique est qualifié pour prendre la décision mais que son client ne l'est pas?

C'est un peu plus compliqué que dans vos exemples. En effet, dans de nombreux cas, le développeur de logiciels est un expert dans les domaines liés à l'informatique (à savoir la programmation, la conception de bases de données, etc.), mais le client professionnel est un expert dans le domaine problématique. Dans de tels cas, la bonne relation est celle de deux experts dans des domaines différents qui travaillent ensemble pour créer une bonne solution.

Quoi qu'il en soit, comme tout bon artisan, le développeur du logiciel est obligé d'avertir le client lorsque le client veut des choses inappropriées. Si vous demandez à votre peintre et décorateur de tapisser la salle de bain, il est également obligé de vous avertir que cela ne fonctionnera pas bien. Mais lorsque le client insiste obstinément sur sa mauvaise idée, il est acceptable de lui faire signer un formulaire "vous avez été explicitement averti" et de mettre en œuvre ce qu'il veut (tant qu'il n'y a pas de risque pour la santé, de risque juridique, etc.).

Dans les exemples du médecin et de l'ingénieur, le professionnel est un consultant qui refuse d'exécuter un service. Dans un magasin informatique, vous ne l'êtes pas.

Nous sommes des employés, pas des consultants, nous sommes donc soumis à la règle d'or: celui qui nous donne des règles d'or. Les programmeurs qui ignorent cela sont arrogants et stupides. J'ai entendu d'innombrables plaintes à ce sujet de la part de gens d'affaires qui en ont assez du personnel informatique qui n'expliqueront pas leurs décisions à quiconque en dehors de leur sacerdoce insulaire et qui rejetteront les demandes que tout le monde en dehors de leur organisation considère comme parfaitement raisonnables. J'ai vu des responsables informatiques limogés sur ce genre de choses.

En tant qu'employé, votre équivalent d'un consultant refusant d'exécuter un service est couvert par une citation de Napoléon Bonaparte:

Tout commandant responsable de l'exécution d'un plan qu'il juge mauvais ou désastreux est un criminel. Il doit signaler les défauts, insister pour qu’ils soient modifiés et, finalement, démissionner plutôt que d’être l’instrument de la destruction de ses propres hommes.

Vous devez choisir vos batailles. Est-ce que l'on vous a demandé de faire si haineux et contraire à l'éthique que vous préférez arrêter? Sinon, expliquez le problème aux parties prenantes et négociez quelque chose de raisonnable, ou faites-le simplement.

Et n'allez pas faire des choses sur lesquelles vous n'avez pas obtenu de rachat. Les gens qui font cela sont appelés "canons lâches".

Soit dit en passant, j'ai quitté un emploi parce qu'ils ont tué un projet et j'ai pensé que c'était une décision vraiment stupide. Quelques mois après mon départ, ils sont venus d'accord avec moi et m'ont demandé de revenir en tant qu'entrepreneur pour faire le projet, mais j'étais déjà engagé ailleurs.

Les médecins prêtent serment de «ne pas nuire» et sont légalement tenus de faire passer le meilleur intérêt du patient en premier . Un médecin qui a effectué une opération inutile et nuisible (même si le patient l'exigeait) s'ouvrirait à une poursuite pour faute professionnelle et pourrait perdre son permis.

De même, un ingénieur civil, responsable d'un projet de construction, a l'obligation légale de s'assurer qu'il respecte tous les codes du bâtiment applicables. Comme pour le médecin, un ingénieur qui fait ce qui est suggéré dans la question serait probablement poursuivi en justice.

Ceci est très différent de la situation d'un développeur de logiciels qui est invité à faire quelque chose qu'il sait impossible à réaliser. Il n'y a aucune ramification juridique à entreprendre un projet, même si vous savez qu'il s'agit essentiellement d'un gaspillage d'argent.

Cela dit, un développeur de logiciels devrait toujours fournir ses meilleurs conseils sur tout projet. Cependant, si les personnes qui paient les factures ne veulent pas écouter et insistent sur une ligne de conduite imprudente, le développeur n'a aucune obligation morale ou légale de refuser.

La même chose ne devrait-elle pas s'appliquer aux professionnels de l'informatique lorsque le professionnel de l'informatique est qualifié pour prendre la décision mais que son client ne l'est pas?

À mon avis OUI!

Si vous allez avoir une longue relation avec votre client.

Ma suggestion dans cette situation sera d'avertir le client par communication écrite et d'en conserver une copie (e-mail, accord quoi que ce soit). Si le client insiste, alors allez-y et faites-le (cela est parfois appelé désaccord et engagement). Assurez-vous simplement que si une mauvaise chose se produit, vous devriez être en mesure de vous défendre correctement.

La principale différence est l'octroi de licences. Les médecins et les ingénieurs civils détiennent des licences professionnelles et en ont besoin pour effectuer leur travail et gagner leur vie, et ils ont également la responsabilité juridique personnelle de plus de choses.

Cela peut mettre plus de pression sur les médecins et les ingénieurs, lorsqu'ils sont poussés à faire quelque chose qui peut leur causer un risque personnel et professionnel, mais cela leur donne plus de recul, car ils peuvent affirmer qu'ils ne peuvent pas faire quelque chose en raison de l'éthique professionnelle, et qu'ils perdront leurs licences s'ils le font. Une menace de licencier un ingénieur civil pour avoir refusé de signer un plan perd sa force lorsque la conséquence de la signature est que l'ingénieur perdra son permis et ne pourra de toute façon pas travailler sur le terrain.

Ceci est lié aux exigences légales. Je ne peux pas prescrire beaucoup de médicaments, et si je fais certaines choses à quelqu'un qu'un médecin peut légalement faire, je commets un crime. De même, la plupart des gouvernements d'ici ne permettront pas à une entreprise de construire un pont sans qu'un ingénieur civil agréé approuve la conception.

Il y a eu des propositions pour octroyer des licences aux programmeurs, mais aucune, à ma connaissance, n'est allée nulle part. Il serait probablement nécessaire d'avoir une obligation légale d'avoir des programmeurs sous licence pour travailler d'abord sur des projets, et cela ne se produira pas de si tôt. Il existe des organisations professionnelles avec des codes d'éthique comparables aux codes médicaux ou d'ingénierie, mais sans aucune force juridique, ils ressemblent davantage à des guides de codes d'éthique personnels.

Je ne pense pas à la dimension éthique, mais la bonne relation avec la base clients / utilisateurs peut être assez variable selon le type de marché. Là où je travaille, nous avons un produit hautement technique et des utilisateurs hautement techniques, et le revenu moyen par client est assez élevé. Nos frontières commerciales sont donc un peu floues: nous avons des clients et des revendeurs à valeur ajoutée qui agissent en tant que consultants, qui aident à la vérification du code et peuvent même soumettre des modules à inclure dans le logiciel. Si nous vendions une application grand public, ce modèle n'aurait aucun sens.