Перейти к содержимому
DevUzDevUz Studio

// мобильное приложение, закупаемое по тендеру

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

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

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

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

Что обычно упускают в ТЗ

Не указано, чей аккаунт разработчика в App Store и Google Play и кто публикует приложение

Чем оборачивается. Без ясности, на чьё юрлицо оформлен аккаунт, возникает спор после сдачи работ: подрядчик публикует под своим аккаунтом — и заказчик зависит от него при каждом обновлении, либо публикация затягивается, потому что аккаунт заказчика не создан и не верифицирован до старта разработки.

Как написать правильно. В ТЗ прописывается, что аккаунты в App Store Connect и Google Play Console регистрируются на юрлицо заказчика до начала работ, а подрядчик получает доступ как участник команды с правом публикации.

Не заданы минимальные поддерживаемые версии iOS и Android

Чем оборачивается. Без диапазона версий подрядчик либо закладывает поддержку устаревших систем «на всякий случай», что удорожает разработку, либо ориентируется на последние версии — и часть пользователей с более старыми телефонами не сможет установить приложение.

Как написать правильно. ТЗ фиксирует минимальную версию iOS и Android, а также перечень типов устройств (телефон, планшет), на которых интерфейс обязан корректно отображаться.

Нет требований к серверной части и API

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

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

Нет сценариев приёмки на реальных устройствах

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

Как написать правильно. В ТЗ приводится перечень моделей устройств и версий систем для тестирования, а также сценарии приёмки — что именно проверяется: регистрация, уведомления, оплата, работа при слабом интернете и в офлайне.

Не оговорены поддержка после публикации и обновления под новые версии систем

Чем оборачивается. После сдачи проекта Apple и Google периодически меняют требования к приложениям, а новые версии iOS и Android иногда ломают работу старого кода. Если поддержка не прописана отдельно, заказчик остаётся с приложением, которое через несколько обновлений систем перестаёт запускаться, а подрядчик уже не обязан это исправлять.

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

Оплата и карта в приложении описаны одной строкой без деталей

Чем оборачивается. Формулировка «интеграция оплаты» или «карта с геолокацией» ничего не говорит о том, какой платёжный провайдер нужен, какая карта — Google Maps, Yandex Maps или локальный сервис, и какие данные они должны отображать. Подрядчик закладывает минимальный вариант, а заказчик на приёмке ожидает большего — отсюда доработки, не предусм...}]

Как написать правильно.

Что даёт хорошее ТЗ

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

Заказчику это даёт сопоставимые заявки от подрядчиков и понятные критерии приёмки вместо спора на последнем этапе.

Подрядчику — точную оценку объёма работ и защиту от доработок, которые на деле не были частью технического задания.

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

Сколько стоит и сколько занимает

Техническое задание — от $400, 1–4 недели: цена зависит от сложности системы, архитектуры, стека и интеграций. Разработка на субподряде — по объёму контракта, оценка до подачи заявки.

ТЗ для тендера или субподряд — подробнее →

Заказчиков и закупки не называем: разбираем типовое ТЗ, а не чей-то тендер.

Готовите закупку или уже выиграли тендер?

Обсудить тендер

Ещё тендерные разборы