Разработка приложения начинается не с макета и не с выбора подрядчика. Сначала нужно понять, какую задачу продукт решает, кто им пользуется и где бизнес готов к затратам. Без этой подготовки смета растёт, сроки расползаются, а готовый продукт напоминает склад идей, а не рабочий инструмент.
С какой цели начинать подготовку
Перед обращением к разработчикам нужно сформулировать одну главную бизнес-задачу приложения: продажи, сервис, удержание клиентов, внутренние процессы или новый цифровой продукт.
На практике путаница начинается там, где в одно приложение пытаются уложить всё сразу: каталог, личный кабинет, чат, оплату, бонусы, аналитику, документы и ещё пару идей, которые всплыли на встрече. Такое желание понятно. Деньги большие, хочется получить максимум. Но разработка любит ясность, а не азарт.
Хорошая постановка звучит предметно: «клиент должен записаться на услугу за две минуты», «сотрудник должен закрыть заявку без звонка в офис», «арендатор должен видеть платежи и передавать показания». В этих фразах уже есть пользователь, действие и результат. Команде проще оценить объём, дизайнеру проще собрать экраны, а владельцу проекта проще отсечь лишнее.
| Вопрос | Что дать подрядчику | Зачем это нужно |
|---|---|---|
| Кто будет пользоваться | Описание 2–3 групп пользователей | Чтобы не проектировать интерфейс «для всех» |
| Какая задача первая | Один основной сценарий | Чтобы запустить продукт без раздувания бюджета |
| Где сейчас теряются деньги | Примеры потерь, задержек, ручной работы | Чтобы функция имела деловой смысл |
| Как измерять результат | Метрики: заявки, покупки, время обработки | Чтобы после релиза не гадать, сработал продукт или нет |
А ведь именно этот разговор часто пропускают. Сразу обсуждают цвет кнопок, вход по номеру телефона и личный кабинет. Между прочим, цвет кнопки почти никогда не ломает проект. Ломает проект отсутствие ответа на вопрос: зачем человек откроет приложение второй раз?
Какие материалы собрать до оценки стоимости
Для расчёта бюджета нужны сценарии пользователей, список функций, описание интеграций, требования к безопасности, примеры похожих продуктов и данные о будущей нагрузке.
Смета без исходных данных похожа на разговор о ремонте квартиры по фотографии подъезда. Исполнитель назовёт вилку, заказчик услышит нижнюю границу, а потом обе стороны будут раздражаться. Чтобы разговор стал предметным, понадобится не толстая папка, а набор внятных материалов.
- краткое описание бизнеса и роли приложения в нём;
- список пользовательских сценариев: регистрация, поиск, заказ, оплата, обращение в поддержку;
- перечень функций с разделением на первый релиз и последующие доработки;
- описание систем, с которыми приложение будет обмениваться данными;
- требования к личным данным, платежам, ролям доступа;
- примеры приложений, где нравятся отдельные решения.
Особое место занимают интеграции. Если приложение должно брать цены из учётной системы, отправлять заявки в систему управления взаимоотношениями с клиентами (CRM), принимать оплату и показывать историю заказов, разработчикам нужны доступы, документация и понимание, кто отвечает за эти системы. Иногда самая дорогая часть проекта прячется не в мобильных экранах, а в старой базе, которую никто не трогал пять лет.
Нагрузка тоже влияет на архитектуру. Одно дело — приложение для трёхсот постоянных клиентов, другое — сервис с акциями, всплесками посещаемости и тысячами одновременных запросов. Здесь не требуется угадывать будущее до процента. Нужны рабочие ориентиры: сколько пользователей ожидается в первый месяц, какой рост планируется через год, бывают ли сезонные пики.
Как оценить подрядчика до подписания договора
Подрядчика нужно проверять по вопросам, процессу, договору, составу команды и готовности обсуждать ограничения проекта, а не только по портфолио и цене.
Красивые кейсы помогают понять вкус команды, но не показывают, как она работает под давлением сроков. На первой встрече многое слышно между строк. Сильный исполнитель спрашивает про бизнес-процесс, данные, поддержку после релиза, роли сотрудников. Слабый быстрее уводит разговор к «сделаем приложение за месяц» и обещает всё включить в первый запуск.
| Признак | Хороший сигнал | Тревожный сигнал |
|---|---|---|
| Оценка | Есть допущения, этапы, границы работ | Названа сумма без вопросов |
| Договор | Зафиксированы результаты этапов | Есть только общая фраза про разработку |
| Команда | Понятны роли аналитика, дизайнера, разработчиков, тестировщика | Всё обещает один менеджер |
| Риски | О них говорят до старта | Их отрицают или обходят молчанием |
Отдельный разговор — права на результат. В договоре должны быть прописаны исходный код, дизайн-макеты, учётные записи, документация, порядок передачи доступов. Если это не зафиксировано, после релиза владелец продукта рискует зависеть от одной команды даже при обычной доработке.
Есть и бытовая проверка, почти смешная, но полезная: попросить подрядчика объяснить, что именно войдёт в первый релиз. Не презентацией, а рабочим языком. Если ответ распадается на туман, проект ещё не созрел для подписания договора. Если границы понятны, разговор о сроках и деньгах становится взрослее.
Что заложить в бюджет помимо разработки
В бюджет нужно включить аналитику, дизайн, разработку, тестирование, публикацию, серверную часть, поддержку, обновления, продвижение и доработки после первых пользователей.
Самая частая ошибка — считать стоимостью приложения только написание кода. Код виден меньше всего, но вокруг него живёт целая инфраструктура. Нужен сервер, администрирование, хранение данных, уведомления, аналитика, проверка на разных устройствах, публикация в магазинах приложений. После релиза начнутся обращения пользователей, мелкие правки и новые требования.
- заложите отдельную сумму на предпроектное обследование и прототип;
- разделите первый релиз и будущие функции;
- уточните стоимость поддержки после запуска;
- проверьте расходы на серверы, рассылки, платёжные сервисы;
- оставьте резерв на изменения после тестовой эксплуатации.
Первый релиз не обязан быть бедным. Он должен быть собран вокруг главного сценария. Если пользователь заказывает услугу, оплачивает, получает подтверждение и видит статус, продукт уже решает задачу. А бонусная программа, сложные фильтры и внутренние рейтинги подождут до момента, когда появятся реальные данные поведения.
Честно говоря, именно после первых пользователей начинается самая интересная часть. Люди нажимают не туда, ищут не то, задают вопросы, которые не звучали на совещаниях. Это не провал проекта, а материал для развития. При условии, что в бюджете есть место не только для запуска, но и для жизни после него.
Итог
Перед заказом разработки нужно принести подрядчику не мечту о «своём приложении», а собранную картину: цель, пользователей, сценарии, функции первого релиза, интеграции, ограничения и бюджетные рамки. Тогда разговор быстро уходит от вкусовщины к предметной работе.
Сильный мобильный продукт рождается до программирования. В момент, когда бизнес честно отвечает, какую боль он убирает и ради какого действия пользователь вернётся на экран. Всё остальное — дизайн, код, тесты, публикация — уже техника исполнения, пусть и сложная.