Чому ТЗ визначає успіх проекту
90% конфліктів між клієнтом і розробником виникають через одне: кожен мав на увазі різне. Клієнт хотів "як у Apple", розробник зробив "як зрозумів". Без ТЗ розробка перетворюється на гру в зіпсований телефон де вимоги змінюються кожного тижня, бюджет розтікається а дедлайни зсуваються.
Хороше ТЗ — не бюрократія. Це інструмент спільного розуміння між усіма хто бере участь у проекті. Час на складання ТЗ = зекономлений час на переробку (зазвичай у співвідношенні 1:5).
Структура ТЗ: 8 обов'язкових розділів
1. Цілі та бізнес-завдання
Найважливіший розділ якого найчастіше немає. Розробник повинен розуміти навіщо сайт, а не тільки що там має бути.
Правильно: "Збільшити кількість звернень з сайту на 30% за 6 місяців через покращення UX форми контактів і SEO просування за ключовими запитами."
Неправильно: "Зробити гарний сучасний сайт."
Запитайте себе:
Яку проблему вирішує сайт для бізнесу?
Що вважатиметься успіхом через 6 місяців після запуску?
Чим новий сайт буде кращий за поточний або за конкурентів?
2. Цільова аудиторія
Опишіть хто ваш типовий відвідувач: вік, рід занять, проблема яку він вирішує на сайті, технічна грамотність, які пристрої використовує (mobile-first?), мова.
Ідеально — 2–3 персони (user personas). Приклад: "Олена, 34 роки, власниця кав'ярні, шукає постачальника кави оптом, заходить з iPhone, не розбирається в технологіях, цінує швидкість і чіткість."
3. Структура сайту та опис сторінок
Перелічіть усі сторінки сайту та опишіть кожну. Не тільки "Головна" і "Контакти" — всі. Для кожної сторінки:
Мета: що відвідувач повинен зробити або зрозуміти після перегляду
Контент: які блоки, секції, тексти, зображення мають бути
Дії (CTA): куди переходить відвідувач далі
Приклад структури для B2B сервісної компанії:
Головна → Послуги (сторінка-список) → Послуга X (картка) → Контакти
Блог → Стаття
Про нас → Команда → Вакансії
4. Функціональні вимоги
Перелічіть усі "рухомі частини" сайту. Типові функції для різних типів сайтів:
Корпоративний сайт: форма контактів, онлайн-чат, карта, фільтр по послугах, багатомовність
Інтернет-магазин: каталог з фільтрами, кошик, оплата (LiqPay/Monobank), особистий кабінет, трекінг замовлення, інтеграція з Новою Поштою
Landing page: форма з валідацією, таймер акції, A/B тест елементів, інтеграція з CRM
Портал: реєстрація/вхід, рівні доступу, особистий кабінет, сповіщення
Для кожної функції вказуйте: що вона робить (не як реалізується — це завдання розробника).
5. Дизайн: референси та обмеження
Не пишіть "зробіть красиво" або "щось сучасне". Натомість:
Референси: 3–5 сайтів що вам подобаються + коментар що саме (колірна схема, типографіка, структура, анімації)
Антиреференси: сайти які вам не подобаються + чому
Фірмовий стиль: чи є брендбук, логотип, корпоративні кольори і шрифти?
Обмеження: "без анімацій що відволікають", "не темна тема", "мінімалізм"
6. Технічні вимоги та платформа
CMS: WordPress, Tilda, Laravel, кастомна розробка — є вже обрана чи відкриті до пропозицій?
Хостинг: де буде розміщено, є вже домен?
Продуктивність: яка очікувана кількість відвідувачів? Пікові навантаження?
SEO: потрібна базова SEO-оптимізація? Микророзмітка? Багатомовність?
Безпека: SSL, захист адмінки, GDPR-вимоги?
Браузери та пристрої: підтримка IE11? (сподіваємось, ні) Мінімальна версія Safari iOS?
7. Інтеграції
Перелічіть всі зовнішні системи з якими повинен "розмовляти" сайт:
CRM (HubSpot, KeyCRM, Bitrix24) — передавати ліди з форм
Платіжні шлюзи (LiqPay, Monobank, Fondy)
Доставка (Нова Пошта API, Укрпошта)
Аналітика (Google Analytics 4, Google Tag Manager, Facebook Pixel)
Пошта (SendGrid, Mailchimp, Gmail SMTP)
Месенджери (Telegram bot, Viber, WhatsApp Business API)
1С або інша ERP для синхронізації товарів/залишків
Для кожної інтеграції: чи є вже акаунт? Чи є API-доступ? Хто надасть документацію?
8. Контент
Хто готує тексти — ви чи розробник? (якщо розробник — це окрема статья витрат)
Хто робить фотографії та ілюстрації?
Чи є відео-контент?
Скільки сторінок контенту потрібно до запуску?
Що НЕ потрібно включати у ТЗ
Технічні деталі реалізації — "зробіть на React з Redux і MongoDB" — якщо ви не технічний фахівець, довірте вибір стеку розробнику. ТЗ описує що, розробник вирішує як.
Дизайн макети — ТЗ передує дизайну, а не навпаки
Точні тексти для кожного блоку — достатньо вказати тип контенту
Копія конкурента — "Хочу як у Rozetka" без розуміння що саме — не вимога, а джерело непорозумінь
Agile vs Waterfall: який підхід до вимог обрати
Waterfall (каскадний)
Повне ТЗ → затвердження → розробка → тестування → запуск. Підходить для:
Проектів з чіткими вимогами що не зміняться
Фіксований бюджет і дедлайн
Державні тендери де ТЗ є юридичним документом
Мінус: якщо на середині розробки з'ясувалось що вимога була неправильною — переробка коштує дорого.
Agile (ітераційний)
Загальне бачення → розробка спринтами → показ клієнту → коригування → наступний спринт. Підходить для:
Продуктів де вимоги можуть змінюватись
Стартапів і MVP
Тривалих проектів (3+ місяці)
Для більшості комерційних сайтів — гібридний підхід: базове ТЗ на 10–15 сторінок + гнучкість у деталях у процесі розробки.
Типові помилки у ТЗ
"Зробіть гарно" — суб'єктивно. Що красиво для вас — може бути жахом для вашої аудиторії
Відсутність пріоритетів — якщо все "must have", то нічого не є пріоритетом. Поділіть на Must / Should / Could / Won't (MoSCoW)
ТЗ без прикладів — "кнопка повинна бути помітною" → додайте референс
Зміна вимог після початку розробки — нові вимоги після підписання = новий бюджет або скорочення інших функцій
ТЗ без власника — хто приймає остаточні рішення по суперечливих питаннях?
Як ми працюємо з ТЗ в IT Master
На практиці більшість клієнтів приходять до нас без ТЗ — і це нормально. Наш процес:
Discovery сесія (1–2 год) — ставимо питання, розуміємо бізнес і цілі
Прототип — wire-frame основних сторінок для узгодження структури
Технічне завдання — складаємо разом або допомагаємо доопрацювати ваше
Оцінка та договір — фіксований бюджет або T&M залежно від проекту
Хочете допомогу зі складанням ТЗ або оцінку вашого проекту? Заповніть форму — ми зв'яжемось протягом робочого дня.