Брифінг до контракту: документ, який економить нам $20K

Це для людей, які мають ідею і шукають виконавця. Якщо нам уже пропонували підписати договір “під ключ” одразу — а нутром відчували, що зарано, — це для нас.

Чому ми пишемо цей пост

У попередньому матеріалі ми говорили про критерії приймання — документ, який описує, що значить “готово”. Але є момент, який передує навіть критеріям. Це момент, коли ми ще не знаємо, що саме замовляємо.

Найдорожча помилка людини з ідеєю — підписати договір на розробку до того, як хтось чесно розклав, що ми робимо, для кого, і чого можна не робити взагалі. Виконавець у такому випадку має лише один спосіб назвати ціну: накинути зверху великий запас “на невідомість”. Іноді цей запас — 2x, іноді 3x.

Лікується це одним маленьким документом і одним маленьким контрактом. Документ — брифінг до контракту. В IT-середовищі його часто називають discovery brief або результат етапу розвідки (англ. discovery). Далі я вживатиму обидва терміни як зручніше.

Чому “під ключ” без брифінгу — це лотерея

Уявімо, що ми звертаємось до архітектора і кажемо: “побудуйте мені будинок”. Архітектор, який поважає себе і нас, не назве ціну. Він спитає: для скількох людей? З гаражем? На якій ділянці? Які зими? Чи плануємо здавати? Тільки після цих питань, після ескізу і після грубої оцінки матеріалів — починається розмова про гроші.

В IT відбувається те саме, тільки питань ще більше, бо програма не має фундаменту, який видно неозброєним оком.

Коли виконавець погоджується підписати контракт “на розробку застосунку” без брифінгу — це означає одне з двох:

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

У одному з ілюстративних проектів, які я бачив за 8 років роботи бізнес-аналітиком у різних галузях — від енергетики до фінтеху, — команда зекономила приблизно $20-30K тільки тому, що замовник наполіг на двотижневому брифінгу до підписання великого договору. Після брифінгу зрозуміло було, що дві з чотирьох “обов’язкових” фіч можна не робити взагалі — користувачам вони не потрібні. Гроші повернулись у бюджет ще до старту розробки.

Що таке брифінг до контракту — простими словами

Це короткий етап (зазвичай 2-4 тижні), за результатом якого ми отримуємо документ на 10-20 сторінок, у якому чесно записано: що ми робимо, для кого, чому, що не робимо, з якими ризиками, скільки приблизно це коштуватиме і скільки триватиме.

Ключове слово — “приблизно”. Брифінг не дає точної ціни. Він дає діапазон, у якому ціна реальна — наприклад, “від $80K до $120K, з обґрунтуванням, чому 30% розкид”. Точніше за чесний діапазон не дасть ніхто, хто не пройшов цього етапу.

І це найважливіше: брифінг — це окремий маленький контракт, який ми підписуємо до великого. Не “ми вам зробимо discovery безкоштовно, а потім ви підпишете розробку у нас”. Безкоштовно — означає, що ми вже в зобов’язанні, бо інакше нам незручно піти до конкурента. Платний — означає, що ми вільні.

7 секцій, які має містити брифінг

Якщо нам приносять брифінг на 80 сторінок — це проблема. Якщо на 3 сторінки — теж проблема. Орієнтир — 10-20 сторінок, із 7 секціями:

1. Контекст

Одна сторінка про те, навіщо цей проект існує. Не “ми хочемо застосунок”. А: “наші клієнти зараз втрачають 40 хвилин на тиждень на щось, що можна зробити за 5 хвилин — і це коштує нам [X] клієнтів на рік”. Якщо в брифінгу немає такої цифри або хоча б оцінки — це не брифінг, а вступ до брошури.

2. Користувачі

Хто конкретно буде клікати на наш продукт. Не “користувач” і не “клієнт”, а 3-5 портретів з іменами і обставинами: “Марія, 42 роки, бухгалтер у малому бізнесі, відкриває застосунок 2 рази на тиждень увечері з телефона, найбільший біль — пошук минулого платежу”.

3. Задача (jobs-to-be-done)

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

4. Припущення

Те, в що ми віримо, але не довели. Кожне припущення — це ризик. Приклад: “припускаємо, що користувачі готові ввести номер картки в нашому застосунку”. Поки не перевірили на 10 людях — це гіпотеза, не факт. У брифінгу таких 5-10. Без переліку припущень ми просто будуємо на піску.

5. Обмеження

Все, що ми не можемо змінити: бюджет ($X), термін (3 місяці), регуляторні вимоги (банк, ATC, медицина), технічний стек (бо інтеграції з існуючою системою). Без чесного переліку обмежень ціна буде брехнею в обидва боки.

6. Артефакти, які буде створено

Що саме ми отримаємо за свої гроші. Не “ми вам зробимо застосунок”, а конкретно: дизайн в Figma на 25 екранів / 80 інструкцій для команди (user stories) з критеріями приймання / архітектурна схема / список зовнішніх інтеграцій з оцінкою складності.

7. Наступний крок

Що відбувається після брифінгу. Найчесніший варіант звучить так: “за результатом ми приймаємо одне з трьох рішень — (а) йдемо в розробку у нас за оцінкою $X-Y, (б) йдемо в розробку до іншого виконавця з цим документом, (в) проект призупиняємо, бо брифінг показав, що ідея не варта грошей”. Усі три варіанти — нормальні. Якщо в наступному кроці виконавець “автоматично” продовжує контракт на розробку — це не брифінг, це presale.

Ілюстративний приклад: енергетичний застосунок

В одному проекті, де я допомагав готувати брифінг для застосунку у сфері енергетики (це ілюстративний композит з мого досвіду, без посилання на конкретного замовника), вийшло так.

Замовник хотів “застосунок для оплати комуналки”. Бюджет він тримав у голові на рівні $150K, термін — 6 місяців.

Після 3 тижнів брифінгу картина змінилась:

Виявилось, що 70% користувачів відкривають застосунок не для оплати, а щоб подивитись показники лічильника. Оплата — другорядна функція.
Дві “обов’язкові” фічі (кешбек і чат із техпідтримкою) виявились непотрібними — це показали 12 коротких інтерв’ю з реальними користувачами.
Натомість з’явилась критична потреба — нагадування за день до останнього дня оплати. Без неї 30% користувачів пропускали термін і платили пеню.

Підсумок: бюджет скоротився до ~$95K, термін — до 3,5 місяців. Запуск пройшов із вимірним результатом: ключова дія (передача показників) стала на ~35% швидшою, а кількість дзвінків у підтримку впала на ~20%.

Брифінг коштував замовнику близько $12K. Економія порівняно з первісним планом — десятки тисяч, плюс продукт, яким люди користуються.

Як оплачувати брифінг

Три практичні правила:

Фіксована ціна, не “за годину”. Брифінг 2-4 тижні з конкретними артефактами. Якщо нам пропонують почасову — це означає, що виконавець не оцінив об’єм роботи, а отже не оцінить і нашу ідею.
Окремий контракт. Не “додаток до майбутньої розробки”. Окремий маленький документ на пів сторінки: терміни, ціна, що отримуємо, що ми не зобов’язані йти далі саме до них.
Платимо повністю до або після, без проміжних застрягань. Стандарт — 50% при старті, 50% після прийняття документа. Без “70/30, бо ми так звикли”.

Сума, на яку варто розраховувати: для невеликого проекту (вебзастосунок або мобільний застосунок) — $8-20K за етап розвідки. Якщо менше — ймовірно, нам продають документ “за шаблоном”. Якщо суттєво більше — варто питати, що там складного.

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

“Discovery нам не потрібен — ідея проста.” Якщо ідея справді проста, брифінг займе не 4 тижні, а 2, і коштуватиме не 20K, а 8K. Простота не скасовує етапу — вона просто його скорочує.
Беремо безкоштовний “presale brief”. Він безкоштовний, бо це маркетинг виконавця, а не наш документ. Він буде писати про себе, не про нас. І ми будемо психологічно “винні” продовжити співпрацю.
Не питаємо про право власності на документ. У договорі на брифінг обов’язково має бути написано: документ — наш. Ми можемо взяти його і піти з ним до будь-якого виконавця.
Здаємось після брифінгу і не вимагаємо діапазону. Брифінг без діапазону вартості й термінів — це наполовину зроблений брифінг. Якщо виконавець каже “не можемо назвати, дуже багато факторів” — або документ погано написаний, або ми обираємо не ту команду.

Що буде далі

Це другий пост серії про артефакти бізнес-аналізу — документи, які захищають нас на стороні замовника. Якщо пропустили перший — там про критерії приймання: що значить “готово” до того, як ми почали.

Наступний матеріал — про інструкцію для команди розробників (user story). Як читати ці рядки в Jira чи Notion і розуміти, за що ми платимо, а де нас просять платити двічі.

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

Якщо в нас зараз є ідея і виконавець, який пропонує підписати договір “під ключ” одразу — це момент для паузи. У Ascend Griffin ми робимо Discovery Sprint — двотижневий брифінг до контракту, після якого ми йдемо в розробку із цифрами в руках, а не з відчуттями.