Всем привет! Мы - отдел бизнес-поддержки (БП) в Social Discovery Group. В этой статье расскажем, как мы повторили шестой подвиг Геракла, очистив доску от 1500 тикетов, которые накопились за 4 года. 1500 задач - это больно. Тикеты кочевали из спринта в спринт, заказчики ежедневно запрашивали статус по задачам, а мы испытывали стресс от переработок и от того, что не можем дать апдейты. Мы поняли, что нужно менять процессы в отделе и применили подход STATIK, который навсегда избавил нас от бесконечной очереди задач.

Как появилась очередь из 1500 задач?

Задача отдела бизнес-поддержки в Social Discovery Group  - обрабатывать тикеты с жалобами и предложениям по работе сервисов от клиентов и других отделов. Например, клиент обратился в техническую поддержку с жалобой о том, что не может заплатить на сайте. Коллеги собирают информацию о проблеме (шаги воспроизведения, скриншоты) и заводят тикет в Jira на наш отдел. Мы проводим дополнительное тестирование, чтобы убедиться, что это не временный сбой у клиента, а проблема на нашей стороне. Если она подтверждается, мы создаем баг-репорт, приоритезируем его и добиваемся фикса от команды разработки.

В среднем, нам прилетало 20-30 тикетов за день. Мы справлялись с первичным воспроизведением проблемы за 2-3 часа, но когда требовалась помощь коллег из других отделов (детализация кейса, рестарт сервиса, данные из БД, анализ от разработки) задачи начинали буксовать. У коллег зачастую не хватало времени оперативно ответить на запросы, и отдельных разработчиков на наши баг-репорты не выделялось. К тому же, у разработки наши тикеты имели меньший приоритет, чем бизнес-задачи. Даже тикеты с highest приоритетом могли зависать до двух месяцев. Менее приоритетные задачи и вовсе оставались на доске годами. 

Как видите, в такой цепочке слишком много неопределенности по срокам выполнения. Все это привело к неудовлетворенности у нас и наших клиентов: 

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

• Заказчики каждый день писали в суппорт и требовали решения проблем.

• Суппорт ежедневно писал нам и мы возвращали тот же ответ: “проблема не решена”.

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

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

Вот, как выглядел жизненный цикл тикета на тот момент:

Опишем примеры проблем, с которыми мы сталкивались:

1. У суппорта не было скриптов, чтобы сразу детализировать проблему и отфильтровать ее на своем уровне.

2. В статусе «New» могло выяснится, что сил нашего отдела недостаточно. Если не хватало данных или доступов, задача переходила в наш «любимый» статус – «Escalated». На этом этапе мы писали коллегам из смежных департаментов в комментариях к тикету и ждали их ответа. На дополнительную проверку и ответ могло уходить от 2 дней до нескольких месяцев, так как коллеги не замечали комментарий или просто забывали ответить. Либо они могли ответить не полностью, и дополнительные вопросы занимали еще несколько недель. Случалось и так, что мы сами не замечали комментариев из-за наплыва новых задач.

3. Если все-таки подтверждали проблему, то мы переводили ее в статус «Awaiting fix». При плохом стечении обстоятельств, тикет мог находиться в нем несколько лет. У нас хронически не хватало ресурсов разработки, но заказчики не давали закрыть задачу с мыслью «вдруг ресурсы появятся в будущем – тогда и починят».

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

Недочеты в организации ЖЦ создали очередь в 1500 зависших кейсов за 4 года  ☹

Подход STATIK и 6 подвиг Геракла

Мы поняли, что слишком сфокусированы на обработке тикетов и не заботимся о главной цели отдела - решить проблему клиента, повысить его лояльность к продуктам компании и выявить уязвимые места в сервисах и на сайте. Может возникнуть мысль: “Почему-бы не нанять еще сотрудников в отдел, если мы не справляемся с нагрузкой?” Опыт показывает, что наладив процессы, можно обойтись без дополнительных ресурсов. Геракл совершил подвиг сам: отвёл русло реки прямиком в конюшни Авгия, а вода очистила их за один день. Мы, чтобы расчистить доску с тикетами, обратились к книге Майка Барроуза “Kanban from the Inside” и применили STATIK - системный подход к внедрению метода Kanban. 

Чтобы его внедрить, мы прошли 5 шагов: 

1) Определили ожидания заказчиков от отдела бизнес-поддержки и поняли, что:

Заказчики должны быть удовлетворены работой над их обращениями.
Добиться этого нам поможет:

1. Прозрачность работы над задачей. В любой момент времени должно быть понятно, что происходит с обращением. 

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

2) Выявили внешние и внутренние источники неудовлетворенности:

Внутренний источник - это то, что мешало нам и бесило в работе нас самих. Внешний источник - то, что мешало заказчикам и бесило их.

3) Выявили источники и природу нагрузки:

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

4) Оценили текущие возможности:

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

 5) Пересмотрели жизненный цикл тикета и создали новый:

Далее, мы проделали комплексную работу по всем проблемам, описанным выше:

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

2. Ввели временный статус “Back to reporter”. Туда переводились задачи, в которых не хватало вводных данных от заказчика для исследования проблемы. Если заказчик не предоставил нужные данные за 3 дня, задача автоматически закрывалась.

3. Плакали всем отделом, но убрали статус «Escalated» совсем и навсегда. Теперь задачи оставались в более конкретном статусе «Problem confirmation». 

4. Потратили более 2 месяцев на то, чтобы прочесть все старые задачи и закрыть дубли. Из 1500 осталось около 800 уникальных тикетов.

5. Внедрили в нашу практику SLA - повесили таймеры на каждый статус. В Problem confirmation – 7 дней, Development – 30 дней.

6. В статусе «Problem confirmation» у нас появилась мотивация пинговать коллег и добиваться ответа. Мы перестали оставлять комментарии в Jira и начали писать им в личку или в треды Slack – теперь ответ занимал не более 1 дня (помните про недели, описанные выше?)

7. В статусе «Awaiting fix» таймер не вводили, но у нас освободилось время на общение с заказчиком и дискуссии. Если мы знали, что на фикс бага или задачи никогда не выделят ресурсы, мы доносили эту мысль до заказчика и сходились на том, что закроем задачу, а вместо нее починим что-то действительно приоритетное. Из-за этого, количество задач в «подвешенном» состоянии сократилось вполовину. Также, мы начали практиковать общие встречи, где заказчик мог донести до отдела разработки, почему та или иная задача важна и ее стоит решить – это помогло приоритизировать таски.  

8. Статус «Development» – таймер 30 дней. Таймеры стали мотивировать нас дополнительно напоминать, ставить реальные сроки фикса и выполнять их. Также, мы ввели ограничение на количество задач в этом статусе до 4: так можно сфокусироваться и починить баг, не нагружая разработку дополнительным визуальным шумом из 20-40 задач в этом статусе на доске.

9. Для того, чтобы наши достижения и практики не потерялись со временем, мы ввели принцип 90-го перцентиля. Это значит, что 90% задач должны быть закрыты в срок и задача считалась успешно выполненной, если проводила в каждом из статусов не более предусмотренного таймерами времени. Соблюдение таймеров мы проверяли в разделе Control Chart в Jira + использовали плагин Jira-helper для построения 90-го перцентиля.

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

В итоге, мы решили проблему, которая висела над нами 4 года. Изменив подход и процессы в отделе, мы сократили большое количество задач без дополнительного времени, сил и бюджета. За 5 месяцев мы превратили 1500 тикетов в 150, имея в своем арсенале всего двух смышленых сотрудников. Мы поняли, что важно находить корневые причины появления проблем - это сильно облегчает поиск решения. Понимание цели - важная часть построения процессов, а плохие процессы рано или поздно приведут к накоплению задач.