Технічне завдання на сайт: приклад і шаблон для бізнесу
Технічне завдання на сайт описує, що потрібно створити, як це має працювати та за якими ознаками замовник прийматиме результат. Для сайту послуг у ньому варто зафіксувати сторінки, контент, форми, інтеграції, вимоги до мобільної версії, SEO та передачі доступів.
Документ не обов’язково має бути великим. Важливо, щоб два виконавці однаково зрозуміли його зміст і могли оцінити однаковий обсяг робіт. Формулювання «сучасний зручний сайт під ключ» для цього недостатньо.
Чим технічне завдання відрізняється від брифу
Бриф допомагає познайомитися з бізнесом: які послуги він надає, хто його клієнти, які є цілі та обмеження. ТЗ перетворює ці відповіді на конкретні вимоги до результату.
У брифі можна написати: «Хочемо отримувати заявки в Telegram». У ТЗ потрібно уточнити, які саме поля надходять у повідомленні, хто його отримує, як обробляються повторні надсилання і що бачить відвідувач у разі помилки.
Якщо ви ще не зібрали матеріали, почніть із підготовки до створення сайту. Далі разом із виконавцем переведіть побажання у вимоги, які можна перевірити.
Опишіть мету та основні сценарії
Вкажіть, що людина повинна робити на сайті: записатися на консультацію, надіслати запит на розрахунок чи замовити дзвінок. Якщо дій кілька, визначте головну для кожного типу сторінок.
Приклад для меблевої майстерні: відвідувач переглядає кухні, відкриває реалізований проєкт, знайомиться з матеріалами й залишає запит на попередній розрахунок. Такий сценарій підказує, які сторінки, зв’язки між ними та поля форми потрібні.
Не записуйте бажану кількість продажів як технічний критерій приймання. Вона залежить також від трафіку, ціни, попиту й роботи менеджера. Натомість працездатність форми або коректне передавання даних можна перевірити до запуску.
Зафіксуйте сторінки та типи контенту
Перерахуйте сторінки й поясніть, які з них мають окремий дизайн. Десять кейсів на одному шаблоні та десять унікальних сторінок можуть мати різну вартість розробки.
Окремо вкажіть, що бізнес редагуватиме самостійно. Якщо менеджер має додавати кейси, у системі керування потрібні поля для назви, опису, фото, категорії та інших узгоджених даних. Саме слово «адмінка» не пояснює, які можливості включені.
Для мовних версій зазначте мови, перелік сторінок, відповідального за переклад і поведінку перемикача. Якщо частину сторінок перекладатимете пізніше, це також треба врахувати в структурі.
Опишіть форми через очікувану поведінку
Для кожної форми потрібні поля, правила перевірки та сценарії успіху й помилки. Приклад вимоги: «Форма містить ім’я, телефон, тип меблів і необов’язковий коментар. Без телефону надіслати її неможливо. Після успішного приймання сервером користувач бачить підтвердження».
Додайте місце отримання звернення та склад повідомлення. Для CRM важливо вказати систему, відповідальний акаунт і доступний спосіб інтеграції. Якщо сторонній сервіс платний, витрати та власника підписки узгоджують окремо.
Продумайте резервний сценарій. Наприклад, якщо повідомлення в месенджер не доставилося, заявка має залишитися в узгодженому сховищі або система повинна повідомити відповідального про збій.
Зробіть вимоги до якості перевірюваними
Замість «ідеально на всіх пристроях» узгодьте перелік браузерів і типові розміри екранів для перевірки. Оцініть меню, читабельність, форми, галереї та відсутність горизонтального прокручування.
Для швидкості визначте сторінки, інструмент і умови перевірки. Одна оцінка в тесті залежить від середовища й сторонніх сервісів. Тому краще зафіксувати конкретні вимоги до оптимізації зображень, завантаження основного контенту та перевірки на мобільному з’єднанні.
SEO-вимоги також потребують розшифрування: редагування Title і description, зрозумілі адреси, sitemap, доступність важливих сторінок для пошуку. Якщо це оновлення чинного сайту, додайте окремий перелік старих URL і правила їхнього перенесення.
Шаблон ТЗ для сайту компанії послуг
Скопіюйте цей перелік у документ і заповніть його перед оцінкою проєкту:
- Бізнес і аудиторія. Послуги, регіон роботи, тип клієнта, його основні запитання.
- Мета сайту. Основна дія та додаткові сценарії відвідувача.
- Сторінки. Повний перелік, окремі шаблони й кількість матеріалів для старту.
- Контент. Хто готує тексти, фото, відео, переклади та коли їх передає.
- Керування. Що команда зможе змінювати самостійно після запуску.
- Форми. Поля, перевірки, стани, отримувачі та резервне збереження.
- Інтеграції. CRM, месенджери, аналітика, оплати або календар за потреби.
- Якість. Мобільні сценарії, браузери, швидкість, базова доступність і SEO.
- Приймання. Список перевірок та відповідальні за підтвердження результату.
- Передача. Домен, хостинг, акаунти, вихідні матеріали, інструкція й підтримка.
Це основа для розмови, а не універсальна специфікація для будь-якого продукту. Кабінет користувача, онлайн-оплата або бронювання ресурсів потребують докладнішого опису правил і винятків.
Як приймати готовий сайт за ТЗ
Перетворіть ключові вимоги на короткі перевірки. Наприклад: додати новий кейс без розробника, відправити форму з телефону, отримати всі поля у CRM, відкрити старе посилання після перенесення.
Поруч із кожною перевіркою зафіксуйте результат і відповідального. Спірні місця краще виявити до початку розробки. Якщо обсяг змінюється під час роботи, погоджуйте вплив на ціну й строки письмово, щоб усі працювали з актуальною версією завдання.
Для створення сайту під ключ не потрібно самостійно знати всі технічні деталі. Підготуйте цілі, сторінки та потрібні сценарії, а Vektor допоможе обговорити їхню реалізацію й оцінити обсяг робіт.
