Привет, я Лена Чуркина, уже больше шести лет работаю проджект-менеджером в IT и на своём опыте успела пройти все стадии принятия бэклога. Настолько, что даже в жизни часто использую планирование и приоритизацию. Поэтому если количество горящих задач в вашей команде стало больше напоминать чёрную дыру, а последняя нервная клетка грозится выйти из чата, то эта статья для вас.
В ЮMoney есть термин «здоровый бэклог» — благодаря постоянной актуализации задач создаётся реально выполнимый объём работ для команды, где нет ничего ненужного. Бэклогом у нас называется всё, что касается поддержки уже существующих продуктов: баги, инциденты, улучшение тех.качества.
В команде разработки ЮKassa мы отвечаем за стабильность core-функциональности нашей платежной системы: работу API, осуществление платежей, сверку с КА и т.д.
Когда мы начали разбирать наш бэклог, там накопилось уже более 300 задач, поэтому мы решили разделить их на три потока: развитие, техбэклог и сопровождение. При этом, задачи развития приоритизирует продакт, а техбэклог и сопровождение зона ответственности всей команды и их приоритизируем все вместе
В развитие попали все идеи, связанные с развитием нашего продукта и то, что в будущем должно перерасти в проекты.
В техбэклог отправили задачи на переработку кода и его техническое качество.
В сопровождении собрали сборную солянку из задач: баги, инциденты, идеи, заказы от соседних департаментов.
Методик для работы с приоритизацией очень много. Я расскажу про опыт внедрения матриц и score в нашей команде и к каким выводам мы пришли.
Матрицы
Где-то здесь должна быть шутка про Нео, но мы поговорим про мистера Эйзенхауэра. Думаю, в дополнительном представлении он не нуждается. Нам приглянулась его матрица из-за лёгкости и доступности, а так же шкал, где учитывается важность и срочность.
Например, перед командой стояла задача сократить объём логирования. Техлид отметил, что объём файлов растёт, свободное место на диске уменьшается, но по подсчётам запаса должно хватить ещё на полгода. Мы понимаем, что задача очень важна, но её можно отложить, поэтому она помещается в квадрат «запланировать».
Ещё один популярный подход — матрица Value vs Effort
Она больше подходит для приоритизации продуктовых задач, направленных на развитие продукта.
Например, у нас была цель — исправить баг в процессе платежа. Разработчик сказал, что уже посмотрел код и понимает, как это починить. Затратив немного усилий, мы получим отсутствие ошибок по 5% платежей, это большая ценность для нас. Поэтому делаем задание в первую очередь.
Таким образом мы проходимся по всем задачам и рассеиваем их на категории. Несмотря на простоту этого метода, за три квартала команда разработки ЮKassa смогла уменьшить бэклог на 50%.
Но матрицы эффективны далеко не всегда — данный метод больше подходит именно для первичной приоритизации. Со временем мы заметили, что они уже не приносят пользы.
Мы сделали все что «важно и срочно», но у нас осталось примерно 100-150 задач в квадрате «важно, но не срочно», например, добавить магазин в blacklist нового процесса или интеграцию нового способа платежа. Их тоже нужно было ранжировать. Для этого мы решили использовать другой метод.
Скоринг
Чтобы получить чёткую последовательность задач и увеличить прозрачность процессов для заказчиков мы решили использовать методику score. Это позволяет определить очередь каждого задания и критерии её оценки. Для приоритизации используем две модели:
ICE SCORE
Impact показывает, насколько сильно данная задача влияет на продукт и на пользователей.
Confidence — насколько мы уверены в оценках и хватает ли данных для принятия решений.
Easy — оценивает, насколько просто нам будет сделать эту задачу. Чем проще задача, тем выше балл.
Эта модель используется для техбэклога. Чтобы проще было выбирать, мы сократили вариативность оценок до 4 пунктов и используем 10-балльную шкалу.
Например, наш разработчик говорит, что в этой задаче на добавление индекса на колонку запросы падают по таймауту. Мы понимаем, как это поправить, есть сильное влияние на процессы, мы в этом уверены, потому что уже посмотрели код. Следовательно, ставим оценки, перемножаем все три величины и получаем итоговый ICE Score.
RICE SCORE
Помимо уже известных Impact и Confidence, добавляются две новые шкалы:
Reach — охват, чтобы понимать, как много пользователей или процессов затрагивает задача.
Effort — в данном случае прямая шкала. Мы используем оценку в Стори Поинтах, то есть, чем сложнее задача, тем больший балл она получает.
Здесь у нас тоже есть примеры шкал. Самая вариативная, это охват. Как раз из-за него мы и стали использовать модель RICE для задач сопровождения. Поскольку у нас разные продукты затрагивают разное количество пользователей, нам важно учитывать охват.
Например, на одной из страниц поехала вёрстка. Продакт говорит, что она очень часто посещается пользователями и это плохо, а разработчик добавляет, что знает, как это быстро поправить. Охват известен, влияние — косметический дефект, уверенность — 100%, усилия — минимальные. Используем формулу и получаем итоговый RICE Score.
Скоринговые модели очень гибкие и их легко адаптировать под себя. Даже у нас в компании у каждой команды они используются по-разному.
Как это выглядит на практике
Как я уже писала, в приоритизации участвует вся команда. За день до встречи в planning poker plugin в jira собирается сессия и скидывается ребятам. Выбирается 5 -10 задач, которые они смотрят и оценивают.
Уже на встрече мы обсуждаем оценки, фиксируем в комментариях, из чего высчитали score и проставляем итоговую оценку.
Вся прелесть этого метода в том, что дальше задачи сами ранжируются на доске. Мы лишь выбираем в фильтрах «техбэклог/не техбэклог» и «бэкенд/фронтенд» и получаем топ важных задач в каждом направлении, а то, что остаётся в самом хвосте можем закрыть.
Вывод
Волшебной методики, которая подойдет всем командам, увы, не существует, всё подбирается индивидуально. Но без приоритизации бэклога растёт риск погрузиться в бесконечный водоворот, который постоянно растёт и забирает с собой время, ресурсы и радость. Особенно это касается команд в крупных компаниях. На примере ЮMoney я рассказала, как разделение и актуализация задач помогла вдвое уменьшить это «стихийное бедствие», сделать процессы прозрачнее и выстроить для заказчиков предсказуемые сроки, когда задача будет взята в работу. Попробуйте и вы! ;)
Если вы хотите стать частью нашей команды, подписывайтесь на каналы ЮMoney с актуальными вакансиями и новостями о жизни компании: