Мы MM.SUP – команда сопровождения аналитического CRM компании Glowbyte – хотим рассказать о том, как не усложнять все и прийти к простым и правильным решениям в сфере построения процессов сопровождения. Рассказ основан на собственном опыте нормализации процессов управления дефектами промышленной среды ведущего банка топ-5 России.
Как все начиналось?
Некоторый банк внедрил систему управления маркетингом. Теперь ему стало легче жить: не нужно вручную обновлять ставки в сотнях таблиц при изменении ставки ЦБ, клиентам не требуется ждать от 3-х рабочих дней, пока их заявки на кредит проверятся рядом специалистов. Все делается автоматически, банку легко подстраивать тысячи предложений под запросы клиента, взаимодействовать по разным каналам коммуникации с каждым потребителям, а еще добавилось много иных бизнесовых “плюшек”, которые повысили в целом доходы банка от маркетинговых кампаний. Но, как и в любой системе, в продукте автоматизации случаются баги: кто-то что-то не то нажал, вылез технический долг команды разработки, пользователи создали огромную нагрузку на систему, и она стала медленнее и т.д. Такие кейсы возникают ежедневно, и кому-то нужно решать все проблемы и обучать пользователей действовать правильно.
На тот момент в банке вопросами поддержки системы занималось множество подразделений: отдел по базам данных, отдел по сопровождению железа, отдел по аналитике сегмента розничного бизнеса, отдел по разработке автоматизации около малого и среднего бизнеса и т.д. Каждый отдел руководствовался правилом, что “все, что не прописано в должностной инструкции, то не принадлежит моей зоне ответственности”.
В итоге большое количество дефектов перетекало от одного исполнителя к другому, дефекты не решались, все давали отписки, что “это не мое”, банк терял деньги на простое системы.
Наш банк собирал регулярные встречи одних подразделений с другими, в результате чего возникало множество комбинаций участников событий, что увеличивало количество этих самых встреч. Было не совсем прозрачно, какой состав участников и от какой команды звать: для обсуждения вопроса по определенному багу Вася из подразделения управления базами данных позвал на встречу Петю и Колю из функционального сопровождения, но забыл позвать Валеру, который больше всех осведомлен о проблеме, из-за чего результат встречи не оправдал себя. Календарь встреч каждого сотрудника разрастался так, что туда уже было просто невозможно вставить еще одну. Сотрудники стали игнорировать мероприятия, и это сделало ситуацию еще печальнее.
Итог: много говорим не с теми людьми, не в то время и к договоренностям не приходим. Дефекты остаются не решенными.
Очередной проблемой в этом механизме являлось то, что пользователям не разрешалось заводить заявки на консультации. Если кому-то нужно было что-то спросить, то от него отмахивались, ссылаясь на существующий объем проблем: висят дефекты нерешенные, а ты тут просто спросить пришел.
Пользователи не знали, как им поступить, чтоб маркетинговая система решала их цели, самостоятельно придумывали обходные пути, которые создавали еще больше проблем и замедляли работу всех коллег.
В завершение наложилась проблема тестирования и внедрения исправлений дефектов. Каждое исправление – это правка конфигов, кода, параметров, объектов и данных в БД и т.д. И каждое исправление должно пройти ряд тестирований – функциональное, нагрузочное, а потом попасть в промышленную среду. Весь этот процесс сопровождается пакетом обязательных регламентных документов и аннотаций, от которых банк отказаться не может в силу норм организации. Если на каком-то из этапов что-то шло не так (даже если это ошибка в сопроводительной документации), поставка откатывалась и передавалась снова на тестирование и проходила через множество рук валидации. Поставки накатывались по ночам, так как днем у всех встречи, что снижало качество работ по выводу в ПРОД.
Если дефект не был аварией, который заблокировал вообще все, то его исправление откладывалось, и рос хвост нерешенных инцидентов.
Все это напоминало машину Голдберга, которая выполняет простые действия через сложные и нетривиальные механизмы. Выполняя простые действия сложными путями, банк сливал SLA почти на каждом дефекте, у сотрудников организации возникали регулярные переработки.
Мы проаудировали процессы банка в части управления сопровождением и выявили следующие проблемы:
нет конкретного ответственного исполнителя;
много созвонов, которые не приносят пользы;
исправление дефектов через поставки без сформированного флоу внедрения;
нет входного окна для “я просто спросить”.
Результатом всех проблем являлось значительное замедление решения инцидентов, слив SLA, в крайних случаях – отсутствие решения в принципе.
Как мы оптимизировали все
Сделать из хаоса конфетку до нас пытались два раза. Команды приходили на проект, смотрели на спутанность процессов и уходили. Мы же зашли с другой стороны: подобрали ответственного тимлида, руководствующегося принципами перманентной проактивности и инициативности, который бы смог не только посмотреть на проблему, но и предложить меры по исправлению, и даже исправить ее. Так во всем беспорядке появилось лицо, которое являлось точкой входа для всех проблем, отвечающее за качество и скорость решения дефектов и своевременную смену их статусов. Команда, которой была поручена активность, брала ответственность буквально за все в поддержке маркетинговых систем банка: коммуникации, сбор встреч по дефектам с нужным составом участников, ответы во всех чатах подразделениям банка, выполняла функцию таймера напоминаний что-то сделать, синхронизировала сроки и статусы по решению дефектов со всех команд, принимала удар на себя, если кто-то что-то не успел сделать/ сделал не так, как ожидалось, а затем искала способы сделать все, чтоб такое не повторилось в будущем. В целом на проекте мы не поддерживали правило “все что не прописано, не входит в зону нашей ответственности”.
«Настоящая ответственность бывает только личной. Человек краснеет один». Фазиль Искандер
Когда у дефекта тысячи исполнителей, ответственность размывается. Всегда есть сосед, о котором можно сказать: “Это он должен был делать”. Когда за все дефекты отвечает один, он найдет, к кому обратиться за решением, пройдет через все круги коммуникации и найдет, с кого спросить решение, если оно не возникло в срок или не возникло вообще. Тем временем, пока этим ответственным выступал наш сотрудник, банк смог выдохнуть и заняться иными важными делами.
“Зачем мы говорим, давайте делать”
Этим принципом руководствовался банк до того, как мы пришли поддерживать их систему. Но на самом деле разговоры бывают продуктивными, и с ними лучше, чем без них, если правильно строить встречу. Мы внедрили еженедельную встречу по дефектам, посещать которую стало обязанностью для всех исполнителей работ по дефектам. Если кто-то не приходит или отклоняет -мероприятие в календаре, обязательно необходимо написать письмо с причиной или прислать замену. У встреч появилась повестка:
обсуждаем исключительно вопросы дефектов;
обязательно ставим сроки для исполнителя;
проверяем соблюдение сроков исполнителем;
синхронизируемся по дальнейшим шагам решения дефекта;
презентуем статистику по количеству инцидентов за период для того, чтобы для всех была прозрачна эффективность работы над дефектами.
Так продуктивные встречи внесли ясность в то, кто и к какому сроку должен выполнить определенную работу.
Появились статус-встречи по обмену новостями в системе: если разработчики что-то внедряют, они должны сообщить о своей будущей поставке на соответствующей встрече.
“Я просто спросить”
Мы внедрили отдельный спейс в jira банка, который предназначается только для консультаций. Так у пользователей появилась возможность спрашивать, а вопросы этого спейса не перепутались с дефектами, и желание банка не смешивать баги и дефекты было учтено. Пользователи стали задавать вопросы, и тенденция показала, что количество дефектов сократилось: людям стало очевиднее, что им нужно делать, чтобы решить свою проблему, и как своими действиями не поломать все.
“Поставки с исправлениями”
Как было сказано выше, выкатить поставку, которая прошла бы все нормы, правила, тестирования, огонь и медные трубы, – задача непростая. Для решения был выделен сотрудник, который стал заниматься исключительно накатом поставок. Их стали планировать к выводу в промышленную среду ПРОД через календарь: любое исправление должно иметь тайминг наката и быть выполнено в запланированное время. Кроме того, от сопровождения Glowbyte был создан “комитет модерации”, который проверял, что поставки с исправлениями дефектов оформлены правильно, банк запланировал в календаре вывод в ПРОД исправления. Как результат – количество отклоненных поставок уменьшилось.
Помимо всего описанного, мы предложили банку экспертизу сопровождения: сами начали исследовать и исправлять дефекты, консультировать пользователей по их вопросам. Все это в итоге еще больше упростило процессы и помогло из сложного сделать простое.
Итоги
Сейчас процессы сопровождения маркетинговых систем этого банка причесаны, аккуратны и отработаны. Около 9 месяцев назад мы зашли на проект, чтобы оказывать услуги сопровождения, и параллельно построили процесс, который устраивает теперь всех. За все время с регулярных 50+ открытых дефектов в день количество снизилось до 10-15. Теперь:
Статусы каждого дефекта прозрачны, сроки и исполнитель известны.
У банка появилось время именно строить бизнес-логику, а не заниматься обслуживанием.
Эффективность маркетинговых кампаний выросла, дефектов продакшн
Новым сотрудникам (разработчикам, аналитикам, бизнес-пользователям и др.) стало проще погружаться в особенности проекта и начинать работать над своими задачами.
На сегодняшний день мы поддерживаем выстроенный процесс в актуальном состоянии и помогаем банку развиваться в новых горизонтах, предлагая лучшие идеи, способы внедрения и свою экспертизу.