Технічне завдання на розробку сайту — це документ, у якому зафіксовано цілі проєкту, структуру, функціональність, сценарії користувачів, інтеграції, технічні та бізнес-вимоги, критерії приймання і межі робіт. Воно має описувати не лише сторінки та дизайн, а й очікувану поведінку продукту.
Замовнику не обов’язково самостійно обирати мову програмування, архітектуру бази даних або спосіб реалізації API. Його завдання — зрозуміло сформулювати бізнес-задачу, потрібний результат, функції, обмеження та сценарії. Технічні рішення доцільно погоджувати з командою після аналізу вимог.
Що дає технічне завдання замовнику й команді
Хороше ТЗ створює спільне розуміння продукту до того, як дизайнери та розробники почнуть роботу. Замовник бачить, за що платить і що отримає, а команда може оцінити складність, виявити залежності та поставити змістовні запитання.
Документ допомагає:
- узгодити цілі, аудиторію та пріоритетні сценарії;
- визначити склад сторінок, функцій та інтеграцій;
- відокремити обов’язковий обсяг від майбутніх покращень;
- підготувати реалістичну оцінку робіт;
- контролювати зміни й уникати різного трактування домовленостей;
- перевірити результат за заздалегідь визначеними критеріями.
ТЗ не усуває всі невизначеності. Під час проєктування можуть з’явитися кращі рішення або нові обмеження. Тому важливо передбачити порядок уточнення та погодження змін.
Чим ТЗ відрізняється від брифу, кошторису та договору
Ці документи пов’язані, але не є взаємозамінними. Їхній точний склад залежить від формату співпраці, тому назва документа менш важлива, ніж його зміст і роль.
| Документ | Що фіксує | Для чого використовується |
|---|---|---|
| Бриф | Початкові відомості про бізнес, аудиторію, цілі, конкурентів і побажання | Допомагає зібрати контекст і розпочати discovery |
| Технічне завдання | Структуру, сценарії, функції, інтеграції, обмеження та критерії приймання | Стає робочою основою для проєктування, розробки й тестування |
| Website requirements document | Бізнес-, функціональні та нефункціональні вимоги до вебпродукту | Може бути ширшим за традиційне ТЗ і не обов’язково визначає спосіб реалізації |
| Кошторис і комерційна пропозиція | Оцінку, етапи, умови оплати, склад послуг і припущення | Пояснюють бюджетну та комерційну модель співпраці |
| Договір | Юридичні права, обов’язки, порядок оплати, передачі результатів і відповідальність сторін | Регулює відносини між замовником та виконавцем |
| Scope of work | Конкретний обсяг робіт, результати, етапи та виключення | Визначає, що входить і не входить у домовлену реалізацію |
ТЗ може бути додатком до договору, але саме по собі не замінює юридичні та комерційні умови.
Хто складає ТЗ і що підготувати до початку
Найкращий результат дає спільна робота. Представник бізнесу надає знання про клієнтів, процеси та обмеження. Аналітик, проєктний менеджер, дизайнер і технічні фахівці перетворюють ці дані на узгоджені вимоги. Якщо первинне ТЗ готує замовник, воно не повинно виглядати як специфікація для програміста — важливі повнота й однозначність.
Вхідні дані для обговорення
- опис компанії, продуктів і географії роботи;
- цілі сайту та бізнес-дії, які вважатимуться конверсіями;
- сегменти аудиторії, їхні потреби й типові заперечення;
- наявний брендбук, контент, домен, хостинг та системи обліку;
- приклади сайтів із поясненням, що саме подобається або не підходить;
- відповідальні за погодження, контент і приймання;
- обмеження щодо бюджету, запуску, технологій або внутрішніх процесів.
На оцінку впливають не тільки кількість сторінок, а й ролі, нестандартна логіка, інтеграції, міграція даних, дизайн, контент і вимоги до якості. Детальніше ці залежності пояснює матеріал про вартість розробки сайту.
Scope та out of scope
Окремо зафіксуйте, що входить у першу версію, а що свідомо відкладено. Наприклад, до scope можуть входити каталог і форма запиту, а онлайн-оплата, кабінет партнера та імпорт старої бази — до out of scope. Це не заборона на розвиток, а захист оцінки від прихованого розширення робіт.
Як скласти технічне завдання на сайт покроково
1. Сформулюйте бізнес-цілі та аудиторію
Замість фрази зробити гарний корпоративний сайт опишіть потрібну роль ресурсу: презентувати послуги, отримувати кваліфіковані заявки, публікувати експертний контент або скорочувати навантаження на менеджерів. Для кожної аудиторії визначте її задачу, сумніви та очікувану дію.
2. Побудуйте структуру і сценарії
Складіть sitemap: головна, категорії, сторінки послуг чи товарів, кейси, блог, контакти та службові сторінки. Після цього опишіть user flows — послідовності дій від точки входу до результату. Наприклад: реклама → сторінка послуги → перегляд кейсу → форма → підтвердження → заявка в CRM.
Для кожного сценарію врахуйте нормальний шлях, порожній результат, некоректне введення, технічну помилку та повернення користувача до попереднього кроку.
3. Опишіть функціональні вимоги
Кожна вимога має відповідати на запитання: хто виконує дію, за яких умов, що вводить або бачить, як реагує система та яким є успішний результат.
Для форми заявки визначте поля, обов’язковість, формат і валідацію; текст згоди, якщо він потрібен; реакцію кнопки; повідомлення про успіх або помилку; одержувачів; передачу в CRM; захист від спаму та аналітичні події. Формулювання форма має бути зручною не дозволяє ані реалізувати, ані перевірити логіку.
Для каталогу опишіть категорії, фільтри, сортування, пошук, пагінацію або інше завантаження, склад картки та поведінку за відсутності результатів. Для інтернет-магазину додайте кошик, оформлення, статуси замовлення, платежі, доставку, повернення і синхронізацію залишків — лише ті процеси, які справді потрібні бізнесу.
4. Визначте ролі, CMS та інтеграції
Фрази потрібен особистий кабінет недостатньо. Перелічіть ролі — наприклад, відвідувач, клієнт, контент-редактор і адміністратор — та дозволені дії кожної. Укажіть, хто може переглядати, створювати, редагувати, видаляти або експортувати дані.
Для CMS перелічіть сутності та поля, якими керує команда: сторінки, послуги, кейси, автори, меню, SEO-дані. Для CRM, платіжних сервісів, доставки та інших систем зафіксуйте напрям обміну, склад даних, момент передавання, обробку дублювань і помилок. Якщо використовується API, потрібно погодити доступи, документацію, обмеження та відповідальну сторону.
Нефункціональні вимоги та якість
Дизайн, адаптивність і контент
Опишіть фірмові матеріали, бажаний характер інтерфейсу, референси, компоненти та стани елементів. Визначте пріоритетні типи пристроїв і поведінку навігації, таблиць, форм та інтерактивних блоків на різних екранах. Зазначте, хто створює тексти, переклади, фото й відео, у якому форматі та коли вони мають бути передані.
Performance, security і середовища
Сайт має швидко працювати — неперевірна вимога. Критерії продуктивності потрібно погоджувати з урахуванням архітектури, реального контенту, пристроїв, мережі та умов вимірювання. Не варто фіксувати відірваний від цих умов бал PageSpeed або гарантувати однаковий результат для кожної сторінки.
Рівень безпеки залежить від даних, акаунтів, платежів, API та ризиків проєкту. Базово варто обговорити HTTPS, розмежування доступів, захист адміністративної частини і форм, оновлення залежностей, резервне копіювання, журналювання та порядок реагування на інциденти.
Уточніть наявність staging і production, відповідальних за домен, хостинг, доступи та розгортання. Окремо визначте тестування: браузери й пристрої, функціональні сценарії, перевірку інтеграцій, контенту та критичних помилок.
Критерії приймання
Критерій має бути спостережуваним. Наприклад: після валідного надсилання форми користувач бачить підтвердження, заявка створюється в CRM із визначеними полями, відповідальному надходить повідомлення, а в аналітику передається погоджена подія. Таку поведінку можна відтворити й прийняти.
SEO-вимоги до сайту ще до розробки
SEO варто закладати в архітектуру до програмування: зміна URL, шаблонів або мультимовної структури після запуску може створити додатковий обсяг робіт.
Що зафіксувати в ТЗ
- логічні clean URLs і правила їх формування;
- редагування SEO Title, Meta Description, H1 та структури підзаголовків;
- canonical, robots meta directives, robots.txt і XML sitemap;
- керування індексацією, перенаправленнями та сторінкою 404;
- хлібні крихти, внутрішню перелінковку та доречну Schema.org розмітку;
- alt для зображень, їх стиснення і сучасні формати;
- мовні версії та hreflang, якщо сайт мультимовний;
- можливість створювати нові SEO landing pages без перероблення системи;
- технічну якість і Core Web Vitals без необґрунтованих гарантій позицій чи балів.
Аналітика та бізнес-події
Укажіть, чи потрібні GA4 і Google Tag Manager, хто створює та перевіряє налаштування. Складіть перелік значущих подій: успішні форми, кліки по телефону або месенджеру, завантаження матеріалів, покупки чи інші дії. Набір подій залежить від бізнес-моделі; відстежувати кожен клік без практичної мети не потрібно.
Міні-приклад ТЗ для корпоративного сайту
Мета: презентувати послуги компанії та отримувати звернення потенційних клієнтів. Структура: головна, про компанію, список послуг, окремі сторінки послуг, кейси, блог, контакти, службові сторінки.
Функції: форми на сторінках послуг і контактів; валідація; повідомлення про результат; передавання звернення в CRM. CMS: редагування сторінок, послуг, кейсів, статей, меню, контактів та SEO-полів. Аналітика: підключення GA4 і GTM, погоджені події успішного надсилання форм та кліків по контактних елементах.
Якість: адаптивне відображення, перевірка підтримуваних браузерів, тестування форм, CRM, посилань і контенту. SEO: керовані метадані, URL, canonical, sitemap, robots, перенаправлення та 404. Деталі дизайну, інтеграції, середовища й критерії приймання оформлюються окремими підрозділами.
Типові помилки у вимогах
- Потрібен сучасний сайт. Уточніть аудиторію, візуальний характер, референси, компоненти й сценарії, які дизайн має підтримувати.
- Потрібна зручна адмінка. Перелічіть ролі, сутності, поля, масові операції, пошук, попередній перегляд і права доступу.
- Потрібна інтеграція з CRM. Назвіть систему, події передавання, поля, відповідність статусів, правила дублів і реакцію на недоступність API.
- Сайт має швидко працювати. Узгодьте сторінки, середовище, методику перевірки та реалістичні критерії.
- Зробіть як у конкурента. Поясніть, який сценарій або принцип потрібен, не копіюючи чужий дизайн чи функції без аналізу.
Практичне правило: якщо дві команди можуть реалізувати фразу зовсім по-різному й обидві формально матимуть рацію, вимогу потрібно уточнити.
Чекліст перед передачею ТЗ
- Цілі, аудиторії та конверсійні дії сформульовано.
- Є sitemap і ключові user flows.
- Функції описано разом зі станами, помилками та результатом.
- Ролі, CMS, форми, інтеграції й відповідальні сторони визначено.
- Зафіксовано вимоги до дизайну, контенту, SEO, аналітики, продуктивності та безпеки.
- Scope відокремлено від out of scope.
- Для критичних сценаріїв підготовлено критерії приймання.
- Визначено тестування, розгортання, гарантійні виправлення та подальшу підтримку.
Як керувати змінами після погодження
Нову вимогу варто оформлювати як change request: описати причину, очікуваний результат, вплив на дизайн, розробку, інтеграції, тестування, бюджет та план робіт. Після погодження оновлюють ТЗ або пов’язаний із ним журнал змін. Так команда відрізняє виправлення невідповідності від нової функції.
Сильне ТЗ не намагається передбачити кожен технічний рядок. Воно робить бізнес-очікування достатньо конкретними, щоб команда могла запропонувати рішення, оцінити його та продемонструвати відповідність результату.
