Технічне завдання на сайт багато хто відкладає на потім: спочатку зроблять, а документ якось додадуть уже по ходу. Це зрозуміло — і це дорого. Правка в тексті ТЗ — кілька хвилин роботи; та сама правка після верстки — години дизайнера, розробника й тестувальника, оплачені з вашого бюджету. Нижче розберемо, як скласти ТЗ на сайт, який закриває питання ще до старту робіт: які блоки має містити документ, де типові прогалини і як за 20 хвилин перевірити, що нічого не забули.
Чому ТЗ — страховка для обох сторін
ТЗ виконує просту функцію: фіксує, що саме входить у роботу, до того, як робота почалася. Звідти й економія: чим пізніше з’являється зміна, тим дорожче вона обходиться. На етапі документа це редагура абзаца; на етапі верстки — переробка макетів, коду та тестів. Саме тому досвідчені замовники спочатку домовляються, що сайт вміє, а вже потім обговорюють ціну й терміни.
Три типові сценарії, у яких бюджет тече без ТЗ. Кожен із них — звична історія з ринку: вимогу озвучили вголос на зустрічі, але не записали в документ, і на фініші виявилося, що сторони пам’ятають її по-різному.
«А давайте ще одну сторінку». На етапі документа нова сторінка — це рядок у структурі. На етапі верстки — дизайн-макет, тексти, розмітка, адаптив під мобільні, перевірка форм. Усе це окремі години роботи, які без зафіксованого обсягу перетворюються на суперечку «це ж очевидно було потрібно» — і на доплату, про яку не домовлялися.
«Зробили, але не те». Без критеріїв приймання кожна сторона впевнена у своїй правоті: підрядник каже «усе за домовленістю», замовник відповідає «я уявляв інакше». У ТЗ така розбіжність вирішується одним реченням у документі. Без нього — тижнем переробок на догоду чужій інтерпретації.
«А де інтеграція з CRM?» Коли про інтеграцію згадують на фініші, вона додає до проєкту тижні: доступи, налаштування полів, тести заявок у обидва боки. У ТЗ інтеграції перераховані списком ще до оцінки, і їхня вартість закладена в кошторис заздалегідь, а не з’являється окремим рахунком у кінці. До цього ж блоку належить і аналітика: лічильники, цілі, події форм. Без неї після запуску не буде видно, звідки приходять заявки, — а це питання, яке неможливо вирішити заднім числом.
Чому усні домовленості цього не закривають, зрозуміло з практики: пам’ять у всіх вибіркова, а інтереси різні. Через два тижні після старту замовник пам’ятає свої слова на зустрічі, проєктний менеджер — свої, і кожен щиро вважає себе правим. Документ не вступає в цю суперечку: те, що записано, не залежить від того, хто як запам’ятав.
ТЗ вигідний обом. Замовник знає, за що саме платить, і може порівняти пропозиції кількох підрядників на рівних умовах. Студія — що саме має здати, щоб проєкт вважався завершеним, і не витрачає час на нескінченні узгодження смаків. Працювати без документа можна, але тоді кожна неозначена деталь стає предметом торгу після того, як гроші вже заплачені. Додається і втрата часу: проєкт, який «майже готовий» два тижні, зриває запуск до сезону чи рекламної кампанії, а це вже втрачений доход, якого немає в жодному рахунку студії.
Що має бути в ТЗ мінімум
Мінімальне ТЗ, яке реально працює, складається з дев’яти блоків. Розберемо кожен із прикладами формулювань, які можна взяти й адаптувати під свій проєкт.
1. Цілі сайту
Одне-два речення: що сайт має зробити для бізнесу. Приклад: «Сайт генерує заявки на консультацію — ціль 30–50 на місяць — і знімає типові запитання клієнтів телефоном». Цілі визначають усе решта: структуру, функції, критерії приймання. Якщо сайт потрібен «просто для присутності», це теж варто зафіксувати — тоді не доведеться оплачувати складні механізми, які ні до чого не ведуть. Перевірка якості цілі проста: за нею видно, яку дію має зробити відвідувач. «Подивитися інформацію» — слабка ціль, за якою неможливо оцінити результат; «залишити заявку на розрахунок» — сильна, бо її можна порахувати.
2. Аудиторія
Хто буде користуватися сайтом. Приклад: «Основний сегмент — власники квартир у новобудовах Києва, 30–45 років, приходять з Instagram і Google, переважно з телефона». Досить двох-трьох сегментів із зазначенням, звідки вони приходять і що для них важливо: ціни, документи, терміни, відгуки.
3. Структура сторінок
Повний перелік сторінок із підпунктами: що буде на кожній. Приклад: «Послуги — окрема сторінка під кожну послугу: склад робіт, етапи, ціни „від“, форма заявки». Саме тут «а давайте ще сторінку» повертається з етапу верстки на етап простого пункту у списку. Не забувайте службові сторінки — політика конфіденційності, умови повернення, сторінка підтвердження заявки: їх зазвичай згадують у самому кінці, коли основні сторінки вже зверстані.
4. Функції
Форми, калькулятори вартості, пошук, особистий кабінет, мультимовність, підписка на розсилку. Приклад: «Форма заявки — ім’я, телефон, обрана послуга; лист приходить менеджеру та клієнту». Кожна функція — окрема робота з власною оцінкою, тому в ТЗ вона описується окремим пунктом, а не узагальненням «з усіма зручностями». Окремої уваги заслуговує мультимовність: якщо сайт планується українською та англійською, це впливає і на структуру, і на верстку, і на обсяг контенту, тож пункт має звучати явно, наприклад: «Дві мовні версії з перемикачем у шапці; переклади надає замовник».
5. Контент: хто і що готує
Тексти, фото, відео, ілюстрації, переклади. Приклад: «Тексти готує студія на основі інтерв’ю з замовником, два коли правок; фото надає замовник у термін до 1 квітня». Невизначеність у цьому блоці — найчастіша причина зриву термінів: сайт готовий, а наповнити його нічим.
6. Інтеграції
CRM, платіжні системи, служби доставки, аналітика, email-сервіси. Приклад: «Заявки падають у CRM у воронку „Сайт“ і дублюються в Telegram-групу менеджерів». Якщо інтеграція важлива, назвіть конкретний сервіс: підключення різних CRM відрізняється за складністю, і ця різниця має бути видною в оцінці.
7. Терміни та етапи
Не лише фінальний дедлайн, а розбивка: прототип, дизайн, верстка, наповнення, тестування. Приклад: «Дизайн-концепція — до 15 березня; правки узгоджуємо протягом трьох робочих днів». Етапи дають точки контролю: не треба чекати двох місяців, щоб побачити, у якому напрямку рухається проєкт. Іще одна корисна деталь — залежності: якщо правки до дизайну тривають тиждень замість трьох днів, етап верстки зсувається відповідно. Коли це прописано наперед, зсув термінів не перетворюється на взаємні претензії.
8. Критерії приймання
Вимірювальні умови, за яких роботу визнають виконаною. Приклад: «Усі сторінки відкриваються у зеленій зоні PageSpeed Insights на мобільному; кожна форма доставляє листа на тестову пошту; жодних сторінок із заглушками „розділ наповнюється“». Без цього блоку підписати акт неможливо принципово — немає шкали, за якою «готово» відрізнити від «майже готово».
9. Взаємодія та відповідальні
Хто зі сторони замовника приймає рішення, за скільки днів дається зворотний зв’язок, що станеться, якщо правок виявиться більше за погоджену кількість. Приклад: «Етапи затверджує директор; коментарі — протягом двох робочих днів; додаткове коло правок дизайну оцінюється окремо».
Для лендінгу логіка та сама, тільки компактніша: структура задається блоками — оффер, переваги, пропозиція, відгуки, форма — і кожен блок описується так само конкретно, як окрема сторінка корпоративного сайту. ТЗ на лендінг, у якому написано лише «сторінка під рекламу», з великою ймовірністю повернеться на доробку після першого ж запуску.
Якщо якийсь блок до проєкту не застосовується — CRM поки немає, кабінет не потрібен, — це теж варто записати. Фраза «інтеграції не потрібні» працює так само, як перелік сервісів: вона знімає питання, чи функцію забули, чи свідомо відмовилися.
Від обсягу цих блоків напряму залежить точність кошторису: що детальніше описані функції та інтеграції, то менше в оцінці «здогадок підрядника». Як із вимог рахується ціна сайту загалом — розібрали в окремій статті «Скільки коштує сайт».
Типові діри в ТЗ
Суперечки в проєктах народжуються з дрібниць, які обидві сторони вважали очевидними. Ось чотири пункти, які найчастіше лишаються поза документом — і найдорожче коштують потім.
«Тексти хтось напише». Хто саме, коли і скільки правок? Якщо тексти пише замовник «потім, коли-небудь», сайт здається порожнім, а запуск зсувається на тижні. Дата, відповідальний і кількість колій правок мають стояти в ТЗ поряд з будь-якою іншою роботою. Практичний орієнтир, який рятує від зриву термінів: контент готовий до етапу наповнення, а не після нього.
Порожній блок критеріїв приймання. Формулювання «зробіть гарно і зручно» не перевіряється жодним інструментом. Зразок для цього блоку — у восьмому пункті попереднього розділу; якщо його немає, проєкт завершується суперечкою про готовність, а не актом.
«Зробіть як у конкурента». Чужий сайт — це чужі рішення під чужу аудиторію, чужий бюджет і чужу команду. Копія зазвичай приносить осічку: конкурент уже вклав у свій ресурс роки й дані, яких немає у вас. Референси корисні як орієнтир для розмови: «подобається логіка каталогу тут, подача цін — тут». У ролі технічного завдання вони працюють погано. Якщо ж підрядник не ставить уточнювальних питань і охоче згоден повторити чужий макет, перечитайте чек-лист «Як обрати digital-агентство» — це ознака команди, яка працює шаблоном.
Мобільна версія не згадана. Український трафік у переважній більшості ніш надходить зі смартфонів, тож мобільна версія — це основна версія сайту. Якщо в ТЗ не сказано, що вона обов’язкова і як само перевіряється, десктопний макет можуть натягнути на телефон і здати як готове. Контрольний прийом простий: попросіть показати проєкт на реальному смартфоні на етапі демо — до підписання акту, а не після.
Чек-лист готовності до розробки: 10 пунктів за 20 хвилин
Перед тим як відправляти ТЗ підряднику або підписувати договір, пройдіть чек-лист. Він займає близько 20 хвилин і знімає більшість суперечок, які інакше виникли б уже під час роботи.
- Ціль сайту сформульована одним реченням і вимірюється: заявки, дзвінки, продажі, записи — замість абстрактного «розвитку бренду» без цифри.
- Визначено основного відвідувача: хто це і звідки він прийде на сайт.
- Є повний перелік сторінок, включно зі службовими: помилка 404, політика конфіденційності, сторінка «дякуємо за заявку».
- Кожна функція описана окремим пунктом: форми, калькулятори, пошук, мовні версії.
- Написано, хто готує кожен тип контенту і скільки колій правок передбачено.
- Перераховані всі інтеграції з конкретними сервісами, а не «з’єднати з CRM».
- Є етапи з датами, а не лише загальний дедлайн здачі.
- Критерії приймання сформульовані так, що їх можна перевірити без участі дизайнера.
- Зазначено, хто зі сторони замовника затверджує етапи і за скільки робочих днів дає зворотний зв’язок.
- Обидві сторони прочитали ТЗ разом і письмово погодили кожен пункт — хоча б у листуванні.
Якщо хоча б один пункт не закритий, сайт готовий до розробки лише наполовину, хоча б у документі все виглядає акуратно.
Корисно пройти чек-лист і в дзеркальний бік: надіслати його підряднику разом із ТЗ і попросити позначити, що само виконавець вважає входженням у вартість, а що — окремою роботою. Відповідь у вигляді списку відсіює непорозуміння ще до договору.
З чого почати: готовий бриф замість чистого аркуша
Найважче в ТЗ — чистий аркуш. Тому ми зібрали всі блоки з цієї статті в готовий бриф на розробку сайту й віддали у відкритий доступ: sava1.com.ua/bryfy/site/. Ви відповідаєте на запитання групами — цілі, аудиторія, структура, функції, інтеграції, терміни, — а на виході отримуєте структурований документ, який можна віддати будь-якій студії.
Готовий бриф корисний іще в одному: коли двоє підрядників отримують однаковий вихідний документ, різниця в їхніх оцінках показує різницю в підходах, а не здогадки кожного з них. Тому його варто заповнити до перемовин, а не після них: пропозиції, зібрані на основі однакового ТЗ, порівнюються предметно — за складом робіт, термінами та умовами, а не за якістю презентацій. Це робить порівняння пропозицій чесним.
Висновок
Якщо підрядник пропонує почати роботу без ТЗ і «узгоджувати все по ходу», поставте одне питання: як тоді виглядатиме акт приймання готового сайту? Відповідь швидко нагадає, навіщо взагалі знадобився документ. Щоб перетворити бриф на працюючий сайт, заповніть його за посиланням — а якщо хочете віддати реалізацію команді, яка працює з ТЗ як з робочим інструментом, дивіться нашу послугу розробки сайтів.