Поддержка мобильных продуктов: задачи, процессы, инструментарий
Redmadrobot о применении модели непрерывных улучшений и системе поддержки клиентов в разработке мобильных приложений.
30.12.2014 | Автор: Александр Алехин, Redmadrobot (Директор департамента поддержки и развития мобильных приложений)
Долгий цикл производства (time to market) — зло, тем более в сфере мобильных технологий, где операционные системы обновляются каждый год, а новые устройства появляются раз в два-три месяца. Поэтому не нужно бояться выходить в стор с простым продуктом с минимумом функционала. Работа над приложениями должна идти в формате непрерывного улучшения короткими итерациями (не более месяца на обновления) и с хорошо налаженной обратной связью. Другими словами, навороченным приложение должно становиться постепенно.
Директор департамента поддержки и развития мобильных приложений Redmadrobot Александр Алехин (alekhinsasha) делится опытом организации процессов.
Необходимость поддержки Основная специализация нашей компании — сервисные приложения для самообслуживания клиентов финансовых, страховых и телекоммуникационных компаний. И тут есть некоторая специфика. С одной стороны, эти компании имеют свои департаменты обслуживания клиентов, которые принимают на себя первую волну вопросов и жалоб пользователей. С другой — поддержка таких приложений требует повышенного уровня предоставления услуг, который привязан к уровню сервиса компании-заказчика.
Основными задачами, решаемыми после публикации приложения являются:
мониторинг работоспособности;
получение обратной связи от конечных пользователей продукта и оказание помощи в решении их проблем;
улучшение стабильности работы и добавление новой функциональности;
адаптация приложения под новые устройства и версии ОС;
отслеживание степени удовлетворения бизнес-потребностей компании-заказчика;
корректировка плана развития продукта.
И вот, как мы решаем эти задачи в Redmadrobot.
Схема работы и процессы поддержки и развития Всю деятельность по поддержке и развитию продуктов мы ведем в соответствии с методологией ITIL в рамках шести основных процессов:
Управление инцидентами и проблемами
Управление изменениями
Управление релизами
Управление предоставлением услуг
Управление аудиторией
Управление ценностью для бизнеса
Управление релизами Формально результатом нашей работы является выпуск нового релиза, поэтому процесс управления релизами можно считать центральным в общей схеме. Он состоит из следующих последовательных этапов:
планирование релиза построение релиза выпуск релиза Состав будущего релиза формируется из:
дефектов, выявленных в ходе эксплуатации новой функциональности, не вошедшей в предыдущие обновления или появившейся в процессе формулирования новых требований Таким образом «топливо» для работы над релизами, как показано на схеме, поставляют процесс управления инцидентами и проблемами и процесс управления изменениями.
Работа по построению релиза идет в соответствии с методологией Agile, и его состав упаковывается в один или несколько спринтов. В качестве трекера задач используется Jira, в которой мы настроили отдельный Workflow и набор Agile-досок.
По теме работы с 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)
информируем о планах по выпуску релизов
фильтруем неадекватные комментарии и плюсуем те, которые по делу
Короче говоря, ведем диалог с пользователями, давая понять, что нам важно их мнение о продукте.
Очевидно, что с негативными отзывами в магазинах приложений работать практически невозможно. Они эмоциональны, неинформативны, к тому же отсутствует обратная связь. Поэтому мы мотивируем пользователей сообщать о проблемах в службу поддержки через форму обратной связи. Ее можно найти на стандартном для наших проектов экране «О приложении» или открыть в момент оценки в случае, если пользователь хочет влепить двойку или единицу.
Помимо сохранения рейтинга форма обратной связи позволяет собрать необходимую для анализа информацию: тип устройства, версию ОС, информацию об аккаунте и контексте.
Выбор правильного момента для показа диалога оценки, а также трюк с перенаправлением негативных эмоций хорошо описаны в статье «Prompting for App Reviews» (перевод от Macilove).
Основные инструменты: — Google Play Developer Console— iTunes Connect— Windows Phone Dev Center— AppAnnie— формы обратной связи
Артефакты на входе: — отзывы в магазинах приложений— заявки, отправленные через формы обратной связи
Артефакты на выходе: — лист верифицированных дефектов для включения в состав будущих релизов— лист часто повторяющихся пожеланий от конечных пользователей
Участники: — инженеры поддержки
Управление ценностью для бизнеса Самый важный процесс с точки зрения развития продукта. Его целью является планирование изменений продукта для достижения заданных бизнесом ключевых показателей.
Думаю, более половины всех мобильных бизнес-приложений вообще не отслеживают никаких метрик. В лучшем случае наблюдают за количеством пользователей в Google Analytics. Решения об изменении дизайна и функционала продукта в таких ситуациях принимаются по наитию и ничем не аргументированы. Между тем, для постоянного улучшения качества продукта жизненно необходим подсчет и анализ ключевых метрик, синхронизированных с целями бизнеса.
В основе процесса лежит сбор и анализ метрик на каждом из этапов воронки конверсии. В рамках процесса мы проводим следующие мероприятия:
настройку систем трекинга и аналитики
проектирование воронок внутри приложения для оценки достижения конкретных бизнес-целей
визуализацию динамики изменения метрик
консалтинг в области аналитики (что хорошо, а что плохо для бизнеса с точки зрения метрик, а не гадания)
мероприятия по улучшению метрик
предоставление аналитики по прямым конкурентам
Основные инструменты: — AppsFlyer— Flurry— Google Analytics— AppAnnie— AppInTop
Артефакты на входе: — метрики на каждом из этапов воронки конверсии
Артефакты на выходе: — обновленный Road Map продукта
Участники: — бизнес-аналитики— владельцы продукта со стороны заказчика
Управление предоставлением услуг Целью данного процесса является контроль соответствия подписанному SLA и улучшение качества услуг поддержки.
Service Level Agreement или SLA (соглашение об уровне сервиса) — это документ, описывающий услуги, предоставляемые в рамках поддержки, порядок предоставления этих услуг, а также измеримые показатели качества, такие как:
время реакции на заявку
время решения инцидентов и дефектов в зависимости от степени их критичности и влияния на бизнес-процессы
Подробнее об SLA можно прочитать в cтатье «SLA для начинающих».
Сейчас мы предлагаем на выбор два варианта соглашения: базовый и расширенный, отличающиеся временем реакции на заявки и решения проблем, а также количеством каналов, которые мы отслеживаем для оценки работоспособности приложения.
На выходе процесс генерирует отчетность, которая дает представление о качестве поддержки и общем состоянии продукта всем заинтересованным сторонам. В ходе экспериментов с отчетностью мы остановились на следующих форматах:
Ежедневный отчет, информирующий релиз-менеджера о возникших критичных проблемах, либо о просроченных задачах, выходящих за рамки SLA, — своего рода сирена, включающаяся, когда что-то серьезно идет не так. Ежедневные отчеты учитывают в том числе и всплески негативных отзывов в магазинах приложений, что особенно актуально в первые дни после выхода обновления.
Еженедельный отчет представляет собой монитор обратной связи, полученной по всем отслеживаемым нами каналам. Отчет состоит из трех частей:
Статистика тикетов в Zendesk по каждому из типов заявок:
Статистика по сбоям в Crashlytics, которая дает представление о стабильности релиза. При каждом сбое генерируется сообщение о возникшей ошибке, которое при превышении определенного уровня критичности автоматически попадает в наш баг-трекер.
Статистика по отзывам в магазинах приложений, учитывающая изменение рейтинга за неделю, общее число отзывов и число заведенных дефектов. Помимо количественных показателей инженер поддержки в свободной форме дает качественную характеристику отзывам, акцентируя внимание на явных проблемах и частых просьбах пользователей.
Ежемесячный отчет содержит информацию о количестве потраченных часов каждого из специалистов для бюджетирования и учета затрат на поддержку, а также процент соблюдения SLA, который позволяет выявить систематические нарушения и принимать управленческие решения. Отчет предназначен для руководителей проектного офиса и департамента поддержки и развития.
Основные инструменты: — Zendesk— Jira Артефакты на входе: — статистика заявок и сообщений по каждому каналу мониторинга— план выпуска патчей (обновлений, устраняющих критичные дефекты) и релизов
Артефакты на выходе: — ежедневные, еженедельные и ежемесячные отчеты о поддержке
Участники: — инженеры поддержки
Выводы Всеми силами убеждайте заказчика в правильности работы короткими итерациями. Дарите ему книги Getting Real и Rework. Приводите в пример успешные продукты, в основе работы над которыми лежит модель непрерывного улучшения. Доказывайте, что только этот подход обеспечит максимально возможное удовлетворение бизнес-потребностей и потребностей их клиентов.
Выстраивайте систему поддержки ваших продуктов. Без нее вы не сможете работать с более-менее крупным заказчиком. Если у вас нет SLA, скорее всего, вы даже не будете допущены к тендеру.
Полный текст статьи читайте на CMS Magazine
