Нужно ли ТЗ, чтобы заказать приложение?
Нет. Для старта достаточно идеи и понимания, для кого приложение и какую задачу оно решает. Всё, что нужно для оценки, я выясняю за 20–30 минут созвона, а список функций первой версии составляю сам.
Иногда заказчик приходит с документом на десятки страниц, который писали месяц. Обычно в нём подробно описано очевидное: кнопка «Назад» возвращает на предыдущий экран, поле e-mail проверяет формат адреса. А главного там нет: какой сценарий приложение должно закрывать в первую очередь, как оно будет зарабатывать и с какими системами бизнеса связано.
Бывает и наоборот: человек присылает три строчки в Telegram. Для первого разговора этого хватает. Я задаю вопросы, мы вместе отсекаем лишнее, и через несколько дней у вас на руках план с этапами, ценами и сроками. Этот план и работает как ТЗ, только написан он под реальную разработку, а не абстрактно.
Большой документ, написанный до разговора с разработчиком, чаще мешает, чем помогает. Он фиксирует решения, которые принимались без понимания цены каждой функции. Когда выясняется, что половина пунктов удваивает бюджет, документ всё равно приходится переписывать.
Что на самом деле должно быть в ТЗ на приложение?
Разработчику нужны ответы на шесть вопросов: кто пользователь, какой главный сценарий, как приложение зарабатывает, с чем оно интегрируется, на каких платформах работает и что считается готовым результатом. Остальное уточняется по ходу.
- Пользователи и роли. Кто открывает приложение: клиент, курьер, мастер, администратор. У каждой роли свой набор экранов, и именно количество ролей сильнее всего влияет на объём работы.
- Главный сценарий. Одна цепочка действий от открытия приложения до результата. Например, в Tattoo AI это «описал идею, получил эскиз, примерил тату через AR». Если сценарий укладывается в одно предложение, первая версия будет быстрой и понятной.
- Монетизация. Подписка, разовые покупки, оплата услуг картой, реклама, или приложение бесплатное и работает на основной бизнес. От этого зависят экраны оплаты, логика доступа на сервере и то, какую часть выручки заберёт стор: у App Store и Google Play это 15–30%.
- Интеграции. CRM, учётная система, платёжный сервис, карты, ваш сайт, существующий бэкенд. Каждая интеграция — отдельный кусок работы, и о них лучше знать до оценки, а не в конце проекта.
- Платформы. iOS и Android нужны почти всегда. Иногда добавляются Huawei AppGallery, RuStore, веб-версия или планшеты.
- Критерии готовности. Что должно работать на демо, чтобы вы подписали акт этапа. Это защищает обе стороны от споров «а я думал, что это тоже входит».
Отдельно стоит подумать про админку. Если в приложении есть каталог, заказы или контент, который нужно обновлять без выпуска новой версии, понадобится панель управления. Её часто забывают упомянуть, а это полноценная часть проекта со своими экранами и ролями. То же касается пуш-уведомлений: кто и когда их отправляет, вручную или автоматически по событию.
Если на эти вопросы есть ответы, данных для оценки достаточно. Если на какие-то ответа нет, ничего страшного: на них мы и отвечаем на первом созвоне.
Опишите задачу в паре строк — отвечу в Telegram, назову цену и сроки по этапам. ТЗ не нужно.
Чем ТЗ отличается от брифа и плана работ?
Бриф — это ваше описание задачи своими словами. План работ и договор — это договорённость о том, что именно войдёт в разработку, за какую цену и в какой срок. На старте от вас нужен только бриф, остальное готовлю я.
| Документ | Кто готовит | Когда | Что внутри |
|---|---|---|---|
| Бриф | Заказчик | До первого созвона | Идея, аудитория, примеры похожих приложений, желаемый срок и бюджет |
| Разбор задачи | Разработчик | 1–2 дня после созвона | Уточнённые сценарии, роли, интеграции, риски |
| Оценка и план | Разработчик | Ещё 2–3 дня | Этапы, цена и срок каждого этапа, состав первой версии |
| Договор и NDA | Обе стороны | Перед стартом | Состав работ, фиксированная сумма, порядок сдачи, передача прав на код |
| Детальные требования | Разработчик | Перед каждым этапом | Экраны, состояния, ошибки, крайние случаи |
Такой порядок экономит время и деньги. Вы не тратите месяц на документ, который придётся переписать после первого разговора. Детали экранов появляются тогда, когда до них дошла очередь, и к этому моменту вы уже видели предыдущие демо и понимаете, что работает, а что нет.
Сумма в договоре фиксированная и дальше не растёт. Если по ходу вы захотите добавить новую функцию, это отдельный этап с отдельной оценкой, а не тихое увеличение счёта.
Какие ошибки заказчики делают в ТЗ?
Самая частая ошибка — описывать приложение целиком, со всеми функциями на годы вперёд, вместо первой версии. Оценка из-за этого вырастает в несколько раз, а запуск откладывается на месяцы.
- Всё в первую версию. Чат, лента, бонусная программа, реферальная система, админка с отчётами. Большая часть этого не нужна, пока нет пользователей. Что стоит включать в MVP, я подробно разбирал в статье о стоимости мобильного приложения.
- Описание интерфейса вместо задачи. «Синяя кнопка в правом верхнем углу» — это готовое решение, а не требование. Лучше написать, что пользователь должен сделать на этом экране. Как это будет выглядеть, решим вместе на этапе дизайна.
- Нет ни слова о деньгах. Если подписка появляется в последний момент, приходится переделывать онбординг, экраны доступа и логику на сервере. Модель монетизации лучше обсудить на первом созвоне.
- Скрытые интеграции. Фраза «ну и чтобы заказы падали в нашу учётную систему» в конце разговора может оказаться небольшой задачей, а может стать самой сложной частью проекта. Всё зависит от того, есть ли у системы нормальный API.
- Требования без приоритетов. Когда всё «обязательно», невозможно предложить вариант подешевле. Разделите функции на две колонки: «нужно к запуску» и «можно потом».
- Копия конкурента. «Как у крупного сервиса, только лучше» — хороший ориентир для дизайна, но плохое ТЗ. За крупным сервисом годы разработки и большая команда. Выберите одну вещь, которую вы сделаете иначе, и постройте первую версию вокруг неё.
Нужен ли дизайн до начала разработки?
Не обязательно. Если макеты в Figma уже есть, я работаю по ним. Если нет, соберу интерфейс сам на основе привычных паттернов iOS и Android или подключу дизайнера.
Для оценки хватает ссылок на 2–3 приложения, которые вам нравятся, и пары слов о том, что именно в них нравится: навигация, цвета, как устроена оплата, насколько быстро человек доходит до результата. Это даёт разработчику больше, чем страница словесного описания экранов.
Прототип на бумаге или в любом онлайн-конструкторе тоже полезен. Не как финальный дизайн, а как карта экранов: по ней видно, сколько экранов войдёт в первую версию, и это одна из главных составляющих цены. Если у вас есть логотип, фирменные цвета и шрифты, пришлите их сразу — интерфейс будет выглядеть как часть вашего бренда с первой сборки.
Что подготовить к первому созвону с разработчиком?
Ответьте письменно на несколько вопросов. Полстраницы такого текста на этапе оценки полностью заменяют ТЗ.
- Одной фразой: что делает приложение и для кого.
- Главный сценарий: путь пользователя от установки до результата.
- Как приложение будет зарабатывать или какую задачу бизнеса решает.
- Какие системы уже есть: сайт, CRM, база клиентов, платёжный сервис.
- 2–3 приложения-примера и что конкретно в них нравится.
- Есть ли дизайн, логотип, фирменные цвета.
- Желаемый срок запуска и к какому событию он привязан.
- Бюджет или хотя бы вилка. Так я смогу предложить версию, которая в неё укладывается, а не абстрактную оценку.
Если вы ещё сомневаетесь, нужно ли вам вообще приложение, или хватит сайта, прочитайте разбор «Сайт или приложение» — он поможет сформулировать задачу.
После созвона процесс такой: 1–2 дня на разбор задачи, затем 2–3 дня на оценку и план. Вы получаете этапы с ценами и сроками, договор и при необходимости NDA. Потом начинается разработка: демо каждую неделю, тестовые сборки на ваш телефон и доступ к репозиторию. Подробнее этапы и гарантии описаны на странице о процессе работы.
Во сколько обойдётся приложение, если ТЗ нет?
Отсутствие ТЗ на цену не влияет. Оценка бесплатная, точную сумму я называю после короткого созвона и фиксирую в договоре.
Для ориентира: мобильное приложение стоит от $2000, MVP занимает 4–8 недель. iOS и Android я делаю одной кодовой базой на React Native, это почти вдвое дешевле двух отдельных нативных приложений. Актуальные стартовые цены по всем видам работ собраны на странице с ценами.
Оплата идёт по этапам, без 100% предоплаты. После каждого этапа — демо, тестовая сборка и акт. Код, аккаунты App Store и Google Play, хостинг и домен оформлены на вас с первого дня. Стек стандартный, поэтому при желании проект можно передать другому разработчику после любого этапа.
Если идея есть, а ТЗ нет, это нормальная точка старта. Опишите задачу своими словами в форме заявки или напишите мне в Telegram. Оценка бесплатная, и после созвона вы будете знать точную сумму и срок.