Как принимать приложение на основе сайта: сценарий, сборка и выпуск

Владимир Хрущев, разработчик Дарнисофт

Интерфейс открывается на телефоне, поля заполняются, кнопка показывает результат. Достаточно ли этого, чтобы принять мобильное приложение? Сначала нужно выяснить, что предъявлено: веб-прототип, установленная сборка или опубликованный продукт. Для каждого результата нужны свои проверки. Разберём эту границу на собственном демонстрационном сценарии и составим заготовку приёмки для заказчика.

Один сценарий до выбора технологии

Наличие сайта ещё не объясняет, зачем пользователю устанавливать приложение. Начните с повторяющегося действия: оформить заказ, проверить статус, согласовать работу или сделать расчёт на объекте. Опишите пользователя, нужные данные и признак завершения действия.

Для направления Дарни Флоу мы подготовили условный сценарий выездного сотрудника инженерной компании. Он вводит объём, ставку, коэффициент сложности и стоимость материалов, затем получает предварительную сумму:

100 × 1 500 × 1,2 + 50 000 = 230 000 ₽.

Это синтетическая модель, не внедрение у клиента. Публичный пример работает как веб-прототип. Он позволяет обсуждать порядок ввода и расчёт, но не подтверждает наличие сборок Android/iOS, работу без сети, камеру или push-уведомления.

Что можно проверить уже в прототипе

Для такой модели полезна небольшая матрица. Это пример критериев для одного сценария; он не заменяет испытания будущего приложения на устройствах.

Ввести объём 100, ставку 1 500, коэффициент 1,2 и материалы 50 000. Итог 230 000 ₽. Проверена выбранная формула, а не вся бизнес-логика компании.

Изменить объём на 20 при тех же остальных значениях. Итог 86 000 ₽. Изменение данных должно менять результат по согласованному правилу.

Оставить обязательное поле пустым. Понятная ошибка ввода; пустое значение не превращается молча в ноль. Правило нужно согласовать отдельно от допустимого нулевого значения.

Открыть интерфейс на узком экране. Поля, единицы и итог читаются, действие доступно. Это ещё не проверка установки и поведения Android/iOS.

Для реального проекта добавьте допустимые диапазоны, дробные значения, округление и все исключения конкретной модели. Фиксируйте исходные данные, ожидаемый результат, фактический результат и объяснение расхождения. Если правило меняется, запись «как в старой системе» перестаёт быть достаточным критерием.

Что унаследовать от сайта

Перед оценкой мобильной разработки изучите данные, авторизацию и доступный API. Существующая система может предоставить серверную логику, если её способы подключения подходят новому сценарию. Отсутствующие серверные функции становятся отдельным объёмом работ.

Возможность использовать готовый веб-интерфейс также требует проверки: как устроены вход, переходы и обработка ошибок, какие ограничения есть у платформ. Одного адреса сайта недостаточно, чтобы заранее определить технологию, цену и сроки.

Для условного расчёта особенно важен источник ставок. Кто меняет справочник? Как узнать его версию? Должен ли сохранённый результат изменяться после обновления ставки? Это решения рабочего процесса, которые не возникают автоматически вместе с новым экраном.

Раскройте слово «офлайн»

«Работает без интернета» нужно превратить в набор проверяемых действий:

• какие данные доступны на устройстве без сети;
• что можно изменить и сохранить локально;
• как сотрудник отличает локальный расчёт от переданного на сервер;
• что происходит при восстановлении связи, повторной отправке и конфликте изменений.

Это возможные требования к будущей системе. Они не заявлены функциями демонстрационного веб-прототипа. Камера, уведомления и фоновые операции также получают отдельные сценарии, если включены в заказ.

Разделите приёмку на три результата

Прототип. Проверяем понятность экранов, последовательность действий, входные данные и результат выбранного сценария. Задача этапа — согласовать поведение до разработки полного приложения.

Приложение. Проверяем согласованную сборку: установку, функции и ошибки на выбранных устройствах и версиях ОС. Работа экрана в браузере не заменяет эти испытания.

Выпуск. Проверяем материалы и результат согласованного способа распространения. Платформы, аккаунты разработчика клиента и ответственность за подготовку релиза определяются заранее. Срок разработки отделяется от рассмотрения магазином; одобрение публикации гарантировать нельзя.

После первого выпуска понадобится отдельно согласованное сопровождение: изменения ОС, зависимостей и интеграций могут потребовать доработок. Важно определить эту ответственность вместе с границами первоначального заказа.

Что подготовить для оценки

Для первого обсуждения достаточно адреса сайта, пользователей, одного-двух частых действий и нужных платформ. Информация об API поможет оценке. Пароли, ключи и сертификаты через публичную форму передавать не нужно; доступы согласуются отдельно.

Источник примера — собственный веб-прототип Дарни Флоу, направления Дарнисофт. На нём можно попробовать расчёт. Это демонстрация интерфейса и формулы, не установленное приложение и не клиентский кейс.

Практический итог подготовки — список функций, ограничения текущего сайта и критерии приёмки для каждого этапа. По ним можно сравнивать предложения исполнителей и понимать, какой результат действительно готов на очередной демонстрации.