Оцінка від IT-компанії: як читати правильно і де виконавець має інші інтереси, ніж ми

Це для людей, які отримали комерційну пропозицію з оцінкою “200 годин · $25K” і не знають, як перевірити: це чесна цифра, чи дві в стелю взяті.

Чому це болить

Оцінка від IT-компанії — це, можливо, найдорожчий PDF у нашому житті після нотаріального договору купівлі-продажу квартири. У ньому одна цифра — і ми вирішуємо, віддавати її чи ні.

Найгірше — те, що ми не знаємо, як цей PDF читати. Нам пишуть “200 годин розробки, 40 годин QA, 30 годин менеджменту, 20 годин дизайну” — і це все. Що там усередині? Чому 200, а не 150? Чому 40 на QA, коли в нас немає платіжних транзакцій? Питати соромно: подумають, що ми торгуємось або не довіряємо.

Не варто соромитись. Гарний виконавець із задоволенням пояснить кожну цифру — це його робота. Поганий буде злитись на питання — і це теж відповідь.

За 8 років роботи в проектах від енергетики до фінтеху, від держсектору до AI-логістики, у мене склався набір простих ознак, за якими видно якісну оцінку — і набір ознак, за якими видно роздуту. Зараз поділюся.

4 ознаки якісної оцінки

Ознака 1: розбивка по задачах, а не по ролях

Чесно:

Задача	Оцінка
Реєстрація користувача (email + SMS-підтвердження)	25 год
Особистий кабінет (перегляд профілю, зміна пароля)	15 год
Інтеграція з банком [назва] для оплати	40 год
…

Нечесно:

Роль	Оцінка
Frontend-розробка	120 год
Backend-розробка	180 год
QA	60 год
PM	40 год

Друга таблиця нічого нам не каже. Перша — каже все. Якщо ми бачимо тільки другу, перше питання має бути: “А можете показати, з яких задач складається ці 120 годин фронтенду?”

Ознака 2: вилки, а не точні цифри

“Реєстрація користувача: 18-28 годин, залежно від того, чи потрібна валідація через банк.”

Це звучить дивно — як це “не знаєте точно?”. Насправді це найчесніше, що може написати виконавець. Програмування — не виробництво гайок. Половина задач містить припущення, які перевіряються тільки в коді. Виконавець, який пише “точно 23 години” — або вже робив це 30 разів (тоді він мав би сказати “у нас є шаблон”), або вгадує, не визнаючись.

Ознака 3: явні припущення

Чесна оцінка містить розділ “Припущення, на яких базується ця цифра”. Приклади:

“Дизайн надає замовник у Figma, ми не робимо UI/UX з нуля.”
“Інтеграція з банком [назва] — припускаємо, що API-документація доступна публічно. Якщо потрібен NDA — додатково 8 годин на узгодження.”
“Тестування — функціональне і ручне. Автотести — окрема позиція, не входить.”

Якщо в оцінці немає цього розділу — це означає одне з двох: або виконавець уже зашив усі припущення в “buffer” (зайві 30%), або планує пред’явити нам додаткові рахунки за все, що не зробив.

Ознака 4: окрема позиція “невизначеність”

Хороші команди пишуть так:

“Сума оцінки: $20-28K. Розкид 30% пояснюється тим, що ми ще не бачили робочу версію API партнера. Після етапу розвідки (2 тижні, $5K) розкид скоротиться до ±10%.”

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

4 ознаки роздутої оцінки

Ознака 1: “Buffer” 50% без пояснення

“Розробка: 200 годин. Менеджмент і ризики: +100 годин.”

Менеджмент — це 5-15% від розробки. 50% — це або страх (виконавець не розуміє нашу задачу), або жадібність. Чесний buffer пишеться як “10% на координацію і непередбачені правки” — і це нормально. 50% означає, що ми платимо за чужу невпевненість.

Ознака 2: “QA окремо, дизайн окремо, документація окремо, девопс окремо, security окремо”

Коли оцінка побудована з 8 розділів, кожен з яких “не входить у попередній”, фінальна сума стає в 2-3 рази більшою за розробку. Це класична тактика: показати маленьку цифру на першій сторінці, додати все інше дрібним шрифтом далі.

Чесно — це коли в оцінці одразу написано: “Сума включає розробку, тестування, дизайн, базову документацію і devops для запуску. Не включає: пост-релізну підтримку (окремий договір), маркетинг, контент.”

Ознака 3: відсутність “що ми НЕ робимо”

У одному з ілюстративних проектів, які я бачив, виконавець подав оцінку на $80K за “повноцінний MVP за 4 місяці”. На прохання уточнити, що не входить — відповіді не було тиждень. На прямий контр-питання “чи робите ви інтеграцію з 1С?” — “так, але це окрема позиція $15K”. І так далі: про кожну фічу виявлялось окремо. Реальна вартість після всіх “окрім” була $140K.

Чесна оцінка має розділ “Поза рамками цієї пропозиції”. Якщо його немає — припускаймо, що поза рамками все, що ми не назвали явно. І це проблема.

Ознака 4: “Швидко, якісно, дешево” — усе разом

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

”Buffer” — нормально чи ні?

Коротко: так, у межах 10-20% від основної суми, з явним поясненням, для чого.

Нормальний buffer виглядає так:

“До оцінки додаємо 15% на координацію, мінорні правки після демо і непередбачені залежності. Якщо buffer не використано — повертаємо як знижку на наступний етап або не нараховуємо взагалі (за форматом договору T&M).”

Ненормальний buffer виглядає так:

“Ризики: +30%.”

Без розшифровки, які саме ризики. Без правила, що відбувається, якщо ризики не реалізувались. Просто +30% згори.

Fixed price vs T&M простими словами

Дві основні моделі оплати, з якими ми зустрінемось:

Fixed price (фіксована ціна за весь проект):

Ми домовляємось: “$50K за весь застосунок”.
Якщо виконавцю довелось більше — це його проблема.
Якщо вийшло швидше — це його прибуток.
Що насправді відбувається: виконавець закладає в ціну великий buffer (20-40%), бо ризик на ньому. Ми за цей buffer платимо, навіть якщо він не використається.

T&M (Time & Materials, погодинно):

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

Підказка: для маленьких проектів з зрозумілою задачею (до 3 місяців) — fixed price часто чесніший. Для довгих або невизначених — T&M, але з тижневим звітуванням і правом призупинити в будь-який момент.

І найважливіше — fixed price не завжди дешевший. У одному ілюстративному проекті, який я бачив, fixed price на $80K у фінальному рахунку обійшовся в $120K через 12 додаткових угод про “зміни рамок проекту” протягом 4 місяців. T&M на ту саму задачу з тижневим звітуванням закінчився б, ймовірно, у $90K.

Питання, які варто поставити перед “Так”

Коли ми отримали оцінку і хочемо поставити паузу — ось 5 питань, які допомагають побачити, що там усередині:

“Покажіть розбивку 200 годин розробки по задачах — по 5-10 годин на задачу.” Якщо у виконавця така розбивка є — добрий знак. Якщо “ми не робимо таку детальну” — погано.
“Які 3 найбільші припущення в цій оцінці? Що відбувається, якщо одне з них не справдиться?” Чесна відповідь має містити конкретні приклади.
“Що НЕ входить у цю цифру?” Хороший виконавець перерахує 5-10 пунктів за секунду.
“Якщо ми робимо етап розвідки за $5-10K — наскільки ця оцінка може змінитись?” Чесна відповідь: “плюс-мінус 20-30%”. Нечесна: “ми вже все знаємо, розвідка не потрібна”.
“Як ви рахуєте складність — за нашими словами чи після спілкування з вашою технічною командою?” Якщо комерційну пропозицію писав менеджер з продажу без розробників — це майже завжди погано закінчується.

Часті помилки на цьому етапі

Підписуємо найдешевшу пропозицію. “Найдешевший” майже завжди закінчується найдорожчим — або через якість, або через додаткові угоди.
Не порівнюємо оцінки за однаковим набором питань. Якщо ми кожному виконавцю розказали по-різному — ми не порівнюємо. Про це буде окремий пост серії.
Соромимось питати про buffer. Buffer 30%+ без пояснення — це наша головна точка торгу. Гарний виконавець або обґрунтує, або зменшить. Якщо просто розсердиться — це теж відповідь.
Не вимагаємо письмового переліку “що НЕ входить”. Усне “ну ми ж домовились” не врятує через 3 місяці, коли почнуться правки за окрему оплату.

Що буде далі

Це четвертий пост серії про артефакти бізнес-аналізу. Попередні — про критерії приймання, про брифінг до контракту і про user story.

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

Якщо не хочемо пропустити — стежимо за мною у LinkedIn, там анонсую кожен матеріал серії.

Якщо в нас зараз на столі оцінка від IT-компанії і нутро каже “забагато” — це привід поставити паузу. У Ascend Griffin ми робимо Vendor Audit — перевірку комерційної пропозиції до підписання, на нашому боці столу. Зазвичай це коштує менше, ніж сума однієї додаткової угоди про “зміну рамок проекту”.