Как мы нашли крутой способ связать бизнес и DevOps +8



Философией DevOps, когда разработка соединяется с обслуживанием ПО, уже никого не удивишь. Набирает силу новый тренд — DevOps 2.0 или BizDevOps. В нем в единое целое сливаются уже три компонента: бизнес, разработка и поддержка. И как в DevOps’e инженерные практики ложатся в основу связи разработки и поддержки, так и в биздевопсе аналитика берет на себя роль «клея», объединяющего разработку с бизнесом.

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



Недостатки классического DevOps


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

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

Корень зла тут кроется в длинной и некачественной петле обратной связи, заложенной в процесс. Бизнес и разработчики при сборе требований и получении обратной связи во время спринтов общаются с ограниченным количеством клиентов, которые сильно влияют на судьбу продукта. Часто то, что является важным для одного, совсем не характерно для всей целевой аудитории.
Понимание того, в правильном ли направлении идет развитие продукта, приходит вместе с финансовыми отчетами и результатами маркетинговых исследований через месяцы после запуска. Да и они из-за ограниченности выборки не дают возможности проверки гипотез на большом объеме клиентов. В общем, получается долго, неточно и неэффективно.

Трофейный инструмент


Мы нашли хороший способ уйти от этого. Инструмент, который раньше помогал только маркетологам, у нас попал в руки бизнесу и разработчикам. Мы начали активно использовать web-аналитику для того, чтобы смотреть на процесс в реальном времени, здесь и сейчас понимать, что происходит. На основе этого планировать сам продукт, его раскатку на большой объем клиентов.
Если планируется какое-то улучшение продукта, можно сразу посмотреть, с какими метриками оно связано, и как эти метрики влияют на продажи, на важные для бизнеса характеристики. Так можно сразу отсеять гипотезы с низким эффектом. Или, например, выкатить новую фичу на статистически значимое число пользователей и в режиме реального времени последить за метриками, понять, все ли работает, как задумывалось. Не ждать обратной связи в виде обращений или отчетов, а тут же самим отслеживать и оперативно корректировать процесс создания продукта. Мы можем выкатить новую фичу, через три дня уже собрать статистически верные данные, сделать изменения еще за три дня — и вот за неделю готов отличный новый продукт.

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

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

Все дело в сложности


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

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

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

Работа с аналитикой


У нас web-аналитики и SCRUM-команды разработчиков находятся в одном помещении. Они постоянно взаимодействуют друг с другом. Когда нужно, специалисты помогают настроить метрики или выгрузить данные, в основном же сами члены команд работают с сервисом аналитики, там ничего сложного.

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

Интересно, что внедрение аналитики не потребовало установки новой IT-системы. Мы используем то же самое ПО, с которым ранее работали маркетологи. Нужно было только согласовать его использование и внедрить его в бизнесе и разработке. Конечно, мы не могли просто взять то, что есть у маркетинга, пришлось все перенастроить заново и уже маркетингу дать доступ в новую среду, чтобы они были с нами в одном информационном поле.

В будущем мы планируем купить улучшенную версию ПО для веб-аналитики, которое позволит справляться с возрастающими объемами обрабатываемых сессий.

Также у нас активно идет процесс интеграции web-аналитики и внутренних баз данных из CRM, учетных систем. Объединив данные, мы получаем полное представление о клиенте во всех нужных разрезах: по источникам, типам клиентов, продуктам. BI-сервисы, помогающие визуализировать данные, скоро станут доступны всем подразделениям.

Что у нас в итоге получилось? Фактически мы сделали аналитику и принятие решений по ней частью производственного процесса, что и дало видимый эффект.

Аналитика: не наступайте на грабли


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

  1. Если аналитику не получается сделать быстро, значит, вы делаете не ту аналитику. Нужно идти по простому пути от одного продукта, а дальше масштабировать.
  2. У вас обязательно должна быть команда или человек, который хорошо понимает будущую архитектуру аналитики. Надо еще на берегу определиться, как вы будете масштабировать аналитику, интегрировать ее в другие системы, переиспользовать данные.
  3. Не генерируйте лишние данные. Web-статистика — это помимо полезной информации еще и огромная помойка с некачественными и лишними данными. И этот мусор будет мешать при принятии решений и оценке, если нет четких целей.
  4. Не делайте аналитику ради аналитики. Сначала цели, выбор инструмента, и лишь потом — аналитика только там, где это даст эффект.

Материал подготовлен совместно с Чеботарь Ольгой (olga_cebotari).

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (5):

  1. apilichev
    /#20277890

    BizDevOps. Звучит. Надо взять на заметку.

    • fessmage
      /#20279166

      Уже даже BizDevSecOps получается, если всё сложить. Что дальше?
      FinOps тут еще в соседней статье недавно придумали, правда в виде должности, а не концепции.

  2. JerleShannara
    /#20278284

    Несколько не в тему: у вас на КДПВ изображен узел «Подарок Инструктору», он при приложении нагрузки тупо развязывается. Если идея КДПВ была не в «уничтожении узлов», то лучше будет заменить его на прямой (там концы верёвок выходят не крест на крест, а по прямому). Как человеку, знакомому с промальпом эта картинка несколько режет глаз.