ТЗ на мобильное приложение: шаблон, пример и чек-лист

Хорошее ТЗ помогает договориться, а не впечатлить объёмом

Представьте, что вы просите сделать запись на занятия. Дизайнер рисует расписание и кнопку оплаты, разработчик добавляет бронь, а администратор студии ожидает ещё лист ожидания, переносы и возвраты. Никто не пытался обмануть остальных. Просто каждый представил своё приложение.

Техническое задание нужно именно для таких случаев. Оно описывает не только экраны, но и правила: кто что делает, когда действие считается завершённым, какие данные меняются и как поступить при ошибке. Чем раньше появляются эти договорённости, тем меньше решений приходится принимать в разгар разработки.

Ниже разберём вымышленное приложение для записи на групповые занятия. Это учебный пример, а не описание проекта клиента. Рядом есть редактируемый шаблон ТЗ: обычный текстовый файл в формате Markdown, который открывается в редакторе и переносится в рабочий документ. Регистрация для доступа не нужна.

Чем ТЗ отличается от брифа и оценки

Бриф нужен, чтобы объяснить идею и начать разговор. ТЗ превращает важные решения в требования к продукту. Оценка показывает состав работ, допущения и зависимости. Если положить эти документы рядом, они должны описывать одну и ту же первую версию, но отвечать на разные вопросы.

Не обязательно приходить к разработчикам с готовой архитектурой. Если пока непонятно даже, кто будет пользоваться приложением первым, начните с подготовки к оценке. Напишите, что уже решено, а что ещё нужно обсудить. Честное «не знаем» полезнее выдуманного технического требования.

Мы советуем назначить одного владельца документа. Он не обязан самостоятельно принимать все решения, но должен следить, чтобы согласованное изменение попало в ТЗ, а старая формулировка не осталась в соседнем разделе. Иначе через неделю у команды окажутся две одинаково убедительные версии договорённостей.

Что включить в документ

В начале достаточно объяснить продукт человеку, который не присутствовал на предыдущих встречах. Большие макеты, схемы и документацию сервисов можно приложить ссылками. В самом ТЗ должны остаться решения, без которых нельзя понять объём и проверить результат.

Фраза «нужна база данных» не заменяет требования. Гораздо понятнее: «Администратор видит отменённую запись, причину отмены и человека, который её оформил». Техническое решение команда предложит после того, как станет ясно нужное поведение.

Заполненный пример: запись в небольшую студию

Допустим, студия сейчас принимает заявки в переписке. В первую версию приложения включаем расписание одной площадки, выбор занятия, бронирование, оплату и просмотр подтверждённой записи. Преподавателю нужен список участников. Администратору нужны управление занятиями и обработка отмен.

За пределами первой версии оставляем абонементы, лист ожидания, выплаты преподавателям, социальные функции и несколько филиалов. Это не отказ от развития продукта. Сначала нужно проверить, снимает ли приложение обычную ручную работу, а уже затем расширять его возможности.

Теперь ключевое правило. Запись подтверждается после достоверного результата оплаты. Пока платёж обрабатывается, место удерживается на согласованное время. Если срок истёк, бронь снимается. Продолжительность удержания должен определить бизнес вместе с командой, а не разработчик на своё усмотрение.

Сразу возникает неприятный, но полезный вопрос: что делать, если подтверждение оплаты пришло позже, когда место уже освободилось? Нельзя просто записать человека сверх вместимости. В ТЗ надо определить решение, сообщение клиенту и действия администратора. Такая договорённость раскрывает объём работы лучше, чем ещё несколько красивых экранов.

Как написать проверяемые критерии приёмки

Критерий приёмки отвечает на вопрос: что именно мы увидим, если функция работает правильно? Для этого не нужен особый технический язык. Подход к пользовательским историям можно посмотреть в руководстве GOV.UK, но сам документ пишите понятными вашей команде словами.

Для последнего места проверка выглядит так. Два клиента одновременно открывают занятие. Первый получает действующую бронь. Второй видит, что места больше нет, и не попадает в оплату, которая уже не может закончиться записью. После успешного платежа первого клиента в списке участников появляется ровно одна запись.

Следующий сценарий: человек закрыл приложение во время оплаты и вернулся через минуту. Приложение запрашивает настоящий статус, а не делает вывод об ошибке только потому, что клиент не увидел экран подтверждения. Повторное уведомление платёжного сервиса не создаёт вторую запись. Повторное нажатие не запускает повторную покупку.

Продумайте и доказательства. Принимающий работу должен проверить запись, статус оплаты и нужное событие аналитики. Один скриншот с зелёной галочкой не доказывает, что администратор получил корректные данные и место действительно занято.

Админ-панель тоже относится к продукту

Владелец бизнеса часто подробно обсуждает приложение клиента и вспоминает про админ-панель ближе к запуску. Но кто отменяет занятие? Кто разбирается с возвратом? Может ли преподаватель менять вместимость группы? Как поддержка поймёт, что запись изменили вручную?

Если для каждой обычной операции приходится просить разработчика исправить данные на сервере, продукт ещё не готов к самостоятельной работе команды. Поэтому админ-панель нужно описывать через реальные обязанности сотрудников, а не общую строчку «управление всем».

Зафиксируйте права каждой роли, подтверждение опасных действий и доступную историю изменений. Начните с операций первого рабочего дня. Более подробные примеры есть в статье об админ-панели, но переносить из неё все функции в свой проект не нужно.

Опишите интеграции через конкретные зависимости

«Подключить расписание» звучит просто, пока не выясняется, что у существующей системы нет тестового доступа, а её поставщик отвечает раз в неделю. В ТЗ нужны название сервиса, контакт ответственного, документация и способ проверить обмен данными до запуска.

Решите, какая система считается главной при расхождении информации. Как отмена занятия попадёт в приложение? Что увидит клиент, если сервис расписания недоступен? Иногда честный временный запрет на бронирование лучше, чем обещание записать человека по устаревшим данным.

Отдельно обсудите личные данные: какие действительно нужны, кто получает доступ и что происходит при удалении аккаунта. Сроки хранения нельзя бездумно копировать из чужого шаблона, они зависят от продукта и обязательств компании. Технические вопросы безопасности удобно сверять с OWASP MASVS, а юридические решения обсуждать с профильным специалистом.

Ошибки и ограничения должны быть понятны человеку

Пустое расписание, отклонённый платёж, потеря связи и истёкший вход в аккаунт не являются редкими украшениями к основному сценарию. Пользователь обязательно встретит что-нибудь из этого. Требование «показать ошибку» не объясняет, сможет ли он повторить действие и что случилось с уже введёнными данными.

Пройдите весь путь и отметьте места, где человек рискует потерять доступ, деньги, результат работы или уверенность в происходящем. Для каждой такой точки нужен понятный ответ: состояние сохранено, действие можно повторить, сведения проверяются или требуется помощь.

Не забудьте доступность интерфейса. Отличается ли выбранное занятие не только цветом? Не исчезает ли кнопка при увеличении текста? Понятен ли статус записи человеку, использующему экранное озвучивание? Введение W3C в доступность поможет начать обсуждение, но проверять надо реальные экраны своего приложения.

Что проверить перед приёмкой первой версии

Для нашей студии успехом будет не число установок, а корректная запись без ручного сопровождения каждого клиента. Поэтому в ТЗ полезно назвать несколько действий, которые команда измеряет после запуска, и точно объяснить их смысл.

Событие завершённой записи должно соответствовать подтверждённой записи, а не нажатию на кнопку. Названия событий и допустимые параметры стоит согласовать заранее, иначе iOS, Android и сервер будут считать похожие действия по-разному.

При приёмке пройдите полный путь в сборке, близкой к опубликованной: установка, вход, успешная запись, ошибка оплаты, отмена и действие администратора. Используйте чек-лист тестирования, чтобы следующая проверка не зависела от того, кто вспомнил больше сценариев.

Как вносить изменения без бесконечных споров

ТЗ неизбежно уточняется. Важно различать объяснение уже согласованного поведения, исправление ошибки и новую функцию. Переименовать непонятную кнопку и добавить выплаты преподавателям не одно и то же.

Для заметного изменения запишите причину, затронутый путь, последствия и принятое решение. Уберите устаревшие формулировки. Если меняется объём, попросите команду обновить допущения до того, как работа продолжится. Это гораздо спокойнее, чем обсуждать трактовки на финальной демонстрации.

В Appfyl такой документ можно использовать для обсуждения первой версии. Посмотрите примеры наших приложений, а затем передайте вводные через бриф проекта. Хороший результат этой подготовки: команда и заказчик одинаково понимают продукт и умеют проверить, что он готов.

Как заполнить шаблон, если вы пока не знаете все ответы

Откройте файл шаблона и начните с одного человека, его задачи и полного пути. Для примера со студией это может звучать так: «Клиент выбирает занятие, оплачивает его, получает подтверждение и позже находит запись в приложении». Теперь выпишите вопросы, которые скрываются за этой фразой: когда место считается занятым, кто вправе отменить запись и что делать, если ответ платежной системы пришел поздно? У каждого вопроса должен быть ответственный. Пустая строка выглядит как забытая деталь; открытый вопрос помогает договориться.

Покажите первый вариант документа человеку, который управляет студией, и будущей команде разработки. Попросите каждого отметить не только ошибки, но и места, где он предполагает другое поведение. Если администратор ждет право переносить запись после оплаты, а разработчик закладывает только отмену, этот разрыв нужно закрыть до утверждения состава работ. Макеты и доступы можно приложить отдельно: основной документ должен оставаться понятным без десятка вложений.

Предварительное обсуждение проекта возможно и с нерешенными вопросами. Важно прямо указать допущения, на которых строится оценка. Критерии приемки можно уточнить во время подготовки, но к моменту проверки функции они уже должны быть согласованы. Так небольшой шаблон превращается в рабочую договоренность, а не в красивый файл, который никто больше не открывает.

Частые вопросы