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

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

Если на руках две сметы, которые расходятся в разы, причина обычно в том, что подрядчики по-разному прочитали одно и то же описание. Документ нужен, чтобы прочитать его можно было только одним способом.

Одна страница для расчёта, документ для договора

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

Дальше — разговор на час и короткий документ: экраны, интеграции, границы первой версии и срок. Этот документ становится предметом договора. Его задача — чтобы фраза «мы думали, это входит» не всплыла на середине проекта, когда спорить уже дорого.

На нём же держится оплата. Цена называется «от», платёж идёт по этапам, и сумма этапа не растёт, пока не меняется объём. Если объём меняется, изменение пересчитывается до начала работ, а не задним числом. Остановиться можно после любого этапа: сделанное работает и остаётся у клиента. Без короткого документа ни одно из этих правил не действует — не с чем сравнить, изменился объём или нет.

Главный сценарий: экран, действие, ответ системы, результат

Первый релиз приложения — это один сценарий, который работает от начала до конца на iOS и Android. Не десять разделов меню, а то, ради чего приложение ставят: заказ оформлен, работа принята, услуга оказана. Поэтому документ начинается с этого сценария, а не со списка функций.

Рабочий формат у нас один и тот же на мобильных и веб-проектах: каждое действие пользователя записывается строкой из четырёх частей — экран, действие, ответ системы, результат. Вот несколько строк для условного приложения с заказами. Это пример формата, а не выдержка из чьего-то проекта:

  • Каталог — пользователь выбирает услугу и нажимает «Заказать» — система проверяет, выполнен ли вход, и открывает форму заказа — заказ создан в статусе «ожидание».
  • Форма заказа — пользователь нажимает «Оплатить» — система открывает платёжную шторку провайдера — заказ ждёт подтверждения оплаты.
  • Экран заказа — провайдер присылает вебхук на сервер — система переводит заказ в «оплачен» и отправляет пуш исполнителю — исполнитель видит новый заказ у себя.
  • Заказ у исполнителя — исполнитель нажимает «Сдать работу» — система уведомляет заказчика и открывает приёмку — у заказчика появляются кнопки «Принять» и «Вернуть на доработку».

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

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

Роли и состояния заказа раньше экранов

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

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

  • покупатель заплатил дважды;
  • исполнитель исчез на приёмке;
  • любого из участников заблокировали посреди сделки.

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

Сюда же относятся продуктовые правила, которые легко забыть. Пример из того же продукта: пока покупатель не внёс депозит, чат отклоняет сообщение с номером телефона, отклоняет сообщение с адресом почты и не пропускает вложения. Каждое из трёх правил — тест, а не надежда. Но тестом правило становится только после того, как его записали в документ.

Что живёт вне приложения и выпадает из ТЗ первым

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

  • Вход, сессии и восстановление пароля — вместе с токеном, который протух посреди работы, и блокировкой после неудачных попыток входа.
  • Пуши и окна разрешений. Системное окно не часть вашего приложения, и изнутри его не проверить, поэтому в документе указано, когда приложение просит разрешение и что оно делает, если пользователь отказал.
  • Платёжная шторка. Она живёт вне приложения, и правило здесь одно: заказ начинается по вебхуку провайдера на сервер, а не по экрану «успешно». Телефон в момент оплаты может быть выключен, убит в фоне или без сети. Подробнее — как устроены платежи в приложении.
  • Плохая сеть и приложение, убитое в фоне. Android закрывает фоновые приложения охотно, и вернуть пользователя на рабочий экран — это функция, которую нужно описать, а не надеяться, что она получится сама.
  • Чат и статусы доставки. Два устройства, один разговор и сообщение, которое не должно молча пропасть: что видит отправитель, если сообщение не дошло, и что видит получатель, когда сеть вернулась.
  • Админка для модерации, споров и возвратов. Она живёт в браузере — разбирать спор с телефона не хочет никто, — и о ней легко забыть, потому что пользователь приложения её не видит.

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

Раздел «не входит» — тоже часть ТЗ

Документ, который перечисляет только то, что будет сделано, оставляет открытым всё остальное. Поэтому в ТЗ на разработку мобильного приложения есть отдельный раздел о том, чего первая версия не делает. У нас в нём обычно стоят: всё, что умеет веб-версия; дизайн-система для продукта, который ещё не встречался с пользователями; продвижение в сторах, скриншоты и рекламные кампании; гарантированные сроки ревью — их назначают Apple и Google, и кто обещает иначе, гадает.

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

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

Аккаунты, ключи и публикация

Аккаунты разработчика в Apple и Google, ключи подписи и сертификаты должны принадлежать компании клиента с первого дня. Подрядчик получает к ним доступ как подрядчик, но не владеет ими. Иначе однажды вы окажетесь заперты вне своего продукта. У нас аккаунты разработчика заводятся на клиента в первую неделю проекта, и доступы, оформленные на его компанию, входят в результат этой недели.

Второе, что стоит заложить заранее, — проверка в сторах. Apple проверяет приложения вручную и отклоняет за вещи, о которых заказчик обычно не думает: за оплату мимо своей комиссии, за пустой демо-аккаунт для проверяющего, за разрешение, назначению которого не поверили. Google пускает быстрее, зато агрессивно убивает фоновые процессы, и это возвращает к пункту про убитый фон.

Отсюда три пункта, которые стоит внести в техническое задание на мобильное приложение:

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

Срок ревью в документе не обещается: его назначают сторы, а не подрядчик.

Кто пишет техническое задание на разработку приложения

Вариантов три, и выбор между ними зависит от того, насколько ясен сценарий к моменту первого разговора.

  • Клиент пишет одну страницу: чем занимается компания, что должно работать и когда. Этого достаточно для базового расчёта за 12 часов, а дальше после часового разговора подрядчик превращает её в короткий документ для договора.
  • Документ становится первым результатом проекта. В первую неделю решаем, какой один сценарий несёт ценность, и заводим аккаунты разработчика на вашу компанию. На выходе — согласованный объём первого релиза, сумма его этапа и доступы, оформленные на вас.
  • Отдельный этап «ТЗ и прототип». Он платный и только по желанию: вы получаете ТЗ и кликабельный прототип, и результат ваш. Если продолжаем вместе, сумма идёт в счёт проекта; если нет, документ и прототип можно отнести другому подрядчику.

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

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

С чего начать

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

Для ориентира: первый релиз мобильного приложения у нас стоит от 800 000 ₽ и занимает восемь недель. Шесть месяцев после сдачи ошибки заказной разработки мы правим за свой счёт.

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