Коли ви замовляєте доопрацювання BAS, виконавець рідко питає, як саме його реалізувати. А дарма: від цього вибору залежить не стільки ціна самої доробки, скільки вартість усіх наступних оновлень. Різниця може становити години щомісяця протягом усього життя системи.
Розберемо обидва шляхи так, щоб ви могли поставити правильні запитання до початку робіт.
Дві дороги для однієї задачі
Уявімо звичайну задачу: потрібна друкована форма, якої немає в типовій конфігурації. Реалізувати її можна двома способами.
Спосіб перший — розширення. Програміст створює окремий файл-розширення (.cfe), у якому описує тільки нову форму. Типова конфігурація залишається недоторканою, наче до неї ніхто не підходив.
Спосіб другий — зміна конфігурації. Програміст відкриває типову конфігурацію в конфігураторі, знімає потрібний об'єкт із замка́ підтримки і дописує код прямо в тіло програми.
Результат для користувача однаковий: кнопка друку з'явилася, форма працює. Різниця в тому, що сталося з самою програмою.
Що таке «підтримка постачальника»
Типова конфігурація BAS постачається на підтримці розробника. Це означає, що програма знає: цей об'єкт — типовий, його автор — постачальник, і при виході нового релізу він оновиться автоматично.
Коли ви змінюєте об'єкт у тілі конфігурації, ви фактично заявляєте: «тепер за цей шматок відповідаю я». Об'єкт частково або повністю знімається з підтримки. Програма більше не може оновити його самостійно, бо не знає, які з ваших змін потрібно зберегти, а які можна перезаписати.
Ключова теза: зняття з підтримки — це не поломка і не помилка. Це передача відповідальності за частину коду від розробника до вас.
Як це відчувається при оновленні
Ось де вибір перетворюється на гроші.
Оновлення типової конфігурації. Стандартна процедура. Порівняння, застосування, перевірка. Передбачувана за часом і майже без ризиків.
Оновлення конфігурації зі змінами. Процедура перетворюється на окрему роботу:
- порівняти зміни нового релізу з вашими доопрацюваннями;
- з'ясувати, чи торкнувся реліз тих самих об'єктів, які ви змінили;
- перенести й адаптувати код там, де виник конфлікт;
- протестувати доопрацьований функціонал;
- перевірити пов'язані документи та звіти;
- перенести зміни в робочу базу.
Головна проблема тут не в обсязі, а в непередбачуваності. Якщо реліз зачепив ті самі механізми, що й ваша доробка, робота може зайняти в рази більше часу, ніж планувалося. А регламентовану звітність оновлювати треба вчасно, незалежно від того, зручний це момент чи ні.
Оновлення бази з розширенням. Проходить за стандартною процедурою. Розширення потрібно перевірити після оновлення, але воно живе окремо, і в більшості випадків працює далі без правок.
Чому розширення дешевше у володінні
| Розширення | Зміна конфігурації | |
|---|---|---|
| Конфігурація на підтримці | Так | Частково або повністю ні |
| Процедура оновлення | Стандартна | Окрема робота щоразу |
| Передбачуваність вартості оновлень | Висока | Низька |
| Ризик конфлікту з новим релізом | Низький | Зростає з кожною доробкою |
| Відокремлення вашого коду від типового | Повне | Немає |
| Можливість швидко вимкнути доробку | Так, одним перемикачем | Ні, потрібна робота в конфігураторі |
| Передача системи іншому підряднику | Просто | Складно |
Останній рядок варто прочитати уважно. Розширення — це фактично документація ваших змін: видно, що саме і де змінено. У конфігурації зі змінами новому підряднику доведеться спершу порівнювати вашу базу з типовою, щоб зрозуміти, з чим він має справу. Це час, який ви оплатите.
Коли розширення не підходить
Було б нечесно стверджувати, що розширення вирішує все. Є задачі, де без зміни конфігурації обійтися складно або невиправдано дорого:
- глибока переробка типових механізмів — наприклад, зміна логіки проведення документа на рівні, де розширення довелося б перевизначити половину модуля;
- старі конфігурації, у яких механізм розширень реалізовано обмежено;
- масштабна галузева доробка, коли змінюється сама модель обліку, а не окремі ділянки;
- бази, які вже давно знято з підтримки — тут дискусія часто безпредметна, конфігурація вже змінена попередніми підрядниками.
В останньому випадку є окреме рішення: повернути базу на підтримку. Це самостійний проєкт — перенести наявні доробки в розширення, оновитися до актуального релізу і далі обслуговувати систему за стандартною процедурою. Робота разова, але вона окупається на оновленнях, особливо якщо базу планують використовувати роками.
Питання, які варто поставити виконавцю
Перед тим як погодити доопрацювання, запитайте:
- Як саме буде реалізована доробка — розширенням чи зміною конфігурації? Відповідь «як вийде» означає, що про це не думали.
- Якщо змінюємо конфігурацію — які саме об'єкти знімаються з підтримки? Список має бути конкретним.
- Як це вплине на вартість наступних оновлень? Оцінка може бути приблизною, але вона має прозвучати.
- Чи можна розв'язати задачу розширенням, хай і трохи дорожче зараз? Іноді різниця в дві години на старті економить десятки годин за рік.
- У якому вигляді я отримаю доробку? Файл .cfe або файл порівняння конфігурацій — це ваш актив, який ви зможете передати іншому виконавцю.
Наша позиція
Якщо задача технічно розв'язується розширенням, ми обираємо розширення. Навіть коли це трохи довше на етапі розробки.
Причина проста: ми бачимо систему не в момент здачі доробки, а протягом років обслуговування. База, яку змінювали в конфігураторі кожні кілька місяців протягом п'яти років, перетворюється на систему, де кожне оновлення регламентованої звітності стає міні-проєктом із непередбачуваними строками. Причому найбільше це б'є по клієнту саме тоді, коли часу немає — у звітний період.
Тому в наших тарифах для конфігурацій, знятих з підтримки, діє надбавка до абонплати, а адаптація коду при оновленні оцінюється окремо. Це не штраф, а відображення реального обсягу робіт: така база справді потребує більше уваги.
Коротко
- Розширення залишає конфігурацію на підтримці, оновлення проходять стандартно, ваш код відокремлений і документований.
- Зміна конфігурації знімає її з підтримки, і кожне наступне оновлення стає окремою роботою з непередбачуваною вартістю.
- Кожна доробка в тілі конфігурації здорожчує всі наступні оновлення — ефект накопичувальний.
- Бувають задачі, де без зміни конфігурації не обійтися, але це має бути свідомий вибір, а не наслідок того, що так було швидше програмісту.
- Базу, зняту з підтримки, можна повернути на підтримку. Це окремий проєкт, який окупається на оновленнях.
Якщо не знаєте, у якому стані ваша конфігурація, почніть з аудиту: ми подивимося, які об'єкти зняті з підтримки, скільки в базі доробок і в якому вигляді вони реалізовані, та скажемо, чи є сенс повертати систему на підтримку.