Закажите комплект, который можно передать другой команде
Если вы хотите заказать ТЗ на мобильное приложение до разработки, начните с перечня результатов. Мы предлагаем согласовать спецификацию с границами версии, редактируемый прототип, описание данных и интеграций, критерии будущей приёмки и правила передачи материалов. Затем отдельно определить, как вы примете сам этап проектирования.
Такой заказ полезен, когда идея уже понятна, но команды по-разному видят объём. После него вы сможете отправить всем участникам один комплект и запросить оценки по одинаковым пунктам. Цены могут различаться: у команд разные ставки, решения и допущения. Зато будет видно, что именно каждая из них предлагает сделать.
Если комплект уже подготовлен, сверьте его с проверкой приёмки ТЗ, затем используйте матрицу сравнения смет.
Иллюстрация сценария
Документ, экраны и проверки в одном комплекте
Если у вас пока только идея, начните с короткого брифа перед разработкой. Он поможет сформулировать задачу. Для заказа отдельного ТЗ следующий шаг: согласовать глубину проработки и результат, за который вы будете платить.
На примере Бакаева: что скрывается за экраном каталога
В Бакаеве мы связали мобильный магазин, админ-панель и 1С. Помогли перенести локальную 1С в облако и настроили обмен через API, интерфейс, по которому системы передают данные. Сотрудник меняет фотографию товара в админке, сервер синхронизации передаёт изменение в 1С. Покупатель оформляет заказ с телефона, и изменение остатка отражается в админ-панели и учётной системе. Изменения из 1С проходят обратный путь к витрине.
Для ТЗ на похожий продукт это несколько связанных требований. Нужно описать, кто меняет товар, какая система задаёт данные, что получает покупатель и как сотрудник проверяет результат. Отдельно согласовать поведение при недоступном обмене. Иначе две команды могут оценить одинаковое слово «каталог», заложив разную серверную работу.
Реальный проект 13FOX
Каталог в приложении связан с управлением товарами
В админ-панели команда магазина ведёт товары, изображения и акции. Обмен карточками товаров, изображениями и остатками связывает админ-панель с 1С и мобильной витриной.
Что включить в заказ на подготовку ТЗ
В предложении подрядчика должны быть названы материалы и глубина каждого из них. «Аналитика и ТЗ» оставляет слишком много вариантов: от списка функций до проработанного комплекта с экранами и правилами обмена. Мы предлагаем закрепить состав результата по этой таблице.
| Материал | Что должно быть внутри | Как проверить |
|---|---|---|
| Цель и границы версии | Пользователи, роли, основные сценарии, первая рабочая версия (MVP), включения и исключения. | Можно назвать, какие действия входят в первую версию приложения и какие пожелания остаются на потом. |
| Спецификация | Требования с номерами, правила, входные условия, успешный результат, ошибки и зависимости. | По номеру требования находится конкретное действие и ожидаемый результат. |
| Редактируемый прототип | Основные экраны и переходы, состояния ожидания, пустого результата и ошибки. | Можно пройти ключевой путь; понятно, где схема, а где уже согласован визуальный дизайн. |
| Системы и данные | Приложение, сервер, админка, внешние системы; поля, источники, направления обмена и права ролей. | Для каждого обмена понятны отправитель, получатель и результат отказа. |
| Критерии будущей приёмки | Сценарии проверки функций, доступа, доступности интерфейса и производительности. | Проверки называют входные данные, условия и наблюдаемый итог. |
| Передаваемый комплект | Исходные файлы, экспорт, версия, журнал решений, открытые вопросы и условия использования. | Заказчик может открыть и редактировать материалы и передать их выбранной команде на согласованных условиях. |
Границы первой версии лучше записать через действия. Например, в неё входит оформление заказа покупателем и обработка оператором; подключение второго склада и программа лояльности отложены. При этом проверка остатка и понятное состояние ошибки нужны для обещанного заказа уже сейчас. Такой список помогает сохранить законченный основной путь.
Прототип показывает логику интерфейса. Если вам нужен финальный дизайн с цветами, шрифтами и всеми компонентами, включите его в заказ отдельно. Точно так же договоритесь, будут ли описаны только внешние зависимости или ещё и проверена техническая возможность подключения к существующей системе.
Открытый вопрос должен иметь продолжение. Например: «Доступен ли нужный метод CRM? Это влияет на передачу заказа; проверить на тестовом доступе; решение согласуют владелец системы и аналитик». Так неизвестное получает ответственного и способ проверки. Критичную для оценки интеграцию иногда нужно исследовать отдельным техническим экспериментом.
Авторский образец: от сценария до приёмки
Вот наш демонстрационный фрагмент ТЗ для заказа из мобильного магазина. Это авторский образец для объяснения состава документа. Его условия нужно адаптировать к вашему продукту.
Мы даём каждому пункту номер: например, S-01 для сценария и A-01 для проверки. Номер позволяет сослаться на один и тот же результат в прототипе, смете и приёмке. Подход с уникальными требованиями и матрицей их проверки описан в инженерном справочнике NASA; здесь мы применяем его к понятному покупательскому сценарию.
| Пункт | Авторский фрагмент |
|---|---|
| S-01 · Сценарий | Авторизованный покупатель отправляет заказ из корзины. Адрес заполнен; состав заказа проверяется сервером по согласованным правилам доступности товара. |
| UI-01 · Экран | Корзина показывает состав и сумму. Во время отправки видно ожидание. После подтверждения покупатель видит номер и статус заказа; при ошибке получает понятное действие для продолжения. |
| API-01 · Обмен | Приложение передаёт серверу состав корзины, количества, адрес и идентификатор операции. Сервер возвращает подтверждение с номером заказа либо определённый ответ об ошибке. Где проверяются остатки и как меняются данные учёта, описывается отдельными требованиями. |
| A-01 · Обычная проверка | На согласованном наборе товаров оформить заказ. Проверить: у покупателя и оператора отображается один заказ с одинаковым составом и согласованным статусом. |
| A-02 · Пропавший ответ | Задать тестовый сбой: сервер сохранил заказ, приложение не получило ответ. Повторить отправку с тем же идентификатором операции. Ожидаемый результат: второй заказ не создаётся, покупатель может получить результат первой операции. |
| Граница и вопрос | Оплата и доставка описываются отдельными сценариями. До оценки нужно решить, где определяется доступное количество и что происходит, если последнюю единицу одновременно заказывают два покупателя. |
В этом фрагменте проверка повтора относится к конкретному заданному сбою. Для других отказов, например потери связи с учётной системой, нужны свои условия и ожидаемые результаты. Мы предложим согласовать эти сценарии, когда разберём архитектуру проекта.
Для HTTP API можно передать описание в формате OpenAPI: операции, поля запроса, ответы и правила авторизации в машиночитаемом файле. Это полезно, когда интерфейс уже спроектирован. Если внешний API ещё неизвестен, в результате этапа должны остаться проверенные ограничения и план уточнения; придумывать адреса методов ради полного документа бессмысленно.
Как записать качество так, чтобы его можно было проверить
Фраза «приложение работает быстро» оставляет разную трактовку. В ТЗ стоит указать действие, устройство и версию ОС, объём данных, сеть, способ измерения и допустимое значение. Например, проверять открытие каталога на согласованном телефоне и наборе товаров. Числовую границу мы предложим после разбора условий, а разработчики проверят её на выпускной сборке в повторяемых условиях. Условия таких замеров описаны в документации Android.
Для доступности интерфейса опишите основной путь с увеличенным текстом и экранным диктором: VoiceOver на iOS или TalkBack на Android. Пользователь должен понимать элементы управления и завершать задачу. Проверка готовой сборки нужна отдельно от просмотра прототипа: это отражают рекомендации Apple и Android.
В требованиях безопасности перечислите роли и разрешённые операции. Например, покупатель получает доступ к своим заказам, оператор получает доступ к заказам в своей зоне ответственности; сервер проверяет права при запросе данных. Для мобильного клиента можно выбрать нужные требования из OWASP MASVS. Для API и админки согласуйте отдельную область проверки.
Как принять само ТЗ до начала разработки
На этом этапе вы принимаете комплект проектирования. Работоспособность будущего приложения проверят после разработки. Сейчас убедитесь, что материалы согласованы между собой, существенные неизвестные названы и команда может оценить обещанный объём.
Мы предлагаем пройти вместе с автором один основной и один проблемный сценарий. Пусть он откроет требование, соответствующий экран, правила обмена и проверку. Если в тексте есть отмена заказа, а на прототипе и в критериях она потерялась, комплект нужно доработать.
Порядок согласования тоже входит в заказ: кто от бизнеса принимает решения, когда передаёт замечания, сколько раундов входит в этап и как оформляются новые пожелания. Исправление противоречия в согласованном сценарии и добавление новой роли требуют разных работ; договоритесь, как их различать.
Для проверки достаточности полезно попросить другую команду оценить один выбранный сценарий по комплекту. Если ей приходится заново выяснять правила заказа или источник цены, эти вопросы стоит вернуть автору ТЗ. Оценка сторонней команды помогает обнаружить пробелы, но не заменяет вашу приёмку материалов.
Как сравнить сметы по одной версии ТЗ
После приёмки зафиксируйте версию комплекта. Всем участникам передайте одинаковые файлы и ответы на вопросы. Если существенное уточнение изменило объём, включите его в новую версию и разошлите всем командам: иначе предложения снова начнут оценивать разные задачи.
Попросите заполнить таблицу оценки по вашим блокам: приложение, сервер, админка, интеграции, тестирование, выпуск и передача. Для каждого блока нужна связь с требованиями. Вот короткая матрица запроса, которую можно использовать при переписке с командами.
| Строка сравнения | Что запросить у каждого подрядчика |
|---|---|
| Основа оценки | Номер версии ТЗ, список оцениваемых требований и используемый прототип. |
| Работы и цена | Состав каждого блока, цена или диапазон, причина диапазона; какие работы включены в итог. |
| Исключения | Какие требования и сопутствующие работы отсутствуют; отдельные варианты их оценки. |
| Зависимости | Что нужно от заказчика и внешних систем, какие допущения влияют на срок и цену. |
| Сторонние расходы | Лицензии, сервисы, серверы и аккаунты: кто оплачивает, что разовое, что регулярное. |
| Приёмка и изменения | Как подтверждается готовность, что передаётся, как оценивается изменение объёма и что входит в поддержку. |
Допустим, одна команда включила новый сервер, а другая предполагает готовый API вашего бизнеса. Сравнить итоговые суммы можно после уточнения этой зависимости. Попросите обе команды объяснить решение и показать, какие пункты они закрывают. Заполнять разницу произвольной «поправкой» в своей таблице рискованно.
ТЗ делает состав предложений прозрачнее, но сохраняет место для разных технических решений. Разумно разрешить альтернативу отдельной строкой: что меняется, какие требования сохраняются, какие ограничения появляются. Так вы сможете обсуждать цену вместе с условиями результата. Факторы общего бюджета разобраны в статье о стоимости мобильного приложения.
От чего зависят цена и срок подготовки ТЗ
Для предложения мы сначала оценим объём исследования. У приложения с одной ролью, готовыми правилами и известным API он меньше, чем у продукта с несколькими кабинетами, недокументированной 1С и согласованием между отделами. Время интервью, анализа систем и уточнения противоречий тоже входит в работу.
На цену влияют число сценариев и состояний, глубина прототипа, описание интеграций, необходимость технической проверки и состав передаваемых материалов. Срок зависит ещё и от доступности людей, которые знают процесс и вправе принять решение. Если несколько руководителей меняют одни правила независимо, понадобится дополнительное согласование.
Попросите разделить предложение на исследование, прототипирование и спецификацию, назвать результаты каждого этапа и правила пересмотра оценки. Тогда будет понятно, какая часть объёма уже определена и что может измениться после проверки неизвестной интеграции. Предложение с фиксированной ценой имеет смысл только вместе с зафиксированным составом и условиями.
Что согласовать о файлах и правах использования
В перечне передачи назовите формат спецификации, редактируемые исходники прототипа, схемы и экспорт для чтения. Проверьте, что заказчик получает копии в своём хранилище и может открыть их без личного аккаунта исполнителя. Для облачного инструмента отдельно согласуйте доступ, владельца проекта и необходимые условия редактирования.
В договоре стоит прямо согласовать использование материалов для оценки, разработки и доработки другой командой, а также передачу ей нужных копий. Уточните права на включённые сторонние материалы и ограничения их лицензий. Порядок, момент и объём передачи прав нужно зафиксировать с учётом конкретного договора.
В самостоятельном заказе ТЗ также полезно заранее решить, сможете ли вы выбрать разработчика независимо от автора документа и входит ли пояснение материалов новой команде в оплаченный этап. Если исполнитель обещает зачесть цену проектирования при продолжении разработки, попросите записать условия такого зачёта рядом с составом этапа.
Частые вопросы о заказе ТЗ
Можно заказать ТЗ у одной команды, а разработку у другой?
Да, такой формат можно согласовать. До заказа определите передаваемые исходники, условия использования и доработки, доступ к прототипу и порядок ответов новой команде. Для оценки всем исполнителям нужен одинаковый комплект.
Нужен ли готовый документ на входе?
Для обсуждения достаточно описать задачу, пользователей и используемые системы, приложить наброски или текущие предложения. Мы предложим состав исследования и проектирования. Если правила ещё неизвестны, их выяснение нужно включить в этап.
Гарантирует ли подробное ТЗ фиксированную смету?
Документ помогает определить объём и сравнить условия. Оценка зависит также от выбранных решений, доступности интеграций и допущений подрядчика. Неизвестные и порядок изменения состава нужно сохранять в предложении.
С чем прийти в 13FOX
Пришлите задачу, описание пользователей, список систем и имеющиеся материалы: наброски экранов, правила процесса, текущие предложения. Мы разберём, что уже определено, что нужно исследовать и какая глубина прототипа и ТЗ поможет выбрать разработчика.
Для компаний из Москвы, Санкт-Петербурга и других городов тот же комплект можно согласовывать удалённо: заранее назначить участников, фиксировать решения и передавать замечания к общей версии. География сама по себе не задаёт состав ТЗ.
Отдельную услугу и состав обсуждения смотрите на странице подготовки технического задания на приложение. Если вам нужен весь маршрут от идеи до выпуска, его объясняем в статье о процессе разработки.
Обсудим заказ ТЗ
Опишите задачу, пользователей и системы. Мы подготовим предложение на исследование, прототип и ТЗ: какие материалы передадим, что проверим и как вы примете результат этапа.