Машина Голдберга в процессах сопровождения: как мы оптимизировали управление дефектами ведущего банка топ-5 России

Мы MM.SUP – команда сопровождения аналитического CRM компании Glowbyte – хотим рассказать о том, как не усложнять все и прийти к простым и правильным решениям в сфере построения процессов сопровождения. Рассказ основан на собственном опыте нормализации процессов управления дефектами промышленной среды ведущего банка топ-5 России.

Как все начиналось?

Некоторый банк внедрил систему управления маркетингом. Теперь ему стало легче жить: не нужно вручную обновлять ставки в сотнях таблиц при изменении ставки ЦБ, клиентам не требуется ждать от 3-х рабочих дней, пока их заявки на кредит проверятся рядом специалистов. Все делается автоматически, банку легко подстраивать тысячи предложений под запросы клиента, взаимодействовать по разным каналам коммуникации с каждым потребителям, а еще добавилось много иных бизнесовых “плюшек”, которые повысили в целом доходы банка от маркетинговых кампаний. Но, как и в любой системе, в продукте автоматизации случаются баги: кто-то что-то не то нажал, вылез технический долг команды разработки, пользователи создали огромную нагрузку на систему, и она стала медленнее и т.д. Такие кейсы возникают ежедневно, и кому-то нужно решать все проблемы и обучать пользователей действовать правильно. 

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

В итоге большое количество дефектов перетекало от одного исполнителя к другому, дефекты не решались, все давали отписки, что “это не мое”, банк терял деньги на простое системы.

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

Итог: много говорим не с теми людьми, не в то время и к договоренностям не приходим. Дефекты остаются не решенными.

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

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

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

Если дефект не был аварией, который заблокировал вообще все, то его исправление откладывалось, и рос хвост нерешенных инцидентов. 

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

Мы проаудировали процессы банка в части управления сопровождением и выявили следующие проблемы:

• нет конкретного ответственного исполнителя;

• много созвонов, которые не приносят пользы;

• исправление дефектов через поставки без сформированного флоу внедрения;

• нет входного окна для “я просто спросить”.

Результатом всех проблем являлось значительное замедление решения инцидентов, слив SLA, в крайних случаях – отсутствие решения в принципе.

Как мы оптимизировали все

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

«Настоящая ответственность бывает только личной. Человек краснеет один». Фазиль Искандер

Когда у дефекта тысячи исполнителей, ответственность размывается. Всегда есть сосед, о котором можно сказать: “Это он должен был делать”. Когда за все дефекты отвечает один, он найдет, к кому обратиться за решением, пройдет через все круги коммуникации и найдет, с кого спросить решение, если оно не возникло в срок или не возникло вообще. Тем временем, пока этим ответственным выступал наш сотрудник, банк смог выдохнуть и заняться иными важными делами.

“Зачем мы говорим, давайте делать”

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

• обсуждаем исключительно вопросы дефектов;

• обязательно ставим сроки для исполнителя;

• проверяем соблюдение сроков исполнителем;

• синхронизируемся по дальнейшим шагам решения дефекта;

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

Так продуктивные встречи внесли ясность в то, кто и к какому сроку должен выполнить определенную работу. 

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

“Я просто спросить”

Мы внедрили отдельный спейс в jira банка, который предназначается только для консультаций. Так у пользователей появилась возможность спрашивать, а вопросы этого спейса не перепутались с дефектами, и желание банка не смешивать баги и дефекты было учтено. Пользователи стали задавать вопросы, и тенденция показала, что количество дефектов сократилось: людям стало очевиднее, что им нужно делать, чтобы решить свою проблему, и как своими действиями не поломать все.

“Поставки с исправлениями”

Как было сказано выше, выкатить поставку, которая прошла бы все нормы, правила, тестирования, огонь и медные трубы, – задача непростая. Для решения был выделен сотрудник, который стал заниматься исключительно накатом поставок. Их стали планировать к выводу в промышленную среду ПРОД через календарь: любое исправление должно иметь тайминг наката и быть выполнено в запланированное время. Кроме того, от сопровождения Glowbyte был создан “комитет модерации”, который проверял, что поставки с исправлениями дефектов оформлены правильно, банк запланировал в календаре вывод в ПРОД исправления. Как результат – количество отклоненных поставок уменьшилось. 

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

Итоги

Сейчас процессы сопровождения маркетинговых систем этого банка причесаны, аккуратны и отработаны. Около 9 месяцев назад мы зашли на проект, чтобы оказывать услуги сопровождения, и параллельно построили процесс, который устраивает теперь всех. За все время с регулярных 50+ открытых дефектов в день количество снизилось до 10-15. Теперь:

• Статусы каждого дефекта прозрачны, сроки и исполнитель известны. 

• У банка появилось время именно строить бизнес-логику, а не заниматься обслуживанием. 

• Эффективность маркетинговых кампаний выросла, дефектов продакшн среды стало меньше. Сложные механизмы мы распутали, упростили, сделали легче и быстрее. 

• Новым сотрудникам (разработчикам, аналитикам, бизнес-пользователям и др.) стало проще погружаться в особенности проекта и начинать работать над своими задачами. 

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