Під час обговорення цін на індивідуальні програмні проекти сторони А та Б найчастіше орієнтуються на одиницю виміру — «людино-дні»: скільки інженерів, за який період і по якій ціні. Ця модель працює лише при стабільному наборі вимог та чітко визначених межах поставки; однак, якщо правила на майданчику часто змінюються, а інструменти ШІ підвищують продуктивність кодування, а замовник продовжує перевіряти роботу за принципом «нагромадження людей», конфлікт не уникнути — сторона Б вважає, що вимоги розростаються, а замовник відчуває: «людей додали, а результату немає».
Політичний сигнал: від продажу людських ресурсів до продажу результатів
У вересні 2026 року Міністерство промисловості та інформаційних технологій опублікувало «План реалізації спеціальної програми „ШІ + ПО“», де неодноразово зазначається про необхідність зміни моделей виробництва програмного забезпечення, розвитку таких послуг, як «Модель як сервіс» та «Інтелектуальний агент як сервіс», а також чітко вказано, що до 2028 року слід створити образцові впровадження інтелектуальних агентів у ключових галузях. Документ не відкидає індивідуальне розроблення, проте дає чітке напрямок: оцінювати цінність програмного забезпечення все більше потрібно за результатами, а не лише за кількістю людино-днів, вкладених у розробку.
Для компаній, що займаються ERP, MES, CRM та системами управління галузями, це означає, що якщо в договорі й далі зазначати лише «XX людей × XX днів», після запуску легко можна опинитися у ситуації, коли «код написано, а бізнес не використовується». Більш стале формулювання передбачає розбивку поставки на прийнятні для перевірки бізнес-результати.
Бізнес-логіка: етапи мають бути конкретнішими, ніж людино-дні
Переведіть проект з «платежів за етапами» на «платежі за етапами», при цьому кожен етап повинен одночасно відповідати чотирьом вимогам:
- Бізнес-сценарій: хто користується, які операції вирішує (наприклад, «складський оператор сканує штрих-код для приймання товару» замість «завершення модуля приймання товару»).
- Обсяг даних: які основні дані, поля стану, сфери доступу задіяні, які правила вибірки.
- Сценарій приймання: з урахуванням тестових даних, які процеси пройдено, які документи чи звіти отримано.
- Обробка винятків: як система повідомляє про помилку, хто має право вносити зміни, чи фіксується це.
Етапи не мають перевищувати 2–4 тижні кожен; надмірно довгі повертають до «чорного ящика розробки». Типовий приклад розбивки: основні дані та права → замкнуте коло ключових документів → звіти та звірки → інтерфейси та перехід на нову систему.
Логіка проектування: область, зміни та «інтелектуальна допомога» включаються до договору
ШІ допомагає кодувати, автоматично генерує тестові випадки, інтелектуально доповнює документацію — це змінює затрати людино-днів на ту саму функцію, але не зменшує бізнес-складність. У договорі та специфікації вимог рекомендується окремо вказувати:
- Базовий обсяг (Baseline): список функцій + перелік того, що не входить у область (Out of Scope); будь-які зміни потребують змінного листа.
- Правила тарифікації змін: нові етапи оцінюються за принципом «сценарій + сценарій приймання», а не за додатковими людино-днями.
- Границі інтелектуальної допомоги: на яких етапах можна використовувати ШІ для підвищення ефективності (генерація коду, чернетки документів), а на яких обов’язково потрібно підписувати вручну (безпека, відповідність, зобов’язання перед клієнтами).
- Власність знань: хто володіє процесними документами, конфігураціями, скриптами, щоб після завершення поставки не виникла розрив у технічному обслуговуванні.
Реалізація розробки: автоматизація приймання та оглядова здатність
Щоб «орієнтація на результат» стала практичною, технічна частина має підтримувати три речі:
- Завантаження тестових сценаріїв приймання: кожен етап має відповідну серію автоматичних або напівавтоматичних сценаріїв, які можна повторювати.
- Ізоляція середовища та даних: дані UAT можна скинути, щоб уникнути ситуації, коли «пройшло лише в демонстраційному середовищі».
- Наглядові журнали: ключові операції фіксуються в журналі, щоб у разі суперечки можна було відстежити, хто і що змінив.
Якщо проект включає інтелектуальний агент або правиловий двигун, приймання має доповнитися механізмом вибіркової перевірки: вводяться випадкові прикордонні випадки, перевіряється, чи відмовляються від відповіді, чи здійснюється підвищення до людського контролю, чи блокуються права відповідно до дизайну, а не лише перевіряється, чи «можна спілкуватися».
Три типові суперечки та їх запобігання
Суперечка перша: «Функції всі виконані, чому бізнес не використовує?»— запобігання: етапи прив’язуються до конкретних операцій та записів про навчання, під час приймання проводиться інспекція на місці, а не лише демонстрація презентації.
Суперечка друга: «Чому треба додавати кошти за невелику додаткову вимогу?»— запобігання: у змінному листі чітко вказуються етапи, сценарії та терміни, після підписання обох сторін розпочинається розробка.
Суперечка третя: «ШІ підвищує ефективність, чи можна скоротити людино-дні?»— запобігання: у договорі розрізняються «вартість реалізації» та «бізнес-складність»; вигоди від підвищення ефективності можуть відображатися у загальній ціні або періоді, але стандарти приймання не знижуються.
Рекомендація для пілотного проекту: почати з одного замкнутого модуля
Не обов’язково чекати, поки вся система перепишеться. Виберіть модуль, який можна замкнути за 2–3 тижні (наприклад, приймання товару, оформлення робочих замовлень, затвердження витрат), і підпишіть додаткову угоду за новим шаблоном: вкажіть сценарії, скрипти, винятки, платежі. Після успішного проходження розширте на весь проект. Для оцінки успіху слід подивитися, чи зменшилася кількість суперечок через змінний лист, чи зросла частота успішного проходження UAT, чи збільшився відсоток успішного проходження UAT, а не скільки людино-днів зменшила сторона Б. Якщо пілотний модуль добре підібраний, то переходити до зміни договорів на весь проект буде легше.
Людино-дні не зникнуть за одну ніч, але вони перетворюються з «єдиного способу ціноутворення» на «орієнтир для оцінки витрат». Саме включення етапів та сценаріїв приймання до договору — базовий навик, який дозволяє індивідуальному програмному забезпеченню в умовах «ШІ + ПО» надавати достовірні результати.
Комбінація з фіксованою загальною ціною та гнучкими ітераціями
Приймання етапів не виключає гнучкість: кожен Спринт все ще може віддавати демонстративні додатки, але оплата та офіційне приймання прив’язані до більш масштабного етапу. Особливо у фіксованих договорах треба чітко вказувати «точку заморозки обсягу» — після якої оцінки додаткові вимоги потрібно оформлювати змінним листом, щоб уникнути усних додавань функцій. Для модулів, що включають інтелектуальний агент, рекомендується окремо приймати «версію правил + відсоток успішної перевірки», не прив’язуючи це до загального запуску сайту.
Дані галузі показують, що близько третьої частини невдач програмних проектів пов’язані з неясними вимогами та стандартами приймання, а не з технічною реалізацією. Найперше вписати в договір «що вважається завершеним» — це цінніше, ніж сперечатися, чи замінив ШІ кількох програмістів. При наступному розгляді проекту можна спочатку запитати: якби завтра вся команда сторони Б пішла у відпустку, чи зможемо ми за сценарієм визначити, чи відповідає поточний етап вимогам — якщо не вдасться відповісти, значить, приймання ще недостатньо чітко прописано. Внесення етапів до договору — це не намагання ускладнити життя стороні Б, а спроба змусити обидві сторони обговорювати на одній сторінці, чи «все закінчено». Це особливо важливо у проектах, де ШІ підвищує ефективність, і треба чітко проговорити це заздалегідь.