Які належні стосунки між розробником програмного забезпечення та бізнес-клієнтом?

ІТ-фахівці - це експерти, яким довіряють ІТ-активи бізнесу чи організації. Як надійні професіонали, ми несемо відповідальність, яка виходить за рамки речей, які, як можна очікувати, зрозуміти або усвідомлювати клієнт, який не є ІТ. Тому я вважаю, що належні відносини між ІТ-фахівцем та його внутрішніми / зовнішніми замовниками більше схожі на стосунки лікаря та пацієнта, ніж службовця та господаря. Чи правий я?

Ось аналогія для роздумів. Пацієнт наполягає на тому, що ногу потрібно ампутувати. Його лікар не погоджується, але пацієнта не можна переконати. Чи повинен лікар ампутувати ногу просто для задоволення пацієнта?

Ще одна аналогія. Замовник хоче, щоб будівельний інженер побудував міст до небезпечної конструкції. Навіть коли інженер пояснює, що це небезпечно, замовник йому не вірить. Чи повинен інженер взагалі будувати міст?

Я думаю, що правильна відповідь в обох цих аналогіях - НІ. Слід вважати, що медичний та інженер-спеціаліст може бути в довірі і повинен виконувати власне рішення, навіть за умови невдоволення пацієнта / замовника. Чи не повинно те ж саме стосуватися ІТ-фахівців, коли ІТ-професіонал кваліфікований для прийняття рішення, але його клієнт ні?

Це трохи складніше, ніж у ваших прикладах. Це тому, що в багатьох випадках розробник програмного забезпечення є фахівцем у галузі ІТ-питань (наприклад, програмування, розробки баз даних тощо), але бізнес-клієнт - це експерт у галузі проблем. У таких випадках належні стосунки стосуються двох експертів у різних галузях, які працюють разом, щоб створити хороше рішення.

У будь-якому випадку, як і будь-який хороший майстер, розробник програмного забезпечення зобов’язаний попередити клієнта, коли клієнти хочуть невідповідних речей. Якщо ви попросите свого художника та декоратора наклеїти шпалери на ванну, він також зобов’язаний попередити вас, що це не вийде добре. Але коли клієнт вперто наполягає на своїй поганій ідеї, нормально, щоб він підписав бланк "вас чітко попередили" та здійснив те, що він хоче (доки у цьому немає ризику для здоров'я, юридичного ризику тощо).

Як у прикладах лікаря, так і в інженера, професіонал - це консультант, який відмовляється від надання послуги. В ІТ-магазині ти не є.

Ми співробітники, а не консультанти, тому ми підпадаємо під золото правило: той, хто дає нам золоті правила. Програмісти, які ігнорують це, зарозумілі та нерозумні. Я чув численні скарги на це від бізнесменів, котрих надоїли працівники ІТ, які не пояснюватимуть свої рішення нікому, що не належить до їхнього опікунського священства, і які звертаються з проханням до всіх, хто знаходиться поза їх організацією, вважає цілком розумним. Я бачив ІТ-менеджерів, звільнених від подібних речей.

Як працівник, ваш еквівалент консультанту, який відмовляється від надання послуги, охоплюється цитатою Наполеона Бонапарта:

Кожен командир, відповідальний за виконання плану, який він вважає поганим чи згубним, є злочинним. Він повинен вказувати на недоліки, наполягати на тому, щоб це було змінено і, нарешті, пішов у відставку, а не був інструментом знищення його власних людей.

Ви повинні вибрати свої битви. Це те, що вас попросили зробити настільки грізним і неетичним, що ви хочете скористатися? Якщо ні, то або поясніть проблему зацікавленим сторонам, і домовіться про щось розумне, або просто зробіть це.

І не продовжуйте робити те, чого ви ще не придбали. Людей, які роблять це, називають "пухкими гарматами".

Я, до речі, кинув одну роботу, бо вони вбили проект, і я подумав, що це дійсно дурний крок. Через пару місяців після того, як я пішов, вони прийшли домовитись зі мною і попросили повернутися як підрядник, щоб зробити проект, але я вже був зобов'язаний в іншому місці.

Лікарі приймають присягу «робити ніякої шкоди» і законом зобов'язані поставити найкращі інтереси пацієнта першим . Лікар, який здійснив непотрібну і шкідливу операцію (навіть якщо цього вимагав пацієнт), відкрився б до справи про неправомірні дії і може втратити ліцензію.

Аналогічно, інженер-будівельник, відповідальний за будівельний проект, має юридичне зобов'язання забезпечити його відповідність усім діючим будівельним нормам. Як і у випадку з лікарем, інженер, який виконує те, що пропонується у питанні, швидше за все, би загрожував судовим позовом.

Це дуже відрізняється від ситуації, коли розробника програмного забезпечення вимагають зробити щось, що вони знають, непрактично. Немає юридичних наслідків для прийняття проекту, навіть якщо ви знаєте, що це по суті марнотрата грошей.

Однак, розробник програмного забезпечення повинен завжди надавати свої найкращі поради щодо будь-якого проекту. Однак якщо люди, які платять рахунки, не бажають слухати та наполягають на нерозумному ході дій, забудовник не має моральних чи юридичних зобов'язань відмовлятись.

Чи не повинно те ж саме стосуватися ІТ-фахівців, коли ІТ-професіонал кваліфікований для прийняття рішення, але його клієнт ні?

На мою думку ТАК!

Якщо ви збираєтеся мати довгі стосунки зі своїм клієнтом.

Моєю пропозицією в цій ситуації буде попередити замовника в письмовій комунікації та зберігати його копію (електронною поштою, домовитися про що завгодно). Якщо замовник наполягає на цьому, то продовжуйте робити це (це іноді називають незгодою і зобов'язанням). Просто переконайтесь, що якщо трапиться якась погана річ, ви повинні належним чином захистити себе.

Ключова відмінність - ліцензування. Лікарі та цивільні інженери мають професійні ліцензії та потребують їх для виконання своєї роботи та заробітку на життя, а також вони несуть юридичну особисту відповідальність за більше речей.

Це може чинити більший тиск на лікарів та інженерів, коли їх підштовхують до того, щоб робити щось, що може спричинити їх особистий та професійний ризик, але це дає їм більше відштовхування, оскільки вони можуть стверджувати, що вони не можуть щось зробити через професійну етику, і що вони втратять свої ліцензії, якщо вони дійдуть. Загроза пожежним інженером-цивільником за відмову від підпису на план втрачає силу, коли наслідком підписання є те, що інженер втратить ліцензію і не зможе працювати в полі в будь-якому випадку.

Це пов'язано з юридичними вимогами. Я не можу призначити багато ліків, і якщо я роблю певні речі комусь, що лікар може законно зробити, я скоїв злочин. Аналогічно, більшість урядів тут не дозволить компанії будувати міст, без ліцензованого інженера-будівельника не затвердити проект.

Були пропозиції щодо ліцензійних програмістів, але жоден, про який я знаю, ніколи не пішов. Ймовірно, буде необхідна юридична вимога мати перших ліцензованих програмістів для роботи над проектами, і це не скоро відбудеться. Існують професійні організації з етичними кодексами, порівняними з медичними чи інженерними кодексами, але без будь-якої юридичної сили вони більше схожі на посібники з персональних етичних кодексів.

Я не думаю про етичний вимір, але належне ставлення до бази клієнтів / користувачів може бути досить різним, залежно від типу ринку. Там, де я працюю, у нас є високо технічний продукт та високо технічні користувачі, а середній дохід на кожного клієнта досить високий. Тож кордони нашого бізнесу дещо розмиті: у нас є клієнти та торговельні посередники з доданою вартістю, які виступають консультантами, які допомагають в оформленні коду і можуть навіть подавати модулі для включення в програмне забезпечення. Якби ми продавали додаток на масовому ринку, ця модель не мала б сенсу.