Цель, роли и сценарии
Проводим интервью с заказчиком и участниками процесса. Описываем, кто начинает действие, какие данные использует, кто продолжает работу и какой результат получает клиент. Фиксируем решения и открытые вопросы.
Реестр требований
13FOX / Проектирование до разработки
Разработка технического задания на мобильное приложение
Предложения разработчиков отличаются по составу и цене. Мы подготовим ТЗ, прототип и критерии приёмки, чтобы вы сравнивали сметы на одинаковый объём работ.
Мы разработали мобильный магазин Бакаев и связали приложение, админ-панель и 1С.
01
Объём первой версииФункции и исключения
02
Логика приложенияЭкраны, данные и API
03
Основа для договораПроверки и передача
Самостоятельный результат
Пакет, который можно
передать в разработку
Мы выясняем, какую рабочую задачу должно решать приложение. Разбираем ежедневную работу пользователей и сотрудников, затем связываем требования с экранами, данными и проверками.
Карта процесса
Реестр требований
Прототип с состояниями экранов
Показываем переходы, ввод данных, загрузку, пустой результат и ошибку. Закладываем требования к увеличению текста, контрасту и озвучиванию элементов. Уровень детализации и набор устройств согласуем до работы.
Описание состояний
Данные, API и управление
Определяем, где хранятся данные, кто может их менять и что видит сотрудник в админ-панели. Описываем методы обмена, поля, права, ошибки и повтор запроса. Непроверенные возможности внешнего API отмечаем как зависимости.
Контракты обмена
Критерии приёмки и версия пакета
Для требований задаём проверяемые результаты. Собираем спецификацию, ссылки на прототип и перечень допущений в одну версию. К ней прилагаем структуру работ, по которой подрядчики смогут разложить свои сметы.
Структура оценки
Авторский демонстрационный фрагмент
Один сценарий.
Согласованные детали.
Так мы связываем действие покупателя с интерфейсом, сервером и приёмкой. Это пример будущей спецификации, созданный для этой страницы; документ клиента здесь не используется.
- ВходКорзина и адрес
- СистемаПроверяет и создаёт заказ
- СотрудникВидит заказ в админке
- КлиентПолучает номер и статус
ТЗ / Мобильный магазинДемо · версия 1.0
S-01 → E-04 → API-01 → A-01
Оформление заказа
Допущения примера: покупатель вошёл в аккаунт, товары продаются поштучно, оплата при получении. Сервер магазина проверяет доступность; механизм учёта согласуется отдельно.
Экран E-04 / Концепт
Заказ принят
№ DEMO-001
Статус: принят
Покупатель видит состав заказа и адрес. Сотрудник получает заказ в рабочем списке админ-панели.
API-01 / Поведение сервера
POST /orders принимает позиции, количество, адрес и ключ операции. Сервер проверяет права, цену и доступность. При успехе возвращает идентификатор, статус, принятый состав и адрес заказа.
A-01 / Критерий приёмки
При доступных товарах создаётся один заказ. Его состав и адрес совпадают в ответе API, приложении и админ-панели. Клиент видит подтверждение только после ответа сервера.
Экран E-04 / Концепт
Проверяем заказ
Ответ ещё не получен
Не подтверждаем покупку
Сохраняем контекст операции. Показываем действие «Проверить статус» и предусмотренный способ связи с магазином.
API-01 / Поведение сервера
Приложение проверяет результат по ключу операции. Повтор с тем же ключом и составом возвращает существующий заказ, если он был создан. Другой состав с тем же ключом отклоняется.
A-02 / Критерий приёмки
В тесте сервер создал заказ, но ответ был потерян. После восстановления связи проверка возвращает тот же идентификатор. Повтор в пределах согласованного срока хранения ключа не создаёт второй заказ.
Экран E-04 / Концепт
Обновите корзину
Товар недоступен
Заказ ещё не создан
Выделяем недоступную позицию. Покупатель меняет состав и заново подтверждает итоговую сумму. Новое подтверждение отправляем с новым ключом операции.
API-01 / Поведение сервера
Сервер возвращает код ошибки и идентификаторы недоступных позиций. В этом сценарии заказ не создаётся. Правила резервирования и конкурентной покупки описываем отдельно.
A-03 / Критерий приёмки
В тесте товар заканчивается после открытия корзины. Приложение показывает причину и сохраняет остальные позиции. В админ-панели не появляется новый заказ до повторного подтверждения покупателем.
В полном ТЗ дополняем пример форматами полей, кодами ответов, сроком хранения ключа операции, матрицей прав и условиями проверки. Названия методов здесь демонстрационные.
Объём первой версии
Решаем, что запускать
и что отложить
Мы определяем MVP как минимальную рабочую версию для выбранной задачи. У каждой функции будет приоритет, у исключений будет причина. Этот список задаёт объём оценки.
Внутри выбранного сценария
Например, для первого запуска магазина: каталог, корзина, заказ, работа сотрудника и обязательный обмен с учётом. Ошибки, права доступа и проверки основного пути включаем в этот объём.
Платформы iOS и Android, поддерживаемые версии ОС, устройства и магазины распространения выбираем вместе с заказчиком.
За границей этой версии
В демонстрационном магазине можем отложить программу лояльности, рекомендации, несколько складов и отдельное приложение курьера. Возвраты и отмены требуют согласованных правил; их нельзя оставлять неопределёнными, если они нужны для запуска.
Финальный дизайн, разработка, лицензии сервисов, публикация и сопровождение оцениваются отдельно от подготовки ТЗ.
Зависимость от систем
Если приложение связано с 1С, CRM или оплатой, мы изучаем доступные методы и ограничения. Заказчик организует участие владельцев систем, документацию и тестовую среду. До проверки API его возможности остаются допущением в оценке.
Сначала выбираем способ решить задачу
| Подход | Когда подходит | Что мы проверяем до решения |
|---|---|---|
| Готовый продукт | Типовой каталог и заказ укладываются в функции платформы. | Лицензию, выгрузку данных, способы оплаты и доступный обмен с учётом. |
| Настройка и расширение | Основной путь есть, нужны свои поля или связь с системой. | Возможность доработки, границы API, обновления и передачу настроек. |
| Заказная разработка | Свои правила заказа, роли и интеграции требуют отдельной системы. | Границы мобильной и серверной частей, управление, нагрузку и поддержку. |
Наши реализованные продукты
Проектируем с опытом
связанных систем
В мобильном магазине важен весь путь заказа: от выбора товара до работы команды. Наш опыт помогает вовремя включить в ТЗ административные действия и обмен данными.
Бакаев / Мобильный магазин
Приложение, админ-панель и 1С
Мы разработали мобильный магазин, помогли перенести локальную 1С в облако и связали её с админ-панелью через API. Сервер синхронизации передаёт изменения между системами.
Сотрудник заменяет фотографию товара в админ-панели: она обновляется в 1С. Покупатель оформляет заказ: остаток уменьшается в админ-панели и 1С. Изменения из учётной системы возвращаются к витрине.
Для нового проекта мы отдельно описываем источник каждого поля, момент изменения остатка и поведение при сбое. Эти правила определяются по его системам и процессам.
Посмотреть кейс Бакаева
Frost Mining / Смежный опыт
В Frost Mining мы разработали магазин термопаст и термопрокладок с собственной админ-панелью, учётом остатков и связанными процессами CRM. Покупатель выбирает фасовку и доставку, сотрудник получает состав заказа. Такой опыт помогает уточнять требования к ассортименту и работе команды.
Открыть проектРабота с вашей командой
От первого разговора
до согласованной версии
Заказчик назначает человека, который принимает решения по продукту. Мы проводим разбор, готовим материалы и выносим спорные вопросы на согласование.
- 01
Разбираем задачу
Собираем цель, роли, примеры операций и текущие материалы. Согласуем результат исследования и состав пакета.
- 02
Проверяем границы
Выбираем сценарии первой версии, изучаем системы и данные. Фиксируем ограничения и вопросы владельцам API.
- 03
Связываем экраны и требования
Готовим прототип и спецификацию. Проходим основной путь и исключения с участниками процесса.
- 04
Передаём пакет
Устраняем противоречия, проверяем связи с критериями приёмки. Передаём согласованную версию и перечень зависимостей.
Приёмка результата проектирования
У требований есть
проверяемый результат
На этом этапе принимаем документы, прототип и согласованные проверки. Готовое приложение позже проверяется на сборке и тестовом стенде по этим критериям. Мы проверяем, что прототип и документ описывают один продукт. Для ключевого сценария есть входные условия, ожидаемый результат и исключения. Все нерешённые вопросы собраны отдельно с ответственными и влиянием на оценку.
Безопасность и данные
Матрица ролей, проверка доступа на сервере, состав персональных данных, хранение и удаление, требования к журналам. Меры и нужные проверки определяем по рискам проекта.
Производительность и доступность
Устройства, сеть, размер каталога и профиль нагрузки. Для скорости задаём согласованные измеримые пороги и способ проверки. Для интерфейса описываем работу с крупным текстом и экранным диктором.
Передача и использование
Редактируемый документ, экспорт для чтения, доступ к исходному прототипу и таблице требований. Форматы, условия передачи прав и использования с другими командами закрепляем в договоре.
Стоимость и срок
Оценка начинается
с объёма исследования
Мы показываем отдельные работы и допущения. Подготовка простого сценария по готовым материалам и исследование нескольких ролей с неизвестным API потребуют разного объёма.
Что влияет на предложение
- Количество ролей, основных сценариев и исключений.
- Наличие брифа, прототипа, действующего продукта и описания процессов.
- Число систем, состояние документации и необходимость проверки API.
- Глубина прототипа, требования к данным, доступности и нагрузке.
- Участники и порядок согласования материалов.
Для сравнения смет
Одна версия для всех команд
В пакет включаем структуру оценки: мобильное приложение, сервер, админ-панель, интеграции, тестирование и запуск. Подрядчики отмечают состав, исключения и допущения по каждой части.
Сопоставимость зависит и от ответов команд: в предложениях должны быть указаны включённые работы, исключения и порядок приёмки со стороны заказчика.
Как заказать ТЗ и сравнить предложенияДо договора
Ответы на вопросы
заказчика
Можно заказать только ТЗ, без разработки в 13FOX?
Да. Мы предлагаем исследование, прототип и техническое задание как отдельный этап. Состав, форматы передачи, возможность использовать материалы с другой командой и условия передачи прав фиксируем в договоре до начала работ.
Что делать, если у нас уже есть ТЗ?
Мы можем начать с проверки текущего документа: найти несогласованные сценарии, пропущенные состояния экранов и зависимости от систем. После разбора предложим объём доработки. Если документ достаточно подробный, можно переходить к оценке разработки.
Сколько стоит подготовка ТЗ и сколько она занимает?
Оценка зависит от числа ролей и сценариев, состояния исходных материалов, глубины прототипа и доступности документации систем. Мы отдельно показываем исследование, прототипирование и спецификацию, а также допущения по доступам и согласованиям. Стоимость и срок предлагаем после разбора задачи.
Будут ли в результате дизайн и работающая интеграция?
В согласованный пакет входит прототип экранов с состояниями и переходами. Финальный визуальный дизайн, программный код, настройка интеграций и публикация приложения относятся к отдельным работам. Если для проверки API нужен технический эксперимент, согласуем его состав заранее.
Как вносить изменения после согласования?
У требований и экранов сохраняем идентификаторы, у пакета документов указываем версию. Новое требование связываем с затронутыми сценариями и проверками. Перед новой оценкой все команды получают одну и ту же обновлённую версию.
Что требуется от нашей команды?
Нужен человек, который принимает решения по продукту, и сотрудники, знающие ежедневный процесс. Для интеграций понадобятся документация, обезличенные примеры и участие владельцев систем. Пароли и реальные клиентские данные в заявке не нужны.
Начнём с вашей задачи
Подготовим предложение
на исследование, прототип и ТЗ
Опишите задачу, пользователей и системы. Если уже есть наброски экранов или предложения подрядчиков, расскажите об этом. Мы определим состав работ и условия подготовки пакета.
Работаем удалённо с компаниями по России, в том числе в Москве и Санкт-Петербурге.