Опыт организации поддержки мобильных приложений

Вы должны сказать: «Мы закончили это. Сделано!», а затем продолжить движение к следующей цели.REWORK

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


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

Необходимость поддержки Невозможно создать хороший продукт с первого раза. Секрет успешных приложений не в том, что их делают гениальные разработчики, а в том, что работа над ними идет в формате непрерывного улучшения и с хорошо налаженной обратной связью.Долгий цикл производства (time to market) — зло, тем более в сфере мобильных технологий, где операционные системы обновляются каждый год, а новые устройства появляются раз в два-три месяца. Если вы разрабатываете первую версию продукта более полугода, это означает, что он морально устареет еще до публикации.

Забавный факт. Год назад мы подписали договор на создание приложения, в котором указали, что минимальной поддерживаемой версией ОС будет iOS 7, к тому моменту еще не вышедшая. Нас заставили вставить примечание, что требование действительно в случае, если новая версия ОС выйдет, и случится это в запланированные Apple сроки. В итоге Apple уже анонсировала iOS 8, но приложение до сих пор не опубликовано.

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

Основными задачами, решаемыми после публикации приложения являются:

мониторинг работоспособности; получение обратной связи от конечных пользователей продукта и оказание помощи в решении их проблем; улучшение стабильности работы и добавление новой функциональности; адаптация приложения под новые устройства и версии ОС; отслеживание степени удовлетворения бизнес-потребностей компании-заказчика; корректировка плана развития продукта. И вот, как мы решаем эти задачи.Схема работы и процессы поддержки и развития Всю деятельность по поддержке и развитию продуктов мы ведем в соответствии с методологией ITIL в рамках шести основных процессов: Управление инцидентами и проблемами Управление изменениями Управление релизами Управление предоставлением услуг Управление аудиторией Управление ценностью для бизнеса 393fd6af02687b82a24a5254e496716f.gifКаждый из процессов может стать темой отдельной статьи. Сейчас я хотел бы дать общее представление об организации работы.Процессы Управление релизами Формально результатом нашей работы является выпуск нового релиза, поэтому процесс управления релизами можно считать центральным в общей схеме. Он состоит из следующих последовательных этапов: планирование релиза; построение релиза; выпуск релиза. Состав будущего релиза формируется из: дефектов, выявленных в ходе эксплуатации; новой функциональности, не вошедшей в предыдущие обновления или появившейся в процессе формулирования новых требований. Таким образом «топливо» для работы над релизами, как показано на схеме, поставляют процесс управления инцидентами и проблемами и процесс управления изменениями.Работа по построению релиза идет в соответствии с методологией Agile, и его состав упаковывается в один или несколько спринтов. В качестве трекера задач используется Jira, в которой мы настроили отдельный Workflow и набор Agile-досок.8af95da1e5ebfa0e5faa70bb98f5db14.gifПо теме работы с Agile Board в Jira рекомендую подробную статью от ребят из Яндекс.Картинок: «Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли».

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

Основные инструменты:  — Jira.

Артефакты на входе:  — лист дефектов;  — лист новой функциональности (Request for Change или RFC).

Артефакты на выходе:  — сборка (Release Candidate);  — отчет о выходном тестировании: регрессионном, интеграционном, новой функциональности;  — лист открытых некритичных дефектов: отдельно на стороне клиента и на стороне сервера;  — заключение QA-менеджера о готовности релиза к публикации.

Участники процесса:  — релиз-менеджер;  — мобильные и серверные разработчики;  — тестировщики. Управление инцидентами и проблемами Целью данного процесса является своевременное решение обнаруженных в ходе эксплуатации приложения проблем.Согласно определению: Инцидент — любое событие, не являющееся частью стандартного (штатного) сценария использования, которое привело к частичной или полной невозможности использования приложения.Проблема — неизвестная причина одного или более инцидентов.

Работа в данном процессе построена по классической трехуровневой схеме:

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

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

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

Информацию об инцидентах и проблемах мы получаем по трем каналам:

наша Helpdesk-система — Zendesk, в которой происходит регистрация, классификация и контроль исполнения заявок; магазины приложений, ежедневный мониторинг отзывов в которых позволяет выявить критичные дефекты, особенно в первые дни после публикации обновления; системы мониторинга работоспособности приложения, которые собирают статистику о сбоях и автоматически заводят задачи в баг-трекер. Основные инструменты:  — Zendesk;  — Crashlytics и Google Analytics;  — Jira.

Артефакты на входе:  — заявки от первого уровня поддержки;  — автоматические сообщения о сбоях.

Артефакты на выходе:  — лист верифицированных дефектов для включения в состав будущих релизов.

Участники процесса:  — инженеры поддержки;  — тестировщики;  — мобильные и серверные разработчики;  — релиз-менеджер. Управление изменениями Цель процесса — оценка стоимости внесения изменений, а также их влияния на продукт.В рамках процесса происходит прием RFC, детализация требований, оценка степени воздействия изменений, затрат и рисков, связанных с их реализацией.Все запросы попадают в трекер, где после анализа реализации в зависимости от степени критичности для бизнеса попадают либо в бэклог продукта, либо сразу в спринт следующего релиза.

Основные инструменты:  — Jira.

Артефакты на входе:  — RFC.

Артефакты на выходе:  — обновленный план развития продукта (Road Map);  — лист новой функциональности для планирования будущих релизов.

Участники процесса:  — владелец продукта со стороны заказчика;  — системный аналитик;  — релиз-менеджер. Управление аудиторией В рамках данного процесса мы напрямую взаимодействуем с конечными пользователями приложения: производим мониторинг отзывов пользователей с целью обнаружения пропущенных дефектов, а также корректировки плана развития продукта; отвечаем на вопросы по функциональности продукта (к сожалению, эта возможность есть пока только в Google Play); информируем о планах по выпуску релизов; фильтруем неадекватные комментарии и плюсуем те, которые по делу. Одним словом ведем диалог с пользователями, давая понять, что нам важно их мнение о продукте.Очевидно, что с негативными отзывами в магазинах приложений работать практически невозможно. Они эмоциональны, неинформативны, к тому же отсутствует обратная связь. Поэтому мы мотивируем пользователей сообщать о проблемах в службу поддержки через форму обратой связи. Ее можно найти на стандартном для наших проектов экране «О приложении» или открыть в момент оценки в случае, если пользователь хочет влепить двойку или единицу.

Помимо сохранения рейтига, форма обратной связи позволяет собрать необходимую для анализа информацию: тип устройства, версию ОС, информацию об аккаунте и контексте.24b147988ce6dfb44295298117fcc709.pngВыбор правильного момента для показа диалога оценки, а также трюк с перенаправлением негативных эмоций хорошо описаны в статье «Prompting for App Reviews» (перевод от Macilove).

Основные инструменты:  — Google Play Developer Console;  — iTunes Connect;  — Windows Phone Dev Center;  — AppAnnie;  — формы обратной связи.

Артефакты на входе:  — отзывы в магазинах приложений;  — заявки, отправленные через формы обратной связи.

Артефакты на выходе:  — лист верифицированных дефектов для включения в состав будущих релизов;  — лист часто повторяющихся пожеланий от конечных пользователей.

Участники:  — инженеры поддержки. Управление ценностью для бизнеса Самый важный, на наш взгляд, процесс с точки зрения развития продукта. Его целью является планирование изменений продукта для достижения заданных бизнесом ключевых показателей. В данный момент мы продолжаем наращивать экспертизу и накапливать знания об этом процессе в рамках экспериментов на ни о чем не подозревающих пользователях.Думаю, не ошибусь, если скажу, что более половины всех мобильных бизнес-приложений вообще не отслеживают никаких метрик. В лучшем случае наблюдают за количеством пользователей в Google Analytics. Решения об изменении дизайна и функционала продукта в таких ситауциях принимаются по наитию и ничем не агрументированы. Между тем для постоянного улучшения качества продукта жизненно необходим подсчет и анализ ключевых метрик, синхронизированных с целями бизнеса.DMAICВ основе процесса лежит сбор и анализ метрик на каждом из этапов воронки конверсии. В рамках процесса мы проводим следующие мероприятия:

настройку систем трекинга и аналитики; проектирование воронок внутри приложения для оценки достижения конкретных бизнес-целей; визуализацию динамики изменения метрик; консалтинг в области аналитики (что хорошо, а что плохо для бизнеса с точки зрения метрик, а не гадания); мероприятия по улучшению метрик; предоставление аналитики по прямым конкурентам. Основные инструменты:  — AppsFlyer;  — Flurry;  — Google Analytics;  — AppAnnie;  — AppInTop.

Артефакты на входе:  — метрики на каждом из этапов воронки конверсии.

Артефакты на выходе:  — обновленный Road Map продукта.

Участники:  — бизнес-аналитики;  — владельцы продукта со стороны заказчика. Управление предоставлением услуг Целью данного процесса является контроль соответствия подписанному SLA и улучшение качества услуг поддержки.Service Level Agreement или SLA (соглашение об уровне сервиса) — это документ, описывающий услуги, предоставляемые в рамках поддержки, порядок предоставления этих услуг, а также измеримые показатели качества, такие как:

время реакции на заявку; время решения инцидентов и дефектов в зависимости от степени их критичности и влияния на бизнес-процессы. SLAПодробнее об SLA можно прочитать в cтатье «SLA для начинающих».Сейчас мы предлагаем на выбор два варианта соглашения: базовый и расширенный, отличающиеся временем реакции на заявки и решения проблем, а также количеством каналов, которые мы отслеживаем для оценки работоспособности приложения.

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

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

Еженедельный отчет представляет собой монитор обратной связи, полученной по всем отслеживаемым нами каналам. Отчет состоит из трех частей:

Статистика тикетов в Zendesk по каждому из типов заявок: запросы на изменение; инциденты; дефекты. Статистика по сбоям в Crashlytics, которая дает представление о стабильности релиза. При каждом сбое генерируется сообщение о возникшей ошибке, которое при привышении определенного уровня критичности автоматически попадает в наш баг-трекер. Статистика по отзывам в магазинах приложений, учитывающая изменение рейтинга за неделю, общее число отзывов и число заведенных дефектов. Помимо количественных показателей инженер поддержки в свободной форме дает качественную характеристику отзывам, акцентируя внимание на явных проблемах и частых просьбах пользователей. Ежемесячный отчет содержит информацию о количестве потраченных часов каждого из специалистов для бюджетирования и учета затрат на поддержку, а также процент соблюдения SLA, который позволяет выявить систематические нарушения и принимать управленческие решения. Отчет предназначен для руководителей проектного офиса и департамента поддержки и развития. Основные инструменты:  — Zendesk;  — Jira.

Артефакты на входе:  — статистика заявок и сообщений по каждому каналу мониторинга;  — план выпуска патчей (обновлений, устраняющих критичные дефекты) и релизов.

Артефакты на выходе:  — ежедневные, еженедельные и ежемесячные отчеты о поддержке.

Участники:  — инженеры поддержки. Выводы Всеми силами убеждайте заказчика о работе короткими итерациями. Дарите ему книги Getting Real и Rework. Приводите в пример успешные продукты, в основе работы над которыми лежит модель непрерывного улучшения. Доказывайте, что только этот подход обеспечит максимально возможное удовлетворение бизнес-потребностей и потребностей их клиентов. Выстраивайте систему поддержки ваших продуктов. Без нее вы не сможете работать с более-менее крупным заказчиком. Если у вас нет SLA, скорее всего, вы даже не будете допущены к тендеру. и небольшой совет Не выпускайте релизы перед праздниками и выходными. Заказчику кажется, что отдых станет слаще, если новый релиз будет опубликован в пятницу вечером. Но во-первых, в это время апдейт вообще никто не заметит, во-вторых, если что-то пойдет не так, вам придется поднимать на уши всю команду в выходные дни, либо грустно следить за стремительным падением рейтинга в магазине.

© Habrahabr.ru