Як скласти технічне завдання на сайт

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

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

Навіщо ТЗ, якщо можна домовитися на словах

Усні домовленості працюють, поки проєкт маленький і всі пам’ятають, про що говорили. Щойно з’являються десяток сторінок, інтеграція з CRM, дві мовні версії й кілька людей з боку клієнта, пам’ять перестає бути надійним інструментом. ТЗ потрібне не для бюрократії, а для чотирьох цілком практичних речей:

• Точна оцінка. Без переліку сторінок і функцій будь-яка ціна — це вгадування. Підрядник або закладає запас «на невідоме», або дає низьку цифру, а потім виставляє додаткові рахунки.
• Спільна мова. Слово «каталог» для одного означає список із фото, для іншого — фільтри, порівняння й вибране. У ТЗ ми записуємо, що саме мається на увазі.
• Контроль меж проєкту. Нові ідеї з’являються завжди. ТЗ дозволяє чесно відрізнити «це входило в домовленість» від «це нова задача, давайте оцінимо окремо».
• Приймання робіт. Якщо в документі є критерії, наприкінці не треба сперечатися, чи «сайт готовий». Ми просто проходимо вимоги по пунктах.

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

Бриф і ТЗ: у чому різниця і хто що пише

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

	Бриф	Технічне завдання
Хто заповнює	Клієнт, іноді разом із менеджером	Аналітик або проєктний менеджер разом із клієнтом
Мова	Мова бізнесу: цілі, клієнти, конкуренти	Мова вимог: сторінки, функції, правила, критерії
Обсяг	1–3 сторінки	Від 5 до 30+ сторінок залежно від проєкту
Для чого	Зрозуміти задачу і зорієнтуватися в бюджеті	Точно оцінити, виконати і прийняти роботу

Чи може клієнт написати ТЗ сам? Може, і це цілком нормально для невеликого сайту-візитки. Але ми радимо інший розподіл ролей: ви відповідаєте за бізнес-частину (цілі, аудиторія, процеси, контент), а технічну частину складає підрядник і погоджує з вами. Власник не мусить знати, що таке кешування чи hreflang. Зате тільки він знає, як насправді обробляються заявки і що відповідає менеджер на дзвінок.

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

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

Обсяг документа залежить від проєкту, але набір розділів у нас майже не змінюється. Для лендингу частина з них займе два рядки, для інтернет-магазину — кілька сторінок кожен.

1. Загальна інформація і цілі

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

2. Аудиторія і сценарії

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

3. Структура сайту

Перелік усіх сторінок і шаблонів із вкладеністю: головна, розділи, послуги, каталог, картки, блог, контакти, службові сторінки (політика конфіденційності, 404, подяка після заявки). Для кожної сторінки — її призначення одним реченням.

4. Опис сторінок і блоків

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

5. Функціонал

Форми і що відбувається після відправлення, пошук, фільтри, кошик, особистий кабінет, калькулятори, мультимовність. Кожну функцію описуємо через поведінку, а не через назву (про це нижче).

6. Контент

Хто готує тексти, фото, відео, переклади, у якому форматі і до якого терміну. Скільки товарів чи статей наповнює студія, а скільки — клієнт.

7. Дизайн

Наявний фірмовий стиль, логотип, кольори, шрифти. Сайти, які подобаються, з поясненням, що саме подобається. Скільки концепцій і раундів правок закладено. Фраза «зробіть красиво» не допомагає дизайнеру. Набагато корисніше: «подобається, що на цьому сайті багато повітря і великі фото робіт, але не подобаються темні кольори».

8. Технічні вимоги

CMS, хостинг, підтримувані браузери і пристрої, вимоги до швидкості, безпеки, резервного копіювання, доступів адміністратора.

9. SEO-вимоги та інтеграції

Перенесення старих URL, редиректи, мета-теги, мікророзмітка, аналітика. Зв’язки із зовнішніми системами: CRM, оплата, доставка, облік, розсилки, месенджери.

10. Етапи, терміни і приймання

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

Від структури до прототипу

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

Структуру сайту краще будувати не з власних уявлень про бізнес, а з того, як люди шукають ваші послуги. Якщо сайт має приводити клієнтів із пошуку, у ТЗ має бути карта сторінок, прив’язана до груп запитів. Як зібрати й згрупувати запити самостійно, ми розповідали в статті «Готуємо семантичне ядро самостійно». Одна група запитів — одна посадкова сторінка; якщо сторінки для групи немає, пошуку нічого показати.

Прототип — це чорно-біла схема сторінки: блоки, їхній порядок і приблизний зміст, без кольорів і картинок. На прототипі легко домовитися про головне. Чи потрібен калькулятор на першому екрані? Де стоїть форма? Скільки товарів у рядку на смартфоні? Правка прототипу займає хвилини, правка готового дизайну — дні.

Ще одна практична порада: прототипи ми робимо одразу і для десктопа, і для смартфона. Більшість відвідувачів сьогодні приходить із телефона, і пошукові системи оцінюють сайт насамперед за мобільною версією. Тому мобільна версія в ТЗ — це не рядок «сайт має бути адаптивним», а окремі схеми головних шаблонів. Детальніше про це — у матеріалі «Як досягти успіху в mobile-first index».

Як формулювати вимоги: погано і добре

Головне правило: кожну вимогу можна перевірити. Якщо двоє людей можуть по-різному відповісти на запитання «виконано чи ні», вимога сформульована погано. Слова «зручний», «сучасний», «швидкий», «стильний», «простий» самі по собі нічого не означають. Їх треба розкривати через конкретні дії, числа або приклади.

Розмито	Конкретно
Сайт має швидко завантажуватися	На мобільному LCP головних шаблонів до 2,5 с за даними PageSpeed Insights
Зручна форма заявки	Поля: ім’я, телефон, коментар (необов’язковий). Після відправлення — сторінка подяки, лист менеджеру і запис у CRM
Каталог із фільтрами	Фільтри за брендом, ціною, розміром і наявністю; кілька значень одночасно; лічильник товарів біля кожного значення
Адмінка має бути простою	Менеджер без програміста додає товар, змінює ціну, банер на головній і статтю в блозі
Сайт має бути оптимізований під SEO	Окремі title, description і H1 для кожної сторінки; редиректи зі старих URL за таблицею; XML-карта сайту; розмітка BreadcrumbList
Як у конкурента	Посилання на сторінку і перелік, що саме взяти: структуру блоку цін і калькулятор, але не анімації

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

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

Технічна частина: що зафіксувати, навіть якщо ви не технар

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

• CMS і власність коду. На чому зроблено сайт і чи зможете ви передати його іншому підряднику. Ми радимо поширені системи і повні доступи для клієнта: до хостингу, домену, адмінки, аналітики.
• Хостинг і домен. На кого оформлені. Домен, зареєстрований на підрядника, — одна з найнеприємніших історій, з якими до нас приходять.
• Швидкість. Цільові показники Core Web Vitals для головних шаблонів і умови перевірки. Як ми підходимо до цієї задачі, описано на сторінці оптимізації сайту.
• Безпека і бекапи. SSL, регулярні резервні копії з терміном зберігання, оновлення CMS і плагінів, захист форм від спаму.
• SEO при запуску. Якщо сайт уже існує і має позиції, у ТЗ обов’язково є таблиця відповідності старих і нових URL з 301-редиректами. Базові вимоги до тегів і структури ми розбирали у статті «Внутрішня SEO-оптимізація сайту».
• Аналітика. Які події відстежуються: відправлення форм, кліки на телефон і месенджери, покупки. Без цього після запуску ви не знатимете, чи працює сайт.

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

Етапи і приймання: як не застрягти у правках

Найбільше нервів у проєктах коштує не розробка, а погодження. Дизайн «висить» тиждень, бо директор у відпустці. Правки надходять від трьох людей і суперечать одна одній. Сайт майже готовий, але щодня з’являється ще одне «маленьке побажання». Усе це можна передбачити в ТЗ заздалегідь.

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

1. Структура і прототипи — погоджуємо перелік сторінок і схеми головних шаблонів.
2. Дизайн — головна і ключові внутрішні сторінки, потім решта шаблонів.
3. Верстка і програмування — робоча версія на тестовому домені.
4. Наповнення — тексти, фото, товари, переклади.
5. Тестування і запуск — перевірка за критеріями, перенесення на бойовий домен, редиректи, аналітика.

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

Критерії приймання формулюємо так само конкретно, як вимоги. Наприклад: усі сторінки зі структури відкриваються без помилок; форми надсилають заявки на вказану пошту і в CRM; сайт коректно відображається в останніх версіях Chrome, Safari, Firefox і Edge на смартфоні та комп’ютері; показники швидкості відповідають цільовим; налаштовано події аналітики. Якщо всі пункти виконано — етап прийнято, а нові ідеї переходять у наступну ітерацію.

Типові помилки в ТЗ

Ось що ми найчастіше бачимо в документах, з якими до нас приходять клієнти, і що потім стає причиною конфліктів.

1. ТЗ скопійоване з інтернету. Шаблон «для будь-якого сайту» містить десятки пунктів, які вам не потрібні, і не містить того, що важливо саме для вашого бізнесу.
2. Опис рішень замість задач. «Потрібен слайдер на головній» замість «потрібно показати три основні послуги на першому екрані». Задачу можна вирішити краще, ніж задумано, рішення — лише виконати.
3. Оцінні слова без розшифровки. «Красиво», «зручно», «швидко» — кожен розуміє по-своєму, і перевірити неможливо.
4. Забутий контент. Дизайн погоджено, верстка готова, а текстів і фото немає. Запуск відкладається на місяці. Про те, як готувати тексти заздалегідь, читайте в статті «Як готувати контент для сайту».
5. Немає процесу після заявки. Форма є, але не описано, куди йде заявка, хто її бачить і як швидко відповідає.
6. Ігнорування старого сайту. Новий сайт запускають з іншими адресами без редиректів, і органічний трафік, накопичений роками, зникає.
7. Немає критеріїв приймання. Наприкінці проєкту починається нескінченний цикл «ще трохи поправити».
8. ТЗ, яке ніхто не оновлює. Під час роботи рішення змінюються, а документ лишається старим. Через пів року ніхто не пам’ятає, що актуально.

Як це виглядає на практиці

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

У результаті ТЗ на дванадцять сторінок описує вісімнадцять шаблонів сторінок, форму прорахунку з передачею даних у CRM, сценарій для заявки у вихідні, перенесення відгуків зі старого сайту, таблицю редиректів і перелік подій для аналітики. Оцінка стає точною, а дизайнер з першого разу малює те, що потрібно. Додаткові побажання, що з’явилися під час роботи, ми оцінили окремо й перенесли в другий етап, не зриваючи дату запуску.

Короткий чекліст перед відправленням ТЗ

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

Часті запитання

Скільки часу займає підготовка ТЗ?

Для сайту-візитки — кілька днів, включно з однією-двома зустрічами. Для корпоративного сайту чи магазину — від одного до кількох тижнів. Цей час окуповується: переробки на етапі розробки зазвичай забирають значно більше.

Чи платна підготовка ТЗ?

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

Чи можна змінювати ТЗ під час роботи?

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

Що робити, якщо я взагалі не знаю, що мені потрібно?

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

Підсумок

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

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