Модель постоянного улучшения и поддержки мобильных приложений
Долгий цикл производства (time to market) в сфере мобильных технологий, где постоянно появляются новые устройства и часто обновляются операционные системы совершенно не применим. Поэтому стратегия выхода на рынок с простым продуктом и минимальным функционалом хорошо себя показала на рынке приложений. Разработка приложений должна идти в формате постоянного улучшения продукта короткими, не более месяца, итерациями. В течении жизненного цикла продукта важно постоянно получать обратную связь от пользователей, постепенно добавляя функционал и вовремя вылавливая баги.
Поддержка мобильных приложений
Основные задачи после публикации приложения:
- мониторинг работоспособности приложения;
- обработка обратной связи пользователей и оказание помощи при работе с приложением;
- повышение стабильности работы приложения;
- добавление нового функционала;
- адаптация приложения под новые устройства и версии ОС;
- корректировка плана развития продукта.
Схема работы и процессы поддержки и развития ITIL
Деятельность по поддержке и развитию продуктов мы ведем в соответствии с методологией ITIL в рамках шести основных процессов:
- Управление инцидентами и проблемами
- Управление изменениями
- Управление релизами
- Управление предоставлением услуг
- Управление аудиторией
- Управление ценностью для бизнеса
Управление выходом обновлений
Формально результатом работы является выпуск нового релиза, поэтому процесс управления релизами можно считать центральным в этой схеме. Он состоит из следующих последовательных этапов:
- планирование релиза
- построение релиза
- выпуск релиза
Состав будущего релиза формируется из:
- ошибок, выявленных в при эксплуатации
- нового функционала, который не вошел в предыдущие обновления или появился при формулировании новых требований
Работа по построению релиза идет в соответствии с методологией 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. Ежедневные отчеты учитывают всплески негативных отзывов в магазинах приложений, что особенно актуально в первые дни после выхода обновления.
Еженедельный отчет представляет собой монитор обратной связи, полученной по всем отслеживаемым нами каналам. Отчет состоит из трех частей:
- Статистика тикетов в системе поддержки пользователей
- Статистика по сбоям в Crashlytics, которая дает представление о стабильности релиза.
- Статистика по отзывам в магазинах приложений, учитывающая изменение рейтинга за неделю, общее число отзывов и число заведенных дефектов.
Ежемесячный отчет содержит информацию о количестве потраченных часов каждого из специалистов для бюджетирования и учета затрат на поддержку и процент соблюдения SLA, который позволяет выявить систематические нарушения и принимать управленческие решения. Отчет предназначен для руководителей проектного офиса и департамента поддержки и развития.
Основные инструменты:
- Zendesk
- Jira
Документы на входе:
- статистика заявок и сообщений по каждому каналу мониторинга
- план выпуска патчей
Документы на выходе:
- ежедневные, еженедельные и ежемесячные отчеты о поддержке
Участники:
- инженеры поддержки
Резюме
Убеждайте заказчиков в правильности работы короткими итерациями, приводя в пример успешные продукты, в основе работы над которыми лежит модель непрерывного улучшения. В итоге этот подход обеспечит максимально возможное удовлетворение бизнес-потребностей и потребностей их клиентов. Выстраивайте систему поддержки ваших продуктов.