Вы обсуждаете приложение для клиентов: нужен вход, запись на услугу, напоминание и оплата. На встрече всё выглядит понятно, но в смете появляются аналитика, прототип и тестирование. За что здесь платить, если экранов пока нет? У каждого этапа разработки приложения должен быть результат, который вы можете проверить: согласованные сценарии, модель экранов, работающая сборка, затем опубликованное приложение. По ним и стоит принимать работу.
На странице услуги я объединяю проект в четыре больших этапа: гипотеза, прототип, разработка и публикация. Здесь подробнее пройду путь заказчика: выделю дизайн, тестирование и дальнейшие обновления, чтобы было понятно, где понадобится ваше решение и что попросить показать.
1. Как понять, что войдёт в первую версию?
Начните с действия, ради которого человек откроет приложение. В примере с записью на услугу ему нужно выбрать время, подтвердить визит и потом увидеть свою запись. Бонусная программа может подождать, а возможность отменить визит стоит обсудить сразу: иначе отмены снова пойдут через администратора.
Я начинаю с разбора задачи и аудитории. От вас здесь нужны примеры того, как люди решают вопрос сейчас: переписка с клиентами, рабочая таблица, описание действий сотрудника. Если приложением будут пользоваться в поездках или на объектах без связи, скажите об этом до оценки. Офлайн-работа затрагивает и хранение данных, и их отправку после возвращения интернета.
После обсуждения зафиксируйте, что входит в первую версию и что останется на потом. Рядом должны быть ограничения: платформы, нужные внешние системы, доступные данные. Этот список позволяет сравнить предложение подрядчика с вашей задачей. Формулировка «сделать приложение для клиентов» такой возможности не даёт.
Если пока непонятно, кому нужен продукт, сначала проверьте идею без разработки. В этой статье дальше исхожу из того, что аудитория и её задача уже определены.
2. Что проверить на прототипе?
Прототип – модель экранов, по которой можно пройти главный сценарий без готового приложения. Например, выбрать услугу, время, вернуться назад и исправить выбор. На этом шаге выясняется, где человеку не хватает пояснения и какие данные он должен знать заранее.
Попросите будущего пользователя выполнить задачу без ваших подсказок. Если вы всё время объясняете, куда нажать, запишите места, где он остановился. Перенести кнопку или добавить пропущенный шаг в модели проще, чем переделывать уже работающую запись и связанные с ней уведомления.
Результат этапа – карта экранов и кликабельная модель с согласованной логикой. Проверьте не только удачный путь. Что увидит человек, если свободного времени нет, он передумал или вернулся в приложение позже? Такие ситуации лучше обсудить, пока они существуют только на экране.
Принимайте этап по тому, что уже можете проверить сами. Красивая презентация ещё не показывает, сможет ли клиент записаться.
3. Когда согласовывать дизайн?
Когда путь пользователя понятен, можно уточнять внешний вид: расположение элементов, размеры текста, цвета, состояния кнопок. Дизайн связан с прототипом, поэтому небольшие изменения логики на этом этапе нормальны. Но если вместо записи на услугу вдруг понадобился маркетплейс, это уже повод пересмотреть состав проекта.
Смотрите на экраны в размере телефона. Длинное название услуги должно помещаться, выбранное время – отличаться от доступного, сообщение об ошибке – объяснять, что делать дальше. Одного красивого главного экрана для приёмки мало: нужны и заполненные формы, и пустые списки, и ожидание ответа.
Со стороны бизнеса вы проверяете названия, тексты и соответствие реальной работе. Подрядчик готовит согласованные макеты и повторяющиеся элементы интерфейса, по которым дальше собирается приложение. После этого программисту не придётся угадывать, как выглядит каждое состояние.
4. Что показывают во время разработки?
На этом этапе экраны начинают работать с настоящими данными. Приложение связывается с серверной частью: там хранятся записи, обрабатываются запросы, проверяются права пользователя. Если нужен обмен с вашей системой учёта, к проекту добавляется её подключение.
Технологии выбирают с учётом задачи, устройств и дальнейшей поддержки. В своём проекте я объясняю эти компромиссы до старта. Заказчику полезнее понять последствия выбора, чем запомнить название языка: будет ли одна программа для обеих платформ, кто сможет её поддерживать, какие функции требуют отдельной работы.
Я показываю промежуточные сборки по ходу разработки. Проверяйте в них законченные действия: удалось ли записаться, появилась ли запись у сотрудника, сохранилось ли изменение после повторного входа. Список готовых экранов сам по себе не отвечает на эти вопросы.
Со своей стороны подготовьте доступы к подключаемым системам и человека, который может объяснить их работу. Если тестового доступа к учёту нет, часть проверок зависнет, даже когда приложение уже выглядит готовым.
5. Как принимать приложение после тестирования?
Тестирование идёт по мере появления функций. Перед публикацией всё равно нужна общая проверка: отдельные части могут работать правильно, а их сочетание – нет. Например, запись создаётся, но после изменения времени напоминание остаётся прежним.
Попросите показать результат на реальных устройствах. Пройдите согласованные сценарии и несколько неудобных ситуаций: пропал интернет, пользователь дважды нажал кнопку, пришёл пустой ответ, приложение закрыли и открыли снова. Если предусмотрены оплата и офлайн-режим, им нужны свои проверки.
Для приёмки пригодится список сценариев с результатами и оставшихся ошибок. Обсудите, что мешает запуску, кто исправляет это и когда можно повторить проверку. Ошибку, из-за которой теряются записи или невозможно выполнить главное действие, нельзя считать мелкой только потому, что её редко удаётся воспроизвести.
Ваше участие здесь особенно важно: разработчик проверяет поведение программы, а вы можете заметить, что оно расходится с порядком работы компании.
6. Что остаётся до публикации в магазинах?
Готовую сборку ещё нужно представить магазину: подготовить описание, изображения экранов и сведения о приложении. Учётные записи разработчика, материалы и требования выбранных площадок обсудите заранее. В моих проектах подготовка сборок и материалов, а также прохождение модерации входят в этап публикации.
Отправка на проверку и доступность для пользователей – разные события. Например, Google Play отдельно показывает статусы проверки и опубликованной версии; приложение могут вернуть на исправление. Поэтому дату рекламного запуска лучше подтверждать после решения магазина. Это различие описано в справке Google Play о публикации.
Принимайте этот этап по приложению, которое можно установить из согласованного магазина и пройти в нём основной сценарий. Проверьте также, что работают серверная часть и сбор событий: публикация без них не покажет, что происходит у пользователей.
В кейсе «Индекс жизни» путь от авторской методики до приложения занял три месяца. В продукт вошли серверная часть, офлайн-режим, подписка и управление контентом. Это пример конкретного состава работ, а не обещание такого же срока для любого проекта.
Кейс: как методика стала приложением «Индекс жизни»
7. Что делать после запуска?
Теперь можно проверять предположения на реальном использовании. Если люди устанавливают приложение, но не заканчивают запись, посмотрите, где они останавливаются. Добавление новых функций не поможет, пока главный сценарий неудобен или ломается.
До запуска договоритесь, кто получает сообщения о сбоях, кто отвечает пользователям и как выбирается следующее обновление. Поддержка включает исправления и адаптацию к изменениям систем; развитие добавляет продукту новые возможности. Эти работы стоит обсуждать отдельно, чтобы ожидания по бюджету совпали.
События для аналитики мобильного приложения лучше определить ещё вместе со сценариями. Тогда после публикации можно сопоставить задуманный путь с тем, что люди действительно делают, и выбрать следующую доработку по этой разнице.
Сколько времени заложить на этапы?
Для первой версии на странице моей услуги указан ориентир: два-три месяца от идеи до публикации. Первые недели уходят на сценарии и аудиторию, к концу первого месяца можно увидеть прототип и дизайн. Затем идут разработка, проверки и подготовка к магазинам. Часть работы пересекается: пока проверяется одна функция, следующая может уже собираться.
Это не универсальный календарь. Срок меняют объём первой версии, сложность обмена данными, офлайн-работа, доступность внешних систем и ваши согласования. Попросите подрядчика привязать план к результатам: когда можно пройти прототип, когда установить сборку, что требуется от вас к каждой встрече.
В смете проверяйте тот же состав: проектирование, дизайн, приложение, серверная часть, тестирование и публикация. Где именно растёт сумма, я объясняю в статье о стоимости мобильного приложения.
Когда не стоит проходить весь путь до разработки?
Если главную задачу уже решает мобильный сайт, сначала проверьте, зачем человеку устанавливать ещё и приложение. Желание иметь иконку на телефоне само по себе не объясняет расходы на разработку и последующие обновления.
Остановиться после прототипа тоже нормально. Если на нём видно, что пользователи не понимают сценарий, сначала переделайте его и повторите проверку. Продолжать по календарю только потому, что следующий этап уже назван в плане, будет дороже.
Отложить проект стоит и тогда, когда внутри компании некому принимать решения или весь бюджет рассчитан до дня публикации. Приложению понадобится человек, который разбирает обратную связь и решает, что менять дальше.
С чем прийти на первый разговор?
Подготовьте описание пользователя, его главного действия и того, как эта работа устроена сейчас. Добавьте список систем, с которыми нужно обмениваться данными, и ограничения по сроку. Готового технического задания для первого разговора со мной не требуется.
Я помогаю определить первую версию, проверить сценарии, разработать приложение и пройти публикацию. Если хотите поручить мне проект, посмотрите, что входит в разработку мобильных приложений. Начать можно с обсуждения сценариев и прототипа, а решение о дальнейшей разработке принять уже после него.
Частые вопросы
Можно заказать только прототип, без дальнейшей разработки?
Да. На этом можно остановиться, проверить сценарии на будущих пользователях и потом решить, стоит ли вкладываться в разработку.
Кому будут принадлежать код и аккаунты приложения?
В моих проектах исходники и учётные записи разработчика оформлены на заказчика. У другого подрядчика уточните это до подписания договора.
Можно продолжить проект с другой командой?
Да, если ей переданы код, доступы и документация. Перед сменой подрядчика попросите новую команду проверить, что она может собрать и запустить приложение.