- PVSM.RU - https://www.pvsm.ru -
Основная специализация нашей компании — сервисные приложения для самообслуживания клиентов финансовых, страховых и телекоммуникационных компаний. И тут есть некоторая специфика. С одной стороны, эти компании имеют свои департаменты обслуживания клиентов, которые принимают на себя первую волну вопросов и жалоб пользователей. С другой — поддержка таких приложений требует повышенного уровня предоставления услуг, который привязан к уровню сервиса компании-заказчика.
Директор департамента поддержки и развития мобильных приложений Redmadrobot Александр Алехин (alekhinsasha [1]) делится опытом организации процессов.
Долгий цикл производства (time to market) — зло, тем более в сфере мобильных технологий, где операционные системы обновляются каждый год, а новые устройства появляются раз в два-три месяца. Поэтому не нужно бояться выходить в стор с простым продуктом с минимумом функционала. Работа над приложениями должна идти в формате непрерывного улучшения короткими итерациями (не более месяца на обновления) и с хорошо налаженной обратной связью. Другими словами, навороченным приложение должно становиться постепенно.
Основными задачами, решаемыми после публикации приложения являются:
И вот, как мы решаем эти задачи в Redmadrobot.
Всю деятельность по поддержке и развитию продуктов мы ведем в соответствии с методологией ITIL в рамках шести основных процессов:
Формально результатом нашей работы является выпуск нового релиза, поэтому процесс управления релизами можно считать центральным в общей схеме. Он состоит из следующих последовательных этапов:
Состав будущего релиза формируется из:
Таким образом «топливо» для работы над релизами, как показано на схеме, поставляют процесс управления инцидентами и проблемами и процесс управления изменениями.
Работа по построению релиза идет в соответствии с методологией Agile, и его состав упаковывается в один или несколько спринтов. В качестве трекера задач используется Jira, в которой мы настроили отдельный Workflow и набор Agile-досок.
По теме работы с Agile Board в Jira рекомендую подробную статью от ребят из Яндекс.Картинок: «Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли». [2]
Качество релиза оценивается по отзывам пользователей, а также по отклонению количества сообщений о сбоях от фонового уровня.
Основные инструменты:
— Jira
Артефакты на входе:
— лист дефектов
— лист новой функциональности (Request for Change или RFC)
Артефакты на выходе:
— сборка (Release Candidate)
— отчет о выходном тестировании: регрессионном, интеграционном, новой функциональности
— лист открытых некритичных дефектов: отдельно на стороне клиента и на стороне сервера
— заключение QA-менеджера о готовности релиза к публикации
Участники процесса:
— релиз-менеджер
— мобильные и серверные разработчики
— тестировщики
Целью данного процесса является своевременное решение обнаруженных в ходе эксплуатации приложения проблем.
Согласно определению:
Инцидент — любое событие, не являющееся частью стандартного (штатного) сценария использования, которое привело к частичной или полной невозможности использования приложения.
Проблема — неизвестная причина одного или более инцидентов.
Работа в данном процессе построена по классической трехуровневой схеме:
Первый уровень
Оперативная служба — единая точка входа обращений. Осуществляет регистрацию и классификацию заявок, определение их приоритета и ответственных за исполнение, отвечает за решение типовых инцидентов.
Как я упоминал в начале, этот уровень поддержки отдается в руки департамента обслуживания клиентов на стороне заказчика. Мы лишь снабжаем специалистов оперативной службы необходимыми документами и инструкциями и помогаем выстроить процесс взаимодействия со вторым уровнем.
Второй уровень
Инженеры поддержки — проводят техническую экспертизу и решают нетиповые инциденты, отвечают за обновление базы знаний о приложении, выявляют дефекты и передают их на третий уровень поддержки. На этом же уровне производится администрирование межплатформенного ПО (middleware), если оно используется.
Решение проблем передается на третий уровень, если причина связана с архитектурой продукта или его программной реализацией.
Третий уровень
Разработчики и тестировщики — осуществляют анализ сложных инцидентов, не решенных на втором уровне, исправляют дефекты, тестируют предоставленные решения.
Информацию об инцидентах и проблемах мы получаем по трем каналам:
Основные инструменты:
— Zendesk
— Crashlytics и Google Analytics
— Jira
Артефакты на входе:
— заявки от первого уровня поддержки
— автоматические сообщения о сбоях
Артефакты на выходе:
— лист верифицированных дефектов для включения в состав будущих релизов
Участники процесса:
— инженеры поддержки
— тестировщики
— мобильные и серверные разработчики
— релиз-менеджер
Цель процесса — оценка стоимости внесения изменений, а также их влияния на продукт.
В рамках процесса происходит прием RFC, детализация требований, оценка степени воздействия изменений, затрат и рисков, связанных с их реализацией.
Все запросы попадают в трекер, где после анализа реализации в зависимости от степени критичности для бизнеса попадают либо в бэклог продукта, либо сразу в спринт следующего релиза.
Основные инструменты:
— Jira
Артефакты на входе:
— RFC
Артефакты на выходе:
— обновленный план развития продукта (Road Map)
— лист новой функциональности для планирования будущих релизов
Участники процесса:
— владелец продукта со стороны заказчика
— системный аналитик
— релиз-менеджер
В рамках данного процесса мы напрямую взаимодействуем с конечными пользователями приложения:
Короче говоря, ведем диалог с пользователями, давая понять, что нам важно их мнение о продукте.
Очевидно, что с негативными отзывами в магазинах приложений работать практически невозможно. Они эмоциональны, неинформативны, к тому же отсутствует обратная связь. Поэтому мы мотивируем пользователей сообщать о проблемах в службу поддержки через форму обратной связи. Ее можно найти на стандартном для наших проектов экране «О приложении» или открыть в момент оценки в случае, если пользователь хочет влепить двойку или единицу.
Помимо сохранения рейтинга форма обратной связи позволяет собрать необходимую для анализа информацию: тип устройства, версию ОС, информацию об аккаунте и контексте.
Выбор правильного момента для показа диалога оценки, а также трюк с перенаправлением негативных эмоций хорошо описаны в статье «Prompting for App Reviews» [3] (перевод [4] от 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 для начинающих». [5]
Сейчас мы предлагаем на выбор два варианта соглашения: базовый и расширенный, отличающиеся временем реакции на заявки и решения проблем, а также количеством каналов, которые мы отслеживаем для оценки работоспособности приложения.
На выходе процесс генерирует отчетность, которая дает представление о качестве поддержки и общем состоянии продукта всем заинтересованным сторонам. В ходе экспериментов с отчетностью мы остановились на следующих форматах:
Ежедневный отчет, информирующий релиз-менеджера о возникших критичных проблемах, либо о просроченных задачах, выходящих за рамки SLA, — своего рода сирена, включающаяся, когда что-то серьезно идет не так. Ежедневные отчеты учитывают в том числе и всплески негативных отзывов в магазинах приложений, что особенно актуально в первые дни после выхода обновления.
Еженедельный отчет представляет собой монитор обратной связи, полученной по всем отслеживаемым нами каналам. Отчет состоит из трех частей:
Ежемесячный отчет содержит информацию о количестве потраченных часов каждого из специалистов для бюджетирования и учета затрат на поддержку, а также процент соблюдения SLA, который позволяет выявить систематические нарушения и принимать управленческие решения. Отчет предназначен для руководителей проектного офиса и департамента поддержки и развития.
Основные инструменты:
— Zendesk
— Jira
Артефакты на входе:
— статистика заявок и сообщений по каждому каналу мониторинга
— план выпуска патчей (обновлений, устраняющих критичные дефекты) и релизов
Артефакты на выходе:
— ежедневные, еженедельные и ежемесячные отчеты о поддержке
Участники:
— инженеры поддержки
Автор: redmadrobot
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/77200
Ссылки в тексте:
[1] alekhinsasha: http://habrahabr.ru/users/alekhinsasha/
[2] «Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли».: http://habrahabr.ru/company/yandex/blog/207316/
[3] «Prompting for App Reviews»: http://dancounsell.com/articles/prompting-for-app-reviews
[4] перевод: http://macilove.com/news/prompting-users-to-write-reviews-about-the-application/
[5] «SLA для начинающих».: http://www.inframanager.ru/survive_guide/sla_for_beginners/
[6] Источник: http://habrahabr.ru/post/245829/
Нажмите здесь для печати.