Вартість обслуговування ПЗ після запуску: що насправді закладати в бюджет

Цифра 15-25% — не здогадка

Запитайте п'ять devops-компаній, скільки коштує обслуговування ПЗ, і ви отримаєте п'ять дещо різних чисел, але всі вони групуються в одному діапазоні. Розбір співвідношення "розробка до обслуговування" від Pulsion за 2026 рік показує, що річне обслуговування становить 15-25% від початкової вартості розробки. Емпіричне правило щодо обслуговування, яке приписують Gartner, потрапляє в той самий діапазон: 15-20% від початкової вартості розробки — щороку, поки система залишається в експлуатації. При розробці вартістю 150 000 доларів це 22 500-37 500 доларів на рік — не одноразове донарахування, а регулярна стаття витрат.

Ця цифра підтверджується різними джерелами, бо обслуговування — не витрати, які можна довільно обнулити. Дослідження, на яке посилаються поряд із цифрою від Gartner, показує, що приблизно 60% сукупної вартості життєвого циклу системи припадає на фазу обслуговування, і лише 40% — на початкову розробку. Більшість команд бюджетують ці 40% аж до спринту, а решту 60% сприймають як щось другорядне, що є повною протилежністю тому, як гроші насправді витрачаються.

Що насправді покриває цей відсоток

15-25% — це не одне ціле. Це чотири різні типи робіт з дуже різним рівнем терміновості, і саме розподіл між ними важливіший за загальну цифру, коли ви формуєте бюджет. Розбивка типової структури витрат на обслуговування від Pulsion виглядає так:

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

Пораховуємо на прикладі розробки вартістю 150 000 доларів, узявши середину діапазону — 20% на рік: це 30 000 доларів щорічно. Розподілений за категоріями вище за їхніми середніми значеннями, цей бюджет виглядає приблизно так: 6 750 доларів на коригувальні виправлення, 5 250 — на адаптивну сумісність, 8 250 — на удосконалення функціоналу і 2 250 — на превентивні оновлення, плюс окремо облікована інфраструктура, що починається з кількох сотень доларів на місяць і зростає разом із трафіком. Жодна з цих статей насправді не є довільною в тому сенсі, в якому дискреційною є, наприклад, маркетингова стаття витрат. Ви можете урізати удосконалювальні роботи в економний квартал і випустити менше покращень. Але ви не можете суттєво урізати коригувальні чи адаптивні роботи без ризику, що система зрештою зламається на очах у користувачів.

Перший рік виглядає зовсім інакше, ніж третій

Цифра 15-25% — це середнє значення за весь життєвий цикл системи, а середні значення приховують форму кривої. На практиці витрати на обслуговування різко зростають у перший рік, потім опускаються до нижчого стабільного рівня, а далі знову починають зростати з віком системи.

Бенчмарки, зібрані за різними обсягами розробки, чітко показують цю закономірність:

• MVP вартістю 30 000 доларів обходиться в 6 000-10 000 доларів обслуговування в перший рік, а потім падає до 4 500-6 000 доларів на рік після стабілізації.
• Продукт вартістю від 75 000 доларів обходиться в 15 000-25 000 доларів у перший рік, стабілізуючись на рівні 11 000-15 000 доларів на рік після цього.
• Платформа вартістю від 200 000 доларів обходиться в 40 000-70 000 доларів у перший рік, стабілізуючись на рівні від 30 000-50 000 доларів і вище, коли спадає перша хвиля багів.

Перший рік проходить у "гарячому" режимі, бо саме тоді реальні користувачі знаходять усе те, що не виявив ваш тестовий набір: крайні випадки в продакшн-даних, патерни навантаження, які ніхто не моделював, збої інтеграції із системами, які ви не контролюєте. Деякі бенчмарки показують, що обслуговування в перший рік може сягати аж половини початкової вартості розробки для менших продуктів. Якщо ваш бюджет на обслуговування в перший рік виглядає як рівні 15% від вартості розробки, ви його недооцінили.

Далі, з часом, крива знову йде вгору. У широко цитованому кейсі відстежили річну вартість обслуговування однієї legacy-системи корпоративного рівня: 2,4 мільйона доларів у перший рік, 2,7 мільйона на другий рік і 3,6 мільйона до п'ятого року — зростання на 50%, спричинене тим, що витрати на обслуговування накопичуються приблизно на 10-20% на рік, оскільки пул фахівців, які розуміються на застарілому стеку, скорочується, підтримка від вендорів дорожчає, а невирішений технічний борг постійно додає тертя. У типовому проєкті кастомного ПЗ ви не побачите таких великих цифр, але форма кривої застосовна за будь-якого масштабу: витрати падають після першого року, а потім знову зростають, щойно технічний борг починає накопичуватися.

У що насправді обходиться відкладене обслуговування

Ефект накопичення — не щось абстрактне. Часто цитоване опитування розробників показало, що інженери в компаніях зі значним обсягом legacy-систем витрачають близько 42% свого робочого тижня, приблизно 17 з 41 години, на обслуговування та технічний борг замість нової роботи, причому застарілі системи назвали головною причиною. Організації зі значним обсягом legacy-систем повідомляють, що витрачають 60-80% усього IT-бюджету на обслуговування, залишаючи лише 20% на щось нове. Це і є кінцевий стан, коли превентивну частину бюджету рік за роком трактують як необов'язкову: коригувальна й адаптивна частини розростаються настільки, що поглинають майже все.

Саме тому цифру 15-25% варто сприймати як мінімум, а не як ціль. Команда, яка щороку витрачає на нижній межі діапазону, пропускаючи при цьому превентивну категорію, не заощаджує гроші — вона відкладає рахунок, який прийде з відсотками.

Яка модель контракту підходить для якого етапу

Правильний спосіб оплати цих робіт змінюється з віком системи, і трактувати кожен рік однаково — одна з найпоширеніших помилок бюджетування, яку ми бачимо. У перший рік має сенс ретейнер із акцентом на виправлення багів і резервом на непередбачені години, оскільки ви ще справді не знаєте, що саме зламається. До другого-третього року, коли обсяг коригувальних робіт знижується, зазвичай краще підходить змішаний ретейнер, що поєднує постійну підтримку із запланованою розробкою функціоналу, оскільки удосконалювальні роботи займають дедалі більшу частку загального обсягу. Після четвертого-п'ятого року варто закладати в бюджет окремий регулярний спринт для погашення технічного боргу, а не дозволяти превентивним роботам щоразу відкладатися через те, що функціонал, який "горить" цього тижня, — саме цей патерн і лежить в основі описаного вище щорічного накопичення на 10-20%.

Як насправді визначити конкретну цифру

Кілька практичних правил, які підтверджуються на проєктах, які ми оцінювали:

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

Усе це також не є аргументом на користь максимізації бюджету на обслуговування. Сенс окремого відстеження категорій — у тому, що це дає вам важіль впливу. Команда, яка бачить, що коригувальні витрати зростають з кварталу в квартал, отримує конкретний сигнал, що щось на вищому рівні — покриття тестами, стандарти код-рев'ю, початкова архітектура — потребує уваги, замість розмитого відчуття, що обслуговувати ПЗ "якось дорого". Команда, яка відстежує лише одну змішану цифру обслуговування, ніколи не отримує такого сигналу — рахунок просто тихо зростає з кожним поновленням, і ніхто не може пояснити, чому.

Наскільки добре це працює, значною мірою залежить від того, як систему було спроєктовано й побудовано із самого початку. Коли ми проводимо проєкти через наш процес, обслуговування — не другорядне питання, яке ми оцінюємо на етапі передачі, а частина обсягу робіт, узгоджена ще на етапі розробки, тож клієнт знає цифру на перший рік ще до написання першого рядка коду. І значна частина того, чи виглядатиме третій рік як керовані 15%, чи як накопичувальний хаос, визначається рішеннями, ухваленими під час початкової розробки. Дізнайтеся, як ми підходимо до кастомної розробки ПЗ, щоб зрозуміти, які рішення щодо супроводжуваності, покриття тестами й гігієни залежностей утримують превентивну статтю дешевою — замість того, щоб через два роки вона перетворилася на статтю коригувальних робіт.