Привет! Я Даша, QA в команде Смартбот. Эта статья будет о том, как мы перестали спорить о срочности обращений и багов.

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

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

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

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

Оглавление

• Контекст

• Как устроен хитмап

• Место хитмапа в рабочем процессе

• Хитмап не идеален

• Что изменилось после внедрения

• Заключение

Контекст

На первой линии поддержки у нас всего двое ребят. Часть тикетов они решают сами, еще часть поднимают на вторую (это уже я). Тут я выступаю как человек, который помогает собрать контекст и дотащить самые сложные кейсы до разработки. Отдельного сотрудника, который системно разбирает саппорт, у нас нет.

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

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

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

В общем, мы решили, что нам нужен хитмап.

Как устроен хитмап

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

В основу мы положили четыре критерия:

1. Серьезность.
Насколько сильно баг ломает конкретный сценарий. Это вопрос про то, что именно перестало работать и можно ли это обойти.

2. Воспроизводимость.
Проблема наблюдается у всех, у нескольких пользователей, у одного пользователя или вообще не воспроизводится стабильно.

3. Тип клиента.
Этот критерий нужен, чтобы учитывать бизнес-контекст. Очевидно, что кейс от клиента на сопровождении и кейс от пользователя на триале — не одно и то же с точки зрения влияния на продукт и команду.

4. Критичность функционала.
Насколько важен для продукта и бизнеса тот раздел или сценарий, где возникла проблема.

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

Разберем на примере. Допустим, у платного клиента (2 балла) не отправляются сообщения (4 балла), проблема воспроизводится у нескольких пользователей (2 балла), а сам сценарий относится к ядру продукта (4 балла). По одному только описанию уже понятно, что такой кейс набирает много баллов сразу по нескольким критериям и уходит в верхнюю часть шкалы. В сумме тикет набирает 12 баллов из 16 возможных, что подтверждает высокий приоритет.

Это, по сути, и есть главное достоинство подхода: задача раскладывается на несколько понятных осей. Так нам намного проще свести свои субъективные оценки к минимуму и меньше руководствоваться «чувством прекрасного».

Место хитмапа в рабочем процессе

Сейчас логика примерно такая:

• первая линия собирает базовую информацию по обращению;

• ориентируется на критерии хитмапа и выставляет приоритет;

• я уже смотрю на доску как на отсортированный поток задач, где видно, куда нужно подключаться в первую очередь;

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

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

Хитмап не идеален

Был случай, когда пришлось его откалибровать. От крупного клиента пришел тикет с формулировкой «упали рассылки», что в отрыве от контекста звучит максимально тревожно. Если у клиента действительно не работают никакие рассылки, это вполне может быть багом уровня «бросаем все и идем чинить».

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

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

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

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

Что изменилось после внедрения

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

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

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

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

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

Заключение

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

В таком сценарии критерий «тип клиента», скорее всего, отвалится или трансформируется, зато остальные (серьезность, воспроизводимость, важность функционала) останутся вполне рабочими. Как вариант, можно добавить к ним оценку ресурсов на фикс.

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

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

1. Соберите из трекера задач, чатов и переписок как можно больше обращений, о приоритете которых вы спорили. На их основе соберите примерный черновик с критериями и разбалловкой (но небольшую часть собранных тикетов отложите до шага 3). Можете прогнать через нейронку, тут уже на ваш вкус.

2. Обсудите ваш черновик с командой. Во-первых, до реформы неплохо бы убедиться, что все с вами согласны. Во-вторых, коллеги могут подсветить неочевидные детали.

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

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

Кстати, мои коллеги тоже делятся опытом тушения пожаров. Если было интересно, рекомендую:

• Маленькой команде — большие цели. Как развивать SaaS, если вас пятеро

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