Привет! Меня зовут Илья, в Авито я разработчик и по совместительству скрам-мастер в B2B-команде, которая делает Автотеку.
Сегодня хотел бы рассказать о том, как мы с командой запускали процесс приоритизации задач, формировали процессы их оценки и переоценки. С какими трудностями нам пришлось столкнуться и какие профиты удалось приобрести. Надеюсь, статья будет полезна командам, бэклог которых содержит > 50 айтемов, а знания о том, что делать, есть только у product owner.
Введение в скрам
Небольшое введение в скрам, для тех кто никогда не сталкивался с ним раньше. Если вы уже имеете представление об этой методологии и её артефактах, можете смело переходить к следующему разделу.
Scrum с английского переводится как «схватка», это название одного из элементов регби. Цель схватки — возобновление игры после незначительного нарушения или её остановки. Эти процессы заложены и в методологию командной работы Scrum. Команда сотрудников, которая работает по скраму, должна постоянно совершенствоваться, достигать поставленных целей, анализировать свой опыт и извлекать из этого опыта, каким бы он ни был, ценные уроки. Для содействия этому, методология предполагает ряд инструментов и встреч.
Рабочий процесс в скраме разделён на итерации, которые называются спринтами. Каждый спринт длится от 1 до 4 недель. В нашем случае это 2 недели.
Перед началом спринта мы собираемся на планирование, где набираем себе задачи. Это те задачи, которые должны быть выполнены в рамках будущей итерации. Главным артефактом спринта является цель. Цель — это то, на чём сфокусирована вся команда в процессе итерации. Если цель не выполнена, спринт считается проваленным. Кроме цели, итогом планирования является набор задач. Он называется sprint backlog.
Помимо планирования есть ежедневные короткие встречи — daily, где команда обсуждает процесс движения к цели. Один раз в спринт проводится встреча, которая называется product backlog refinement (PBR), где мы уточняем предстоящие задачи, производим оценку их сложности, декомпозируем большие задачи на те, которые можно сделать в рамках спринта.
Также каждый спринт есть две активности: обзор спринта и ретроспектива спринта. Это встречи для получения обратной связи от заказчиков по итогам спринта и для извлечения ценных уроков после текущей итерации.
В этой статье я описываю изменение рабочих процессов в промежутке между планированием и PBR.
Предпосылки к использованию приоритетов
Мы занимаемся развитием B2B-продукта, что подразумевает гетерогенность задач, большое количество A/B-тестов и проверок гипотез, а наша работа часто похожа на поиск и создание инновационных решений. Команда образовалась летом 2020 года, её участники уже работали по скраму и имели представления о таких процессах как ретроспективы, дейли, планирования и прочее. Это позволило быстро начать доносить продуктовую ценность до пользователей. После создания команды роль владельца продукта, дальше я буду называть его PO, выполнял tech lead. Вместе мы сформировали бэклог продукта, начали работать, и всё было хорошо.
Через какое-то время к нам присоединился менеджер продукта, и бэклог начал стремительно расти. В бэклоге одновременно лежали гипотезы, запросы на MVP, также нужно было не забывать про развитие уже работающих в продакшене штук и техдолг. И для команды разработчиков было неочевидно, решение каких задач даст наилучший результат.
Также появилась проблема с тем, что хвост бэклога редко рассматривался, то есть мы упускали из виду важные вещи. В итоге на очередной ретроспективе мы договорились провести обзор техник приоритизации и попробовать использовать какой-либо фреймворк для оценки задач. Мы надеялись, что это снизит когнитивную нагрузку от постоянного определения приоритетов на планировании и на product backlog refinement (PBR).
Нам хотелось понять:
Как определять приоритеты и делать это на основании данных экспериментов и A/B-тестов.
Как PO делиться своей экспертностью в оценке задач. Во время отпуска PO было бы здорово, чтобы команда могла самостоятельно определить приоритеты и взять в работу то, что важно сейчас.
Как сразу обрабатывать фичареквесты и не допускать их гибели в бесконечных Слак-чатах.
Какие методологии оценки и инструменты помогут поддерживать бэклог в актуальном состоянии.
По итогам ретро стала понятна целевая картина:
В команде есть методология оценки задач.
Бэклог всегда находится в актуальном состоянии и отсортирован по приоритету.
Команда, когда это необходимо, может дать оценку приоритета новой задаче без PO.
Новые задачи не теряются в недрах бэклога, и им проставляется приоритет на общекомандных мероприятиях.
ICE, RICE или WHY’s?
Количество систем приоритизации огромно, и нам не было понятно, какую использовать. В нашем исследовании мы рассматривали и приоритеты на основе value, и многокомпонентные оценки, типа WSJF или RICE.
Тем не менее, выбор нужно было сделать. Мы определили, что:
Раз команда — достаточно молодая, то мы должны использовать чуть более субъективную оценку, чем если бы в нашей работе было много legacy и подкручивания тех или иных метрик.
CustDev ещё не был поставлен на поток, поэтому оценить охват аудитории, на которую та или иная фича оказывала влияние, было достаточно сложно. Поэтому при выборе систем приоритизации мы исключали те, которые учитывают этот фактор.
У нас большое количество гипотез, которые мы хотим проверять. Нужно было, чтобы инструмент оценки позволял это учитывать.
По этим критериям мы поняли, что хорошим кандидатом является фреймворк ICE. Про него есть хорошая статья на Хабре. Вот формула оценки задачи по фреймворку:
ICE стоит на трёх столпах:
Влияние (Impact) показывает, насколько идея положительно повлияет на ключевой показатель, который мы пытаетемся улучшить.
Уверенность (Confidence) показывает, насколько мы уверены в оценках влияния и лёгкости реализации.
Лёгкость реализации (Ease) — это оценка того, сколько усилий и ресурсов потребуется для реализации идеи.
При оценке задачи мы определяем значение каждого показателя, перемножаем их и получаем ICE score. Просто и, как показала практика, достаточно эффективно.
Процесс оценки задач
Прекрасно, фреймворк оценки выбран. Но как и когда проставлять задаче приоритет, и кто его должен проставлять? Где его хранить? Как обновлять? Где шкала оценок по каждому из трёх составляющих?
Сначала мы определились с оценками по каждому критерию ICE, и написали гайды, как их выбирать.
Оценка impact
Мы составили таблицу, в которую накидали большое количество разных критериев, в которые может бить оцениваемая задача. Приведу несколько пример того, сколько баллов нужно поставить в импакт, если задача:
Балл влияния | На что влияет задача |
1 | Лояльность партнёров. |
1 | Улучшает UI. |
2 | Улучшает UX. |
2 | Улучшает привлечение партнёров или клиентов. |
2 | Улучшает удержание партнёров или клиентов. |
2 | Улучшает конверсию B2B-продаж. |
2 | Влияет на OKR. |
В разных компаниях и контекстах эта таблица будет отличаться, и даже степень влияния будет разной от команды к команде, но можно начать с этого, а дальше уже набивать в табличку другие критерии.
Оценка confidence
В статье о фреймворке на Медиуме мы нашли полезный способ оценки уверенности:
У нас процесс определения confidence выглядит следующим образом. Сначала PO определяет оценку от 1 до 10, формируя тем самым повод к обсуждению этой оценки. Для примера возьмём задачу на создание какой-либо ценности для пользователя, пусть это будет сервис оценки автомобиля. Мы смотрим на критерии с картинки и понимаем, что сейчас уверены в том, что решение задачи даст нам продуктовый результат на уровне Low. То есть оценка где-то около anectodal evidence.
Мы понимаем, что с такой оценкой задача будет точно не в верхушке бэклога, и это стимулирует нас к тому, чтобы увеличивать confidence по ней. Например, провести пользовательский опрос или, возможно, реализовать эту задачу не как полноценный сервис, а начать с MVP, или раскопать каких-то исследований по теме. Вся суть принципа оценки приоритетов заключается как раз в том, чтобы стимулировать команду не строить космолёты, а подтверждать свои гипотезы. И определение confidence тут играет главную роль.
Мы перевели картинку для себя и оцениваем уверенность по ней:
Оценка ease
Для оценки критерия лёгкости реализации мы просто составили таблицу Story Points/Ease от 1 до 10. 10 баллов лёгкости — это 0 SP и задачу, по сути, можно не делать, а 1 балл — это 21 SP, что в нашем случае значит что задача займёт более двух спринтов.
Story points | Ease |
0 | 10 |
0.1 | 9 |
0.5 | 8 |
1 | 7 |
2 | 6 |
3 | 5 |
5 | 4 |
Когда проставлять ICE-оценки
Напомню, что одной из наших целей было научиться определять приоритет продуктовой задачи без участия PO, и вариант того, что оценки есть только у него в голове, нас не устраивал. Поэтому мы решили ввести мероприятие, аналогичное PBR, которое прозаично назвали product score backlog refinement (PSBR).
Это еженедельная встреча, на которой мы всей командой садимся и проходимся по новым задачам, которые появились в бэклоге и не имеют оценки. Обычно их приносит PO, но может и любой желающий. Также в бэклог попадают задачи из фичреквестов коллег или по обратной связи обзора спринта. Процесс оценки задачи со временем стал достаточно быстрым: сейчас на разбор 10 задач мы тратим не более получаса. После того как все оценки расставлены, мы или смотрим на roadmap, и проверяем, что оценили всё, что требуется сделать на ближайший спринт, или проходимся по бэклогу снизу вверх и проверяем приоритеты у задач.
Мелкие задачи
Теперь о наболевшем. Что делать с достаточно мелкими задачами, которые невозможно оценить? Или что делать, если задача не несёт продуктового импакта, а делать её надо? А что если мы потратим больше времени на оценку всех задач, чем на производство фич?
Если задача маленькая, простая, её невозможно оценить, но точно надо делать — не тратьте время на оценку. Поставьте каждому критерию по 10 priority points. Так задача всегда будет на самом верху списка, просто берите её и делайте. Но не стоит поступать так с каждой задачей — это уже будет жульничеством. У нас в команде есть соглашение, где мы договорились что если задача не сложнее 2 SP, то мы берём её с высоким приоритетом и делаем.
Зелёные задачи
Эту концепцию мы взяли у Макса Дорофеева, автора «Джедайских техник». По его мнению, существуют два типа задач: красные и зелёные. Красные задачи необходимо делать, чтобы выжить. Зелёные же задачи могут сделать тебя счастливее.
Если мы понимаем, что задача на оценке не набирает достаточный балл приоритета, чтобы начать её делать в ближайшее время, но команда от выполнения задачи станет счастливей, мы помечаем такую задачу тегом “green”. По нашим соглашениям мы берём хотя бы одну задачу с тегом “green” в спринт.
Выбор инструмента для работы с приоритетами
После определения модели работы с приоритетами, мы хотели подобрать инструменты для того, чтобы органично встроить её в наш рабочий процесс.
Наш основной инструмент для работы с задачами — Jira. Но из коробки в нём не было инструментов для работы с приоритетами на основе ICE. Поэтому мы провели небольшое исследование рынка. По итогу составили таблицу плюсов и минусов для разных инструментов:
Hygger.
Плюсы:
Перспективный инструмент для PO.
Модный, молодежный, интуитивно понятный.
Приоритизация из коробки по ICE, RICE, Value/Effort и т. д.
Минусы:
Нет интеграции с Jira.
Авито не использует этот инструмент.
Будет дублирование задач, если мы не перейдём полностью в Hygger.
Google sheets.
Плюсы:
Инструмент прост в освоении.
Бесплатный.
Минусы:
Дублирование задач в Jira и Google sheets.
Со временем список задач превратится в стену текста, и с ним будет очень сложно работать.
Jira с платными плагинами.
Плюсы:
Инструмент, используемый всеми в компании.
Единый рабочий процесс.
Минусы:
Нет нужных плагинов.
Взвесив все плюсы и минусы, мы решили попробовать Hygger. И первое время это было классно.
Как нам казалось:
Перенесли бэклог.
Приоритизировали.
…
Profit.
К сожалению, спустя месяц стало понятно, что ведение списков задач одновременно в двух местах требует достаточно серьёзной когнитивной нагрузки. А перейти полностью на Hygger не было возможности из-за глубокой интеграции рабочих процессов в продукты Atlassian.
Мы продолжали вести приоритизацию в Hygger, но стали смотреть в сторону плагинов для Jira. Это стало неплохим челленджем для того, чтобы научиться грамотнее её использовать. Мы нашли плагин Issue Score, который подходил для наших задач.
Этот плагин позволяет создавать формулы, считать на их основании приоритет, выводить приоритет на карточку задачи и, что очень важно, на table view. Единственный минус плагина — он платный, от 250 долларов в год. Но удобство работы того стоит.
После прикручивания плагина, мы добавили поля Confidence, Impact и Ease в карточку задачи, а также вывели приоритет на общий список задач на доске, с фиксированной сортировкой по значению этого приоритета.
Вот как стал выглядеть наш список задач:
Также в Jira мы создали правило, что зелёная задача с тегом “green” подкрашивается в этом списке. Теперь работа с приоритизацией бэклога стала действительно удобной.
Подводя итог
Давайте ещё раз пройдемся по пунктам того, что мы хотели в целевой картине, и что получилось в итоге.
Хотели:
В команде есть методология оценки задач.
Бэклог всегда находится в актуальном состоянии и отсортирован по приоритету.
Команда, когда это необходимо, может дать оценку приоритета новой задаче без PO.
Новые задачи не теряются в недрах бэклога, и им проставляется приоритет на общекомандных мероприятиях.
Фичреквесты не теряются в недрах Слака и других средств обратной связи.
Получили:
По прошествии года можно сказать, что методология ICE нам отлично подходит. Но у нас всё так же довольно большое количество гипотез. К выбору методологии оценки для конкретной команды стоит подходить исходя из того, чем эта команда занимается. Один из главных элементов оценки в ICE — это Confidence, при низкой уверенности мы вполне можем или отказаться от задачи, или провести A/B-тест для того, чтобы повысить уверенность.
Бэклог всегда находится в актуальном состоянии. Каждый спринт мы проходимся по нему, обновляем приоритеты. Посмотрев на бэклог в Jira, можно увидеть наши фокусы на ближайшие 2-3 спринта.
Мы можем дать оценку задаче без PO, но тут нужно понимать, что оценка будет тем точнее, чем раньше мы подключились к процессу работы по ней. Тут отдельно хочу отметить, что включение этого пункта в целевую картину дало интересный побочный эффект. Практически каждый спринт мы стали брать задачи в discovery внутри команды - т.е. мы начинаем работать не с конкретными требованиями по задаче, а с гипотезой о том, как она может повлиять на продукт. Проводим тесты, делаем А/Б и т.п.
Новые задачи теперь теряются редко. Мы создали отдельный фильтр по новым задачам и задачам без приоритета, и на PSBR идём по этому списку.
Фичареквесты теряться стали значительно реже после того, как мы приняли соглашение, что будем заводить их в Jira или приносить на дейли сразу, как только увидели. После этого мы оцениваем каждый реквест и либо кладём его в бэклог, либо выкидываем.
Мы научились эффективнее работать в Jira, и теперь при взгляде на бэклог не появляется вопрос «а дальше что?». PO спокойно может идти в отпуск, не думая, что разработка будет сконцентрирована в его отсутствие на разгребании техдолга.
Зелёные задачи позволили постоянно держать мотивацию команды на высоком уровне.
На этом всё. Задавайте любые вопросы в комментариях.
