Мы не верим стикерам! Или как аналитики Рук поставили под сомнение результаты Воркшопа по Продукту

Кто мы и чего хотели

Мы — команда Рук (https://hands.ru), — пришли к необходимости сформировать SCRUM-команду для работы с продуктовым бэклогом. Для этого мы попросили Илью Павличенко и Рому Дорошенко провести у нас воркшоп по продукту, на котором мы разбирались, на какие компоненты можно разложить задачи из бэклога и какие компетенции потребуются в SCRUM-команде.

Табличка компонент бэклога

Так выглядят таблицы компонент (HitMap) и компетенций (FTAM), выработанные за время воркшопа:

Таблицы вызывали некоторое недоверие: они очень большие и оттого “непрозрачные”. Чтобы получить какое-то понимание, мы решили покрутить таблицу компонент и посмотреть, что и как поменяется. Имели в виду при этом такие соображения:

  1. При составлении FTAM мы считали вклад от всех задач бэклога одинаковым. Но вообще-то они упорядочены по убыванию приоритета. Хотелось попробовать по-разному учитывать этот эффект и посмотреть, что изменится.
  2. За время воркшопа мы в нескольких командах выписывали все компоненты, встречающиеся на пути пользователя. Задачи бэклога разложились по ним довольно естественно (не нашлось ненужных компонент; каждая задача компонентами более-менее описывается). Поэтому кажется, что принципиально новых компонент не должно прилететь — можно считать список компонент неизменным.
  3. Ещё мы посмотрели, выделяются ли среди компонент группы чем-то “похожих” (по задачам тоже посмотрели), но никаких откровений не нашли.

Вклад от задач в зависимости от приоритета

Интуитивно кажется, что менее приоритетные задачи при планировании компетенций scrum-команды нужно учитывать с меньшим “весом”, чем более приоритетные. Но как именно? Мы попробовали такие подходы: равнозначные задачи (“вес” 1), 1/n,1/n, 1/2n, где n — порядковый номер задачи в бэклоге. Вот визуализация того, как будут перемещаться важности компонент:

На картинке видны какие-то непонятные разноцветные линии. Для себя мы сделали такой вывод: вес1/2n слишком радикально работает (учитывает, по сути, только компоненты из первых 5 задач). А из остальных трёх вариантов большой разницы не видно. В итоге выбрали вес с корнем как “средний” вариант.

Интересный факт: две топовые компоненты (аналитика и backend) сохраняют свои позиции независимо от выбора “веса”.

Вывод про устойчивые компоненты

Со временем бэклог продукта будет меняться. Приоритеты меняются, задачи приходят и уходят (и иногда закрываются). Попробуем смоделировать, как при этом будут меняться требуемые от команды компетенции.

Для простоты ограничимся следующим:

  1. Новых задач не ожидаем;
  2. Возвращение старых задач игнорируем;
  3. Перемешивать задачи внутри бэклога не планируем.

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

Посмотрим, как будет меняться бэклог:

Видим, что топ-компоненты (а именно backend и frontend, аналитика, мастера и админы и их должностные инструкции) стоят на месте, а начиная с 7-ой компоненты уже происходит некоторая ‘болтанка’, усиливающаяся по мере увеличения позиции. Интерпретируем это так: основной список компетенций не будет меняться со временем. Любопытно, что туда вошли мастера-ремонтники (получают от нас заказы и выполняют их) и администраторы (обрабатывают заказы).

Что дальше?

А дальше мы провели селф-дизайн воркшоп и запустили скрам. Уже 3 месяца, а новых зависимостей нет. Инструмент отработал штатно в теории и на практике, рекомендуем!

Авторы статьи: Антон Воробьёв и Пётр Ширяев, HANDS.RU

 

 

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *