Проект близький до завершення, але замовник каже: «Це не те, що я хотів». Ситуація знайома кожному розробнику. Причина — погане технічне завдання. Складання технічного завдання на розробку сайту — наша спеціалізація. Ми, інженери з десятирічним досвідом, підготували понад 50 ТЗ для інтернет-магазинів, сервісів і порталів. Наш підхід: детальна аналітика, формалізація вимог і версіонування в Git. Хороше ТЗ — інструмент комунікації між замовником, розробниками та тестувальниками. Воно фіксує, що буде розроблено, як виглядає і як перевіряється. Без ТЗ проект перетворюється на хаос. Зв'яжіться з нами для аудиту вашого проекту — ми допоможемо перетворити хаотичні побажання на чітку документацію.
Що таке технічне завдання і навіщо воно потрібне?
Основна помилка в ТЗ — описувати інтерфейс замість поведінки. «Кнопка синього кольору в правому куті» — не ТЗ. А ось «При натисканні на кнопку "Оформити замовлення" система створює замовлення зі статусом draft, резервує товар, надсилає email підтвердження та перенаправляє на сторінку /orders/{id}» — це ТЗ.
Якісне технічне завдання економить бюджет. Воно виключає неоднозначність і знижує ризик переробок.
Як виглядає якісне ТЗ?
Хороше ТЗ містить:
- вимірювані критерії (LCP < 2,5 с, конверсія > 3%),
- однозначні формулювання — будь-який розробник зрозуміє однаково,
- опис поведінки, а не інтерфейсу,
- облік в Git з версіонуванням та обговоренням через Pull Request.
Погане ТЗ — набір скріншотів і фраз «зробіть красиво». Воно гарантує переробки, які обходяться в 3–5 разів дорожче.
Чому ТЗ краще зберігати в Git?
Markdown + Git дають переваги перед Word:
| Критерій | Word | Git (Markdown) |
|---|---|---|
| Версійність | Ручна (v1, v2) | Автоматична (коміти) |
| Спільна робота | Конфлікти при злитті | Merge без проблем |
| Обговорення | Коментарі в тексті | Pull Request з історією |
| Розмітка | Візуальна | Текстова, читана в будь-якому редакторі |
ТЗ в Git в 10 разів зручніше для керування версіями. Ми використовуємо саме такий підхід.
З чого складається ТЗ для інтернет-магазину?
Призначення та цілі системи — складання технічного завдання
Описує контекст: для кого створюється, яку бізнес-задачу вирішує, критерії успіху (конверсія не менше 3%, час завантаження до 2 секунд).
Користувацькі ролі та права
Приклад матриці доступу:
| Дія | Гість | Покупець | Менеджер | Адмін |
|---|---|---|---|---|
| Перегляд каталогу | ✓ | ✓ | ✓ | ✓ |
| Додавання до кошика | ✓ | ✓ | — | — |
| Оформлення замовлення | ✗ | ✓ | — | — |
| Управління замовленнями | ✗ | свої | всі | всі |
| Управління товарами | ✗ | ✗ | ✓ | ✓ |
| Управління користувачами | ✗ | ✗ | ✗ | ✓ |
Функціональні вимоги
Кожна вимога у форматі: ідентифікатор, опис, передумови, результат, винятки. FR-001: Реєстрація користувача
- Передумови: користувач не аутентифікований, email не зареєстрований.
- Сценарій: введення email, пароля, імені; валідація; створення облікового запису зі статусом «не підтверджено»; надсилання листа з посиланням (TTL 24 години).
- Винятки: email вже використовується → помилка; невалідний email → помилка; помилка надсилання → повторна черга.
- Результат: запис у таблиці users, запис у черзі email.
Нефункціональні вимоги
- Продуктивність: 95-й перцентиль API < 300 мс при 100 rps; FCP < 1,5 с, LCP < 2,5 с; JS-бандл < 150 КБ gzip.
- Надійність: uptime 99,5%, відновлення < 15 хвилин, резервне копіювання щоденно зі зберіганням 30 днів.
- Безпека: JWT (TTL 1 година + refresh 30 днів), bcrypt (cost 12), rate limiting, HTTPS, HSTS, параметризовані запити, CSP.
Інтеграції
- Оплата: ЮKassa (API v3: карта, СБП, ЮMoney), webhook з HMAC-SHA256.
- Доставка: СДЕК (розрахунок, створення накладної, трекінг).
- Email: SendGrid (транзакційні листи: підтвердження, відновлення, статуси).
- Аналітика: Яндекс.Метрика + GA4 з електронною торгівлею.
Схема даних
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 Середовища та деплой
- development: Docker Compose локально
- staging: https://staging.example.com — тестування перед релізом
- production: https://example.com
- CI/CD: develop → автодеплой на staging, main → ручний деплой на production з обов'язковим прогоном тестів
- Моніторинг: UptimeRobot (щохвилини), Sentry (помилки), Grafana + Prometheus (метрики)
Приймальні критерії
- Пагінація (20 товарів на сторінку)
- Фільтрація за категорією, ціною, наявністю
- Сортування за ціною, новизною, популярністю
- Повнотекстовий пошук від 3 символів
- Картка товару: фото, опис, ціна, кнопка «В кошик»
- Breadcrumbs з мікророзміткою BreadcrumbList
- LCP < 2,5 с на мобільному (Lighthouse)
- Додавання неіснуючого товару повертає 404
Скільки часу займає підготовка ТЗ?
Для інтернет-магазину середнього розміру (50–100 екранів) складання ТЗ займає 2–3 тижні. Включає аналітичні інтерв'ю, прописування сценаріїв, узгодження нефункціональних вимог і рев'ю з технічною командою. Вартість розраховується індивідуально — залежить від складності та кількості інтеграцій.
Типові помилки при складанні ТЗ
- Описувати інтерфейс, а не поведінку
- Пропускати нефункціональні вимоги
- Використовувати загальні фрази без цифр
- Не фіксувати винятки та граничні випадки
- Зберігати ТЗ в Word без версіонування
Що входить у роботу
- Повний аудит поточного стану (якщо є прототип або попередня документація)
- Інтерв'ю з ключовими співробітниками замовника (до 5 осіб)
- Формування функціональних і нефункціональних вимог
- Опис інтеграцій і схеми даних
- Створення матриці ролей і прав
- Узгодження та фіксація приймальних критеріїв
- Версіонування в Git з історією змін
- Фінальне рев'ю з командою розробки
Ми гарантуємо прозорість кожного етапу. Замовте складання ТЗ — почнемо з аудиту. Отримайте консультацію щодо вашого проекту.