Як рахують вартість розробки програмного забезпечення

Вартість розробки програмного забезпечення рахують з обсягу робіт: які функції, екрани та інтеграції потрібні, скільки годин піде на кожну частину і хто з команди її виконає. Тому чесна оцінка — це розбивка на рядки і діапазон, який звужується, коли обсяг стає зрозумілішим. Принцип однаковий для будь-якої розробки на замовлення — для автоматизації бізнес-процесів і зв'язки ваших систем, адмінки, дашборду, SaaS-продукту чи сайту. Відрізняється лише те, які рядки в оцінці важать найбільше.

Ключові висновки

• Вартість рахують з обсягу: функції, ролі в команді, години і ставка, плюс окремі рядки на тестування, керування, інфраструктуру й підтримку.
• Тип роботи змінює, що саме дорожчає: в інтеграції це чужі API, у SaaS — ролі, білінг та ізоляція даних, у дашборді — джерела даних.
• Перша оцінка — це діапазон. Його звужують дослідження задачі й рішення про обсяг.
• Пропозиції порівнюють за однакових умов і рядок за рядком, а не за підсумковою сумою.
• Найдешевша оцінка без розбивки — сигнал ризику, а не вигода.

Зміст

Нижче — з чого складається цифра, як тип проєкту змінює оцінку, чому перша оцінка завжди приблизна, чим відрізняються моделі оплати і як порівняти дві пропозиції рядок за рядком. Сум тут немає: ціна залежить від обсягу саме вашого проєкту, а не від середнього по ринку. Які бувають напрями розробки на замовлення, можна подивитися окремо.

З чого складається вартість розробки програмного забезпечення

В основі будь-якої оцінки — ланцюжок «обсяг — ролі — години — ставка». Спершу описують обсяг: що програма має робити, для кого і з якими системами працювати. Потім визначають ролі: аналітик, дизайнер, бекенд- і фронтенд-розробники, тестувальник, керівник проєкту. Далі кожну частину роботи оцінюють у годинах. І вже години множать на ставку кожної ролі. Цифра в пропозиції — це сума таких рядків, а не одне число «на око».

Якщо сторони оформлюють розробку договором підряду, Цивільний кодекс прямо каже, з чого складається ціна: вона включає відшкодування витрат підрядника і плату за виконану ним роботу (Цивільний кодекс України, ст. 843). Для замовника це підказка: у пропозиції варто бачити і саму роботу, і витрати, які виконавець несе, щоб її виконати.

Рядки, які варто бачити в оцінці

Добра оцінка розкладена хоча б на такі частини:

• Дослідження і план. Розбір задачі, вимог і ризиків, архітектура, план робіт.
• Дизайн. Прототипи й макети екранів, якщо інтерфейс новий.
• Бекенд. Логіка, база даних, ролі й права, безпека.
• Фронтенд. Екрани, їхні стани, адаптивність під телефон.
• Інтеграції. Обмін даними з обліком, оплатою, доставкою чи іншими вашими системами.
• Тестування. Перевірка функцій до запуску і після кожної зміни. Його варто бачити окремим рядком, а не «заодно» в розробці.
• Керування проєктом. Планування, зустрічі, звіти, погодження змін.
• Інфраструктура і сторонні сервіси. Сервери, домени, платні API, розсилки. Це окремі рахунки, а не робота виконавця, тож їх теж варто бачити окремо.
• Запуск. Перенесення даних, налаштування робочого середовища, перший реліз.
• Підтримка після запуску. Виправлення помилок і оновлення. Що в неї входить і на який період, краще погодити до старту.

Професор Університету Осло Магне Йоргенсен, який досліджує оцінювання програмних проєктів, зауважує, що багато компаній не користуються жодним із двох інструментів, які роблять оцінки точнішими. Перший — історичні дані, наприклад яку частку зусиль зазвичай забирають незаплановані роботи й керування проєктом. Другий — чеклісти з нагадуваннями про роботи, які легко забути (M. Jørgensen, IEEE Software / InfoQ). Список вище — такий самий чекліст, тільки з боку замовника: якщо рядка немає в пропозиції, спитайте, де він.

Години на якість коду теж не варто сприймати як надлишок. Мартін Фаулер пише, що висока внутрішня якість програми знижує вартість майбутніх функцій (Martin Fowler, Is high quality software worth the cost?). Тобто від того, як написано першу версію, залежить ціна кожної наступної зміни.

Як тип проєкту змінює оцінку

Ланцюжок «обсяг — ролі — години — ставка» однаковий для всіх, але в кожного типу роботи свої рядки, які важать найбільше. Ми проєктуємо й розробляємо SaaS-платформи, MVP, внутрішні системи, адмінки й кабінети клієнтів, інтеграції та сайти. Нижче — що в кожному з цих випадків найсильніше впливає на оцінку і що варто підготувати до розмови з виконавцем.

Інтеграція. Коли треба з'єднати сайт, облік, оплату, доставку чи програмний РРО, на оцінку інтеграції з чужими сервісами через API найбільше впливають кількість ендпоінтів (точок обміну даними), тип авторизації, кількість сторонніх систем і вимоги до безпеки. Окреме питання — чи є в програми API взагалі. Якщо система закрита, доводиться писати парсери чи скрипти, які повторюють дії людини, або підключатися напряму до бази даних, а це інший обсяг роботи. І ще одне: чужі сервіси оновлюють свої API, тож код інтеграції доводиться оновлювати слідом. Спитайте, чи входить це в підтримку.

SaaS. Розробка SaaS-платформи з ролями й підпискою — це не «сайт з кабінетом», а платформа для багатьох клієнтів одночасно, з ролями, білінгом і складною бізнес-логікою. На оцінку сильно впливає, як ізолювати дані клієнтів: спільна база з розмежуванням на рівні рядків, окремі схеми чи окремі бази для кожного клієнта. Вибір залежить від вимог до захисту й зберігання даних (комплаєнсу), масштабу і бюджету. Як працює сама модель — у статті як працює бізнес-модель SaaS.

Адмінка чи кабінет клієнта. Тут найбільше важать ролі: скільки їх, хто що бачить і що може змінювати, чи потрібен журнал дій, імпорт і експорт даних. Проста таблиця для одного адміністратора і система, де менеджер, бухгалтер і склад бачать різне, — це різні обсяги, навіть якщо екрани схожі.

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

Сайт. Для сайту на оцінку впливають кількість унікальних шаблонів сторінок, інтеграції з оплатою, доставкою чи обліком, система керування контентом і те, чи готові дизайн і тексти. Багато однакових сторінок каталогу — це один шаблон, а кілька зовсім різних сторінок — кілька шаблонів.

Бекенд і фронтенд. Їх оцінюють окремими рядками, бо це різна робота. Бекенд — це логіка, дані, інтеграції і безпека. Фронтенд — екрани, їхні стани (завантаження, помилка, порожній список) і адаптивність. За простими екранами може стояти складна логіка, і навпаки.

Перша версія. Якщо бюджет обмежений, варто звузити першу версію до MVP з головними функціями, а решту додати після перших користувачів.

Чому перша оцінка приблизна і як її уточнюють

Помилятися в оцінках — звична річ для галузі. Йоргенсен у статті для IEEE Software пише, що проєкти в середньому перевищують заплановані зусилля приблизно на 30 %, а точність оцінок з 1980-х років, схоже, майже не змінилася. Ще одне його спостереження: діапазони «від і до», які дають команди, систематично завузькі, щоб відобразити реальну невизначеність (M. Jørgensen, IEEE Software / InfoQ).

Як діапазон звужується, добре видно в довіднику для менеджерів, виданому Software Engineering Laboratory при NASA (редакція 1990 року). Першу оцінку там роблять одразу після визначення вимог, і її невизначеність така, що реальна цифра може виявитися удвічі меншою або удвічі більшою за оцінку. Далі оцінку переглядають після аналізу вимог, проєктування, реалізації й тестування, і щоразу межі стають ближчими. Щоб урахувати ще не визначені вимоги, зміни в команді тощо, довідник радить закладати в план значення між оцінкою і верхньою межею. Довідник спирається на дані наземних систем NASA, тож це ілюстрація принципу, а не норма для вашого проєкту (NASA SEL-84-101, рис. 3-1 і табл. 3-2).

Що з цього випливає для замовника:

• просіть діапазон, а не одну цифру, і питайте, що його звузить;
• не вимагайте точної ціни, поки обсяг не описано: Йоргенсен прямо радить уникати ранніх оцінок, зроблених на дуже неповній інформації (InfoQ). Це не те саме, що усереднити ціни кількох пропозицій;
• якщо є змога, отримайте кілька незалежних оцінок обсягу в годинах, наприклад від незалежного технічного консультанта й від інженерів виконавця: за Йоргенсеном, середнє незалежних оцінок зусиль зазвичай точніше за більшість окремих (InfoQ).

Корисно також сказати виконавцю, навіщо вам оцінка. Фаулер вважає, що оцінка цінна тоді, коли допомагає ухвалити важливе рішення (Martin Fowler, Purpose of estimation). «Чи вкладемося ми в бюджет першої версії», «що запускати першим» і «чи варто взагалі починати» — різні питання, і точність для них потрібна різна.

Нарешті, оцінювати мають ті, хто робитиме роботу. У Scrum Guide розмір робіт оцінюють розробники, які їх виконуватимуть, а обсяг уточнюють у міру того, як команда дізнається більше (The Scrum Guide). Той самий принцип варто застосувати й до вашої оцінки: спитайте, хто саме її робив.

Технічний консалтинг без припущеньМета — усунути припущення та здогадки, а архітектурні плани й дорожні карти повністю належать вам.

Фіксована ціна чи оплата за години: що це змінює

Основних моделей оплати дві, плюс проміжний варіант, про який нижче. За фіксованої ціни сторони заздалегідь домовляються про суму за визначений обсяг. За оплати за години (time and material) замовник платить за фактично витрачений час, а обсяг можна змінювати по ходу.

Мартін Фаулер звертає увагу: коли кажуть «фіксована ціна», зазвичай мають на увазі, що фіксують одразу ціну, строк і обсяг, а для цього потрібні детальні, стабільні й точні вимоги. Він описує й інший варіант: зафіксувати бюджет і дату, а склад функцій обирати разом у ході роботи (Martin Fowler, Fixed price). Цей підхід добре лягає на першу версію продукту: бюджет відомий, а функції стають у чергу за пріоритетом.

Фіксований обсяг підходить, коли задача чітка і вимоги навряд чи зміняться. Оплата за години — коли задачу ще з'ясовують або продукт розвивається поступово. Ми для чітких завдань працюємо за проєктом із детальною оцінкою, а time and material пропонуємо для гнучкої розробки.

Якщо сторони оформлюють розробку договором підряду, Цивільний кодекс розрізняє приблизний і твердий кошторис. Кошторис вважається твердим, якщо договір не каже інакше. Твердий кошторис змінюють лише за погодженням сторін, а витрати на його перевищення несе підрядник, якщо інше не встановлено законом. Виняток — якщо після укладення договору істотно подорожчали матеріали, устаткування чи послуги інших осіб, якими користується підрядник: тоді він може вимагати збільшити кошторис, а якщо замовник відмовляє, — розірвати договір. Якщо ж через додаткові роботи істотно перевищується приблизний кошторис, підрядник має своєчасно попередити замовника. Замовник, який не погодився на перевищення, може відмовитися від договору, і тоді підрядник може вимагати оплати виконаної частини роботи. Підрядник, який вчасно не попередив, виконує договір за ціною, встановленою договором (Цивільний кодекс України, ст. 844).

Стаття 632 того самого кодексу каже, що змінити ціну після укладення договору можна лише у випадках і на умовах, встановлених договором або законом (Цивільний кодекс України, ст. 632). Тому порядок змін обсягу й ціни варто прописати в договорі до старту, а не домовлятися про нього, коли зміна вже потрібна.

Як порівняти дві пропозиції на розробку

Дві пропозиції можна чесно порівняти, лише якщо вони про одне й те саме. Добрий орієнтир — методика, за якою публічні замовники визначають очікувану вартість закупівлі. Вона починає з визначення потреби, радить надіслати постачальникам не менше трьох письмових запитів цінових пропозицій з повною характеристикою предмета закупівлі, а отримані ціни звести до однакових умов: валюти, умов поставки й оплати (наказ Мінекономіки № 275). Методика написана для публічних закупівель, але принцип годиться і для приватного бізнесу: однаковий опис задачі для всіх виконавців і порівняння за однакових умов.

Друге правило — не обирати лише за найнижчою ціною. Йоргенсен пише, що недооцінка зусиль особливо поширена там, де виконавці змагаються ціною. Конкурс із сильним фокусом на низькій ціні, ймовірно, призведе до вибору надто оптимістичного виконавця, а з ним — до перевищень і нижчої якості. В інших галузях це називають «прокляттям переможця». Йоргенсен радить замовникам орієнтуватися менше на ціну і більше на компетенцію (M. Jørgensen, IEEE Software / InfoQ).

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

Що спитати у виконавця до підпису

Перед підписанням договору пройдіться цим списком. Відповіді краще отримати письмово.

1. З чого складається оцінка і який у неї діапазон?
2. Що точно не входить у ціну?
3. Хто оцінював: менеджер чи інженери, які робитимуть роботу?
4. Як оформлюються зміни обсягу і хто їх погоджує?
5. Що входить у підтримку після запуску і на який період?
6. Хто оновлює інтеграції, коли чужі сервіси змінюють свої API, і за чий рахунок?
7. Кому належать код і права на нього, чи буде у вас доступ до репозиторію?
8. Чи підписує виконавець угоду про нерозголошення (NDA) до детального обговорення?
9. Чи можна почати з короткого етапу дослідження, а оцінку розробки отримати після нього?
10. Чи не вистачить готового рішення? Тут допоможе стаття як вирішити, готова програма чи розробка під себе.

Наші відповіді на частину цих питань такі. NDA ми підписуємо до будь-якого детального обговорення й передаємо всі права на код та IP. У SaaS-проєктах після релізу підтримуємо продукт і виправляємо баги, а період підтримки погоджуємо в договорі. В інтеграціях у межах супроводу оновлюємо код, коли сторонні платіжні чи логістичні системи оновлюють свої API. Але навіть із нами перевірте це в договорі: правило має бути записане, а не обіцяне.

Як ми готуємо оцінку

Після короткого discovery-дзвінка ми надсилаємо детальну оцінку й план робіт, тож ви бачите, за що платите, ще до старту. Бюджет погоджуємо з вами, а якщо обсяг змінюється, кажемо про це до того, як змінюється робота.

Коли ви надсилаєте ідею, ми розбираємо обсяг, ризики й архітектуру, а тоді повертаємося з чіткою пропозицією та планом. Жодних зобов'язань, доки ви не впевнені в плані. Так ми працюємо в Expletech — студії розробки систем, сервісів і сайтів на замовлення.

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

Часті питання

Чому дві студії оцінюють один проєкт так по-різному?

Вони можуть оцінювати різний обсяг: одна заклала тестування, підтримку й інтеграції, інша — ні. Різняться також склад команди, ставки й запас на невідоме. Дайте обом однаковий опис задачі й порівнюйте пропозиції рядок за рядком, а не лише підсумкову суму.

Чи можна дізнатися вартість без технічного завдання?

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

Чим фіксована ціна відрізняється від оплати за фактичні години?

За фіксованої ціни сторони заздалегідь погоджують суму за визначений обсяг, тому потрібні детальні й стабільні вимоги. Якщо ви платите за години, то оплачуєте фактично витрачений час і можете змінювати обсяг по ходу. Є й проміжний варіант: зафіксувати бюджет і дату, а склад функцій обирати разом у ході роботи.

Що може не входити в оцінку розробки?

Перевірте окремо дизайн, тестування, керування проєктом, перенесення даних, сервери й платні сторонні сервіси, підтримку після запуску та оновлення інтеграцій. Якщо рядка немає в пропозиції, спитайте, чи входить ця робота і хто за неї платить.

Чи може вартість змінитися після підписання договору?

Залежить від договору. Стаття 632 Цивільного кодексу України допускає зміну ціни після укладення договору лише у випадках і на умовах, встановлених договором або законом. Якщо ж розробку оформлено договором підряду, стаття 844 ще й розрізняє твердий і приблизний кошторис. Тому порядок змін обсягу й ціни варто прописати в договорі до старту. Це не юридична консультація.

Як обмежити обсяг першої версії продукту?

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

Джерела

1. Цивільний кодекс України № 435-IV, ст. 632, 843, 844
2. Мінекономіки — Примірна методика визначення очікуваної вартості предмета закупівлі (наказ № 275 від 18.02.2020)
3. Magne Jørgensen — What we do and don't know about software development effort estimation (IEEE Software, InfoQ)
4. NASA Software Engineering Laboratory — Manager's handbook for software development, SEL-84-101, rev. 1
5. Martin Fowler — Fixed price
6. Martin Fowler — Purpose of estimation
7. Martin Fowler — Is high quality software worth the cost?
8. Ken Schwaber, Jeff Sutherland — The Scrum Guide (листопад 2020)