Філософією DevOps, коли технологія з'єднується з обслуговуванням ПЗ, вже нікого не здивуєш. Набирає сили новий тренд - DevOps 2.0 або BizDevOps. У ньому в єдине ціле зливаються вже три компоненти: бізнес, розробка та підтримка. І як у DevOps'e інженерні практики лягають в основу зв'язку розробки та підтримки, так і в біздевопсі аналітика бере на себе роль «клею», що поєднує розробку з бізнесом.
Хочу відразу зізнатися: про те, що у нас вийшов справжнісінький біздевопс, ми дізналися тільки зараз, почитавши розумні книги. Воно якось саме склалося завдяки ініціативі співробітників та невгамовній пристрасті до покращень. Зараз аналітика - це частина виробничого процесу розробки, що значно скорочує петлі зворотного зв'язку і регулярно забезпечує інсайтами. Розповім докладно, як у нас все влаштовано.
Недоліки класичного DevOps
Коли замислюються нові клієнтські продукти, бізнес створює ідеальну модель поведінки клієнтів та розраховує на хорошу конверсію, на базі чого будує свої бізнес-мети та результати. Команда розробників зі свого боку прагне зробити дуже добрий, якісний код. Підтримка сподівається на повну автоматизацію процесів, на легкість і зручність супроводу нового продукту.
Реальність найчастіше складається таким чином, що клієнти отримують досить складний процес, бізнес упирається в низьку конверсію, команди розробки випускають фікс за фіксом, а підтримка тоне у потоці звернень від клієнтів. Знайомо?
Корінь зла тут криється в довгій і неякісній петлі зворотного зв'язку, закладеного в процес. Бізнес та розробники при збиранні вимог та отриманні зворотного зв'язку під час спринтів спілкуються з обмеженою кількістю клієнтів, які сильно впливають на долю продукту. Часто те, що є важливим для одного, зовсім не притаманно всій цільовій аудиторії.
Розуміння того, чи в правильному напрямку йде розвиток продукту, приходить разом із фінансовими звітами та результатами маркетингових досліджень через місяці після запуску. Та й вони через обмеженість вибірки не дозволяють перевірки гіпотез на великому обсязі клієнтів. Загалом, виходить довго, неточно та неефективно.
Трофейний інструмент
Ми знайшли хороший спосіб уникнути цього. Інструмент, який раніше допомагав лише маркетологам, у нас потрапив до рук бізнесу та розробників. Ми почали активно використовувати web-аналітику для того, щоб дивитися на процес у реальному часі, тут і зараз розуміти, що відбувається. На основі цього планувати сам продукт, його розкочування на великий обсяг клієнтів.
Якщо планується якесь покращення продукту, можна відразу подивитися, з якими метриками воно пов'язане, і як ці метрики впливають на продаж, на важливі для бізнесу характеристики. Так можна відразу відсіяти гіпотези з низьким ефектом. Або, наприклад, викотити нову фічу на статистично значну кількість користувачів і в режимі реального часу стежити за метриками, зрозуміти, чи все працює, як замислювалося. Не чекати зворотного зв'язку у вигляді звернень чи звітів, а одразу самим відстежувати та оперативно коригувати процес створення продукту. Ми можемо викотити нову фічу, через три дні вже зібрати статистично вірні дані, зробити зміни ще за три дні — і за тиждень готовий чудовий новий продукт.
Можна відстежити всю вирву, всіх клієнтів, які увійшли в контакт з новим продуктом, виявити точки, в яких вирва різко звужувалась, і розібратися в причинах. І розробники, і бізнес тепер стежать за цим, це є частиною щоденної роботи. Вони бачать один і той же клієнтський шлях, і разом можуть генерувати ідеї та гіпотези щодо покращення.
Така інтеграція бізнесу та розробки разом з аналітикою дає можливість створювати продукти безперервно, постійно оптимізувати, шукати та бачити вузькі місця, весь процес загалом.
Вся справа у складності
Коли ми створюємо новий продукт, то починаємо не з чистого аркуша, а вбудовуємо його в існуюче поєднання сервісів. Приміряючись до нового продукту, клієнт найчастіше контактує з кількома підрозділами. Він може поспілкуватися зі співробітниками контакт-центру, з менеджерами в офісі, може звернутися на підтримку, онлайн-чати. За допомогою метрик ми можемо побачити, наприклад, яке навантаження на контакт-центр, як краще обробляти вхідні запити. Ми можемо зрозуміти, скільки людей доходить до офісу і підказати, як далі консультувати клієнта.
З інформаційними системами все так само. Наш банк існує вже понад 20 років, за цей час створено і досі функціонує великий пласт різноманітних систем. Взаємодія між бекенд-системами іноді буває непередбачуваною. Наприклад, у якійсь давній системі за певним полем є обмеження за кількістю символів, і іноді це фарбує новий сервіс. Відстежити баг стандартними методами досить складно, а з допомогою web-аналітики — просто.
У нас дійшло до того, що ми стали з усіх задіяних систем забирати та аналізувати тексти помилок, які показують клієнту. Виявилося, що багато з них застаріли, а ми навіть уявити не могли, що вони якось беруть участь у нашому процесі.
Робота з аналітикою
У нас web-аналітики та SCRUM-команди розробників знаходяться в одному приміщенні. Вони постійно взаємодіють один з одним. Коли потрібно, фахівці допомагають налаштувати метрики або вивантажити дані, здебільшого самі члени команд працюють із сервісом аналітики, там нічого складного.
Допомога потрібна, якщо, наприклад, потрібні якісь залежності, додаткові фільтри обмеженого типу клієнтів чи джерел. Але в поточній архітектурі ми рідко зіштовхуємося.
Цікаво, що впровадження аналітики не вимагало встановлення нової IT-системи. Ми використовуємо те саме ПЗ, з яким раніше працювали маркетологи. Потрібно було лише узгодити його використання та впровадити його у бізнесі та розробці. Звичайно, ми не могли просто взяти те, що є у маркетингу, довелося все переналаштувати заново і вже маркетингу дати доступ до нового середовища, щоб вони були з нами в одному інформаційному полі.
У майбутньому ми плануємо купити покращену версію ПЗ для веб-аналітики, яке дозволить справлятися з зростаючими обсягами сесій, що обробляються.
Також у нас активно триває процес інтеграції web-аналітики та внутрішніх баз даних із CRM, облікових систем. Об'єднавши дані, ми отримуємо повне уявлення про клієнта у всіх необхідних розрізах: за джерелами, типами клієнтів, товарами. BI-сервіси, що допомагають візуалізувати дані, незабаром стануть доступні всім підрозділам.
Що в нас у результаті вийшло? Фактично ми зробили аналітику та прийняття рішень щодо неї частиною виробничого процесу, що й дало видимий ефект.
Аналітика: не наступайте на граблі
Ну і насамкінець хочу поділитися порадами, які допоможуть вам уникнути набивання шишок у процесі вибудовування биздевопса.
- Якщо аналітику не вдається зробити швидко, то ви робите не ту аналітику. Потрібно йти простим шляхом від одного продукту, а далі масштабувати.
- У вас обов'язково має бути команда чи людина, яка добре розуміє майбутню архітектуру аналітики. Треба ще на березі визначитися, як ви масштабуватимете аналітику, інтегруватимете її в інші системи, перевикористовуватимете дані.
- Не генеруйте зайві дані. Web-статистика - це крім корисної інформації ще й величезний смітник з неякісними та зайвими даними. І це сміття заважатиме при прийнятті рішень та оцінці, якщо немає чітких цілей.
- Не робіть аналітику заради аналітики. Спочатку цілі, вибір інструменту, і лише потім — аналітика лише там, де це дасть ефект.
Матеріал підготовлений спільно з Чоботар Ольгою ().
Джерело: habr.com