Доробка BAS — один з найчастіших запитів до SATELION, і водночас один з найризикованіших з погляду бюджету: клієнти регулярно приходять з проектами, які подорожчали вдвічі проти початкового кошторису. За досвідом SATELION у десятках доробок, причина майже завжди одна й та сама — не складність самої задачі, а сім типових помилок на етапі постановки і ведення проекту. Нижче — що саме зазвичай ламає бюджет і як цього уникнути.
Помилка 1: розмите технічне завдання
Найдорожча помилка — почати доробку без чіткого опису результату. Формулювання на кшталт «зробіть звіт зручнішим» або «додайте автоматизацію в закупівлі» залишають простір для тлумачення, і виконавець з клієнтом можуть уявляти зовсім різний результат.
Коли ТЗ нечітке, доробка неминуче проходить через кілька ітерацій переробки — а кожна ітерація це додаткові оплачені години. За практикою SATELION, чітке ТЗ з конкретними прикладами вхідних і вихідних даних скорочує кількість ітерацій в рази.
Помилка 2: клієнт веде проект без PM-контролю
Коли клієнт спілкується напряму з розробником без проєктного менеджера, який стежить за обсягом задачі, відбувається непомітне розростання скоупу: «а ще додайте», «а можна ще ось це» — і кожне таке доповнення без фіксації в задачі й окремої оцінки годин непомітно подвоює кошторис.
PM-модель SATELION вирішує це не забороною прямого контакту з розробником, а контролем: клієнт так само спілкується з виконавцем напряму, але кожна зміна обсягу фіксується і оцінюється окремо, перш ніж потрапити в роботу.
Помилка 3: доробка "поверх" замість інтеграції в стандартну конфігурацію
Швидкий, але небезпечний підхід — писати код, який обходить стандартну логіку BAS замість того, щоб інтегруватися в неї. Це дає результат швидше на старті, але після наступного оновлення платформи доробка ламається, бо чіпляється за внутрішню структуру, яку розробники BAS могли змінити.
Виправлення зламаної після оновлення доробки коштує майже стільки ж, скільки коштувала сама доробка — фактично клієнт платить за роботу двічі. Коректний підхід — розширювати конфігурацію через штатні механізми розширення, навіть якщо це займає більше часу на старті.
Помилка 4: тестування прямо на бойовій базі
Доробка, перевірена одразу на робочій базі даних, — ризик зупинки роботи всієї компанії, якщо щось піде не так. Але є і суто бюджетний наслідок: помилки, знайдені після того, як доробка вже потрапила в роботу бухгалтерії чи складу, виправляються в терміновому режимі — а термінові виправлення завжди дорожчі за заплановану роботу.
SATELION тестує кожну доробку на копії бази перед впровадженням у бойову систему — це стандартний, а не додатково оплачуваний етап процесу.
Помилка 5: відсутність документації змін
Доробка без документації працює нормально, поки її не потрібно змінювати — новому виконавцю (чи навіть тому самому через рік) доводиться розбирати код заново, щоб зрозуміти логіку. Це прямий додатковий час, який клієнт оплачує за роботу, яка вже була одного разу зроблена.
Мінімальна документація — опис логіки зміни і місця в конфігурації, де вона зроблена — коштує кілька годин на етапі розробки і економить у рази більше при будь-якій наступній зміні.
Помилка 6: недооцінка складності інтеграцій
Доробка, яка виглядає локальною (наприклад, змінити форму документа), часто зачіпає інтеграції — обмін з сайтом, маркетплейсами, банком, ПРРО. Якщо на етапі оцінки ці зв'язки не врахували, реальний обсяг роботи розкривається вже в процесі і бюджет зростає непередбачувано.
SATELION перед оцінкою вартості доробки перевіряє, з якими інтеграціями пов'язана задача — це займає час до старту, але виключає найбільш болючий сценарій розростання бюджету в середині проекту.
Помилка 7: вибір виконавця виключно за найнижчою ціною
Найдешевша пропозиція на доробку BAS часто означає відсутність спеціалізації саме на BAS — виконавець вчиться на задачі клієнта, а не застосовує вже напрацьований досвід. Результат — більше годин на ту саму задачу і вищий ризик помилок першого-другого пункту цього списку.
Власна WMS-система SATELION, побудована на BAS з нуля тією ж командою, яка виконує клієнтські доробки, — практична перевірка того, що команда витримує складні кастомні задачі, а не лише прості правки форм.
Як не подвоїти бюджет: короткий чекліст
Перед стартом доробки перевірте: чи є чітке ТЗ з прикладами результату, чи контролює проєкт PM (а не тільки прямий контакт з розробником), чи закладено тестування на копії бази, чи враховані пов'язані інтеграції, і чи буде документація змін частиною результату, а не додатковою послугою.
Якщо на ці п'ять запитань немає впевненої відповіді "так" ще до підписання кошторису — саме там ховається майбутнє подвоєння бюджету.
Доробка BAS подвожчує бюджет не через непередбачувану складність, а через повторювані, добре відомі помилки процесу — розмите ТЗ, відсутність PM-контролю, тестування на бойовій базі, ігнорування інтеграцій. Усі сім вирішуються на етапі підготовки проекту, а не після того, як бюджет вже перевищено.