Досвід організації підтримки мобільних додатків

    
Ви повинні сказати: «Ми закінчили це. Зроблено! », А потім продовжити рух до наступної мети.
 REWORK
 
Привіт! Мене звуть Олександр Альохін, я відповідаю за підтримку і розвиток проектів у компанії Redmadrobot. Сьогодні я хотів би поділитися досвідом організації процесів підтримки мобільних додатків і розповісти, як це працює у нас.

 
Основна спеціалізація компанії в даний момент — сервісні програми для самообслуговування клієнтів фінансових і телекомунікаційних компаній. Цей факт накладає деяку специфіку. З одного боку ці компанії мають свої департаменти обслуговування клієнтів, які беруть на себе першу хвилю питань і скарг пользоваталей. З іншого боку підтримка таких додатків вимагає підвищеного рівня надання послуг, який прив'язаний до рівня сервісу компанії-замовника.
 
 

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

Неможливо створити хороший продукт з першого разу. Секрет успішних програм не в тому, що їх роблять геніальні розробники, а в тому, що робота над ними йде в форматі безперервного поліпшення і з добре налагодженою зворотним зв'язком.
 
Довгий цикл виробництва (time to market) — зло, тим більше в сфері мобільних технологій, де операційні системи оновлюються щороку, а нові пристрої з'являються раз на два-три місяці. Якщо ви розробляєте першу версію продукту більше півроку, це означає, що він морально застаріє ще до публікації.
 
Кумедний факт. Рік тому ми підписали договір на створення програми, в якому вказали, що мінімальний підтримуваної версією ОС буде iOS 7, до того моменту ще що не вийшла. Нас змусили вставити примітку, що вимога дійсно в разі, якщо нова версія ОС вийде, і станеться це в заплановані Apple терміни. У підсумку Apple вже анонсувала iOS 8, але додаток до цих пір не опублікована.
 
Зараз ми намагаємося донести ці очевидні речі нашим замовникам і працювати за моделлю безперервного поліпшення з короткими итерациями: не більше 3-х місяців на перший реліз і не більше місяця на оновлення. І для того, щоб ця модель працювала, необхідна вибудувана система підтримки та розвитку продукту.
 
Основними завданнями, які розв'язуються після публікації додатку є:
 
     
моніторинг працездатності;
 отримання зворотного зв'язку від кінцевих користувачів продукту і надання допомоги у вирішенні їхніх проблем;
 поліпшення стабільності роботи і додавання нової функціональності;
 адаптація програми під нові пристрої і версії ОС;
 відстеження ступеня задоволення бізнес-потреб компанії-замовника;
 коригування плану розвитку продукту.
 
І ось, як ми вирішуємо ці завдання.
 
 

Схема роботи і процеси підтримки та розвитку

Всю діяльність з підтримки та розвитку продуктів ми ведемо відповідно до методології 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. Рішення про зміну дизайну та функціоналу продукту в таких сітауціі приймаються з натхнення і нічим не агрументіровани. Тим часом для постійного поліпшення якості продукту життєво необхідний підрахунок і аналіз ключових метрик, синхронізованих з цілями бізнесу.
 DMAIC
В основі процесу лежить збір і аналіз метрик на кожному з етапів воронки конверсії. У рамках процесу ми проводимо такі заходи:
 
     
настройку систем трекінгу та аналітики;
 проектування воронок всередині програми для оцінки досягнення конкретних бізнес-цілей;
 візуалізацію динаміки зміни метрик;
 консалтинг в області аналітики (що добре, а що погано для бізнесу з точки зору метрик, а не гадання);
 заходи щодо поліпшення метрик;
 надання аналітики по прямим конкурентам.
 
 
Основные инструменты:
— AppsFlyer;
— Flurry;
— Google Analytics;
— AppAnnie;
— AppInTop.

Артефакты на входе:
— метрики на каждом из этапов воронки конверсии.

Артефакты на выходе:
— обновленный Road Map продукта.

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

 
 
Управління наданням послуг
Метою даного процесу є контроль відповідності з підписаним SLA і поліпшення якості послуг підтримки.
 
 Service Level Agreement або SLA (угода про рівень сервісу) — це документ, що описує послуги, що надаються в рамках підтримки, порядок надання цих послуг, а також вимірні показники якості, такі як:
 
     
час реакції на заявку;
 час вирішення інцидентів і дефектів в залежності від ступеня їх критичності і впливу на бізнес-процеси.
 
 SLA
Детальніше про SLA можна прочитати у cтатті «SLA для початківців».
 
Зараз ми пропонуємо на вибір два варіанти угоди: базовий і розширений, що відрізняються часом реакції на заявки та вирішення проблем, а також кількістю каналів, які ми відстежуємо для оцінки працездатності програми.
 
На виході процес генерує звітність, яка дає уявлення про якість підтримки та загальному стані продукту всім зацікавленим сторонам. У ході експериментів зі звітністю ми зупинилися на наступних форматах:
 
 Щоденний звіт, що інформує реліз-менеджера про виниклі критичних проблемах, або про прострочені завданнях, що виходять за рамки SLA, — свого роду сирена, включающаяся, коли щось серйозно йде не так. Щоденні звіти враховують у тому числі і сплески негативних відгуків в магазинах додатків, що особливо актуально в перші дні після виходу оновлення.
 
 Щотижневий звіт являє собою монітор зворотного зв'язку, отриманої по всіх відслідковується, нами каналам. Звіт складається з трьох частин:
 
     
Статистика тікетів в Zendesk по кожному з типів заявок:
 
     
запити на зміну;
 інциденти;
 дефекти.
 
 Статистика по збоїв у Crashlytics, яка дає уявлення про стабільність релізу. При кожному збої генерується повідомлення про виниклу помилку, яке при прівишенія певного рівня критичності автоматично потрапляє в наш баг-трекер.
 Статистика за відгуками в магазинах додатків, що враховує зміну рейтингу за тиждень, загальне число відгуків і число заведених дефектів. Крім кількісних показників інженер підтримки у вільній формі дає якісну характеристику відгуками, акцентуючи увагу на явні проблеми і частих проханнях користувачів.
 
 Щомісячний звіт містить інформацію про кількість витрачених годин кожного з фахівців для бюджетування та обліку витрат на підтримку, а також відсоток дотримання SLA, який дозволяє виявити систематичні порушення і приймати управлінські рішення. Звіт призначений для керівників проектного офісу та департаменту підтримки та розвитку.
 
 
Основные инструменты:
— Zendesk;
— Jira.

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

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

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

 
 

Висновки

 
     
Всіма силами переконуйте замовника про роботу короткими итерациями. Даруйте йому книги Getting Real і Rework. Приводьте в приклад успішні продукти, в основі роботи над якими лежить модель безперервного поліпшення. Доводьте, що тільки цей підхід забезпечить максимально можливе задоволення бізнес-потреб і потреб їхніх клієнтів.
 Вибудовуйте систему підтримки ваших продуктів. Без неї ви не зможете працювати з більш-менш великим замовником. Якщо у вас немає SLA, швидше за все, ви навіть не будете допущені до тендеру.
 
 
і невеликий рада
Чи не випускайте релізи перед святами і вихідними. Замовнику здається, що відпочинок стане солодше, якщо новий реліз буде опублікований у п'ятницю ввечері. Але по-перше, в цей час апдейт взагалі ніхто не помітить, по-друге, якщо щось піде не так, вам доведеться піднімати на вуха всю команду у вихідні дні, або сумно стежити за стрімким падінням рейтингу в магазині.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.