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