Мобильное или веб-приложение: выбор по сценарию

Где и как будут пользоваться продуктом?

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

Каждое требование записывайте на конкретном примере. Не просто «доступ к камере», а «сфотографировать показания счётчика и прикрепить снимок к заявке». Не просто «работа без интернета», а «заполнить акт осмотра без связи и отправить его, когда сигнал появится». То же касается уведомлений и доступности для людей с ограниченными возможностями: описывайте ситуацию, а не название функции. Если типов пользователей несколько, опишите ситуацию для каждого: вполне может оказаться, что им нужны разные интерфейсы.

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

Что каждый вариант означает для выпуска и поддержки?

Веб-приложение и приложение из магазина живут по разным правилам. Веб-версию можно обновить в любой момент, когда вы решите. Приложение из магазина проходит проверку, а пользователи устанавливают обновления, когда им удобно, поэтому вам, возможно, придётся одновременно поддерживать несколько версий. Аккаунты в магазинах, подпись приложения и карточки тоже требуют отдельной работы. Поэтому разработку веб-приложений и разработку мобильных приложений планируют по-разному с первого дня.

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

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

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

Что проверить первым?

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

Проверяйте прототип с обычными пользователями на обычных устройствах, а не только на новых телефонах разработчиков. Затем запишите, какую платформу вы выбрали, почему и какие ограничения остаются, — тогда к этому решению можно будет вернуться, если обстоятельства изменятся. Несколько сессий, за которыми вы наблюдаете сами, обычно дают больше, чем общий опрос о том, «удобно ли пользоваться».

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