Як протистояти тиску, пояснити свої міркування і дотримуватися своєї особистої та професійної етики.
Розробниця програмного забезпечення розповіла, що її керівник проєкту сказав їй: «Щоб зекономити час, я не хочу, щоб ти робила юніт-тестування». Вона була шокована такою вказівкою. Як досвідчена розробниця, Чізуко знала, що юніт-тестування завершених частин коду перед їх інтеграцією у основну гілку є важливим для перевірки правильності реалізації коду.
Керівник Чізуко спонукав її піти на компроміс із якістю, марно сподіваючись, що це пришвидшить її роботу. Можливо, це й справді заощадило б Чізуко трохи часу, однак пропуск юніт-тестування, безсумнівно, призвів би до того, що дефекти були б виявлені пізніше ніж слід, — у момент, коли їх усунення є складнішим і дорожчим. Треба віддати Чізуко належне: вона все ж вирішила провести юніт-тестування, поставивши свої професійні стандарти вище за хибну вказівку.
Я вже давно переконаний, що ми ніколи не повинні дозволяти нашим керівникам, замовникам чи колегам схиляти нас до виконання роботи неякісно. Дотримання власних принципів і професійної етики є питанням особистої та професійної доброчесності.
Кожен із нас повинен прагнути дотримуватися найкращих відомих нам професійних практик, адаптуючи їх таким чином, щоб вони були ефективними в кожній конкретній ситуації.
Припустімо, вас змушують робити те, що викликає у вас професійний дискомфорт. Сформулюйте свою відповідь так, щоб уникнути виконання завдання, яке, на вашу думку, означало б «погано зроблену роботу», пояснивши свої міркування та занепокоєння. Залишайтеся відкритими до можливості, що ви помиляєтеся. Можливо, вимога насправді не є ні необґрунтованою, ні недоречною. Ви маєте право отримати пояснення, яке переконає вас у доцільності прохання. Якщо вам не надали достатніх аргументів, щоб переконати, вам потрібно вирішити – чи погодитися, чи вибрати те, що ви вважаєте кращим варіантом дій.
Як і в багатьох інших випадках, філософію непокори можна довести до такого крайнього рівня, коли вона перестає бути корисною.
Варто шукати точку балансу між досягненням професійної досконалості та збереженням доброчесності, уникаючи при цьому надмірної догматичності чи негнучкості.
Ігри, в які грає влада
Люди, які перебувають при владі, можуть намагатися вплинути на вас різними способами, щоб ви зробили те, що, на вашу думку, означало б неякісну роботу. Припустімо, ви надаєте оцінку вартості майбутньої роботи людині, якій не подобаються зазначені вами цифри. Вона може тиснути на вас, щоб ви зменшили вартість, щоб допомогти їй, керівнику вищого рівня або замовнику досягти власних цілей бюджету проекту та його реалізації. Це зрозуміла мотивація, але це не є достатньою підставою для зміни оцінки.
Людина, яка заперечує проти наданої оцінки вартості, може відчувати тиск, про який ви не здогадуєтесь. Вона має право отримати пояснення, як саме ви отримали цю оцінку, а також обговорення можливості її коригування. Переговори у цьому випадку є цілком доречними. Однак зміна оцінки лише тому, що комусь вона не до вподоби, заперечує ваше бачення реальності. Це не змінює ймовірного результату.
Поспіх до коду
Припустімо, ви працюєте в ІТ-відділі компанії і з’являється новий проєкт. Бізнес-стейкхолдери можуть тиснути на вашу команду розробників, щоб вона негайно почала писати код, навіть без чітко визначеної бізнес-мети та початкового набору вимог. Можливо, у них є фінансування, яке вони хочуть витратити відразу, перш ніж його втратити.
Команда розробників також може бути зацікавлена в тому, щоб якнайшвидше приступити до роботи. Можливо, вони не хочуть витрачати час на вивчення вимог: «Вони все одно, ймовірно, зміняться, то навіщо взагалі цим займатися?». Опрацювання вимог не всім може видаватися найкращою ідеєю проведення часу весело, хоча насправді це корисний етап.
У результаті багато часу витрачається на безцільне кодування для досягнення незрозумілого результату.Занадто часто ніхто не несе відповідальності за недосягнуту ціль, оскільки вона узагалі не була чітко визначена. Чи не було б краще для ІТ-відділу протистояти тиску бізнесу й не розпочинати роботу доки не буде встановлено кінцеву мету, і потім дослідити можливі рішення, перш ніж створювати непридатний продукт?
Нестача знань
Люди, які тиснуть на вас із вимогою виконати те, що ви вважаєте недоречним, можуть просто не розуміти практик розробки програмного забезпечення, які ви відстоюєте. Наприклад, хтось може вважати проведення технічних рев’ю робочих продуктів зайвим. Можливо, вони не вбачають необхідності витрачати час на обговорення чи документування вимог. Менеджери або замовники можуть наполягати на своєчасному завершенню розробки продукту, навіть якщо він ще не відповідає всім критеріям релізу.
Замовники не завжди усвідомлюють, що спрощення вимог до якості зараз може й дозволить швидше «щось» зарелізити, але це «щось» потребуватиме значних виправлень, аби стати прийнятним. Невдала структура продукту ускладнює його модифікацію в разі подальших запитів на зміни.
Один мій колега одного разу запропонував своєму керівнику технічний підхід до реалізації певної програми. Хоча керівник був досвідченим розробником, але він не зміг оцінити переваги запропонованого рішення й відхилив ідею. У мого колеги було три варіанти дій:
- Надати додаткове пояснення запропонованого підходу, щоб зробити зрозумілою як саму техніку, так і її потенційні переваги.
- Реалізувати запропоновану стратегію попри спротив керівника.
- Дотриматися вказівок менш обізнаного керівника і застосувати неоптимальний підхід.
Який варіант, на вашу думку, є найкращим? Я пропоную спершу спробувати варіант № 1 (просвітницький підхід). Якщо це не допоможе, тоді варто обрати варіант №2. Залежно від дріб’язковості керівника, такий підхід супроводжується певним ризиком, але, на мою думку, він кращий, ніж варіант №3.
У мене колись був менеджер, який не розумів, як я можу писати документацію для користувачів нового застосунку ще до завершення розробки програмного забезпечення. Він був науковцем, мав певний досвід програмування і вважав, що розуміється на процесі розробки ПЗ. Я пояснив йому, що завдяки заздалегідь опрацьованим вимогам та дизайнам я знаю, як працюватиме застосунок. Підкреслив, що саме тому я не вважаю марною тратою часу створення довідкових екранів і посібника користувача до написання останнього рядка коду. Не впевнений, що мені вдалося розвіяти його скептицизм, проте я не відмовився від свого підходу лише через брак розуміння з боку менеджера.
Один замовник сказав мені, що не розуміє, чому проєкт займе стільки часу, скільки передбачала моя команда. Спираючись на свій обмежений досвід роботи з комп’ютерами, він назвав роботу SMOP («simple matter of programming»).
Я раніше не чув цього виразу, але намагався пояснити, що він точно не підходить для цього проєкту. Люди, які не працюють у цій сфері професійно, часто не усвідомлюють суттєвої різниці між простим написанням коду та якісною інженерією програмного забезпечення.
Сумнівна етика
Незалежні консультанти та підрядники можуть зазнавати різних видів тиску, що спонукають їх виконувати роботу неякісно. Один потенційний клієнт, якому я мав надавати консультаційні послуги, попросив мене прийти до його компанії під неправдивим приводом. Він хотів, щоб у контракті було зазначено, що я виконуватиму певну роботу, хоча насправді мої зобов’язання були зовсім іншими. Клієнт не міг отримати фінансування на діяльність, яку він планував, але у нього були кошти на іншу послугу.
Я вважав цю вимогу неетичною і відмовився як від проєкту, так і від співпраці з цим клієнтом. Прийняття таких умов означало б професійну недбалість з мого боку. Якби керівництво клієнта дізналося про ситуацію, це могло б призвести до юридичних проблем. Робота мені не була настільки необхідною.Кличеш ти кого?
Я був провідним бізнес-аналітиком на проєкті зі створення системи обліку хімічних речовин для дуже великої корпорації. Наші дві основні категорії користувачів складалися з: (а) понад тисячі хіміків, які виконували різні види робіт, та (б) кількох співробітників складу хімікатів. Керівник складу, Джейсон, сказав мені: «Я був хіміком-лаборантом, перш ніж очолити склад, тож вам не потрібно консультуватися з іншими хіміками щодо їхніх вимог до цієї системи. Я можу розповісти вам усе, що вам потрібно знати».
Джейсон помилявся. Його знання про вимоги хіміків були надто вузькими та застарілими. Якби я прислухався до його поради, ми б пропустили багато вимог і обмежень, якими володіли різні групи спеціалістів-хіміків, для яких призначався цей застосунок.
Замість того, щоб покладатися лише на інформацію, надану Джейсоном, як він пропонував, я зібрав команду з шести представників хіміків, щоб детально розібрати їхні вимоги. Думаю, це засмутило Джейсона, проте для мене було важливіше забезпечити надійне та повне джерело вимог. У результаті було створено застосунок, який добре сприйняли користувачі і який успішно використовувався протягом багатьох років.
Ігнорування процесів
Чітко визначені процеси існують не просто так. Коли користувачі запитували мене про внесення змін до застосунку під час моєї роботи у великій корпорації, я направляв їх до нашого дуже простого інструменту для подання запитів на зміни. Інформація, яку користувач надавав, дозволяла відповідним особам приймати обґрунтовані бізнес- та технічні рішення щодо запропонованих змін. Дехто з користувачів не хотів витрачати час на подання запиту і запитував, чи не можна внести зміни відразу. Вибачте, але ні, так не можна. Ігнорування резонних та дієвих процесів заради вигоди, на мою думку, є виконанням роботи неякісно.
Якщо хтось хоче обійти встановлений і ефективний процес, поясніть, чому запропонований вами підхід є необхідним. Підкресліть, як він підвищує якість і цінність проєкту або зменшує ризики та витрати. Така інформація допоможе іншій стороні зрозуміти, чому ви відстоюєте свій підхід і чините опір її проханням. Ви також можете отримати пропозиції щодо того, як зробити процес ще ефективнішим. Однак деякі люди просто не налаштовані на конструктивний діалог. Навіть доклавши максимум зусиль, щоб переконати їх дослухатися до вас, вони можуть тиснути на вас, змушуючи йти на компроміси або слідувати невдалому підходу.
Ризик
Припустимо, ви відмовляєтеся діяти в спосіб, який вважаєте непрофесійним або неетичним. Інша сторона може поскаржитися вашому керівникові, що ви марнуєте час на непотрібні дії або не йдете на співпрацю. Керівник може вас підтримати або, навпаки, чинити додатковий тиск, щоб змусити вас підкоритися.
У цьому випадку вибір залишається за вами. Чи піддастеся ви тиску та виконаєте роботу неякісно, з потенційно негативними наслідками для проєкту та вашого психічного стану? Чи продовжите працювати так, як вважаєте професійно правильним? Існує певний ризик, але я віддаю перевагу другому варіанту.
Оригінальна стаття – Don’t let your boss or your customer talk you into doing a bad job від Карла Вігерса, переклад – Марʼяна Закорчевна, ревью – Галина Остапенко. Оригінальне фото з статті.