Разработка мобильных приложений для всех платформ

Аналитика|

Создание мобильного приложения: соединяя Agile и Waterfall.

Здравствуйте, дорогие читатели. После небольшого летнего перерыва наш блог снова работает в обычном режиме. И начнем мы с публикации цикла статей из серии «Developer story”, в которых несколько приоткроем завесу тайны, отделяющей разработчика от широкой аудитории - покажем «внутреннюю кухню» создания мобильного приложения. Мы не стремимся описать буквально все, что происходит в процессе разработки и не будем останавливаться на совсем мелких деталях – для этого есть специализированные ресурсы. Мы лишь в общих чертах опишем основные процессы, поделимся опытом с нашими коллегами (и, кстати, будем рады получить отзывы) и, возможно, вдохновим кого-нибудь из наших читателей на создание собственного бизнеса.

Различные методики работы над проектами, известные многим специалистам IT-отрасли, применимы, в общем-то, и при создании мобильных приложений. И здесь мы не изобретаем велосипед, так как, с одной стороны, нам самим действительно проще, комфортнее, эффективнее работать по тем схемам, которые уже неоднократно опробованы и не дают сбоев, а, с другой стороны - лишних сложностей не любят и сами клиенты. Оно и понятно – когда дело касается не одной тысячи, и даже не десятка тысяч рублей, рисковать глупо, особенно в условиях крайне нестабильного отечественного бизнеса. Любая разработка мобильных приложений содержит в своей основе максимально продуманный проект. Схемы реализации могут быть разными, но, в основном, нами используется банальная последовательная (пусть и с распараллеливанием процессов на каждом этапе), известная под названием «каскадная» или «waterfall». C некоторыми клиентами при этом, мы ведем работу и по другой, более гибкой методике, в которой есть черты технологии, известной под названием “agile”.

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

Ниже мы подробно опишем обе этих схемы.

 

Традиционная схема.

 

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

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


2. Переговоры с клиентом и заключение договора на выполнение работ. После формализации задачи заключается договор и составляется профиль с заранее определенными этапами разработки (подготовка материала для реализации, реализация, поддержка созданного решения).

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

4. Проектирование. 


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

Первую составляют создание ТЗ и начало формирования тест-кейсов будущего приложения, а также создание спецификаций на API. Вторая (при постоянном взаимодействии с первой) включает в себя прототипирование приложения, и, опять же, параллельную работу разработчиков и дизайнеров по:

-созданию дизайн-макетов и их согласованию с заказчиком;

- формированию окончательного вида карты приложения;

- формированию концепции анимации (при необходимости).

И вот, когда все готово, мы получаем полный набор документов, согласно которому можно создать программное решение.

 

 


5. Программная реализация.

Так же как и предыдущий этап, этот состоит из серии процессов, осуществляющихся параллельно и последовательно в зависимости от схемы работы, согласованной с клиентом. После получения документации и её анализа происходит уточнение календарного плана и его согласование с заказчиком. Далее осуществляется разработка серверной части приложения (которая позже дополняется, изменяется и тестируется при внесении изменений в саму структуру приложения) и происходит распределение задач между участниками проектной команды, программирование, контроль за исполнением. Сам клиент может также получать основную информацию о ходе реализации проекта. По завершении основных работ в рамках создания серверной части, программирования и дизайна происходит отладка приложения: альфа-тестирование (с возможным участием клиента) и бета-тестирование (совместное с клиентом). Когда все ошибки исправлены, а функционал – вычищен, приложение публикуется в сторах: Apple App Store, Google Play, магазине приложений и игр для Windows Phone. Теперь оно доступно пользователю для загрузки.

Последние два этапа – т.н. «пост-продакшн» - осуществляются параллельно.

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

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

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

Разумеется, внутри каждого этапа возможны различные отклонения от стандарта, распараллеливание. Конечно же, существуют и определенные проблемы, связанные с большими трудозатратами, трудностями контроля, возможным моральным устареванием некоторых технических решений уже в процессе разработки. Решить данные проблемы призвана методика, в которой достигнут синтез традиционной «каскадной» схемы и более гибкой «agile» технологии.

 

Постоянные обновления.

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

Ответить на эти вопросы и решить проблему морального устаревания призвана т.н. «гибкая» методика работы с клиентом.

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

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

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

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

 

Почему именно так?

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

Но плюсы все-таки перевешивают. Правильно отлаженная, работа над постоянным улучшением позволит разработанному программному решению не «умереть» и стать для клиента полноценным маркетинговым инструментом по управлению лояльностью, повышению узнаваемости бренда среди аудитории мобильных устройств (которая с каждым годом растет все больше и больше). И именно постоянное обновление позволит клиенту не только держать себя в тонусе и не расслабляться, но и быть более подготовленным к постоянным изменениям, новым рыночным и технологическим трендам, таким, как, например, грядущее радикальное обновление мобильной платформы Apple. Как известно, тот, кто стоит на месте - движется назад. Вперед же идет тот, кто движется чуть быстрее, чем нужно.

 

Эта статья в нашем Tumblr.

Политика обработки персональных данных