Технічне завдання на розробку сайту: як скласти ТЗ і нічого не пропустити

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

Без документа фраза «потрібен сучасний сайт із каталогом» для замовника може означати двадцять сторінок, фільтри, CRM і три мови, а для виконавця — п’ять шаблонів і форму контакту. Обидві сторони можуть діяти добросовісно, але очікувати різне.

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

Що таке ТЗ на сайт

Технічне завдання — це погоджений документ, який описує:

• цілі проєкту;

• користувачів і сценарії;

• межі робіт;

• структуру сайту;

• функціональні вимоги;

• дизайн і контент;

• інтеграції;

• SEO, аналітику, performance, accessibility і security;

• критерії приймання;

• порядок запуску й подальших змін.

ТЗ не обов’язково має бути одним великим файлом. Для гнучкого проєкту це може бути основний документ, sitemap, прототип, таблиця контенту, backlog і список acceptance criteria, пов’язані між собою.

Чим ТЗ відрізняється від брифу, кошторису та прототипу

Документ	На яке питання відповідає
Бриф	Хто бізнес, яка задача, аудиторія та контекст?
ТЗ	Що саме потрібно реалізувати й перевірити?
Sitemap	Які сторінки існують і як вони пов’язані?
User flow	Як користувач проходить ключовий сценарій?
Прототип	Як інформація й дії розташовані на екранах?
Кошторис	Скільки коштують погоджені роботи?
План	У якій послідовності й строки їх виконують?
Договір	Які юридичні права, обов’язки й умови сторін?

Бриф не замінює ТЗ, а ТЗ не замінює договір. Вони працюють разом.

Хто повинен складати технічне завдання

Що дає замовник

• цілі та показники бізнесу;

• опис продуктів і послуг;

• аудиторії;

• процес обробки заявки чи замовлення;

• обов’язкові юридичні умови;

• контент і бренд-матеріали;

• потрібні інтеграції;

• обмеження бюджету й запуску;

• відповідальних за погодження.

Що робить студія

• ставить уточнювальні питання;

• виявляє суперечності;

• проєктує sitemap і user flows;

• пропонує технічний підхід;

• деталізує функції та стани;

• визначає залежності;

• формує критерії приймання;

• оцінює обсяг і ризики.

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

Коли ТЗ можна зробити коротким

Стислий документ підходить, якщо:

• використовується перевірений шаблон;

• функціонал типовий;

• є готова дизайн-система;

• команда вже працювала разом;

• ризик змін невисокий;

• рішення можна швидко показати прототипом.

Детальніше ТЗ потрібне для ecommerce, кабінетів, оплат, ролей, міграцій, складних форм, інтеграцій, мультимовності та нестандартної логіки.

Структура ТЗ на розробку сайту

1. Контекст і мета проєкту

Почніть не з кольору кнопки, а з причини створення сайту.

Зафіксуйте:

• яку бізнес-проблему вирішує проєкт;

• хто користувач;

• яку дію має виконати;

• звідки приходитиме трафік;

• який результат очікується;

• які показники підтвердять успіх;

• які обмеження існують.

Приклад:

Створити корпоративний сайт для трьох напрямів послуг. Основні цілі: отримання кваліфікованих заявок із пошуку та реклами, демонстрація кейсів і автоматична передача звернень у CRM.

Якщо канал залучення ще не обраний, матеріал Google Ads чи SEO допоможе визначити, чи потрібні окремі SEO-сторінки, рекламні лендинги або обидва формати.

2. Аудиторії та ролі

Не обмежуйтеся фразою «чоловіки та жінки від 25 років». Для проєктування важливі задачі, знання й контекст.

Опишіть:

• сегмент;

• задачу;

• критерії вибору;

• заперечення;

• пристрій і контекст;

• доступні ролі;

• права кожної ролі.

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

3. Межі проєкту

Один із найважливіших розділів — що входить і не входить у роботу.

Наприклад:

Входить: UX, UI, адаптивні макети, верстка, CMS, імпорт до 100 товарів, форми, базове SEO, GA4, тестування, розміщення.

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

Цей блок захищає сторони від припущення, що «це очевидно включено».

4. Тип сайту та технологічні обмеження

Визначте формат: лендінг, корпоративний сайт, каталог, магазин, портал або вебсервіс.

Технологію не варто обирати лише за модою. Опишіть вимоги до редагування, масштабування, мов, інтеграцій, безпеки, продуктивності й володіння даними. Уже після цього порівнюйте WordPress і конструктори сайтів або розглядайте індивідуальну розробку.

Якщо платформа задана, вкажіть:

• версію або дозволений діапазон;

• політику плагінів;

• хостинг і середовище;

• репозиторій та деплой;

• staging;

• підтримувані браузери;

• правила оновлення.

5. Інформаційна архітектура

Додайте sitemap із усіма типами сторінок:

• головна;

• сторінки послуг;

• категорії;

• картки;

• кейси;

• блог;

• автори;

• пошук;

• контакти;

• юридичні сторінки;

• системні сторінки;

• сторінки помилок.

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

Якщо сайт має отримувати органічний трафік, структура повинна враховувати семантику до дизайну. Базову перевірку можна звірити з SEO-аудитом сайту своїми руками, але для складної міграції потрібна окрема карта URL.

6. User flows і функціональні сценарії

Опишіть не лише сторінки, а шлях:

1. користувач відкриває сторінку послуги;

2. обирає пакет;

3. відкриває форму;

4. вводить дані;

5. бачить валідацію;

6. підтверджує згоду;

7. надсилає форму;

8. отримує повідомлення;

9. дані потрапляють у CRM;

10. менеджер отримує сповіщення.

Для кожного сценарію додайте:

• передумови;

• основний шлях;

• альтернативи;

• помилки;

• порожні стани;

• права;

• результат.

Щоб не змішувати логіку та оформлення, корисно окремо розуміти різницю між UI та UX: ТЗ фіксує сценарій, прототип показує структуру, а UI-макети — вигляд компонентів і станів.

7. Функціональні вимоги

Кожну функцію описуйте через дію й результат.

Розмито	Перевірювано
Зручний каталог	Користувач фільтрує товари за категорією, ціною та наявністю; вибір зберігається в URL
Швидкий пошук	Пошук знаходить назву й артикул, показує підказки та сторінку без результатів
Зворотний зв’язок	Валідна форма створює лід у CRM, надсилає сповіщення й показує підтвердження
Зручна адмінка	Редактор без коду змінює ціни, тексти, FAQ, SEO-поля та порядок блоків
Безпечний кабінет	Користувач бачить лише власні дані, може відновити пароль і завершити сесію
Адаптивний сайт	Ключові сценарії проходять на погоджених ширинах без горизонтального скролу

Для інтернет-магазину окремо опишіть каталог, залишки, ціни, промокоди, кошик, checkout, оплату, доставку, статуси, повернення та листи. Корисні вимоги до checkout можна взяти з матеріалу про покинуті кошики й завершення замовлення.

8. Контент

Створіть таблицю:

Сторінка

Текст

Фото

Відео

Відповідальний

Дедлайн

Статус

Вкажіть:

• хто пише й редагує;

• хто перекладає;

• які формати файлів;

• максимальні розміри;

• правила назв;

• alt-тексти;

• що використовувати тимчасово;

• хто має права на матеріали;

• як імпортується наявний контент.

Не погоджуйте макети лише на lorem ipsum. Реальні заголовки, ціни, характеристики й юридичні тексти впливають на структуру.

9. UI/UX і адаптивність

Зафіксуйте результати дизайну:

• wireframes;

• клікабельний прототип;

• UI-концепція;

• ключові desktop і mobile екрани;

• компоненти;

• стани hover, focus, disabled, loading, success і error;

• правила сітки;

• типографіка;

• іконки й зображення;

• анімації;

• design QA після верстки.

Не перераховуйте конкретні моделі телефонів без причини. Узгодьте діапазони ширин, контрольні viewport і поведінку компонентів.

Для доступності визначте цільовий рівень WCAG, клавіатурну навігацію, видимий фокус, contrast, labels, error messages та альтернативи для нетекстового контенту.

10. SEO-вимоги

SEO потрібно закласти до верстки, а не додавати після запуску.

Мінімум:

• редаговані Title, Description і H1;

• зрозумілі URL;

• canonical;

• robots.txt;

• sitemap.xml;

• статуси відповіді;

• redirects;

• breadcrumbs;

• hreflang для мов;

• structured data;

• alt;

• pagination і filters;

• правила індексації;

• Open Graph;

• Search Console після запуску.

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

Для редизайну додайте export старих URL, карту redirects, збереження метаданих і перевірку після релізу.

11. Performance-вимоги

«Сайт має бути швидким» — не критерій.

Вкажіть:

• середовище тесту;

• тип сторінок;

• мобільний і desktop профілі;

• допустимі формати й вага зображень;

• lazy loading;

• кешування;

• CDN, якщо потрібен;

• budget JavaScript і CSS;

• цільові Core Web Vitals;

• спосіб вимірювання лабораторних і польових даних.

web.dev рекомендує оцінювати LCP, INP і CLS на 75-му перцентилі реальних завантажень. Для діагностики команда може використати каталог безкоштовних інструментів вебмайстра, але в ТЗ потрібно зафіксувати конкретний метод приймання.

12. Аналітика й маркетингові події

Фрази «встановити GA4» недостатньо. Додайте measurement plan:

Подія	Коли спрацьовує	Параметри	Платформа	Бізнес-значення
generate_lead	Успішна відправка	form_id, service	GA4, Ads	Заявка
click_phone	Клік по номеру	page, placement	GA4	Намір дзвінка
add_to_cart	Додавання товару	item_id, value	GA4	Крок ecommerce
purchase	Підтверджена оплата	transaction_id, value	GA4, Ads	Продаж

Опишіть GTM, consent, UTM, cross-domain, referral exclusions, тестовий трафік, CRM і відповідального за перевірку.

Після запуску зміни краще оцінювати не за враженням, а через аналітику й, коли є достатній трафік, A/B-тестування сайту.

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

Для кожної інтеграції вкажіть:

• систему;

• напрям передавання даних;

• поля й mapping;

• авторизацію;

• частоту;

• джерело істини;

• правила повторної спроби;

• дублікати;

• помилки;

• логування;

• тестове середовище;

• відповідального з обох сторін.

«Інтегрувати CRM» недостатньо. Потрібно визначити, що створюється, хто відповідальний, як оновлюється статус і що відбувається при недоступності API.

14. Security і privacy

Опишіть вимоги відповідно до ризику:

• HTTPS;

• ролі й мінімальні права;

• MFA для адміністратора, якщо доступно;

• password policy;

• rate limiting;

• validation;

• protection від spam;

• secure file uploads;

• оновлення залежностей;

• logs;

• backups;

• retention;

• incident contacts;

• privacy policy;

• consent;

• видалення й export даних.

Для складних застосунків OWASP ASVS можна використовувати як основу перевірюваних security-вимог, а не як формальну згадку.

15. Адміністративна панель

Опишіть, що команда редагує без розробника:

• сторінки;

• меню;

• ціни;

• товари;

• SEO-поля;

• redirects;

• форми;

• FAQ;

• банери;

• користувачів;

• ролі;

• переклади.

Додайте історію змін, preview, draft, scheduled publishing і правила видалення, якщо вони потрібні.

16. Мови й локалізація

Вкажіть:

• список мов;

• основну мову;

• структуру URL;

• перемикач;

• fallback;

• хто перекладає;

• локалізацію дат, валют і форматів;

• hreflang;

• переклад метаданих;

• поведінку неперекладеної сторінки.

Мультимовність — це не лише копія тексту, а окрема структура даних і SEO-сигналів.

17. Критерії приймання

Критерій має бути однозначним і перевірюваним.

Погано: «форма працює швидко».

Краще:

За валідних обов’язкових полів форма створює лід у CRM із URL і UTM, надсилає сповіщення менеджеру та показує користувачу підтвердження. За помилки CRM дані не губляться, а подія записується в log.

Для кожної вимоги визначте:

• умови;

• дію;

• очікуваний результат;

• пристрої;

• тестові дані;

• відповідального;

• доказ проходження.

18. Тестування

Зафіксуйте види перевірок:

• functional;

• cross-browser;

• responsive;

• accessibility;

• performance;

• SEO;

• security;

• analytics;

• content;

• integrations;

• regression;

• user acceptance testing.

Додайте список браузерів, пристроїв, середовищ, severity дефектів і правило, які помилки блокують запуск.

19. Запуск і передача

До definition of done включіть:

• production deploy;

• domain і SSL;

• DNS;

• analytics;

• Search Console;

• robots і sitemap;

• redirects;

• backups;

• доступи;

• ліцензії;

• репозиторій;

• документацію;

• навчання редактора;

• гарантійний період;

• support contacts.

Сайт не готовий лише тому, що сторінки відкриваються на staging.

20. Change request

Навіть хороше ТЗ змінюється. Важливо не забороняти зміни, а керувати ними.

Процес:

1. описати нову вимогу;

2. визначити причину;

3. оцінити вплив на бюджет, строки й архітектуру;

4. погодити пріоритет;

5. оновити документ і backlog;

6. реалізувати після підтвердження.

Без change request команда або робить додаткову роботу без оцінки, або сперечається, чи входила вона «за замовчуванням».

Мінімальне ТЗ для лендингу

• одна основна ціль;

• джерело трафіку;

• офер;

• структура блоків;

• форма й поля;

• повідомлення success/error;

• CRM;

• UTM і події;

• адаптивність;

• performance;

• SEO-метадані;

• юридичні тексти;

• критерії приймання.

Мінімальне ТЗ для корпоративного сайту

• sitemap;

• шаблони послуг;

• кейси;

• блог;

• пошук;

• форми;

• CMS;

• ролі;

• multilingual;

• SEO;

• analytics;

• integrations;

• redirects для редизайну;

• acceptance criteria.

Мінімальне ТЗ для інтернет-магазину

• каталог і categories;

• attributes і filters;

• пошук;

• картка товару;

• ціна й stock;

• cart;

• checkout;

• payment;

• delivery;

• promo;

• emails;

• statuses;

• returns;

• feed;

• CRM/ERP;

• ecommerce events;

• security;

• performance;

• acceptance criteria.

10 помилок у ТЗ

1. Описати рішення без бізнес-мети.

2. Використовувати слова «сучасний», «зручний», «швидкий» без критерію.

3. Забути error, empty, loading і success states.

4. Не зафіксувати mobile.

5. Не визначити відповідального за контент.

6. Додати SEO після дизайну.

7. Написати «інтегрувати CRM» без mapping.

8. Не розмежувати scope і future backlog.

9. Не визначити acceptance criteria.

10. Не передбачити порядок змін.

Чекліст перед передаванням ТЗ у розробку

• бізнес-ціль зрозуміла;

• scope і out of scope зафіксовані;

• sitemap погоджений;

• ключові flows описані;

• функції мають стани й помилки;

• контент має відповідальних;

• UI/UX-результати визначені;

• mobile та accessibility включені;

• SEO-вимоги задані;

• performance вимірюється;

• analytics має event map;

• integrations деталізовані;

• security відповідає ризику;

• acceptance criteria перевірювані;

• launch і handoff входять у definition of done;

• change request погоджений.

Висновок

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

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

BB STUDIO може провести брифінг, спроєктувати sitemap і flows, підготувати прототип, сформувати ТЗ та оцінити розробку без прихованого обсягу.

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

Чи повинен замовник сам написати ТЗ?

Ні. Замовник надає бізнес-контекст, процеси й обмеження, а студія допомагає перетворити їх на технічні та перевірювані вимоги.

Чи можна оцінити сайт без ТЗ?

Можна назвати діапазон за брифом. Точніша оцінка потребує sitemap, функцій, інтеграцій, дизайну й меж робіт.

Наскільки детальним має бути документ?

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

Чи можна змінювати ТЗ після старту?

Так, через change request: описати зміну, оцінити вплив і погодити бюджет, строки та пріоритет.

Чи потрібен прототип, якщо є ТЗ?

Для більшості сайтів так. Текст описує правила, а прототип швидше показує структуру й сценарій.

Чи входять SEO та аналітика в ТЗ?

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