Чому розробникам треба розбиратись у бізнес-домені

Розробники працюють у різних проєктах, а відтак — у різних доменах. Можна сконцентруватись виключно на розвитку технічних навичок. Інша стратегія — поєднувати професійні скіли з вивченням бізнесу, в якому працюєш.

Але виникає питання: коли достатньо тільки кодити, а коли слід глибше розбиратися у бізнес-домені? Думками і порадами з редакцією поділилися Web Developer Максим Деренський та Software Architect Євген Заболотний з команди NIX.

Коли можна обмежитись кодом

На початку кар’єри розробникам важливо зосередитись на «поліруванні» коду. Рівень завдань новачків можна порівняти з роботою асистентів. Тобто основною функцією є виконання завдань, які перевіряються більш досвідченим колегою.

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

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

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

Коли коду недостатньо

Неповне розуміння вимог

Розроблений продукт не існує у вакуумі. Він належить до конкретної сфери бізнесу та має відповідати потребам цільової аудиторії. Не зрозумієш споживачів, то і не зможеш запропонувати потрібне їм рішення.

Євген Заболотний: «Технічне завдання можна зрозуміти без знань домену. Ви отримаєте вхідні та вихідні дані (інформацію для розробки продукту) і зможете виконати проєкт.

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

Наприклад, у Healthcare є закони про захист персональних даних. У Європі та США діють різні стандарти. Не знаючи цього, ви створите працюючий продукт, але його не можна буде випускати на ринок. Те саме стосується і інших сфер. Якщо розробник не знає фінансових протоколів, це може ускладнити інтеграцію продукта з фінансовими установами».

Максим Деренський: «Коли я працював у напрямі автоматизації роботи на складських приміщеннях, замовник щомісяця робив відеоекскурсії для команди розробників. Ми спілкувались із працівниками та запитували, на що вони витрачають найбільше часу в роботі.

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

Ми розробили застосунок, який працює як бездротовий сканер. Спеціалісти з меншими зусиллями пришвидшили роботу. А розробникам розуміння бізнесу допомогло зрозуміти вимоги проєкту та не витрачати час на уточнюючі питання замовнику».

Неефективне спілкування з командою

Усі учасники команди мають розуміти термінологію, що стосується сфери продукту. Тоді ані менеджеру проєкту, ані замовнику, не доведеться витрачати час на додаткові роз’яснення.

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

Неправильна реалізація

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

Як-от для реалізації оплати розробники спростили звʼязку invoice-payment до просто payment. Спочатку продукт може працювати, а потім виявиться, що платіж підвисає. Щоб оформити покупку в розстрочку, необхідно створювати ще один платіж. З часом логіка може ускладнитись. Якщо немає звʼязку між кодом і доменною галуззю, стає важко впроваджувати зміни.

Євген Заболотний: «Знання домену дозволяє розраховувати дії на кілька кроків уперед та формувати різні сценарії розвитку продукту після релізу.

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

Щоб зробити продукт універсальним у плані технічних покращень, краще відразу закласти цю можливість в архітектуру. Інакше будете писати новий функціонал, а не доповнювати існуючий».

Зменшення довіри клієнтів

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

«‎Заходячи» у новий проєкт, приділіть час вивченню домену. Наприклад, якщо працюєте з FinTech-застосунками, вам потрібно знати, що таке ACH Authorization (документ, який регулює автоматичні електронні перекази грошей із банківського рахунку клієнта).

Це дозволить створювати системи, що відповідають стандартам безпеки. Перейшли у Healthcare? Для обміну даними між різними медичними системами знадобляться HL7 (Health Level Seven) чи FHIR (Fast Healthcare Interoperability Resources). Тобто у кожному домені є специфічні терміни, без знань яких ви не зможете запропонувати клієнту потрібне рішення.

Євген Заболотний: «Для Solution Architect та Sales-менеджера особливо цінне розуміння якомога більшої кількості бізнес-доменів. Їхня робота передбачає регулярну взаємодію з клієнтами з різних галузей бізнесу.

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

Із чого почати вивчення домену

Якщо немає досвіду розробки

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

Максим Деренський: «Припустимо, ви хочете розробляти софт, який допоможе комфортніше пережити ймовірні блекаути. У сфері енергетики для розробок обирають такі мови, як Python, Java, C/C++. Цікаво реалізувати в мобільний застосунок функцію увімкнення/вимкнення світла, електрочайника, відкривання/закривання дверей авто?

Тоді вам у сферу IoT (Internet of Things). Вам знадобляться знання C, Java, Python, Swift. Таким чином ви зможете поєднати ваші уподобання з ІТ-професією. Залишиться тільки знайти компанію, де є відповідні проєкти».

Паралельно з вивченням мов візьміться за технології, які стануть інструментами для вирішення конкретних завдань.

• FinTech: Blockchain, криптовалюти, штучний інтелект (AI) та машинне навчання (ML), інтернет речей (IoT), Big Data та аналітика, DevOps, веб-технології.

• Software & Hi-Tech: Штучний інтелект (AI) та машинне навчання (ML), інтернет речей (IoT), блокчейн, віртуальна та доповнена реальність (VR/AR), Big Data, DevOps, Cloud Computing, веб-технології.

• Healthcare: Електронні медичні записи (EMR/EHR), телемедицина, медичні застосунки для мобільних пристроїв, системи управління лікарнями та поліклініками, аналітика в охороні здоров’я, веб-технології.

• Automotive: Електроніка та контроль, автоматизоване водіння (ADAS), з’єднані автомобілі (Connected Cars), інтернет речей (IoT), електромобілі, технології безпеки.

• GameDev: Ігрові двигуни: Unity, Unreal Engine, Godot, CryEngine.

Якщо є досвід розробки

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

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

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

• FinTech

Finextra. Веб-сайт із новинами, аналітикою та інсайтами у сфері фінансових інновацій, цифрового банкінгу, блокчейну та інших тем, пов’язаних із фінансовими технологіями.

• Software & Hi-Tech

TechCrunch. Про тенденції та новини у сфері технологій, стартапів та бізнесу.

MIT Technology Review. Статті від Массачусетського технологічного інституту.

• Healthcare
Онлайн-курс "PR Basis" від Skvot.
Дізнайся нюанси різних сфер і обрери свою.Як результат — матимеш стратегію бренду у своєму портфоліо та зможеш стартувати в піарі. Інсайтами ділиться лекторка, яка має 9+ років досвіду.
Детальніше про курс

Healthcare IT News. Новини про розвиток інформаційних технологій у галузі охорони здоров’я.

• Automotive

Automotive News. Огляди на події в автомобільній індустрії, новини про виробників автомобілів, тенденції у виробництві, інновації тощо.

• GameDev

Game Developer. Спеціалізована платформа для розробників відеоігор. 

• e-Commerce

Ecommerce Platforms. Огляди та порівняння різних платформ електронної комерції.

• Telecom

Telecoms.com. Новинний ресурс у галузі комунікаційної індустрії.

• Manufacturing

IndustryWeek. Про ефективність виробництва, постачання, логістику, технологічні інновації виробництва та промисловості.

Візьміть собі за правило — не починайте роботу, допоки достатньо не ознайомились із доменом. Для початку варто зрозуміти, які потреби користувачів має вирішити ваша розробка. З чітким усвідомленням кінцевої мети та розумінням специфіки бізнесу, ви зможете запропонувати ефективне рішення.