Как создать приложение: от идеи до выпуска
Определяем сценарии, проверяем прототип и принимаем рабочие сборки. Разбираем данные, тестирование, публикацию и передачу проекта.
Проверить сценарий.
Подготовить выпуск.
Практический план для заказчика с примерами требований, проверками на устройствах и ссылками на официальные инструменты.
Начните с действия, ради которого приложение откроют снова
Создать мобильное приложение — значит организовать рабочий процесс на телефоне: пользователь выполняет задачу, данные попадают в нужную систему, компания поддерживает результат после выпуска. Набора красивых экранов для этого недостаточно. До выбора технологии опишите, кто, где и как часто будет пользоваться продуктом.
Для примера возьмём выездного инженера: он получает заявку на обслуживание оборудования, открывает инструкцию, прикладывает фотографии и передаёт результат диспетчеру. У него бывают плохая связь, занятые руки и несколько незавершённых заявок. Это учебный сценарий, а не опубликованный кейс iSEO.pro.
- Попросите будущих пользователей показать, как они решают задачу сейчас. Запишите задержки, повторный ввод и потерянные данные.
- Выберите один главный результат: например, передать оформленный отчёт без последующего переписывания диспетчером.
- Определите исходный показатель: время заполнения, долю неполных отчётов, число обращений за помощью.
- Проверьте, действительно ли нужен установленный продукт. Для редкого запроса информации может хватить удобного сайта.
На выходе нужен короткий документ: аудитория, проблема, основной сценарий, ограничения и способ измерения пользы. Формулировка «как у конкурента» этих ответов не даёт.
Соберите законченный сценарий и границы проекта
Первая версия должна позволять выполнить полезную задачу целиком. Если инженер может заполнить отчёт, но диспетчер не может его получить, сценарий ещё не готов. Составьте карту пути: вход → список заявок → карточка → выполнение → отправка → подтверждение.
Рядом с каждым шагом укажите участника, источник данных и исключения. Что увидит новый сотрудник без заявок? Кто исправляет ошибочную запись? Можно ли вернуться к черновику? Как понять, что сервер принял данные? Эти вопросы определяют объём разработки точнее числа экранов.
| Включить | Отложить | Проверить до оценки |
|---|---|---|
| Заявки, карточка, фото, черновик и отправка. | Внутренний чат и сложные рейтинги сотрудников. | Откуда приходят заявки и куда уходит результат. |
| Роли инженера и диспетчера, восстановление доступа. | Дополнительные роли без подтверждённого сценария. | Какие данные доступны каждой роли. |
| Понятное поведение при потере сети. | Полная автономная копия всей базы. | Что хранится локально и как решаются конфликты. |
Зафиксируйте также то, что не входит в работу. Любое добавление оцените по пользе, стоимости и влиянию на срок. Утверждать приоритеты должен назначенный представитель заказчика, а не каждый участник обсуждения по отдельности.
Переведите пожелания в проверяемые условия
Вместо «быстро и удобно» запишите конкретные действия и ожидаемый результат. Разделите требования к функциям, данным, устройствам, безопасности и эксплуатации. Подрядчик должен знать версии операционных систем, ориентировочный объём записей, допустимый размер вложений и предполагаемые пики использования.
| Пожелание | Проверка | Ожидаемый результат |
|---|---|---|
| «Работает без интернета». | Открыть назначенную заявку, отключить сеть, сохранить отчёт, закрыть и снова открыть приложение. | Согласованные поля и вложения сохранены локально; статус не выдаёт черновик за отправленный отчёт. |
| «Нет дублей». | Повторить отправку после обрыва ответа. | В принимающей системе одна операция, приложение показывает её итоговый статус. |
| «Есть разграничение доступа». | В тестовой среде войти двумя сотрудниками с разными назначениями. | Каждый видит только разрешённые записи; запрет проверяется и на сервере. |
Сохраните критерии в общей таблице с ответственным, статусом и ссылкой на доказательство. Для скорости согласуйте измеримый сценарий, устройство и сеть. Порог выбирают под задачу: произвольное обещание «любое действие за секунду» трудно проверить и легко понять по-разному.
Проверьте логику до дорогой разработки
Сначала соберите связанный прототип основных экранов. Затем дайте человеку задачу без подсказок: «Найдите назначенную заявку, приложите фото и отправьте результат». Наблюдайте, где он останавливается, ищет кнопку или неверно понимает статус. Записывайте наблюдение, а не только оценку «нравится».
Прототип должен содержать загрузку, пустой список, отказ в разрешении, ошибку и успешный результат. Отдельно проверьте длинные названия, открывшуюся клавиатуру, увеличение текста, возврат назад и подтверждение необратимого действия. После проверки исправьте затруднения и повторите проблемный сценарий.
В дизайн передают согласованную логику, а не россыпь картинок. Дизайнер оформляет компоненты, состояния и правила для разных размеров экрана. Интерактивный макет не подтверждает работу сервера, камеры или автономного сохранения: эти части принимают на установленной сборке.
У iSEO.pro прототип мобильного продукта — от 200 000 ₽. Уточняйте состав: исследование, сценарии, количество состояний и передаваемые материалы. Если прототип уже оплачен, его повторное включение в смету разработки нужно отдельно обосновать.
Выбирайте платформу по ограничениям продукта
Составьте список устройств вашей аудитории и обязательных возможностей: камера, сканирование, уведомления, фоновые операции, связь с оборудованием. Для внутреннего приложения используйте фактический парк телефонов. Для внешнего продукта опирайтесь на данные клиентов и предусмотрите способ проверить гипотезу первой версией.
Нативная разработка даёт отдельную реализацию для каждой платформы. Кроссплатформенный подход позволяет разделять часть кода, но не отменяет настройки интеграций, сборки и тестирования iOS и Android. Веб-приложение или конструктор тоже могут подойти, если их реальные возможности закрывают сценарий.
Попросите команду проверить самый рискованный элемент небольшой технической пробой: например, сканирование конкретного кода или сохранение фотографий при потере связи. Сравнивайте решения по этой проверке, доступности специалистов, стоимости сопровождения и возможности передачи проекта. Название популярного фреймворка само по себе не доказывает пригодность.
При выборе конструктора выясните, можно ли выгрузить данные, что входит в тариф, кому принадлежат аккаунты и насколько продукт зависит от поставщика. AI-инструменты ускоряют отдельные задачи, но сгенерированный код всё равно требует проверки логики, доступа к данным и воспроизводимости сборки.
Спроектируйте сервер и обмен с учётными системами
Опишите, где хранится каждый объект: пользователь, заявка, фотография, статус, справочник. Назначьте источник истины. Если диспетчер поменял задание в CRM, а инженер редактировал старую копию без сети, система должна разрешить конфликт по заранее согласованному правилу.
Для каждой интеграции зафиксируйте направление обмена, обязательные поля, идентификаторы, частоту обновления и обработку ошибок. Проверьте её на тестовых данных до завершения всех экранов. Недоступный API или отсутствие нужного поля могут изменить архитектуру и срок проекта.
Нажатие кнопки — это намерение пользователя. Подтверждение сервера — отдельное событие. При неизвестном результате приложение должно уточнить статус операции, а не безусловно создать её заново.
Согласуйте правила хранения локальных данных, выход из аккаунта и минимально необходимые разрешения. В техническое задание на безопасность можно включить применимые проверки OWASP MASVS: хранение, авторизацию, сетевой обмен и приватность. Это основа для работы специалистов, а не автоматический сертификат безопасности. Связку с отделом продаж рассматривайте вместе с внедрением CRM.
Принимайте реализацию частями на своём устройстве
Разбейте разработку на проверяемые участки. Сначала вход и получение данных, затем основной сценарий, исключения и интеграции. На демонстрации попросите пройти путь на установленной сборке: презентация с изображениями не показывает сохранение состояния и реальное поведение устройства.
- Команда передаёт номер сборки, перечень изменений и известные ограничения.
- Вы проверяете согласованные сценарии на тестовом аккаунте.
- Замечания получают шаги воспроизведения, ожидаемый результат и приоритет.
- Исполнитель исправляет проблему и передаёт новую сборку.
- Вы повторяете исходную проверку и связанные сценарии, которых коснулось изменение.
На стороне заказчика заранее подготовьте тексты, справочники, тестовые аккаунты и доступных специалистов по существующим системам. В плане должны быть зависимости и даты предоставления материалов. Срок «разработка завершена» отделяйте от готовности карточек магазинов, прохождения модерации и фактического запуска.
Протестируйте обычные действия и сбои
Составьте матрицу устройств и состояний на основе аудитории. Включите слабое устройство, поддерживаемые версии ОС и характерные размеры экрана. Эмуляторы помогают расширить покрытие, но камера, уведомления, энергосбережение и реальные прерывания требуют проверки на устройствах.
| Условие | Действие | Что зафиксировать |
|---|---|---|
| Нестабильная сеть. | Оборвать связь во время сохранения, затем восстановить. | Сохранность данных, понятный статус, отсутствие дубля. |
| Прерывание работы. | Свернуть приложение и вернуться; повторить после перезапуска. | Восстановление согласованного состояния и отсутствие чужих данных. |
| Отказ в разрешении. | Запретить камеру или уведомления. | Понятное объяснение и доступный дальнейший путь без падения. |
| Обновление версии. | Установить обновление поверх предыдущей сборки с заполненными данными. | Сохранность записей, корректный вход и совместимость с сервером. |
Для iOS используйте TestFlight: выберите приложение в App Store Connect, откройте вкладку TestFlight, добавьте описание проверки, загрузите сборку и назначьте группу тестировщиков. Первой сборке для внешних тестировщиков требуется проверка Apple. Собирайте отзывы и привязывайте их к версии.
Для Android изучите отчёт о тестировании Google Play: раскройте найденную проблему, посмотрите устройство, версию ОС и доступные диагностические материалы. Автоматический отчёт не заменяет проверку бизнес-сценариев и не гарантирует отсутствие ошибок.
Подготовьте публикацию и передачу проекта
Заранее определите владельца аккаунтов разработчика и ответственных за выпуск. Проверьте доступность регистрации, условия выбранного магазина и требования к вашей категории приложения. Не планируйте рекламный старт, исходя только из обещания пройти модерацию к определённому часу.
Подготовьте рабочую сборку, описание, реальные снимки интерфейса, контакт поддержки и сведения о данных. Для App Store сверьтесь с App Review Guidelines: проверяющим нужен доступ к функциям, работающий сервер и пояснения к неочевидным сценариям. Правила оплаты и учётных записей проверяйте применительно к продукту, региону и способу распространения.
При передаче получите исходный код с историей изменений, дизайн, инструкции сборки и развёртывания, перечень сервисов и подтверждённые доступы. Попросите воспроизвести сборку и выпуск по инструкции. Наличие архива на диске ещё не доказывает, что другая команда сможет поддерживать приложение.
В расчёте стоимости приложения отдельно разобраны публикация и эксплуатация. Ориентиры iSEO.pro: приложение под ключ от 1,5 млн ₽, развитие от 1 млн ₽ за согласованный объём работ. Это не универсальная цена любого проекта и не автоматически ежемесячный платёж.
Смотрите на завершённые задачи и качество работы
До релиза согласуйте события аналитики: начало сценария, успешное завершение, ошибка, повторная попытка. Успех подтверждайте фактическим результатом, а не только нажатием кнопки. Не отправляйте в аналитику содержимое отчётов, телефоны и другие лишние данные.
После выпуска сравните показатели с исходной ситуацией: сколько пользователей дошли до результата, где остановились, какие ошибки мешают работе. Разделяйте версии приложения и типы устройств. Рост установок не объясняет, стали ли отчёты полнее и работа быстрее.
Назначьте владельца мониторинга, канал поддержки и порядок реакции на сбой. Планируйте обновления под изменения ОС, магазинов и внешних сервисов. Поддержка включает восстановление работы, а развитие — новые возможности; их объём и бюджет лучше согласовать раздельно. Разбор типичных проблем приведён в статье об ошибках разработки приложений.
Что должно быть понятно до запуска
Частые вопросы о создании приложения
Можно ли начать без подробного технического задания?
Можно начать с исследования и прототипа. Но до оценки основной разработки нужно согласовать сценарии, данные, ограничения и критерии приёмки. Иначе одинаковое название функции будет означать для сторон разный объём работ.
Нужно ли сразу выпускать iOS и Android?
Зависит от аудитории и способа распространения. Для сотрудников с известным парком устройств можно выбрать одну платформу. Для внешней аудитории решение принимают по данным пользователей и цене потери части сценариев.
Можно ли создать приложение на конструкторе?
Да, если проверены нужные функции, ограничения, стоимость эксплуатации и возможность передачи данных. Сначала проверьте самый сложный сценарий и условия выхода с платформы. Успешная сборка простого экрана не подтверждает готовность всего продукта.
Как определить срок разработки?
Попросите план по этапам с результатом, зависимостями и ответственными. Отдельно обозначьте предоставление доступов, согласования, испытания и публикацию. Один срок без состава работ не позволяет контролировать исполнение.
Достаточно ли тестирования подрядчика?
Технические проверки выполняет команда, а заказчик подтверждает бизнес-сценарии и соответствие требованиям. Нужен общий реестр замечаний с повторной проверкой исправлений. Для критичных данных отдельно согласуют объём проверки безопасности.
Что считать завершением проекта?
Согласованные сценарии работают в принятой версии, существенные дефекты закрыты, продукт доступен оговорённым пользователям, материалы и доступы переданы. Ответственные за эксплуатацию понимают, как наблюдать за работой и выпускать изменения.
СПРОЕКТИРУЕМ ПРИЛОЖЕНИЕ ПОД
ВАШ ПРОЦЕСС
Разберём пользователей, основные действия и интеграции. Согласуем состав первой версии, критерии приёмки и план выпуска.