Философией DevOps, когда разработка соединяется с обслуживанием ПО, уже никого не удивишь. Набирает силу новый тренд — DevOps 2.0 или BizDevOps. В нем в единое целое сливаются уже три компонента: бизнес, разработка и поддержка. И как в DevOps’e инженерные практики ложатся в основу связи разработки и поддержки, так и в биздевопсе аналитика берет на себя роль «клея», объединяющего разработку с бизнесом.
Хочу сразу признаться: о том, что у нас получился самый настоящий биздевопс, мы узнали только сейчас, почитав умные книги. Оно как-то само сложилось благодаря инициативе сотрудников и неуемной страсти к улучшениям. Сейчас аналитика — это часть производственного процесса разработки, значительно сокращающая петли обратной связи и регулярно снабжающая инсайтами. Расскажу подробно, как у нас все устроено.
Когда задумываются новые клиентские продукты, бизнес создает идеальную модель поведения клиентов и рассчитывает на хорошую конверсию, на базе чего строит свои бизнес-цели и результаты. Команда разработчиков со своей стороны стремится сделать очень хороший, качественный код. Поддержка же надеется на полную автоматизацию процессов, на легкость и удобство сопровождения нового продукта.
Реальность чаще всего складывается таким образом, что клиенты получают довольно сложный процесс, бизнес упирается в низкую конверсию, команды разработки выпускают фикс за фиксом, а поддержка тонет в потоке обращений от клиентов. Знакомо?
Корень зла тут кроется в длинной и некачественной петле обратной связи, заложенной в процесс. Бизнес и разработчики при сборе требований и получении обратной связи во время спринтов общаются с ограниченным количеством клиентов, которые сильно влияют на судьбу продукта. Часто то, что является важным для одного, совсем не характерно для всей целевой аудитории.
Понимание того, в правильном ли направлении идет развитие продукта, приходит вместе с финансовыми отчетами и результатами маркетинговых исследований через месяцы после запуска. Да и они из-за ограниченности выборки не дают возможности проверки гипотез на большом объеме клиентов. В общем, получается долго, неточно и неэффективно.
Мы нашли хороший способ уйти от этого. Инструмент, который раньше помогал только маркетологам, у нас попал в руки бизнесу и разработчикам. Мы начали активно использовать web-аналитику для того, чтобы смотреть на процесс в реальном времени, здесь и сейчас понимать, что происходит. На основе этого планировать сам продукт, его раскатку на большой объем клиентов.
Если планируется какое-то улучшение продукта, можно сразу посмотреть, с какими метриками оно связано, и как эти метрики влияют на продажи, на важные для бизнеса характеристики. Так можно сразу отсеять гипотезы с низким эффектом. Или, например, выкатить новую фичу на статистически значимое число пользователей и в режиме реального времени последить за метриками, понять, все ли работает, как задумывалось. Не ждать обратной связи в виде обращений или отчетов, а тут же самим отслеживать и оперативно корректировать процесс создания продукта. Мы можем выкатить новую фичу, через три дня уже собрать статистически верные данные, сделать изменения еще за три дня — и вот за неделю готов отличный новый продукт.
Можно отследить всю воронку, всех клиентов, которые вошли в контакт с новым продуктом, обнаружить точки, в которых воронка резко сужалась, и разобраться в причинах. И разработчики, и бизнес теперь следят за этим, это часть ежедневной работы. Они видят один и тот же клиентский путь, и вместе могут генерировать идеи и гипотезы по улучшению.
Такая интеграция бизнеса и разработки вместе с аналитикой дает возможность создавать продукты непрерывно, постоянно оптимизировать, искать и видеть узкие места, весь процесс в целом.
Когда мы создаем новый продукт, то начинаем не с чистого листа, а встраиваем его в уже существующее хитросплетение сервисов. Примериваясь к новому продукту, клиент чаще всего контактирует с несколькими подразделениями. Он может пообщаться с сотрудниками контакт-центра, с менеджерами в офисе, может обратиться в поддержку, в онлайн-чаты. С помощью метрик мы можем увидеть, например, какая нагрузка на контакт-центре, как лучше обрабатывать входящие запросы. Мы можем понять, сколько людей доходит до офиса, и подсказать, как дальше консультировать клиента.
С информационными системами все точно так же. Наш банк существует уже более 20 лет, за это время создан и до сих пор функционирует большой пласт разнородных систем. Взаимодействие между бэкенд-системами бывает иногда непредсказуемым. Например, в какой-то древней системе по определенному полю есть ограничения по количеству символов, и иногда это крашит новый сервис. Отследить баг стандартными способами довольно тяжело, а с помощью web-аналитики — элементарно.
У нас дошло до того, что мы стали из всех задействованных систем забирать и анализировать тексты ошибок, которые показываются клиенту. Оказалось, что многие из них устарели, а мы даже представить себе не могли, что они как-то участвуют в нашем процессе.
У нас web-аналитики и SCRUM-команды разработчиков находятся в одном помещении. Они постоянно взаимодействуют друг с другом. Когда нужно, специалисты помогают настроить метрики или выгрузить данные, в основном же сами члены команд работают с сервисом аналитики, там ничего сложного.
Помощь требуется, если, к примеру, нужны какие-то зависимости, дополнительные фильтры по ограниченному типу клиентов или источников. Но в текущей архитектуре мы редко с этим сталкиваемся.
Интересно, что внедрение аналитики не потребовало установки новой IT-системы. Мы используем то же самое ПО, с которым ранее работали маркетологи. Нужно было только согласовать его использование и внедрить его в бизнесе и разработке. Конечно, мы не могли просто взять то, что есть у маркетинга, пришлось все перенастроить заново и уже маркетингу дать доступ в новую среду, чтобы они были с нами в одном информационном поле.
В будущем мы планируем купить улучшенную версию ПО для веб-аналитики, которое позволит справляться с возрастающими объемами обрабатываемых сессий.
Также у нас активно идет процесс интеграции web-аналитики и внутренних баз данных из CRM, учетных систем. Объединив данные, мы получаем полное представление о клиенте во всех нужных разрезах: по источникам, типам клиентов, продуктам. BI-сервисы, помогающие визуализировать данные, скоро станут доступны всем подразделениям.
Что у нас в итоге получилось? Фактически мы сделали аналитику и принятие решений по ней частью производственного процесса, что и дало видимый эффект.
Ну и напоследок хочу поделиться советами, которые помогут вам избежать набития шишек в процессе выстраивания биздевопса.
Материал подготовлен совместно с Чеботарь Ольгой (olga_cebotari).
Хочу сразу признаться: о том, что у нас получился самый настоящий биздевопс, мы узнали только сейчас, почитав умные книги. Оно как-то само сложилось благодаря инициативе сотрудников и неуемной страсти к улучшениям. Сейчас аналитика — это часть производственного процесса разработки, значительно сокращающая петли обратной связи и регулярно снабжающая инсайтами. Расскажу подробно, как у нас все устроено.
Недостатки классического DevOps
Когда задумываются новые клиентские продукты, бизнес создает идеальную модель поведения клиентов и рассчитывает на хорошую конверсию, на базе чего строит свои бизнес-цели и результаты. Команда разработчиков со своей стороны стремится сделать очень хороший, качественный код. Поддержка же надеется на полную автоматизацию процессов, на легкость и удобство сопровождения нового продукта.
Реальность чаще всего складывается таким образом, что клиенты получают довольно сложный процесс, бизнес упирается в низкую конверсию, команды разработки выпускают фикс за фиксом, а поддержка тонет в потоке обращений от клиентов. Знакомо?
Корень зла тут кроется в длинной и некачественной петле обратной связи, заложенной в процесс. Бизнес и разработчики при сборе требований и получении обратной связи во время спринтов общаются с ограниченным количеством клиентов, которые сильно влияют на судьбу продукта. Часто то, что является важным для одного, совсем не характерно для всей целевой аудитории.
Понимание того, в правильном ли направлении идет развитие продукта, приходит вместе с финансовыми отчетами и результатами маркетинговых исследований через месяцы после запуска. Да и они из-за ограниченности выборки не дают возможности проверки гипотез на большом объеме клиентов. В общем, получается долго, неточно и неэффективно.
Трофейный инструмент
Мы нашли хороший способ уйти от этого. Инструмент, который раньше помогал только маркетологам, у нас попал в руки бизнесу и разработчикам. Мы начали активно использовать web-аналитику для того, чтобы смотреть на процесс в реальном времени, здесь и сейчас понимать, что происходит. На основе этого планировать сам продукт, его раскатку на большой объем клиентов.
Если планируется какое-то улучшение продукта, можно сразу посмотреть, с какими метриками оно связано, и как эти метрики влияют на продажи, на важные для бизнеса характеристики. Так можно сразу отсеять гипотезы с низким эффектом. Или, например, выкатить новую фичу на статистически значимое число пользователей и в режиме реального времени последить за метриками, понять, все ли работает, как задумывалось. Не ждать обратной связи в виде обращений или отчетов, а тут же самим отслеживать и оперативно корректировать процесс создания продукта. Мы можем выкатить новую фичу, через три дня уже собрать статистически верные данные, сделать изменения еще за три дня — и вот за неделю готов отличный новый продукт.
Можно отследить всю воронку, всех клиентов, которые вошли в контакт с новым продуктом, обнаружить точки, в которых воронка резко сужалась, и разобраться в причинах. И разработчики, и бизнес теперь следят за этим, это часть ежедневной работы. Они видят один и тот же клиентский путь, и вместе могут генерировать идеи и гипотезы по улучшению.
Такая интеграция бизнеса и разработки вместе с аналитикой дает возможность создавать продукты непрерывно, постоянно оптимизировать, искать и видеть узкие места, весь процесс в целом.
Все дело в сложности
Когда мы создаем новый продукт, то начинаем не с чистого листа, а встраиваем его в уже существующее хитросплетение сервисов. Примериваясь к новому продукту, клиент чаще всего контактирует с несколькими подразделениями. Он может пообщаться с сотрудниками контакт-центра, с менеджерами в офисе, может обратиться в поддержку, в онлайн-чаты. С помощью метрик мы можем увидеть, например, какая нагрузка на контакт-центре, как лучше обрабатывать входящие запросы. Мы можем понять, сколько людей доходит до офиса, и подсказать, как дальше консультировать клиента.
С информационными системами все точно так же. Наш банк существует уже более 20 лет, за это время создан и до сих пор функционирует большой пласт разнородных систем. Взаимодействие между бэкенд-системами бывает иногда непредсказуемым. Например, в какой-то древней системе по определенному полю есть ограничения по количеству символов, и иногда это крашит новый сервис. Отследить баг стандартными способами довольно тяжело, а с помощью web-аналитики — элементарно.
У нас дошло до того, что мы стали из всех задействованных систем забирать и анализировать тексты ошибок, которые показываются клиенту. Оказалось, что многие из них устарели, а мы даже представить себе не могли, что они как-то участвуют в нашем процессе.
Работа с аналитикой
У нас web-аналитики и SCRUM-команды разработчиков находятся в одном помещении. Они постоянно взаимодействуют друг с другом. Когда нужно, специалисты помогают настроить метрики или выгрузить данные, в основном же сами члены команд работают с сервисом аналитики, там ничего сложного.
Помощь требуется, если, к примеру, нужны какие-то зависимости, дополнительные фильтры по ограниченному типу клиентов или источников. Но в текущей архитектуре мы редко с этим сталкиваемся.
Интересно, что внедрение аналитики не потребовало установки новой IT-системы. Мы используем то же самое ПО, с которым ранее работали маркетологи. Нужно было только согласовать его использование и внедрить его в бизнесе и разработке. Конечно, мы не могли просто взять то, что есть у маркетинга, пришлось все перенастроить заново и уже маркетингу дать доступ в новую среду, чтобы они были с нами в одном информационном поле.
В будущем мы планируем купить улучшенную версию ПО для веб-аналитики, которое позволит справляться с возрастающими объемами обрабатываемых сессий.
Также у нас активно идет процесс интеграции web-аналитики и внутренних баз данных из CRM, учетных систем. Объединив данные, мы получаем полное представление о клиенте во всех нужных разрезах: по источникам, типам клиентов, продуктам. BI-сервисы, помогающие визуализировать данные, скоро станут доступны всем подразделениям.
Что у нас в итоге получилось? Фактически мы сделали аналитику и принятие решений по ней частью производственного процесса, что и дало видимый эффект.
Аналитика: не наступайте на грабли
Ну и напоследок хочу поделиться советами, которые помогут вам избежать набития шишек в процессе выстраивания биздевопса.
- Если аналитику не получается сделать быстро, значит, вы делаете не ту аналитику. Нужно идти по простому пути от одного продукта, а дальше масштабировать.
- У вас обязательно должна быть команда или человек, который хорошо понимает будущую архитектуру аналитики. Надо еще на берегу определиться, как вы будете масштабировать аналитику, интегрировать ее в другие системы, переиспользовать данные.
- Не генерируйте лишние данные. Web-статистика — это помимо полезной информации еще и огромная помойка с некачественными и лишними данными. И этот мусор будет мешать при принятии решений и оценке, если нет четких целей.
- Не делайте аналитику ради аналитики. Сначала цели, выбор инструмента, и лишь потом — аналитика только там, где это даст эффект.
Материал подготовлен совместно с Чеботарь Ольгой (olga_cebotari).
Комментарии (5)
JerleShannara
13.06.2019 17:27Несколько не в тему: у вас на КДПВ изображен узел «Подарок Инструктору», он при приложении нагрузки тупо развязывается. Если идея КДПВ была не в «уничтожении узлов», то лучше будет заменить его на прямой (там концы верёвок выходят не крест на крест, а по прямому). Как человеку, знакомому с промальпом эта картинка несколько режет глаз.
apilichev
BizDevOps. Звучит. Надо взять на заметку.
fessmage
Уже даже BizDevSecOps получается, если всё сложить. Что дальше?
FinOps тут еще в соседней статье недавно придумали, правда в виде должности, а не концепции.