Модель постоянного улучшения и поддержки мобильных приложений

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

Поддержка мобильных приложений

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

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

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

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

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

Управление выходом обновлений

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

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

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

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

Работа по построению релиза идет в соответствии с методологией Agile, и его состав упаковывается в один или несколько спринтов. В качестве трекера задач используется Jira, в которой мы настроили отдельный Workflow и набор Agile-досок.

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

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

• Jira

Документация на входе:

• лист ошибок
• лист новой функциональности (Request for Change или RFC)

Документы на выходе:

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

Участники процесса:

• релиз-менеджер
• мобильные и серверные разработчики
• тестировщики

 Управление ошибками

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

Первый уровень

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

Второй уровень

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

Третий уровень

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

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

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

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

• Zendesk
• Crashlytics и Google Analytics
• Jira

Документы  на входе:

• заявки от первого уровня поддержки
• автоматические сообщения о сбоях

Документы на выходе:

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

Участники процесса:

• инженеры поддержки
• тестировщики
• мобильные и серверные разработчики
• релиз-менеджер

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

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

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

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

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

• Jira

Документы на входе:

• RFC

Документы на выходе:

• обновленный план развития продукта (дорожная карта)
• лист новой функциональности для планирования будущих релизов

Участники процесса:

• владелец продукта со стороны заказчика
• системный аналитик
• релиз-менеджер

Обратная связь с аудиторией

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

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

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

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

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

• Google Play Developer Console
• iTunes Connect
• Windows Phone Dev Center
• AppAnnie
• формы обратной связи

Документы на входе:

• отзывы в магазинах приложений
• заявки, отправленные через формы обратной связи

Документы на выходе:

• список устраненных дефектов для включения в состав будущих релизов
• список часто повторяющихся пожеланий от пользователей

Участники:

• инженеры поддержки

Управление ценностью для бизнеса

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

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

• настраиваем системы трекинга и аналитики
• проектируем воронки продаж внутри приложения
• визуализируем процесс изменения целевых метрик
• планируем мероприятия по улучшению метрик
• получаем и анализируем информацию по конкурентам

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

• AppsFlyer
• Flurry
• Google Analytics
• AppAnnie
• AppInTop

Документы на входе:

• Цели для каждого из этапов воронки конверсии

Документы на выходе:

• обновление плана развития продукта

Участники:

• бизнес-аналитики
• владельцы продукта со стороны заказчика

Управление качеством предоставления услуг

Целью данного процесса является контроль соответствия подписанному SLA (соглашению об уровне сервиса) и улучшение качества услуг поддержки.

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

• время реакции на заявку
• время решения инцидентов и дефектов в зависимости от степени их критичности и влияния на бизнес-процессы

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

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

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

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

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

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

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

• Zendesk
• Jira

Документы на входе:

• статистика заявок и сообщений по каждому каналу мониторинга
• план выпуска патчей

Документы на выходе:

• ежедневные, еженедельные и ежемесячные отчеты о поддержке

Участники:

• инженеры поддержки

Резюме

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