Команда виконала технічне завдання. Усі заплановані функції працюють. Систему запущено, акт підписано. Але через пів року працівники продовжують вести облік у таблицях, керівництво не довіряє звітам, а кожна зміна потребує нового бюджету. Чи можна назвати такий ІТ-проєкт успішним?
На мою думку, саме з цього запитання варто починати розмову про цінність розробки. Працездатність програми — необхідна умова. Проте замовник інвестує у зміни: швидше обслуговування клієнтів, точніше планування, менші втрати, надійніший контроль. Якщо цих змін немає, технічна готовність системи ще мало про що говорить.
Штучний інтелект робить цю різницю помітнішою. Він допомагає створювати програмні компоненти, тести й прототипи. Однак прискорення окремих завдань залишає відкритим головне питання: чи правильну систему ми будуємо і чи зможе організація отримати від неї користь?
Уявімо підприємство, яке вирішило замовити власну CRM. У переліку вимог — картки клієнтів, історія звернень, воронка продажів, інтеграція з поштою та звітність. За цим описом уже можна оцінювати роботу й починати розробку.
Але причина втрати клієнтів може полягати в тому, що менеджери не мають спільних правил роботи із заявками. Одне звернення обробляють двічі, інше залишається без відповіді. Ніхто не визначив, коли відповідальність переходить від відділу продажів до сервісної команди. У такій ситуації нова CRM здатна лише перенести організаційну плутанину в новий інтерфейс.
Тому на початку проєкту потрібно домовитися про очікувану зміну. Наприклад, скоротити час першої відповіді клієнтові, забезпечити передачу кожного звернення відповідальному працівникові або усунути повторне введення даних. Тоді можна обґрунтовано вирішувати, чи потрібна власна розробка, чи достатньо налаштувати готовий продукт і змінити порядок роботи.
Я вважаю готовність поставити під сумнів початкове замовлення ознакою професійної зрілості ІТ-команди. Підрядник має вміти пояснити, чому певна функція не допоможе досягти мети або чому до її створення потрібно розв’язати іншу проблему. Замовникові, своєю чергою, потрібна готовність переглядати власні припущення.
Після визначення мети починається інша складна робота — проєктування системи, яка витримає реальні умови експлуатації.
На демонстрації все може виглядати переконливо: користувач оформлює замовлення, система приймає оплату, склад отримує повідомлення. У реальному житті покупець двічі натискає кнопку, підтвердження платежу затримується, а складський сервіс тимчасово недоступний. Команда має заздалегідь визначити, як система поводитиметься в таких ситуаціях, що побачить користувач і як буде відновлено коректний стан даних.
Саме тут стає зрозумілою цінність інженерії. Вона охоплює зв’язки між компонентами, правила обробки помилок, права доступу, відновлення після збоїв. Якість реалізації кожного з цих рішень безпосередньо впливає на бізнес.
Тому я обережно ставлюся до формулювання «код неважливий». Помилка в програмі може спричинити втрату грошей або даних. Водночас бездоганно реалізований окремий модуль не виправить суперечливих вимог чи невдалої моделі взаємодії між системами. Професійна розробка потребує уваги до всіх цих рівнів.
Архітектурні рішення також визначають майбутню свободу замовника. Чи можна буде підключити новий канал продажів? Замінити зовнішній сервіс? Передати підтримку іншій команді? Отримати власні дані у придатному для використання вигляді? Відповіді на ці запитання впливають на вартість володіння системою протягом багатьох років.
При цьому складніша архітектура не обов’язково краща. Невеликому продукту може бути достатньо простого рішення, яке команда добре розуміє й здатна підтримувати. Закладати потрібно обґрунтовані можливості розвитку. Кожне додаткове ускладнення має свою ціну.
З появою інструментів ШІ ця дисципліна набуває особливого значення. Коли нову функцію легко згенерувати, виникає спокуса додавати можливості без достатнього обговорення їхньої користі. Проте кожна прийнята зміна поповнює обсяг того, що доведеться перевіряти, захищати, документувати та підтримувати.
Швидке створення коду не звільняє команду від цих зобов’язань. Якщо перевірка не встигає за розробкою, зростає обсяг роботи, якість якої ще не підтверджена. Тому продуктивність варто оцінювати за часом до перевіреного результату, враховуючи виправлення й переробки.
Наступне випробування починається під час впровадження. Системі потрібні підготовлені дані, зрозумілі правила використання, навчені працівники та підтримка. Якщо ці завдання залишити «на після запуску», бізнес отримає програму, до роботи з якою він ще не готовий.
Уявімо електронний документообіг, у якому документ проходить погодження онлайн, але паралельно його потрібно роздрукувати, підписати й передати тим самим людям. Кількість операцій зростає. Щоб отримати користь від такого впровадження, необхідно переглянути регламенти, визначити чинний порядок погодження та усунути дублювання там, де воно не потрібне.
Це потребує участі керівництва замовника. ІТ-команда може запропонувати рішення, показати наслідки різних варіантів і забезпечити технічну реалізацію. Повноваження змінювати роботу підрозділів залишаються всередині організації. Відповідальність сторін потрібно узгоджувати на початку проєкту.
Я пропоную керівникам ще до затвердження бюджету зафіксувати кілька речей: яку проблему розв’язуємо, як виміряємо покращення, хто відповідає за зміну процесу та які ресурси потрібні після запуску. До цього варто додати умови перегляду рішення — ознаки, за яких слід змінити підхід, скоротити масштаб або припинити розробку.
Важливо також зафіксувати початковий стан. Якщо компанія хоче прискорити обробку замовлень, потрібно знати, скільки часу вона займає зараз і де виникають затримки. Інакше після впровадження легко підмінити оцінку результату переліком виконаних робіт.
Для українських ІТ-компаній здатність вести таку розмову із замовником має стратегічну цінність. Вона потребує знання галузі, сильної інженерної команди та готовності супроводжувати рішення в експлуатації. Саме з цього складається довіра до технологічного партнера.
Коли керівник приймає ІТ-проєкт, варто повертатися до проблеми, заради якої його починали. Чи зникло повторне введення даних? Чи скоротився час очікування? Чи може бізнес покластися на систему у щоденній роботі? Відповіді на ці запитання і мають визначати, чи виправдалися вкладені зусилля.
Довідковий матеріал щодо можливостей і обмежень ШІ-асистентів: GitHub Docs: можливості, обмеження та перевірка підказок GitHub Copilot.
Діяльність Асоціації у цьому напрямі: Комітет цифровізації Software Ukraine.