Шаг 1. Сформулируйте цель и аудиторию
Начните с ответа на вопрос, какую задачу бизнеса решает приложение. Например: увеличить повторные заказы, разгрузить администраторов от записи по телефону, дать клиентам личный кабинет с бонусами или перевести курьеров с бумажных листов на смартфон.
Затем опишите, кто будет пользоваться приложением: покупатели, курьеры, мастера, сотрудники офиса. У каждой группы свои сценарии, и от их количества напрямую зависит объём работ. Приложение «только для клиентов» и приложение «для клиентов и курьеров» — это два разных бюджета.
Хорошая формулировка цели помещается в одно предложение и содержит измеримый результат. «Хотим приложение, как у конкурента» — это не цель, а «хотим, чтобы клиенты записывались сами, без звонка администратору» — уже цель.
Шаг 2. Составьте список функций и разделите его на этапы
Выпишите все желаемые возможности, а затем отметьте, без каких приложение не имеет смысла. Это и будет первая версия, или MVP. Остальное лучше перенести во второй этап: так вы быстрее выйдете к пользователям и потратите бюджет на то, что действительно нужно.
Удобно разделить функции на три группы:
Для каждой функции полезно коротко записать, зачем она нужна бизнесу. Если ответ звучит как «у конкурентов есть», функцию стоит отложить.
- Обязательно для запуска — без этого приложение не решает главную задачу.
- Желательно — улучшает опыт, но можно добавить через месяц-два после релиза.
- Когда-нибудь — идеи, которые стоит проверить после того, как появятся первые пользователи и аналитика.
Ориентировочную стоимость каждого модуля можно посмотреть в калькуляторе: так проще решить, что войдёт в первую версию.
Шаг 3. Перечислите интеграции
Укажите, с какими системами приложение должно обмениваться данными. Интеграции часто занимают заметную часть бюджета, поэтому их лучше назвать сразу, а не обнаруживать в середине проекта.
Типичный список для бизнес-приложения: CRM (amoCRM, Bitrix24, RetailCRM), 1С, сайт, платёжный сервис, онлайн-касса, служба доставки, мессенджеры, сервис рассылок, Госуслуги. Если у системы есть API и документация — приложите ссылку, это ускорит оценку.
Шаг 4. Подготовьте простое техническое задание
Многих заказчиков пугает слово «ТЗ», но для старта не нужен документ на сто страниц. Достаточно нескольких страниц, по которым разработчик поймёт задачу и сможет дать оценку. Вот структура, которой хватает в большинстве случаев:
| Раздел ТЗ | Что написать |
|---|---|
| Цель и аудитория | Какую задачу решает приложение и для кого оно |
| Роли пользователей | Клиент, сотрудник, администратор — и что может каждый |
| Список экранов | Главная, каталог, карточка, корзина, профиль — с кратким описанием |
| Ключевые сценарии | Например: выбрать услугу, выбрать время, оплатить, получить напоминание |
| Интеграции | CRM, 1С, оплата, касса, мессенджеры — со ссылками на API |
| Дизайн | Фирменный стиль, логотип, примеры приложений, которые нравятся |
| Управление контентом | Кто и как будет менять товары, цены, акции |
| Сроки и бюджет | Желаемая дата запуска и рамки бюджета, если есть |
Если ТЗ пока нет — это не проблема. Его можно составить вместе с разработчиком на этапе предварительного обсуждения: мы задаём вопросы, а вы отвечаете на понятном языке бизнеса.
Шаг 5. Определите бюджет и сроки
Назовите подрядчику реальные рамки бюджета. Это не повод «завысить цену», а способ сразу предложить подходящий объём первой версии. Если бюджет ограничен, хороший разработчик скажет, что можно отложить без потери смысла.
Со сроками так же: если есть жёсткая дата — открытие точки, сезон, рекламная кампания, — скажите об этом сразу. Тогда план работ будет строиться от даты, а не наоборот.
Шаг 6. Выберите подрядчика
Сравнивайте предложения не по итоговой цифре, а по составу работ. Одинаковая цена может означать очень разный объём: в одном случае с серверной частью и админкой, в другом — только экраны.
Что стоит спросить у разработчика перед заказом:
- Делаете ли вы приложение сразу для iOS и Android?
- Входит ли в стоимость серверная часть и админ-панель?
- Кто публикует приложение в App Store, Google Play и RuStore и на чьи аккаунты?
- Передаётся ли исходный код и все доступы после оплаты?
- Есть ли гарантийный период и на каких условиях поддержка после релиза?
- Как будет организована коммуникация и как часто я увижу промежуточный результат?
- Какие работы с вашими системами (CRM, 1С, касса) вы уже делали?
Ответы на эти вопросы скажут о подрядчике больше, чем красивая презентация.
Шаг 7. Что прописать в договоре
Договор защищает обе стороны, поэтому важно не подписывать его «по шаблону», не читая. Обратите внимание на несколько пунктов.
Состав работ и результат: лучше всего, если к договору приложено ТЗ или спецификация модулей. Этапы и порядок оплаты: удобно платить частями по мере сдачи этапов. Права на результат: исключительные права на код и дизайн должны переходить к вам. Порядок приёмки: как и в какой срок вы проверяете работу и сообщаете о замечаниях. Гарантия: в течение какого времени разработчик бесплатно исправляет найденные ошибки.
Отдельно договоритесь, на чьё имя регистрируются аккаунты разработчика в магазинах. Правильно, когда приложение публикуется на аккаунт вашей компании: тогда оно остаётся вашим при любом развитии событий.
Шаг 8. Обсудите запуск и поддержку заранее
Приложение после релиза продолжает жить: выходят новые версии iOS и Android, меняются требования магазинов, появляются новые идеи. Уточните заранее, как будет устроена поддержка — обновления, исправление ошибок, развитие функций — и сколько она стоит.
Аккаунты разработчика в App Store, Google Play и RuStore лучше начать оформлять сразу после старта проекта. Для российских компаний с оплатой взносов Apple и Google есть сложности, и их проще решить заранее, чем за день до релиза.
Частые ошибки при заказе приложения
Большинство переплат и сорванных сроков происходят не из-за разработчика, а из-за решений, принятых до старта. Вот ошибки, которые мы встречаем чаще всего, и как их избежать.
- Пытаться уместить всё в первую версию. В итоге запуск откладывается, бюджет растёт, а половиной функций никто не пользуется. Лучше выпустить ядро и развивать его по данным.
- Выбирать подрядчика только по цене. Самое дешёвое предложение часто не включает сервер, админ-панель или публикацию — и эти работы приходится оплачивать отдельно.
- Не назвать интеграции заранее. Когда CRM или 1С «всплывают» в середине проекта, приходится пересматривать и сроки, и смету.
- Публиковать приложение на чужой аккаунт. Если аккаунт разработчика принадлежит подрядчику, перенос приложения потом потребует времени и согласований.
- Не продумать, кто будет управлять контентом. Без админ-панели каждое изменение цены или акции превращается в задачу для программиста.
- Забыть о продвижении. Приложение в магазине само по себе не приводит пользователей — о нём нужно рассказать текущим клиентам на сайте, в соцсетях и в точках продаж.
Если вы учли эти пункты, вы уже на шаг впереди большинства заказчиков и получите приложение быстрее и без неприятных сюрпризов в смете.