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

в 21:07, , рубрики: Help Desk Software, helpdesk, mobile development, разработка под iOS

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

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


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

Необходимость поддержки

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

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

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

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

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

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

И вот, как мы решаем эти задачи.

Схема работы и процессы поддержки и развития

Всю деятельность по поддержке и развитию продуктов мы ведем в соответствии с методологией ITIL в рамках шести основных процессов:

  1. Управление инцидентами и проблемами
  2. Управление изменениями
  3. Управление релизами
  4. Управление предоставлением услуг
  5. Управление аудиторией
  6. Управление ценностью для бизнеса

Опыт организации поддержки мобильных приложений
Каждый из процессов может стать темой отдельной статьи. Сейчас я хотел бы дать общее представление об организации работы.

Процессы

Управление релизами

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

  • планирование релиза;
  • построение релиза;
  • выпуск релиза.

Состав будущего релиза формируется из:

  • дефектов, выявленных в ходе эксплуатации;
  • новой функциональности, не вошедшей в предыдущие обновления или появившейся в процессе формулирования новых требований.

Таким образом «топливо» для работы над релизами, как показано на схеме, поставляют процесс управления инцидентами и проблемами и процесс управления изменениями.

Работа по построению релиза идет в соответствии с методологией Agile, и его состав упаковывается в один или несколько спринтов. В качестве трекера задач используется Jira, в которой мы настроили отдельный Workflow и набор Agile-досок.
Опыт организации поддержки мобильных приложений
По теме работы с Agile Board в Jira рекомендую подробную статью от ребят из Яндекс.Картинок: «Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли».

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

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

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

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

Участники процесса:
— релиз-менеджер;
— мобильные и серверные разработчики;
— тестировщики.
Управление инцидентами и проблемами

Целью данного процесса является своевременное решение обнаруженных в ходе эксплуатации приложения проблем.

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

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

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

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

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

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

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

Основные инструменты:
— Zendesk;
— Crashlytics и Google Analytics;
— Jira.

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

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

Участники процесса:
— инженеры поддержки;
— тестировщики;
— мобильные и серверные разработчики;
— релиз-менеджер.
Управление изменениями

Цель процесса — оценка стоимости внесения изменений, а также их влияния на продукт.
В рамках процесса происходит прием RFC, детализация требований, оценка степени воздействия изменений, затрат и рисков, связанных с их реализацией.

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

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

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

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

Участники процесса:
— владелец продукта со стороны заказчика;
— системный аналитик;
— релиз-менеджер.
Управление аудиторией

В рамках данного процесса мы напрямую взаимодействуем с конечными пользователями приложения:

  • производим мониторинг отзывов пользователей с целью обнаружения пропущенных дефектов, а также корректировки плана развития продукта;
  • отвечаем на вопросы по функциональности продукта (к сожалению, эта возможность есть пока только в Google Play);
  • информируем о планах по выпуску релизов;
  • фильтруем неадекватные комментарии и плюсуем те, которые по делу.

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

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

Помимо сохранения рейтига, форма обратной связи позволяет собрать необходимую для анализа информацию: тип устройства, версию ОС, информацию об аккаунте и контексте.
Опыт организации поддержки мобильных приложений
Выбор правильного момента для показа диалога оценки, а также трюк с перенаправлением негативных эмоций хорошо описаны в статье «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, — своего рода сирена, включающаяся, когда что-то серьезно идет не так. Ежедневные отчеты учитывают в том числе и всплески негативных отзывов в магазинах приложений, что особенно актуально в первые дни после выхода обновления.

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

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

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

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

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

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

Участники:
— инженеры поддержки.

Выводы

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

и небольшой совет

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

Автор: alekhinsasha

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js