Содержание статьи
- Сколько времени нужно для создания мобильного приложения
- Как происходит оценка работ
- Сколько времени занимает каждый этап разработки
- Что растягивает время создания приложения
- Как ускорить разработку: мифы VS способы, которые работают
- Сроки создания приложения в Лайв Тайпинге
Сколько времени нужно для создания мобильного приложения
Полгода–год — это среднее время разработки приложения для бизнеса. Разброс большой, потому что все проекты различаются по виду и объёму работ.
Проекты с типовой функциональностью создаются быстро: на ecom с разделами «Каталог», «Акции», «Избранное», «Корзина», «Оплата», «Личный кабинет» без сложных технологий (AR, геймификация) уходит три–четыре месяца. Сложный проект с большим количеством интеграций, разными пользовательскими ролями может потребовать больше года.
Но даже примерно представляя, что нужно сделать, разработчики не могут назвать клиенту точные сроки разработки приложения при первом разговоре. Чтобы конкретизировать их, нужно провести детальную оценку работ на этапе предпроектной аналитики.
Как происходит оценка работ
Проект создаётся в несколько этапов: аналитика, дизайн, написание кода, тестирование. На этапе предпроектной аналитики, собрав с клиента требования к приложению, аккаунт–менеджер идёт к аналитикам, разработчикам, дизайнерам и тестировщикам, чтобы специалисты сами оценили, какое количество часов займёт у них работа.
В полученную оценку закладываются риски. Аккаунт-менеджер готовит смету, называет клиенту сроки и стоимость разработки. В процессе сроки могут растянуться или уменьшиться, как и цена. Например, если фича окажется легкой в реализации, мы сделаем её быстрее и дешевле. Если вам нужна оценка вашего проекта — пишите или звоните нам +7 495 204-35-03. Мы сориентируем вас по цене и срокам и поможем в разработке.
Сколько времени занимает каждый этап разработки
1. Предпроектная аналитика
Длительность этапа: 1–2 месяца.
Что нужно сделать. Клиент связывается с разработчиками, чтобы рассказать о своём проекте. Студия изучает требования, готовит коммерческое предложение и смету. Клиент принимает решение о сотрудничестве. Если оно положительное, — подписывает договор.
Почему так долго. Перед тем как выбрать подрядчика, клиенту нужно изучить, что предлагает рынок. Он звонит в несколько компаний и рассказывает о своём проекте. Студии проводят предпроектную аналитику, подготавливают смету, презентуют коммерческое предложение клиенту.
По нашим наблюдениям, на эту коммуникацию уходит около месяца. Этап может растянуться из-за долгого составления договора. Чтобы избежать этого, мы сделали понятный шаблон с прозрачными условиями. Скачайте его и напишите нам, чтобы начать работу над вашим проектом
2. Аналитика и проектирование
Длительность этапа: 1-2 месяца.
Что нужно сделать. Конкретизировать требования, продумать разделы, возможности приложения, написать технические документы, разработать прототип.
Почему так долго. Длительность этапа зависит от того, насколько клиент представляет, какое приложение хочет. Если у вас уже есть техническое задание или бриф, то этап аналитики мы закроем быстрее. Если вы пришли с идеей, то нам потребуется больше времени, чтобы конкретизировать всю функциональность.
Фиксирование возможностей приложений в документах, составление прототипа не даст нам заплутать в дебрях технических решений и поможет действовать по заранее продуманному плану. Мы будем знать, что делать, а вы — что получится в итоге.
3. Дизайн
Длительность этапа: 4–6 недель.
Что нужно сделать. Согласовать «внешность» приложения. Проработать дизайн-концепцию и стилизовать под неё все экраны из прототипа.
Почему так долго. Мы разрабатываем дизайн под ваш брендбук или создаём абсолютно новую стилистику. Чтобы понять, что мы делаем то, что вам нужно, мы подбираем стиль элементов, цвета, иллюстрации для главных экранов приложения и презентуем дизайн-концепцию — пример того, как будет выглядеть проект в итоге. Если дизайн-концепция вам нравится, мы стилизуем под неё все экраны из прототипа. Если нет — принимаем правки и дорабатываем.
4. Разработка и тестирование
Длительность этапа: от 3-х месяцев.
Что нужно сделать. Разработать серверную часть, или бэкенд. Написать код, запрограммировать и сверстать элементы приложения. Подключить интеграции. Протестировать код, исправить баги и проверить, что после исправлений все работает корректно, а новые ошибки не появились.
Почему так долго. Этап разработки самый длительный, потому что именно на нём выполняется основная, самая ресурсозатратная часть работ. Специалисты пишут код, подключают сторонние сервисы, проверяют, как всё это работает, исправляют ошибки и проверяют снова. Узнать подробней об этом процессе можно в статье «Разработка мобильных приложений: как мы делаем это в Лайв Тайпинге».
5. Релиз в App Store и Google Play
Длительность этапа: до 1 месяца.
Что нужно сделать. Зарегистрировать аккаунт разработчика, подготовить маркетинговые материалы, выложить сборки в стор.
Почему так долго. Сборка — это файл с готовым мобильным приложением, который нужно опубликовать в магазинах. Чтобы это сделать, мы загружаем сборку в личный кабинет магазина и отправляем её на модерацию. В App Store проверка длится до трёх дней, а в Google Play — до пяти. Если с приложением всё хорошо, то его публикуют. Если оно не соответствуют регламентам, — сборку отклоняют, и попытка повторного релиза откладывается до тех пор, пока разработчики не исправят недочёты.
По срокам мы оцениниваем этот этап примерно в месяц, потому что на регистрацию аккаунта, подготовку маркетинговых материалов и доработки приложения уходит дополнительное время. Если вы хотите узнать об этом процессе больше, читайте наши статьи про публикацию в App Store и Google Play, в которых мы подробно рассказали, как выложить сборку, чтобы рецензенты одобрили её.
Поддержка после релиза
После релиза начинается новая фаза жизненного цикла проекта — Поддержка и развитие. Без неё невозможно поддерживать здоровое функционирование приложения. Если у вас уже есть готовый проект, который нуждается в доработках и развитии, — пишите или звоните +7 495 204-35-03 нам.
Что растягивает время создания приложения
Мы назвали примерные сроки мобильной разработки, а теперь хотим рассказать, почему они могут растянуться.
1. Разработка серверной части на третьей стороне
Приложения для бизнеса — это проекты, у которых есть серверная сторона, или бэкенд. Наличие бэкенда позволяет подключить к приложению системы, которые будут помогать ему работать: записывать, передавать и сохранять данные о клиентах, оплате или о работе сайта компании.
Когда мы пишем бэкенд сами, мы можем отвечать за его работу, прогнозировать риски. Но если бэкендом занимается кто-то другой, то написание приложения может растягиваться из-за коммуникации и согласования работ с третьей стороной.
2. Масштаб интеграций
Подключение корпоративного сайта, различных платёжных, CRM-систем, систем смс–оповещений и других сервисов к бэкенду называется интеграцией. У каждой системы свой интегратор — «поставщик» услуг. Без него невозможно реализовать некоторую функциональность. Так мы не сможем сделать оплату в ecom-приложении, не подключив к нему банк, который будет обрабатывать платежи.
Чем больше у проекта интеграций, тем дольше может длиться их подключение и настройка. Опять же из-за того, что нужно вести переговоры с третьей стороной. Если на этом этапе возникает ошибка, мы не можем гарантировать своевременные правки. Нам нужно ждать, когда у интегратора, который сотрудничает с другими клиентами, появится слот под нашу задачу.
3. Несколько итераций тестирования
При написании кода неминуемо возникают баги, как опечатки при письме. Это нормальный процесс, к которому разработчики готовы. Но при исправлении одной фичи, сбой может дать другая, сопряжённая с ней. Поэтому после исправления багов нужно проверить, как работает вся система в целом. Так мы убедимся, что не сломалось то, что уже работало. Такая проверка называется регрессионным тестированием.
4. Обилие кастомных элементов
Кастомные элементы — это те элементы, которые были разработаны специально под ваше приложение, например всплывающий поп-ап, новая механика прокрутки часового барабана или элементы геймификации, которые изначально не заложены в систему.
Кастомные элементы способны выделить приложение на фоне конкурентов — это принесёт бизнесу больше внимания пользователей, следовательно, увеличит его KPI. Но эти элементы нужно писать с нуля. И чем они сложнее, тем больше времени уйдёт на разработку.
Наша «Новогодняя игра» в приложении SEPHORA тоже кастомная. Мы разработали для неё новую механику — пользователь «разбивает» шарик на экране тапами и получает подарок.
5. Долгое согласование
Чтобы сделать разработку гибкой, мы разбиваем проектные работы на мини–этапы, или итерации. В каждую итерацию входит свой набор задач. Мы выполняем их, а потом отправляем готовую работу клиенту на согласование. Клиент должен убедиться, что всё хорошо, и закрыть акты приёмки работ. Но иногда согласование затягивается в силу разных причин: команда клиента уходит в отпуск, увольняется продуктовый овнер или возникают какие-то личные, непредвиденные обстоятельства. Бывает другой вариант — на стороне клиента несколько ЛПР, у которых разное видение решения тех или иных задач, поэтому они долго ведут переговоры.
6. Неопытность менеджера на стороне клиента
Мы сталкивались с ситуациями, когда клиент поручал ведение проекта и общение со студией разработки менеджеру-новичку. Человек недавно пришёл в команду, поэтому у него ещё нет навыков и компетенций, чтобы определять вектор развития продукта и правильно ставить задачи. Выправлять это помогала наша книга о разработке мобильного приложения для бизнеса. За 70 страниц она учит разбираться в процессах, помогает находить общий язык с разработчиками и делает подкованного заказчика из любого, кто её прочтёт.
7. Новые идеи
По ходу разработки клиент может понять, что здорово было бы добавить дополнительную функциональность. Это нормальный и полезный процесс, но новая идея — всегда дополнительное время на её реализацию. Если мы работаем по Time&Materials или предоставляем клиенту разработчиков по аутстаффу, то вводить такие изменения проще, но время разработки всё равно растягивается, потому что у специалистов появляются новые задачи.
Как ускорить разработку: мифы VS способы, которые работают
Мы разберём три популярных на рынке мифа о сокращении сроков разработки. На первоначальном этапе они действительно могут быть выгодными, но эти способы берут экономию из будущего. Доработки потребуют больше времени, сил, денег, чем полноценная разработка.
Мифы о том, как сократить сроки разработки
- Сделать кроссплатформу. Кроссплатформенное приложение не надо разрабатывать отдельно под каждую платформу — его можно написать один раз и установить на iOS и Android. На нативную разработку уходит больше времени, если вы разрабатываете приложение для обеих платформ. Поддерживать и добавлять новую функциональность в кроссплатформу сложнее. Если в дальнейшем вы захотите разработать новые разделы или серьёзно изменить приложение, то проще будет написать его заново.
- Сделать приложение только под одну платформу. Да, разработать приложение только под iOS быстрей, чем под iOS и под Android, но разрабатывая его только под одну платформу, вы теряете пользователей другой. Можно сделать приложение сначала под одну платформу, а потом написать код для другой, но это будет в 1,5 дольше параллельной разработки.
- Сделать приложение через конструктор. Коробочное решение — это вариант, который поможет только распробовать то, что называется настоящей разработкой. С его помощью вы увидите, как аудитория отреагирует на вашу услугу/продукт. Но выстроить полноценную коммуникацию с пользователем не получится — у «коробки» для этого нет инструментов. Она не обладает функциональностью, которая помогла бы достучаться до пользователя и заинтересовать его. Если вы хотите развивать свой бизнес в мобайле долгосрочно, вам нужно рукописное приложение.
5 способов действительно ускорить разработку приложения
Взамен решений, описанных выше, мы предлагаем вам пять других способов сделать мобильное приложения быстрее — проверенных и рабочих.
- Приходить с продуманной идеей. Если вы придёте к студии мобильной разработки зная, что вам от неё нужно, и имея чёткие представления том, как приложение должно работать, то этап аналитики будет короче.
- Начинать разработку бэкенда раньше. Мы начинаем разработку серверной части, когда приложение ещё находится на этапе дизайна, потому что iOS- и Android-специалисты не могут работать без данных от сервера. Если запускать разработку параллельно, то мобильным разработчикам придётся ждать бэкендеров.
- Декомпозировать работы по проекту. Большие задачи по проекту лучше делить не несколько маленьких, чтобы работать над ними итерациями. Если мы увидим, что какое-то решение неудачное, то так заменить или исправить его будет быстрее.
- Не затягивать согласование. Чтобы запустить проект в срок и быстрее получить первую прибыль, лучше выделить для ведения проекта отдельного человека — продуктового овнера, в рабочие процессы которого заложено время на коммуникацию со студией разработки и принятие решений.
- Сделать всё по инструкциям в сторах. Проверка приложения в магазинах занимает не больше недели. Но если сборка возвращается на доработку, то этот процесс затягивается. Есть свои правила публикации для iOS-приложений и для Android. Соблюдайте их, чтобы пройти проверку с первого раза.
Сроки создания приложения в Лайв Тайпинге
От четырёх месяцев — это минимальный срок разработки приложений в «Лайв Тайпинге». За меньшее время мы просто не сможем сделать качественный продукт, который будет закрывать потребности ваших клиентов и работать бизнесу на пользу. Позвоните +7-495-204-35-03 или напишите нам, чтобы мы могли оценить сроки создания приложения для вас.