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

Не будем откладывать самое интересное на конец статьи, и сразу скажем, что разработка приложения может занимать очень разное время — фактически от 1 месяца до нескольких лет. Однако сколько будет разрабатываться каждое конкретное приложение зависит как от запросов со стороны клиента, так и от степени готовности инфраструктуры. В одних случаях подготовка проекта может продолжаться несколько месяцев, а в других минимальная версия приложения может оказаться в маркете уже через несколько недель.

Существует мнение, что любой проект начинается с технического задания (ТЗ). В случае с мобильной разработкой в современных условиях, это далеко не всегда так. Дело в том, что постановка ТЗ требует определенной компетенции и понимания, насколько нужны отдельные функции, как они могут быть реализованы, и в какую сумму обойдется компании дополнительные фичи — та же привязка карт, оплаты в приложении и так далее.

В своей практике мы наблюдаем два типа клиентов. У одних уже есть вся инфраструктура и налаженные процессы. Таким заказчикам нужно просто разработать мобильное приложение, которое дополнит их собственный бизнес-процесс новым интерфейсом. В этом случае действительно возможно ТЗ, потому что специалисты точно знают, что должно делать приложение, через какие интерфейсы передавать данные, в каком виде предоставлять их пользователям.

Однако в 95% случаев заказчик не имеет полностью сформированных процессов, и разрабатывать их приходится вместе с исполнителем. Именно поэтому мы отказались от формализации ТЗ в тех ситуациях, когда у клиента его нет. Это стало результатом практического опыта, потому что на большинстве проектов ТЗ значительно менялось в процессе, а на некоторых дело доходило до создания чего-то вообще иного, чем было заявлено в начале.

Поэтому вместо ТЗ мы используем метод пользовательских историй. Это может быть таблица, документ или просто текст, в котором описано, что приложение должно делать. Например, «Клиент входит в приложение , вводит логин и пароль» — без дополнительного уточнения, как именно это будет работать. В пользовательских историях пишутся такие сценарии, как «Посмотреть баланс счета», «Написать комментарий». «Подтвердить email» При этом в пользовательских историях не фиксируется размер шрифта, параметры фреймов, куда передается информация из приложения Благодаря этому пользовательская история делается намного быстрее и проще, чем ТЗ. Таким образом экономится 2-3 недели из всего цикла разработки.

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

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

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

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

Например, когда приложение разрабатывается для уже существующие инфраструктуры, работы не затрагивают серверную часть. В этом случае проект обычно длится от 2 до 6 месяцев. Хороший пример такого приложения — «Фотолизинг». Мы создавали только интерфейс, через который инспекторы фотографируют и получают задачи. Все остальное — на стороне клиента.

Когда с мобильным приложением заказывают всю систему, включая серверную часть, разработка получается объемнее. И даже если на проект направить больше людей, этот этап все равно выйдет более длительным. Хотя бы потому, что нужно будет устраивать приемку всех компонентов системы. Например, при разработке "Маркетплейса Дезинфекторов" требовалось создать сразу всю инфраструктуру, и на проект ушло около 6 месяцев.

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

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

• Может ли пользователь ввести логин и пароль?
• Возникают ли ошибки при работе?
• Почему календарь остается на английском, хотя язык приложения установлен русским.
• и так далее…

Тестирование может проводиться как силами разработчика, так и на стороне клиента. Нередко тесты проводятся параллельно с двух сторон. Если приложение достаточно объемное, на тестирование и исправление ошибок отводится около 2 недель.

После приемки работы происходит публикация в Google Play и/или Apple AppStore, а также подключение к бэкэнду на стороне заказчика. Поскольку интеграция не всегда проходит гладко, а на одобрение приложения маркетом нужно время, этот этап также занимает 1-2 недели.

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

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

Пока в Neti не было ни одного проекта мобильного приложения, у которого не было хотя бы небольшого развития. Это обусловлено тем, что пользователи выражают свои желания, новые потребности становятся очевидны, и компании выгодно реализовать несколько дополнительных возможностей. В большинстве случаев такие доработки стоят десятки тысяч рублей и очень быстро окупаются. При этом развитие приложения и гарантийная доработка связаны друг с другом. Недавно к нам вернулся заказчик со словами: «У нас есть два пула запросов — один за дополнительные деньги, а второй — нужно кое-что поправить».

В среднем, если нам приходится разрабатывать приложение вместе с заказчиком «с нуля» (а так происходит в большинстве случаев, разработка занимает от 4-6 месяцев. Однако есть приемы, которые позволяют сократить это время…равно как и расходы на разработку.

• Отказ от лишнего формализма в ТЗ дает экономию в 1-2 недели на этапе постановки задачи, и позволяет избежать лишних работ. Например, когда мы разрабатывали приложение для дрессировки собак, оказалось, что анимация в нем и вовсе не нужна, равно как и многоязычность. В результате проект удалось выполнить не за ХХ месяцев, а за ХХ месяцев.

• Для тех заказчиков, у которых нет определенности даже с пользовательскими историями существует возможность запустить «Предпроект». Эти работы делаются подрядчиком практически «в ноль», без прибыли, но направлены на формулирование требований, подготовку небольших пользовательских историй. В рамках предпроекта фактически происходит формирование понимания, как реализовать ожидаемый набор функционала на базе доступных на сегодняшний день технологий. После предпроекта заказчик может пойти с дальнейшим запросом к любому исполнителю, но он важен и разработчику. Ведь никто не хочет создавать «непонятно что» за «неизвестно какой» бюджет. Благодаря предпроектную можно сэкономить время и отказаться от разработки, если возможности мобильного приложения не соответствуют ожиданиям заказчика.

• Запуск MVP или пилотного проекта помогает начать работу с приложением в самое короткое время. Это очень удобно, если нет точного понимания, чего хотят пользователи, и какой функционал должен быть реализован следующим. На практике выпустить MVP можно буквально через 1-1,5 месяца, если предварительные этапы подготовки к разработке мобильного приложения уже пройдены.

• Регулярные демонстрации тоже оказываются эффективным средством ускорения проекта. На своем опыте мы убедились, что очень важно показывать клиенту разработку раз в неделю. Потратив 1-2 часа на демонстрации можно избежать ошибок и недопонимания. Иногда бывает даже так, что в процессе разработки клиент понимает, что ему нужен другой функционал. Например, приложению все-таки требуется мультиязычность. И чем раньше это станет ясно, тем меньше времени уйдет на переделывание.

• Кроссплатформенные фреймворки помогают сократить время реализации проекта примерно в 1,8 раз на саму разработку, если приложение создается сразу для двух платформ (а так обычно и бывает). При работе с React Native или Flutter мы тестируем первую версию приложения на Android, и если все ОК, то за пару дней создается такое же приложение под iOS. Да, в нем могут быть свои ошибки и баги, которые вылавливаются во время тестов. Но все равно на этот процесс уходит буквально несколько дней, а не дополнительные 3 месяца на отдельную нативную разработку.