Проект близок к завершению, но заказчик говорит: «Это не то, что я хотел». Ситуация знакома каждому разработчику. Причина — плохое техническое задание. Составление технического задания на разработку сайта — наша специализация. Мы, инженеры с десятилетним опытом, подготовили более 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 с историей изменений
- Финальное ревью с командой разработки
Мы гарантируем прозрачность каждого этапа. Закажите составление ТЗ — начнём с аудита. Получите консультацию по вашему проекту.