Техническое задание на мобильное приложение нужно, чтобы заказчик и команда одинаково понимали результат. Хорошее ТЗ описывает пользователей, действия, правила, исключения и способ проверки готовности. Оно не обязано превращаться в энциклопедию технологий: важнее устранить неоднозначность в тех местах, где разные трактовки приводят к переделкам, спорным платежам и неудобству клиентов.
Чем ТЗ отличается от идеи и брифа
Идея обозначает направление: например, дать клиентам возможность записываться без звонка. Бриф собирает исходные сведения о компании, аудитории и ожиданиях. Техническое задание переводит эти сведения в согласованное поведение продукта. Из него должно быть понятно, какие операции поддерживаются, какие ограничения действуют и что будет считаться выполненной работой.
Фраза «нужна удобная запись» подходит для начала разговора, но не для приёмки. Более определённое требование описывает выбор филиала, услуги и времени, получение подтверждения и отображение записи в истории. Затем добавляются правила: когда слот блокируется, можно ли записать другого человека, как работает отмена и кто получает уведомление. Именно эти детали формируют границы реализации.
ТЗ не заменяет исследование. Если компания ещё не знает, как должен работать процесс, длинный документ лишь закрепит неподтверждённые предположения. Сначала полезно выяснить фактический порядок действий и проверить спорные сценарии. В самом задании можно сохранять открытые вопросы, но их необходимо явно выделять и назначать срок принятия решения.
Также документ не должен подменять юридическое соглашение. Порядок оплаты, ответственность, права и другие договорные условия требуют отдельного согласования. Техническая часть помогает конкретизировать предмет работы и приёмку, но сама по себе не решает все вопросы отношений сторон. Чем яснее граница между поведением системы и условиями сотрудничества, тем легче использовать оба документа.
Сформулируйте цель и границы
В начале укажите, какой процесс меняется и для кого. Например: повторный клиент выбирает доступное время самостоятельно, а администратор видит подтверждённую запись в действующем расписании. Затем обозначьте, что остаётся за пределами версии: назначение персональных скидок, продажа абонементов или перенос между филиалами. Это предотвращает расширительное толкование общей формулировки.
Добавьте критерий полезности, но не смешивайте его с технической приёмкой. Снижение числа звонков зависит от аудитории, коммуникаций и работы бизнеса. Корректное создание записи — проверяемое поведение системы. Команда может отвечать за реализацию согласованного сценария, а экономическая гипотеза оценивается после запуска с учётом других факторов.
Определите версии продукта. Первая поставка может включать один филиал и ограниченную аудиторию, следующая — дополнительные роли и интеграции. У каждого требования укажите принадлежность к версии. Пометка «потом» без конкретного условия быстро теряется; лучше записать причину переноса и событие, после которого вопрос будет пересмотрен.
Полезно добавить словарь терминов. Если в компании «заказ», «заявка» и «бронь» означают разные состояния, это нужно объяснить. Одно слово в интерфейсе, отчёте и серверной логике должно обозначать одно и то же. Согласование терминов выглядит простой работой, но часто снимает больше противоречий, чем подробное описание экранных координат.
Опишите роли и права
Начните с перечня участников процесса: гость, зарегистрированный клиент, сотрудник, администратор филиала, центральный оператор. Не создавайте роли по названию должности автоматически. Две должности могут иметь одинаковые действия, а одна должность — разные права в разных подразделениях. Основанием для роли служит набор разрешённых операций и область доступных данных.
Для каждой роли укажите, что она видит, создаёт, изменяет и отменяет. Например, клиент видит только свои записи, администратор — записи своего филиала, центральный оператор — все филиалы. Правило нужно проверять не только в интерфейсе. Отсутствие кнопки ещё не означает отсутствие доступа к операции, поэтому требование должно относиться к поведению системы целиком.
Предусмотрите изменение полномочий. Сотрудник переведён в другой филиал, уволен, временно замещает коллегу или потерял устройство. Кто меняет доступ, как быстро изменение действует и что происходит с уже открытой сессией? Для заказчика это операционные вопросы. Их описание помогает технической команде спроектировать механизм, который соответствует реальному управлению персоналом.
Не включайте в ТЗ реальные пароли, ключи и клиентские данные. Достаточно указать способ получения тестового доступа и ответственного. Примеры записей можно обезличить или придумать. Документ часто пересылается нескольким исполнителям, поэтому его содержание должно оставаться пригодным для обсуждения без раскрытия служебных секретов.
Пишите сценарии через действия
Один сценарий удобно описывать последовательностью: исходное состояние, действие пользователя, ответ системы и конечный результат. Например, клиент уже вошёл, выбирает запись, нажимает отмену, подтверждает решение и видит обновлённый статус. Затем укажите, что происходит в расписании и какие уведомления получает сотрудник. Это связывает экран с бизнес-процессом.
Избегайте требования «сделать как у известного сервиса». Ссылка может помочь обсудить идею, но чужой интерфейс не раскрывает скрытые правила и ограничения. Выпишите конкретное поведение, которое нравится: повтор заказа, сохранение адреса, понятный статус. После этого проверьте, подходит ли оно вашей аудитории и действующим системам.
Не описывайте одно и то же правило в нескольких местах разными словами. Если срок отмены задан в разделе бизнес-правил, сценарии могут ссылаться на него. Дублирование усложняет изменение: в одном месте уже написано два часа, в другом осталось три. Для критичных правил полезны идентификаторы, по которым их можно связать с задачами и проверками.
У сценария должен быть владелец со стороны бизнеса. Вопрос о том, разрешать ли отмену после назначения мастера, не может решаться исключительно дизайнером. Команда может предложить варианты и объяснить последствия, но итоговое правило должно подтвердить лицо, отвечающее за процесс. В документе сохраняют принятое решение и дату его согласования.
Не забудьте исключения
Основной путь обычно понятен всем участникам, а расхождения возникают при ошибках. Сеть пропала после отправки заявки, свободное время занял другой клиент, внешний сервис не отвечает, обязательные данные устарели. Для каждого такого случая опишите, что видит человек, что может сделать дальше и сохраняется ли уже введённая информация.
Повторное нажатие заслуживает отдельной проверки. Пользователь может несколько раз отправить форму, если не видит реакции. Требование должно определять бизнес-результат: одна операция не создаёт несколько одинаковых заказов. Не нужно предписывать конкретный алгоритм, если это не обусловлено архитектурой. Важнее дать команде однозначное условие и способ воспроизведения.
Продумайте конфликт действий. Клиент отменяет запись одновременно с изменением статуса сотрудником. Какая операция допустима, что считается актуальным состоянием и как объясняется отказ? Если такие правила не согласовать, разные части системы могут вести себя по-разному. На ранней стадии полезна простая таблица состояний и разрешённых переходов.
Ошибки должны быть понятны пользователю и полезны поддержке. В интерфейсе не нужны внутренние технические подробности, но может понадобиться безопасный номер обращения. В ТЗ укажите, какие сведения сохраняются для диагностики и какие нельзя выводить. Это позволяет связать удобство клиента с возможностью команды разобраться в проблеме.
Данные и источник истины
Для основных сущностей составьте перечень полей и правил. У услуги есть название, длительность, цена, доступные филиалы и признак активности. У записи — клиент, время, исполнитель и состояние. Уточните обязательность, допустимые значения и поведение при отсутствии данных. Не всякое пустое поле является ошибкой: иногда бизнес действительно не располагает сведением.
Назначьте источник истины для каждой группы данных. Если цена приходит из учётной системы, приложение не должно независимо хранить другую актуальную цену без описанного правила синхронизации. Если пользователь меняет телефон, нужно определить, где изменение считается подтверждённым и какие системы его получают. Такие решения важнее выбора формата таблицы в самом документе.
Обсудите историю изменений. Компании может понадобиться узнать, кто перенёс запись и какое время было раньше. Не следует сохранять всё бессрочно просто на всякий случай. Опишите конкретную задачу, состав истории и организационные требования к хранению, а вопросы применимых правил обработки данных передайте ответственному специалисту заказчика.
Если предстоит миграция, включите её отдельным разделом. Какие записи переносятся, как сопоставляются идентификаторы, что делать с дублями и как проверяется полнота? Перенос данных не равен копированию файла. Важны корректность связей, обработка ошибок и возможность восстановить исходное состояние, если результаты проверки окажутся неудовлетворительными.
Интеграции и внешние зависимости
Для каждого подключения укажите назначение, владельца системы, доступную документацию и тестовую среду. Затем перечислите операции: получить расписание, создать запись, отменить бронь, получить статус. Название CRM или платёжного сервиса не заменяет этого перечня. У разных конфигураций одного продукта могут быть разные возможности и ограничения.
Определите поведение при недоступности внешней системы. Разрешается ли просмотр ранее загруженных данных, можно ли отправить отложенную заявку или операция должна остановиться? Ответ зависит от риска. Устаревший список статей и устаревшее свободное время имеют разную цену ошибки, поэтому единое правило «всё кэшировать» недостаточно для описания продукта.
Отдельно зафиксируйте ответственность за изменения на другой стороне. Кто предоставляет доступы, настраивает методы, подготавливает тестовые данные и отвечает на вопросы? Если подключение зависит от стороннего подрядчика заказчика, это нужно отразить в календаре. Техническое задание должно показывать внешнюю зависимость, а не создавать впечатление полного контроля мобильной команды.
Укажите критерии проверки интеграции: операция выполнена, данные появились в целевой системе, повтор не создал дубль, ошибка обработана понятным образом. При сложной зависимости полезен ранний эксперимент до окончательного утверждения объёма. Его выводы включают в актуальную версию ТЗ вместе с подтверждёнными ограничениями.
Нефункциональные требования
Скорость, доступность и совместимость нужно описывать измеримо. «Приложение быстро работает» не содержит способа проверки. Лучше определить ключевую операцию, условия сети, объём данных, устройство и допустимый результат. Конкретные значения выбирают под аудиторию и возможности системы; произвольные красивые числа способны неоправданно увеличить стоимость.
Укажите поддерживаемые платформы и диапазон устройств. Решение должно учитывать реальную аудиторию, а не только телефон руководителя. Для интерфейса важны длинные тексты, увеличение шрифта, контраст и понятность элементов управления. Не нужно превращать ТЗ в копию всех рекомендаций платформ: выделите применимые требования и согласуйте, как команда подтверждает их выполнение.
Для работы без сети опишите данные и действия по отдельности. Смотреть сохранённую историю, редактировать черновик и подтверждать новую бронь — разные возможности. Если действие откладывается, пользователь должен понимать, что оно ещё не завершено. После восстановления связи может потребоваться разрешение конфликта, и это также часть ожидаемого поведения.
Безопасность формулируйте через активы и операции: защита доступа, разделение ролей, безопасное хранение секретов, диагностические журналы и восстановление. Универсальная строка «обеспечить полную безопасность» не является проверяемым требованием. Для проекта с повышенными рисками нужен отдельный профильный разбор, а в ТЗ должны оставаться конкретные согласованные меры и проверки.
Аналитика, поддержка и эксплуатация
Определите, какие вопросы компания хочет решать по данным. Например, на каком шаге люди прекращают запись или сколько раз повторяют операцию после ошибки. Затем сформируйте события и их смысл. Событие «успех» должно означать фактическое завершение нужной операции, а не только нажатие кнопки. Иначе отчёт будет выглядеть хорошо при неработающем процессе.
Для каждого события укажите момент отправки и допустимые параметры. Избегайте передачи лишних персональных данных. Аналитика должна помогать принять решение, а не собирать всё доступное. Согласуйте владельца отчётов и порядок проверки: тестовый сценарий должен давать ожидаемую последовательность событий без необъяснимых повторов.
Раздел поддержки описывает, как пользователь сообщает о проблеме, какие сведения доступны сотруднику и как обращение связано с конкретной операцией. Если приложение не даёт понять номер заказа или текущий статус, поддержка тратит время на уточнения. Поэтому эксплуатационные сценарии стоит проектировать одновременно с пользовательскими, а не добавлять после первого потока жалоб.
Также зафиксируйте результаты передачи: исходные материалы, инструкция сборки, описание размещения, порядок обновления и перечень внешних сервисов. Укажите формат и критерий достаточности. Например, другой специалист способен развернуть тестовую среду по инструкции. Это проверяемее, чем обещание передать «всю необходимую документацию» без определения состава.
Критерии приёмки
Для требования полезен формат «дано — когда — тогда». Дано: клиент имеет активную запись и отмена разрешена. Когда: он подтверждает отмену. Тогда: запись получает нужный статус, место освобождается, а история показывает результат. Дополните проверку случаем, когда отмена уже запрещена. Так правило превращается в конкретный набор наблюдаемых исходов.
Не связывайте приёмку только с демонстрацией подрядчика. Заказчик должен иметь возможность повторить ключевые сценарии на согласованной сборке. Укажите версию, окружение, тестовые данные и ожидаемый результат. Если проверка требует недоступного сервиса, её нельзя считать успешно выполненной на основании устного объяснения, как всё должно работать после подключения.
Разделите обязательные условия выпуска и замечания, не блокирующие его. Потеря заказа или доступ к чужим данным отличаются от небольшого визуального несоответствия. Правило классификации должно быть согласовано заранее. При выпуске с известными ограничениями сохраняют список, владельца решения и план устранения, чтобы замечания не исчезли между этапами.
Проверка должна охватывать переход со старой версии, если продукт уже существует. Пользователь может обновиться с сохранёнными данными и незавершённой операцией. Для нового приложения аналогично важны первый запуск, повторный вход и восстановление доступа. ТЗ, которое описывает только идеальную новую установку, оставляет значительную часть реального использования за рамками приёмки.
Управление версиями документа
Назначьте одно актуальное место хранения и понятную нумерацию. Пересылка файлов с названиями «финал», «финал новый» и «последний точно» быстро создаёт расхождения. Команда должна знать, какая версия принята для текущей поставки. Изменения после согласования фиксируют с причиной и влиянием, а не вносят незаметно в старый текст.
Для запроса на изменение достаточно описать исходное правило, предлагаемое поведение и бизнес-причину. Команда оценивает затронутые части, трудоёмкость, проверки и срок. Заказчик принимает решение с учётом того, что придётся перенести. Даже небольшая правка текста может изменить бизнес-смысл, поэтому оценивать нужно последствия, а не количество отредактированных строк.
Сохраняйте связь требования с задачей и результатом проверки. Не обязательно внедрять сложную систему: для небольшого проекта подойдёт таблица с идентификатором, версией и статусом. Такая связь помогает ответить, почему функция реализована именно так и какое решение было принято. Она особенно полезна при смене участников команды или возвращении к отложенной возможности.
Не стремитесь заморозить документ навсегда. По мере исследования и пилота появляются новые сведения. Цель управления изменениями — сделать решения осознанными и видимыми. Актуальное ТЗ отражает согласованный продукт; архив сохраняет историю, позволяя восстановить контекст без бесконечного поиска сообщений в переписке.
Учебный фрагмент задания на запись
В условном примере клиент выбирает одну услугу в одном филиале и подтверждает время без предварительной оплаты. Свободные интервалы предоставляет действующая система расписания. Запись считается созданной только после подтверждения этой системой. До подтверждения интерфейс показывает ожидание, а при недоступности предлагает повторить позже, сохраняя выбранную услугу.
Если интервал занят между просмотром и подтверждением, приложение не создаёт альтернативную запись автоматически. Клиент получает объяснение и актуальный список времени. Повторное нажатие на подтверждение не должно создавать вторую бронь. В истории появляется только подтверждённая запись, а сотрудник видит её в своём рабочем интерфейсе с теми же временем и услугой.
Отмена разрешена по правилу, которое определяет бизнес. В учебном документе его лучше вынести в отдельный параметр, а не повторять число в нескольких сценариях. Если отмена недоступна, приложение показывает способ связаться с администратором. Самостоятельный перенос в другой филиал исключён из первой версии и не подразумевается наличием функции отмены.
Для приёмки готовят свободный интервал, занятый интервал и имитацию недоступности расписания. Проверяют создание, повтор, отказ, отображение истории и действия администратора. В результате одна короткая функциональная область становится достаточно определённой для оценки. На таком уровне можно обсуждать стоимость и сроки гораздо предметнее, чем по формулировке «сделать удобный календарь».
Проверка ТЗ перед передачей исполнителю
Прочитайте документ от лица нового участника. Понятно ли, кто пользователь, какой результат он получает и где заканчивается версия? Есть ли правила для основных исключений, владельцы интеграций и способ проверить готовность? Если ответ требует пояснения «это же очевидно из нашей переписки», существенная информация ещё не перенесена в общий источник.
Затем проведите встречу по противоречиям. Попросите представителя продаж, операционного отдела и поддержки пройти один и тот же сценарий. Разногласия о статусах, сроках и полномочиях лучше обнаружить до реализации. Техническая команда должна видеть согласованное правило, а не самостоятельно выбирать между несовместимыми ожиданиями подразделений.
Уберите требования, которые не влияют на текущий результат и не имеют обоснования. Избыточный документ может быть так же вреден, как слишком краткий: важные правила теряются среди пожеланий. Сохраните будущие идеи в отдельной очереди, а в текущем ТЗ оставьте достаточный состав для реализации, проверки и эксплуатации первой версии.
После этой проверки отправьте одинаковую версию всем участникам оценки. Попросите отметить допущения, исключения и вопросы прямо по разделам. Сравнение ответов покажет, какие места ещё неоднозначны. Хорошее техническое задание не гарантирует отсутствие изменений, но делает их причиной новую информацию, а не разное понимание уже обсуждённых слов.
Проверка одного требования на полноту
Возьмите любую важную строку и попробуйте составить по ней проверку без устного пояснения автора. Например, требование «пользователь видит актуальную цену» оставляет вопросы о моменте актуальности, недоступности источника и изменении суммы после добавления в корзину. Уточнённое правило связывает цену с конкретным подтверждением и описывает действие при расхождении. Затем проверьте, не противоречит ли оно отмене или повторному заказу. Такой небольшой разбор выявляет качество всего документа лучше оценки его толщины. Если проверка требует предположений, перенесите их в открытые вопросы и согласуйте с владельцем процесса до реализации.