Складання технічного завдання на розробку сайту
Технічне завдання — документ, який фіксує що саме буде розроблено, у якому вигляді, та як це буде перевірятися. Погане ТЗ — джерело суперечок про те, хто правий. Хороше ТЗ — інструмент комунікації між замовником, розробниками та тестувальниками.
Основна помилка при написанні ТЗ: описувати інтерфейс замість поведінки. «Синя кнопка в правому куті» — не ТЗ. «При натисненні на кнопку "Оформити замовлення" система створює замовлення зі статусом draft, резервує товар на складі, відправляє email підтвердження та перенаправляє користувача на сторінку /orders/{id}» — ТЗ.
Структура технічного завдання
1. Призначення та цілі системи
Описує контекст: для кого створюється, яку бізнес-задачу вирішує, які критерії успіху (не «зручний сайт», а «конверсія в заявку не менше 3%», «час завантаження головної сторінки до 2 секунд»).
2. Користувацькі ролі та права
Ролі:
- Гість (неавтентифікований користувач)
- Покупець (зареєстрований користувач)
- Менеджер (працівник компанії)
- Адміністратор
Матриця доступу:
| Дія | Гість | Покупець | Менеджер | Адмін |
|---------------------|-------|----------|---------|-------|
| Переглянути каталог | ✓ | ✓ | ✓ | ✓ |
| Додати в кошик | ✓ | ✓ | — | — |
| Оформити замовлення | ✗ | ✓ | — | — |
| Керувати замовленнями | ✗ | свої | всі | всі |
| Керувати товарами | ✗ | ✗ | ✓ | ✓ |
| Керувати користувачами | ✗ | ✗ | ✗ | ✓ |
3. Функціональні вимоги
Кожна вимога у форматі: ідентифікатор, опис, передумови, результат, виключення.
FR-001: Реєстрація користувача
Передумови:
- Користувач не автентифікований
- Email не зареєстрований у системі
Основний сценарій:
1. Користувач вводить email, пароль, ім'я
2. Система валідує дані (формат email, пароль ≥ 8 символів)
3. Система створює облік зі статусом "не підтверджений"
4. Система відправляє лист з посиланням підтвердження (TTL 24 години)
5. Користувач отримує повідомлення "Перевірте email"
Виключення:
- Email вже використовується → помилка "Цей email вже зареєстрований"
- Невалідний email → помилка валідації
- Помилка відправки email → завдання ставиться в повторну чергу,
користувачу показується повідомлення "Лист прийде впродовж кількох хвилин"
Результат: запис у таблиці users, запис у черзі email
4. Нефункціональні вимоги
Продуктивність:
- Час відповіді API: 95-й перцентиль < 300ms при навантаженні 100 rps
- Сторінка каталогу: FCP < 1.5s, LCP < 2.5s (Core Web Vitals)
- Розмір початкового JS-бандла: < 150KB gzip
Надійність:
- Uptime: 99.5% (планові простої поза робочим часом)
- Час відновлення після збою: < 15 хвилин
- Резервна копія БД: щодня, зберігання 30 днів
Безпека:
- Аутентифікація: JWT з TTL 1 година + refresh token 30 днів
- Хеширування паролів: bcrypt, cost factor 12
- Rate limiting: 5 невдалих спроб входу → блокування на 15 хвилин
- HTTPS всюди, HSTS header
- SQL-ін'єкції: лише параметризовані запити, ORM
- XSS: Content Security Policy, санітизація користувацького вводу
5. Інтеграції
Зовнішні сервіси:
- Оплата: ЮKassa (API v3)
- Методи: банківська карта, СБП, ЮMoney
- Webhook: POST /api/payments/webhook (HMAC-SHA256 підпис)
- Доставка: СДЭК API v2
- Розрахунок вартості при оформленні замовлення
- Створення накладної при підтвердженні замовлення
- Трекинг через webhook або polling (кожні 4 години)
- Email: SendGrid (transactional)
- Підтвердження реєстрації
- Відновлення пароля
- Статуси замовлень
- Аналітика: Яндекс.Метрика + GA4
- Електронна торгівля (перегляд товару, додавання в кошик, купівля)
6. Схема даних
Не повна ERD-діаграма, але ключові сутності та їх відносини:
users (1) ─── (N) orders
orders (1) ─── (N) order_items
order_items (N) ─── (1) products
products (N) ─── (1) categories
products (1) ─── (N) product_images
users (1) ─── (1) carts
carts (1) ─── (N) cart_items
7. Середовища та розгортання
Середовища:
- development: локально (Docker Compose)
- staging: https://staging.example.com — для тестування перед релізом
- production: https://example.com
CI/CD:
- Гілка develop → автодеплой на staging
- Гілка main → деплой на production (ручне підтвердження)
- Прогон тестів обов'язковий перед деплоєм
Моніторинг:
- Uptime: UptimeRobot (перевірка кожну хвилину)
- Помилки: Sentry
- Метрики: Grafana + Prometheus
8. Критерії приймання
Чіткі умови, при яких робота вважається виконаною:
Модуль "Каталог":
☐ Список товарів з пагінацією (20 товарів на сторінці)
☐ Фільтрація по категорії, ціні, наявності
☐ Сортування по ціні, новизні, популярності
☐ Пошук працює (повнотекстовий, від 3 символів)
☐ Карточка товару: фото, опис, ціна, кнопка "В кошик"
☐ Breadcrumbs з мікромітками BreadcrumbList
☐ LCP карточки товару < 2.5s на мобільному (Lighthouse)
☐ Тест: додавання неіснуючого товару повертає 404
Формат документа
ТЗ живе в Git разом з кодом. Markdown + PlantUML для діаграм. Версіонується, проходить ревью через PR. Зміни вимог — через PR з обговоренням, не через Telegram.
Обсяг розумного ТЗ для сайту середної складності: 30–80 сторінок. Менше — недостатня деталізація. Більше — ТЗ заради ТЗ, яке ніхто не читає.
Сроки
Складання ТЗ для інтернет-магазину середнього розміру (50–100 екранів) — дві-три тижні з урахуванням ітерацій з замовником. Це включає: аналітичні інтерв'ю з stakeholders, прописування сценаріїв використання, узгодження нефункціональних вимог, ревью з технічною командою. Економія на ТЗ зазвичай обертається переробками, які коштують у 3–5 разів дорожче.