Разработка мобильных приложений и веб-сервисов. Все этапы от подготовки до запуска

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

Предпроектная подготовка

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

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

На этом этапе мы вместе с Заказчиком определяем цели и задачи, которые мы собираемся решить с помощью приложения, и целевую аудиторию. Обычно Заказчик приходит с проблемой, а наше дело — найти и предложить оптимальные методы для достижения цели. Изучаем аналогичные решения, выписываем удачные примеры. Изучаем сервисы, с которыми нужна интеграция (понимаем, как это нужно сделать, какие данные нужны, что нужно подготовить и т.п.)

Что получаем на предпроектной подготовке:

1. Уточнение и описание полного функционала программы;

2. Возможность сразу определить "узкие"/сложные места и запланировать риски;

3. Определение ориентировочной стоимости разработки и графика работ для планирования бюджета.

Какие специалисты участвуют в предпроектной подготовке?

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

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

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

О том, что прописывается в ТЗ и как оно составляется, можно прочитать здесь:

Как составить ТЗ так, чтобы тебя понимали

Оценка стоимости проекта по Техническому заданию

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

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

Может оказаться, что стоимость проекта получилась больше, чем предполагает Заказчик. Тогда на этом этапе продумываются альтернативные варианты, пересматриваются или упрощаются некоторые функции. В таком случае, перед началом работ, ТЗ можно откорректировать.

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

Почему невозможно рассчитать реальную окончательную стоимость?

Конечно, эта оценка приближена к реальным прогнозам, но она все таки не является итоговой, так как невозможно оценить, сколько на самом деле будет идти работа. Разработка приложений — это каждый раз создание нового продукта, даже если приложение может быть похоже на уже существующие все равно, итоговый продукт уникальный — разные взаимосвязи работы и ее логика. Все это влияет на оценку и стоимость. Тем более, что в ходе работ Заказчик может поменять требования или появятся новые решения и технологии для решения поставленных задач. По статистике, если условия задания в процессе разработки не меняются, то стоимость остается в пределах 15% от оценки по смете.

Когда предпроектная работа утверждена, составляется ориентировочный план работ — порядок этапов-спринтов. Спринт — это временной отрезок, за который подготавливается часть программы. Для эффективной работы все спринты длятся от 2 до 4 недель. Новый спринт обычно начинается после завершения предыдущего, но в некоторых случаях могут вестись работы параллельно по двум или нескольким спринтам. Это понятие из Scrum-разработки, методология управления проектами и одна из техник Agile Software Development. Подробнее об этих техниках можно прочитать здесь.

Стартуем спринт

Перед запуском спринта еще раз вместе с Заказчиком все проверяем — нет ли вопросов по ТЗ, достаточно ли данных, оценку и сроки спринта. Если все верно, то подписывается Приложение к Договору. В нем все фиксируется, и начинается работа по спринту.

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

Тестирование

В конце каждого спринта проводится тестирование на ошибки и удобство использования. Правим ошибки и завершаем работу по спринту.

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

Советуем прочитать статьи про тестирование:

Особенности тестирования мобильных приложений

Зачем нужно тестирование приложений

Когда работа по спринту завершена, Заказчик его оценивает, может внести некоторые правки и доработки. Следовательно, когда спринт утвержден, мы переходим к новому. И так, пока не будет выполнен весь объем работ.

Разворачиваем и запускаем проект

Когда все спринты завершены и приложение собрано, настало время запускать проект. Если приложение планируется распространять в Google Play и App Store, то необходимо подготовить материалы для публикации — тексты, скриншоты, настраивание подписки и внутренних покупок, и все это должно пройти модерацию.

Если речь идет о веб-приложении или о серверной части (отвечает за обработку и контроль передачи данных и запускается в работу вместе с приложением), то разворачиваем приложение на сервере. Сервер предоставляется Заказчиком, при необходимости, мы поможем подобрать и выбрать его.

Работа завершена. Что дальше?

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

Резюме

Теперь вы знакомы с процессом создания веб-сервисов и приложений. Это очень увлекательный процесс и для нас, и для Заказчика. Оставляйте заявку на сайте, мы будем с вами создавать нечто уникальное и полезное!