Cách chúng tôi tìm ra cách thú vị để kết nối doanh nghiệp và DevOps

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

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

Cách chúng tôi tìm ra cách thú vị để kết nối doanh nghiệp và DevOps

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

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

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

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

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

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

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

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

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

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

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

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

Làm việc với phân tích

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

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

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

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

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

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

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

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

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

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

Nguồn: www.habr.com

Thêm một lời nhận xét