Технічне завдання на сайт: що в ньому має бути

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

Хороша новина: ТЗ на сайт — це не сто сторінок. Це девʼять розділів, і більшість із них займають абзац.

1. Навіщо сайт

Одне речення про те, яка дія людини вважається результатом: заявка в месенджер, дзвінок, замовлення, запис.

Звучить очевидно, але саме звідси ростуть рішення. Сайт під заявки й сайт під впізнаваність виглядають по-різному, і якщо мета не записана, кожна сторона добудовує її сама.

2. Хто покупець

Коротко: хто ці люди, що вони вирішують і чого бояться. Два-три абзаци.

Без цього підрядник пише тексти «для всіх», а такі тексти не працюють ні для кого.

3. Структура сторінок

Перелік усіх сторінок і того, що на кожній. Не дизайн — склад.

Головна: герой, послуги, ціни, кейси, FAQ, контакти
Послуга (×8): кому підходить, що входить, чого немає,
              ціна і строк, FAQ, форма
Ціни: пакети, калькулятор
Контакти: канали звʼязку, години роботи

Це половина ТЗ за обсягом і джерело оцінки строку: ціну визначає кількість типів сторінок, а не їх загальна кількість.

4. Функції

Усе, що не є текстом і картинкою: форми, калькулятор, фільтри каталогу, особистий кабінет, онлайн-запис, пошук.

По кожній — що вона робить і що відбувається після натискання. «Форма зворотного звʼязку» недостатньо: куди йде заявка, які поля обовʼязкові, що бачить людина після відправки.

5. Інтеграції

Поіменний перелік: CRM, платіжна система, служба доставки, система запису, 1С.

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

6. Хто пише тексти і звідки фото

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

Те саме про фото: своя зйомка, стокові зображення чи ваш архів.

7. Що НЕ входить

Найважливіший розділ, і його пишуть найрідше.

Перелік того, що входить, напише будь-хто. Цінну інформацію несе другий список: копірайтинг понад одну ітерацію, фотозйомка, наповнення каталогу, друга мова, налаштування рекламних кампаній, SEO-просування після запуску, хостинг і домен.

Усе, чого немає в першому списку і немає в другому, стане суперечкою.

8. Як приймаємо

Критерії, які можна перевірити, а не оцінити на смак:

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

«Має подобатися» критерієм не є: його неможливо перевірити, а отже, неможливо й вимагати.

9. Строки й оплата по етапах

Не одна дата, а точки: прототип, дизайн, верстка, наповнення, запуск. До кожної — строк і платіж.

Це дає вам можливість побачити відставання тоді, коли його ще можна надолужити, а не в день здачі.

Чого в ТЗ бути не повинно

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

Точних пікселів і кольорів. Це завдання дизайну, а не ТЗ.

Формулювань «сучасний», «зручний», «продаючий». Їх неможливо перевірити, а значить неможливо вимагати.

Що робити, якщо підрядник не пропонує ТЗ

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

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

Писати ТЗ самому з нуля не треба: ви не зобовʼязані знати, які питання поставити. Але вичитати й погодити — зобовʼязані, і це ваша частина роботи.

ТЗ рятує, коли міняється підрядник

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

Без ТЗ новий виконавець починає з нуля — йому треба заново зʼясовувати, що мало бути зроблено. З ТЗ він відкриває документ і бачить обсяг, структуру й критерії приймання. Це різниця в кілька тижнів і в кілька тисяч гривень на сам тільки перехід.

Той самий документ відповідає й на болісне питання «скільки вже зроблено»: за переліком сторінок і функцій видно, що закрите, а що ні.

Хто його пише

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

Ненормально, коли ТЗ немає взагалі, а є листування в месенджері. Листування не має структури: через місяць ніхто не згадає, у якому саме повідомленні про що домовились.

---

Перед ТЗ зазвичай робиться прототип — на ньому структуру видно, а не уявляється. А до того, як платити, варто поставити дванадцять питань підряднику.

Як ми це робимо по етапах — на сторінці процесу.