Як скласти ТЗ на сайт, якщо ви не програміст

ТЗ — це не документ на 40 сторінок

Для невеликого сайту достатньо двох-трьох зрозумілих сторінок ТЗ. Мета не в кількості термінів, а в усуненні різних трактувань. «Форма заявки» для когось — ім’я й телефон, а для когось ще файл, вибір послуги, згода та лист менеджеру.

Почніть із п’яти простих питань

1. Що має змінити сайт? Більше заявок, менше ручної роботи, продажі, записи чи довіра?
2. Хто ним користується? Новий клієнт, постійний, співробітник, адміністратор?
3. Що має зробити користувач? Запишіть шлях діями.
4. Що відбувається після дії? Куди потрапляє заявка і хто відповідає?
5. Як зрозуміти, що робота готова? Визначте перевірювані критерії.

Структура, яку можна просто скопіювати

Описуйте функції через поведінку

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

Як правильно використовувати референси

Посилання корисні, якщо ви пояснюєте, що саме подобається: типографіка, щільність каталогу, навігація чи взаємодія. Додайте 2–4 приклади з коротким коментарем.

Контент — частина ТЗ

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

Додайте критерії приймання

• Працює в актуальних мобільних і desktop-браузерах.
• Форми реально надсилають дані.
• На телефоні немає горизонтального скролу.
• Ключові сторінки мають title та description.
• Власник отримує доступи до домену, хостингу та сервісів.
• Повний сценарій перевірено на production-домені.

Не обирайте технології без причини

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

Позначте пріоритети

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

Що попросити наприкінці проєкту

• Вихідний код і доступ до репозиторію.
• Доступ до домену, DNS і хостингу.
• Список зовнішніх сервісів.
• Коротка інструкція для адміністратора.
• Опис процесу deploy.
• Відомі обмеження.

Запишіть це в ТЗ заздалегідь, щоб передача проєкту була частиною роботи.