Бриф на розробку сайту й додатків: що включити, щоб не переплачувати і не переробляти

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

Бриф на розробку сайту: навіщо він, якщо підрядник «усе розуміє»

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

Мета й метрики успіху: який бізнес-результат вам потрібен

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

Що входить у бриф на розробку сайту і що прямо не входить

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

Структура на дві сторінки, яку можна скопіювати

Розділ	Що написати	Приклад
Мета	Результат і цифра	КП за дві години замість двох днів
Користувачі	Хто й що робить	Менеджер створює КП
Входить	Основні частини простими словами	Форма, PDF, зв’язок із CRM
Не входить	Що виключаємо	Перенесення даних, мобільний додаток
Інтеграції	Системи й дані	CRM, платіжний сервіс
Приймання	Як перевіримо	Десять сценаріїв проходять
Люди	Хто вирішує й як швидко	Один власник, відповідь за два дні

Користувачі, сценарії та інтеграції з вашими системами

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

Вимоги до даних, безпеки та GDPR, а також до доступності

Напишіть, з якими даними працює продукт і де їх потрібно зберігати. У брифі на розробку сайту цей рядок часто пропускають, а потім за нього платять подвійно, бо підрядник змушений переробляти вже готову базу даних. Якщо зачіпаються персональні дані мешканців ЄС, підряднику, що обробляє їх для вас, потрібен письмовий договір, як вимагає стаття 28 GDPR. Щодо безпеки назвіть базу замість «має бути безпечно», наприклад OWASP Application Security Verification Standard. Щодо доступності попросіть відповідність WCAG 2.2 названого рівня. Ці рядки майже нічого не коштують у брифі й дуже дорого обходяться, якщо їх додати пізно.

Строки, етапи приймання та хто ухвалює рішення

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

1. Запишіть, що покажуть на кожному етапі.
2. Визначте перевірку: сценарії, пристрої, дані.
3. Домовтеся, хто підписує і за скільки днів.
4. Вирішіть, як оцінюються й погоджуються зміни.

Як вибрати формат співпраці, ми розбирали в матеріалі про аутсорсинг розробки чи власну команду.

Які запитання ставить гарний підрядник і що означає, якщо він мовчить

Гарна команда ставить запитання до кошторису. Очікуйте таких:

• Який бізнес-результат потрібен і як ви його виміряєте?
• Хто користувачі й хто ухвалює рішення з вашого боку?
• До яких систем потрібно підключитися і хто володіє доступом?
• Який діапазон бюджету й жорсткий строк, якщо він є?
• Що не можна змінювати, а що може зачекати до другої версії?

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