Техническое задание на e-commerce-приложение: вопросы, которые влияют на бюджет
Собственник интернет-магазина получает от подрядчиков заметно расходящиеся оценки одного и того же приложения, и причина чаще всего в том, насколько подробно описаны требования. Техническое задание (ТЗ) переводит намерения бизнеса в объём работ, считаемый в часах. Разберём десять разделов документа и вопросы в каждом, от ответов на которые двигается бюджет.
Что описывает техническое задание на приложение интернет-магазина
Техническое задание описывает поведение системы: что видит пользователь на каждом экране, откуда приходят данные, что происходит при ошибке и по каким признакам работа считается выполненной. Бриф отвечает на вопросы «зачем» и «для кого», и по нему можно назвать только диапазон цены. По техническому заданию объём работ считают в часах и фиксируют стоимость в договоре.
В состав документа входят текст требований, макеты экранов и схема обмена данными с внешними системами. Как опорный каркас разделов подойдёт ГОСТ 19.201-78: для коммерческого проекта он не обязателен, но помогает не потерять нефункциональные требования и порядок приёмки.
Для приложения интернет-магазина документ удобно делить на десять разделов: роли и доступ, каталог, корзина и оформление, оплата, доставка, бонусы, интеграции, аналитика, нагрузка и защита данных, приёмка.
Какие требования двигают бюджет
Стоимость складывается из объёма работ и ставок команды. Ставки видно в коммерческом предложении, а объём работ формируется текстом требований. Объём двигают четыре оси.
- Однозначность формулировок. Требование, которое читается двумя способами, оценивают с запасом часов на неопределённость — либо по минимуму, с возвратом за доплатой в разработке.
- Число состояний, а не экранов. Один экран каталога — это список, пустой результат, ошибка сети, загрузка и товар без остатка. Каждое состояние проектируют, разрабатывают и проверяют отдельно.
- Количество и тип интеграций. У каждой внешней системы свой формат обмена, свои сценарии отказа и своя тестовая среда. Две интеграции и шесть — разные проекты при одинаковом наборе экранов.
- Нефункциональные требования. Пиковая нагрузка, время ответа каталога, версии операционных систем и правила работы с персональными данными влияют на архитектуру, а с ней — на срок и бюджет.
Как формулировка в ТЗ меняет объём работ
| Что в документе | Что происходит с объёмом работ | Что уточнить до оценки |
|---|---|---|
| Функция названа, поведение не описано | В оценку входит запас часов на неопределённость | Сценарий по шагам и поведение при ошибке |
| Каталог без указания объёма и атрибутов | Решения по хранению и поиску принимаются в разработке | Число позиций, варианты товара, список фильтров и их источник |
| Интеграция указана одной строкой | Согласование форматов уходит в календарный срок проекта | Владелец доступов, формат обмена, тестовая среда |
| Нагрузка и время ответа не заданы | Архитектуру выбирают под средний режим, и она не держит пик | Пиковые одновременные пользователи и даты пиков |
| Критерии приёмки отсутствуют в документе | Доработки по спорным требованиям идут за доплату | Проверяемый признак готовности по каждой функции |
Как выглядит однозначное требование
Проверяемое требование отвечает на пять вопросов: что делает пользователь, откуда берутся данные, что показывает приложение при ошибке, какие действуют ограничения и в каких единицах измеряется результат. Тест простой: напишите по формулировке проверку для тестировщика. Не получилось — требование описывает намерение.
Примеры формулировок: расплывчато и однозначно
| Расплывчато | Однозначно |
|---|---|
| Быстрый поиск по каталогу | Поиск работает по названию и артикулу, выдача появляется не дольше секунды на каталоге до 50 000 позиций; если совпадений нет, показываются десять популярных товаров категории |
| Удобная корзина | Доступны изменение количества, удаление позиции и ввод промокода; сумма пересчитывается без перезагрузки экрана; товар, которого не осталось на складе, помечается и не мешает оформить остальные |
| Интеграция с учётной системой | Остатки и цены приходят из учётной системы согласованным протоколом обмена раз в 15 минут, остаток повторно проверяется при оформлении заказа; когда сервис недоступен, показываются последние данные с отметкой времени |
| Бонусная программа | Один бонус равен одному рублю, списать можно до 30% суммы заказа; начисление проходит после получения заказа и не действует на товары раздела «Распродажа» |
Пороги, сроки и форматы в примерах — ориентиры, каждый бизнес задаёт их сам. Обратная крайность тоже стоит денег: документ пишут неделями, а слишком жёстко зафиксированные требования меняют по ходу проекта. Подробность нужна там, где ошибка дорогая: данные, оплата и интеграции.
Роли, каталог и корзина: ядро приложения
Роли и права доступа
Обычно в приложении живут четыре роли: гость, покупатель, сотрудник магазина и администратор контента. Для бюджета важна граница доступного гостю: просмотр каталога без авторизации — один объём работ, оформление заказа без регистрации — другой, со слиянием корзины гостя с аккаунтом после входа.
В документе фиксируют способ авторизации (телефон с кодом, почта с паролем, биометрия после первого входа), срок жизни сессии и то, какие действия сотрудника доступны из приложения.
Каталог и карточка товара
Каталог — раздел, где расхождение между ожиданием и данными обходится дорого. В ТЗ нужны число позиций и категорий, варианты товара (размер, цвет, комплектация), атрибуты для фильтров и сортировок, правила вывода цены со скидкой, число изображений в карточке и наличие по магазинам.
Рабочий критерий для спорных функций: фильтр или блок, который нечем наполнить из учётной системы, в первый релиз не ставят. Фильтр по составу ткани требует заполненного атрибута у каждой позиции — иначе он работает на части каталога.
Корзина и оформление заказа
Здесь описывают шаги оформления, ввод адреса с подсказками, выбор даты и интервала, промокоды. Отдельно идут сценарии расхождений: товар разобрали во время оформления, цена изменилась после добавления в корзину, оплата прошла, а позиции уже нет на складе. Их чаще других дописывают после релиза, и каждый раз это переделка готового кода.
Оплата, доставка и бонусы
Оплата
Список способов оплаты фиксируют на первый релиз: банковская карта, СБП, оплата при получении, счёт для юридических лиц, рассрочка. Каждый способ — отдельная работа и проверки, поэтому «все популярные способы» превращаются в открытый объём работ. Дополнительно описывают сценарий неуспешной оплаты, полный и частичный возврат, выдачу чеков по 54-ФЗ и ответственного за договор с платёжным сервисом.
Доставка
В разделе описывают способы (курьер, пункты выдачи, самовывоз, почта), источник тарифов и правила расчёта — по зонам, весу или сумме заказа. Нужны сценарии переноса даты, частичной выдачи и поведение приложения, когда адрес вне зоны доставки. Расчёт на стороне службы доставки — это интеграция со своим сроком согласования, а не строка в настройках.
Бонусы и программа лояльности
Для бюджета ключевой вопрос один: где живёт баланс. Собственная механика — это разработка правил начисления и списания. Внешняя система лояльности — интеграция с обработкой отказов и сценарием «сервис недоступен, а покупатель хочет списать бонусы». В документе фиксируют лимит списания, срок жизни бонусов, уровни и то, как бонусы сочетаются с промокодами.
Интеграции: раздел, который двигает срок и бюджет
Интеграции определяют календарный срок сильнее, чем число экранов: он зависит не только от разработки, но и от готовности внешних систем. У каждой системы своё согласование форматов, обработка отказов и проверки — поэтому раздел описывают подробнее остальных.
Учётная система и остатки
Учётная система (чаще всего 1С) остаётся источником правды по товарам, ценам и остаткам. В ТЗ указывают направление обмена, частоту обновления, объём справочников и поведение при расхождении остатков. Обязательный пункт — тестовая среда с реальными данными: проверка на десяти придуманных товарах не покажет проблем каталога.
CRM, маркетинг и уведомления
Сюда входят передача заказов и клиентских данных в CRM, сегменты для рассылок, push-уведомления и триггерные сообщения. Описывают список передаваемых полей, правило идентификации клиента между каналами и события, которые инициируют сообщение. Если согласия на обработку персональных данных собираются в приложении, место сбора тоже попадает в документ.
Маркетплейсы и службы доставки
Для магазина, который торгует и на маркетплейсах (Wildberries, Ozon, Яндекс Маркет), фиксируют, что считается единым остатком и как приложение ведёт себя при расхождении. По доставке нужны список служб (СДЭК, Boxberry, Почта России), способ получения тарифов и статусов и формат адресной базы пунктов выдачи.
Что фиксировать по каждой интеграции
- Система и версия. Конкретная конфигурация, а не название семейства продуктов.
- Владелец доступов. Кто выдаёт доступы и отвечает за изменения на своей стороне.
- Формат и направление обмена. Протокол, состав полей, частота, объём одной передачи.
- Поведение при сбое. Что видит пользователь, когда внешний сервис недоступен.
- Тестовая среда. Стенд с данными, близкими к боевым, и срок его готовности.
- Ответственный на стороне бизнеса. Человек, который решает спорные вопросы по форматам без дополнительных согласований.
Аналитика и события
Раздел аналитики описывает события и их параметры: просмотр карточки, добавление в корзину, начало оформления, успешная оплата, отказ на шаге оплаты. Каждое событие — работа разработчика и проверка данных, поэтому список фиксируют заранее, а не после запуска.
В документ попадают инструменты отчётности, владельцы доступов к ним и правило идентификации пользователя между приложением и сайтом. Персональные данные в параметры событий не передают. Для первого релиза обычно хватает событий воронки от просмотра карточки до успешной оплаты; расширенная схема планируется отдельной задачей.
Нагрузка, производительность и защита данных
Нефункциональные требования пропускают чаще других, а исправляют дорого: они влияют на архитектуру, и переделка после релиза означает переписывание кода.
- Пиковая нагрузка. Одновременные пользователи в пике и даты пиков: распродажа, рассылка, сезон. Пик, который в десять раз выше обычного, пишут в ТЗ до начала разработки.
- Время ответа. Допустимые задержки для каталога, поиска и оформления заказа в секундах, а не в словах «работает плавно».
- Устройства и версии. Поддерживаемые версии iOS и Android, слабая сеть, работа без интернета там, где она нужна.
- Персональные данные. Состав данных, место хранения, порядок получения согласия и сроки: требования 152-ФЗ учитывают в проектировании, а не в конце проекта.
- Доступ сотрудников. Кто из персонала видит заказы и контактные данные покупателей.
Приёмка: как закрывается спор «сделано или нет»
Для каждой функции первого релиза записывают проверяемый признак готовности и тестовый сценарий. Отдельно описывают порядок приёмки: срок проверки, форму замечаний и границу между дефектом (поведение расходится с ТЗ) и новым требованием (поведение в ТЗ не описано). Без этой границы любое уточнение становится предметом спора о деньгах.
В тот же раздел попадают требования к публикации. Правила App Review Guidelines у Apple и Developer Program Policies у Google задают обязательные условия: ссылка на политику конфиденциальности, заполненная декларация о собираемых данных, возрастной рейтинг и работа тестовой учётной записи для проверяющего. Их удобнее учесть в требованиях, чем получить отклонение на модерации. Гарантийный период фиксируют здесь же.
MVP и развитие: как разделить объём
Разделение идёт по двум правилам. В первый релиз входит сценарий, который приводит к заказу, и то, что нельзя добавить позже без переделки: структура данных каталога, авторизация, учёт остатков, события аналитики. В развитие уходит то, что повышает повторные покупки на уже собранной аудитории.
Разделы ТЗ: что входит в первый релиз, а что в развитие
| Раздел ТЗ | Первый релиз | Развитие |
|---|---|---|
| Роли и доступ | Гость и покупатель, один способ авторизации | Роли сотрудников, вход по биометрии |
| Каталог и карточка | Категории, варианты товара, базовые фильтры, поиск по названию и артикулу | Расширенные фильтры, рекомендации, отзывы с фотографиями |
| Корзина и оформление | Полный путь до оплаты, промокод, история заказов | Подписка на регулярную доставку, подарочная упаковка, списки желаний |
| Оплата | Карта и СБП, возврат по заявке | Рассрочка, счёт для юридических лиц, сохранённые карты |
| Доставка | Два способа с расчётом стоимости и статусами | Интервалы, перенос даты, частичная выдача |
| Бонусы | Баланс и списание по одному правилу | Уровни, персональные предложения, игровые механики |
| Интеграции | Учётная система, платёжный сервис, одна служба доставки | CRM и рассылки, маркетплейсы, системы рекомендаций |
| Аналитика | События воронки оформления заказа | Расширенная схема событий, свои отчёты |
| Нагрузка и данные | Пиковые значения, время ответа, согласия на обработку данных | Оптимизация под рост каталога и аудитории |
| Приёмка | Критерии готовности и тестовые сценарии по всем функциям релиза | Регламент проверок для очередных версий |
Вопросы к бизнесу до начала работы над ТЗ
Ответы на эти вопросы определяют содержание документа.
- Кто принимает решения по спорным требованиям? Один человек с правом финального слова ускоряет согласования.
- Сколько позиций в каталоге и какие атрибуты заполнены? Отсюда следуют поиск, фильтры и карточка товара.
- Какие способы оплаты обязательны в первом релизе? Список закрывает открытый объём работ.
- Какие способы доставки и откуда берутся тарифы? Расчёт на стороне службы — интеграция.
- Где живёт баланс бонусов? Своя механика и внешняя система лояльности — разные по стоимости сценарии.
- Какие внешние системы участвуют и кто выдаёт доступы? По каждой нужен ответственный сотрудник.
- Какая нагрузка в пике и когда она бывает? Пик влияет на архитектуру.
- Какие данные покупателей собираются и где хранятся? Это закладывают в проектирование.
- Что считается успешным запуском? Отсюда берутся критерии приёмки.
- Какие функции бизнес готов перенести в развитие? Ответ сильнее остальных влияет на бюджет первого релиза.
Итог: техническое задание на одной странице
Техническое задание отвечает на вопрос «как система ведёт себя в каждом сценарии» по десяти разделам документа. Бюджет двигают четыре вещи: однозначность формулировок, число состояний в интерфейсе, количество интеграций и нефункциональные требования. Детальный документ до старта — выгодный путь: он сокращает в оценке запас на неопределённость и переводит спор о доработках в сверку с критериями.
Что сделать дальше:
- Собрать письменные ответы на десять вопросов из чек-листа выше.
- Переписать спорные требования по шаблону из пяти вопросов: действие пользователя, источник данных, поведение при ошибке, ограничения, единицы измерения.
- Составить список внешних систем с владельцем доступов и сроком готовности тестовой среды.
- Описать критерии приёмки и границу между дефектом и новым требованием.
Частые вопросы
Что должно быть в техническом задании на мобильное приложение?
Десять смысловых разделов: роли и права доступа, каталог и карточка товара, корзина и оформление заказа, оплата, доставка, бонусы и программа лояльности, интеграции, аналитика, требования к нагрузке и безопасности, критерии приёмки. К документу прилагаются макеты экранов и схема обмена данными с внешними системами. Каждое требование формулируется так, чтобы по нему можно было написать проверку: с источником данных, поведением при ошибке и измеримым ограничением.
Кто должен составлять ТЗ — заказчик или разработчик?
Содержательные решения остаются за бизнесом: способы оплаты и доставки, механика бонусов, границы первого релиза, ответственные за доступы к учётной системе. Техническую часть — форматы обмена, структуру данных, требования к нагрузке и критерии приёмки — обычно описывает подрядчик или системный аналитик на стороне заказчика. Оптимальный порядок: бизнес отвечает на вопросы о сценариях и данных, аналитик превращает ответы в проверяемые требования, обе стороны согласуют документ до оценки бюджета.
Чем техническое задание отличается от брифа?
Бриф описывает цель, аудиторию и ожидания от продукта — он нужен на старте обсуждения и занимает несколько страниц. Техническое задание описывает поведение системы в каждом сценарии: что видит пользователь, откуда приходят данные, что происходит при ошибке, по каким признакам работа считается выполненной. По брифу можно назвать только диапазон цены, по техническому заданию — рассчитать объём работ в часах и зафиксировать стоимость в договоре.
От чего зависит стоимость разработки мобильного приложения?
Стоимость складывается из объёма работ и ставок команды, а объём считают по описанным требованиям. Расплывчатая формулировка оставляет подрядчику два варианта: заложить запас часов на неопределённость или оценить по минимуму и вернуться за доплатой, когда выяснятся подробности. Детализация сокращает запас: при описанных состояниях экранов, форматах обмена и критериях приёмки оценка становится расчётом, а не предположением о намерениях заказчика.
Нужно ли описывать в ТЗ интеграцию с 1С и CRM?
Да, и подробнее остальных разделов — интеграции чаще всего двигают сроки и бюджет. По каждой внешней системе фиксируют версию и владельца доступов, направление и частоту обмена, формат передачи данных, объём справочников, поведение приложения при недоступности сервиса и наличие тестовой среды с реальными данными. Отдельно указывают ответственного на стороне бизнеса: без него согласование форматов затягивается.
Что включить в MVP мобильного приложения интернет-магазина?
Сценарий, который приводит к заказу: поиск товара, карточка, корзина, оформление, оплата, статусы доставки и история заказов. Плюс то, что нельзя добавить позже без переделки: структуру данных каталога, авторизацию, учёт остатков, события аналитики. Программу лояльности с уровнями, подписки, рекомендации и раздел с контентом выносят в развитие — они повышают повторные покупки, когда в приложении уже есть аудитория.
