Ктоокажетсяближе?

Сначала прототип, потом смета

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

1. ШАГ 1

   Разговор о деле

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

2. ШАГ 2

   Прототип на вашем телефоне

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

3. ШАГ 3

   Разработка этапами

   Каждый этап заканчивается сборкой, которую ваша команда ставит себе на телефон через TestFlight и внутреннее тестирование Google Play. Вы смотрите не отчёт о работе, а саму работу - и правки стоят дёшево, пока сценарий ещё можно изменить.

4. ШАГ 4

   Релиз и то, что после

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

Что спрашивают чаще всего

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

• Нам вообще нужно приложение или хватит сайта?

  +

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

• Нативная разработка или кроссплатформенная?

  +

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

• Сколько стоит и сколько занимает?

  +

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

• Кому принадлежат аккаунты в App Store и Google Play?

  +

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

• Приложение точно пропустят в магазины?

  +

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

• У нас уже есть сайт. Придётся делать всё заново?

  +

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

• Приложение будет работать без интернета?

  +

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

• Что происходит после релиза?

  +

  Продукт продолжает жить: выходят новые версии iOS и Android, меняются правила магазинов, у людей на руках остаются старые сборки. Мы собираем ошибки с настоящих устройств, разбираем падения, держим совместимость с сервером и выпускаем обновления. Объём сопровождения фиксируется отдельно - от «реагируем на поломки» до регулярного развития.

• Проект начала другая команда, и всё встало.

  +

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