Сначала более ценная и короткая работа

Привет всем читателям, желающим грамотно выстраивать самые многозадачные бэклоги. Меня зовут Фёдор Гвоздев, я основатель интернет-магазина корейской косметики HolySkin. Работаю над развитием этого проекта уже 8 лет и не раз сталкивался с трудностями приоритизации. В этой статье я постараюсь поделиться своим опытом и представить самые «рабочие» модели, которые не раз выручали нас в работе.

Введение

В любом планировании однажды наступает момент, когда требуется выработка новой стратегии, расстановки приоритетов. Многие менеджеры сталкиваются с хаотичными предложениями и мнениями, что сбивает с верного пути и как итог – важные фичи брошены или не начаты, цели не ясны, команда теряет мотивацию.

Возникает вполне логичный вопрос – «Как эффективно расставить приоритеты работы команды?»

Эффективная организация – залог успеха любого проекта, но как выстроить её грамотно, исключая бесконечные звонки, споры и презентации? Работа с бэклогом не так проста, как может показаться и, чтобы добиться реального результата, при минимальных затратах на его разработку, стоит прибегнуть к приоритизации задач. Для этого существуют специальные механизмы. Они дают возможность перейти от словесных перепалок к количественным оценкам, матрицам и диаграммам, которые приведут команду к построению продуктивного алгоритма действий.

В данной статье рассмотрим самые популярные модели приоритизации задач и разберёмся почему важно их использовать.

ICE - быстрый метод приоритизации

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

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

Рассмотрим состав аббревиатуры:

  • Impact – маркер говорит о том принесёт ли внедрение инициативы, технологии экономический рост или увеличение другого ключевого показателя, относительно которого проводится оценка задач.

  • Confidence – показатель уверенности в успешности исполнения, зачастую, основывается на двух оставшихся критериях.

  • Ease – оценка трудо- и ресурсоёмкости проекта.

Процесс оценки

В механизме используется шкала от 1 до 10 для каждого критерия, затем при перемножении значений трёх компонентов получается итоговое ICE Score, а все фичи ранжируются по важности.

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

Пример оценки

Собираем список задач, и оцениваем каждую по 10-бальной шкале, начиная с первого столбца - impact.

Пример таблицы подсчета ICE Score
Пример таблицы подсчета ICE Score

Плюсы:

  • Простота понимания алгоритма.

  • Высокая скорость принятия решений.

Минусы:

  • Субъективность, здесь отсутствуют объективная оценка и расчёт. Относительность результатов может стать причиной потери важной задачи или её смещения с более высокой позиции.

RICE

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

Не смотря на схожесть составляющих RICE и ICE, отличаются они не только уровнем объективности оценки, но и составляющими процесса оценки.

Дадим объяснения каждого компонента: 

  • Reach – количество охваченной аудитории, которую затронула фича или его внедрение, в реальных числах.

  • Impact – пользы от внедрённой фичи итоговому продукту или всему проекту.

  • Confidence – показатель уверенности в успешности исполнения. В модели RICE измеряется в процентах и позволяет исправить ситуацию, когда нет конкретных доказательств уверенности во влиянии.

  • Effort – характеризует трудозатраты и выражается в задействованных людях в месяц для реализации одного проекта.

Для ясности – если проект состоит из этапов – планирование (1 человек) – 1 неделя, дизайн (1 человек) – 2 недели, разработка (1 человек) – 3 недели, то в сумме мы получаем 3 членов команды на 6 недель работы. Трудозатраты (Effort) равны двум.

Процесс оценки

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

Пример оценки

Оцениваем каждый фактор по методике, описанной выше, и считаем итоговое количество баллов по формуле.

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

Плюсы:

  • Количественная оценка полезности и трудозатрат снижает уровень субъективности приоритизации.

Минусы:

  • Риск необходимости переоценки. Результат по методике RICE нельзя считать окончательным, так как она всё же является более систематизированной моделью уверенности команды в той или иной фиче.

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

WSJF – Weighted Shortest Job First

Универсальная и наиболее эффективная модель приоритизации. Рассматривает оптимальное количество критериев, что позволяет рационально структурировать работу.

Название механизма — это аббревиатура фразы «Weighted Shortest Job First» – самые важные и простые задачи первостепенны, в ней и заключена идея приоритизации. После оценки вы получите готовый список, в котором задачи будут убывать по сложности реализации и эффективности для вашего проекта.

Вычисления при использовании данной модели сводятся к одной простой формуле, но сложность появляется в составной части числителя, так как cost of delay складывается из ещё трёх критериев оценки. Именно такая составляющая делает WSJF действительно эффективной.

Рассмотрим детально все компоненты системы:

  • Cost of delay (= User-Business Value + Time Criticality + Risk Reduction or Opportunity Enablement) – техническая сложность реализации работы, которая включает в себя:

    • User-Business Value ­ (бизнес ценность) – критерий, оценивающий как полезна задумка, задача будет для бизнеса.

    • Time Criticality (временная критичность или спешка) – как важно сделать задачу быстро или её выполнение может подождать.

    • Risk Reduction (фактор риска) – оценивая этот параметр фактически нужно ответить на вопрос – «от каких рисков мы сможем себя уберечь? ».

    • Opportunity Enablement (фактор возможностей) – количество потенциально открытых возможностей.

  • Job size (ресурсозатратность) – включает в себя трудовые ресурсы, сроки работ, затраты на внештатных работников.

Процесс оценки

Для наиболее эффективной оценки фичей по WSJF часто используют StoryPoints или ScrumPoints – мера трудоёмкости или сложности задач бэклога. Она основана на числовом ряде Фибоначчи – числовая последовательность, где первый элемент 1, а последующие равны сумме двух предыдущих.

Система поинтов от низшего к высшему, основанная на ряде Фибоначчи
Система поинтов от низшего к высшему, основанная на ряде Фибоначчи

Числа увеличиваются не линейно, за счёт чего при оценке разница между задачами с 1 и 5 StoryPoints становится более очевидной и упрощает выбор.

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

Таблица подсчета WSJF оценок
Таблица подсчета WSJF оценок

Он сводится к созданию матрицы с итоговыми оценками. Именно из-за матричного вида существует строгое правило заполнения:

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

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

Пример оценки

В качестве примера возьмем бэклог с тремя фичами для нашего интернет-магазина. Задача - провести оценку по всем инструментам в Cost of delay для каждой функции. Напомню, что оценка производится по ряду Фибоначчи.

Посе Job size рассматривается как затраты человеческих ресурсов – этот алгоритм был разобран в примерах ранее.

Получаем следующий вид:

Оцениваем последовательно, по одной колонке, всегда проставляем единицу для одной из задач
Оцениваем последовательно, по одной колонке, всегда проставляем единицу для одной из задач

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

На мой взгляд данный механизм обладает исчерпывающих количеством инструментов и потому является самым подходящим для приоритизации любого бэклога – от малого до самого «страшного». На данный момент WSJF – фаворит нашей команды.

Плюсы:

  • единовременная приоритизация всего бэклога

  • эффективная шкала оценки

  • важные и актуальные критерии

Минусы:

  • возможность интуитивных результатов при плохой коммуникации бизнеса и исполнителей

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

Заключение

Приоритизация задач – сложный и затяжной процесс. Фреймворк в этом случае является отличным помощником, но, несмотря на это требует доработки со стороны менеджера.

Механизмы как RICE, ICE, WSJF хотя и не всегда исчерпывают работу над ранжированием приоритетов, являются эффективными и способны достаточно сильно изменить вектор работы – уберечь от финансовых потерь и избавить от выполнения бесполезных задач.

RICE и ICE – это отличный вариант для еженедельных совещаний с командой, поможет быстро внести ясность в предстоящую работу и придать мотивации.

WSJF – более сложный инструмент для многозадачных бэклогов, его эффективность не раз подтверждается на моём личном опыте. Использовать его можно для проектов, где потери могут быть слишком велики.

Причины использовать модели приоритизации в своей работе:

  • В процесс принятия решений включается вся команда.

  • Значительное сокращение времени.

  • Избавление от бесконечного количества звонков, презентации и собраний.

  • Эффективное формирование целей по Smart.

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

Удачных проектов!

Комментарии (18)


  1. Luchnik22
    01.02.2023 01:22

    Был опыт с системой похожей на WSJF, но только в которой продукт сам выбирал критерии (в том числе сложность, бизнес эффект и т.д.) у которых были веса, там было порядка 12 критериев и вес каждого менялся в зависимости от ситуации, формула выглядела очень сложной, но вся суть сводилась к примерно этому:

    критерий 1 *  вес критерия 1 + критерий 2 * вес критерия 2 + ... критерий N + вес критерия N = результат / размер задачи = score


  1. 2er6e1
    01.02.2023 04:54

    бэклоги?

    это что за "дата"?

    тут не про информационный мусор, случайно?


    1. 2er6e1
      01.02.2023 06:44
      -1

      тест

      delete

      ну и хабр у вас тут.

      опрометчивые месседжи собираете?

      удалить невозможно.


  1. MikhailZakharov
    01.02.2023 10:33

    Вопрос не с целью подколоть, но почему вы используете скоринговые системы? Они имеют смысл только если несколько менеджеров продукта конкурируют за ресурсы. Или несколько проектов конкурируют за ресурсы. В остальных случаях упрощенной модели (круто / не круто) типа Kano будет достаточно.


    1. Luchnik22
      01.02.2023 14:49

      Вначале статьи сказано:

      В любом планировании однажды наступает момент, когда требуется выработка новой стратегии, расстановки приоритетов. Многие менеджеры сталкиваются с хаотичными предложениями и мнениями, что сбивает с верного пути и как итог – важные фичи брошены или не начаты, цели не ясны, команда теряет мотивацию.

      Возникает вполне логичный вопрос – «Как эффективно расставить приоритеты работы команды?»

      Однако в таком скоринге нет необходимости, если вы живёте по какому нибудь OKR, у вас есть Research отдел и цели проробатываются с менеджментом выше

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


      1. MikhailZakharov
        01.02.2023 15:12

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


        1. acmnu
          01.02.2023 17:20

          Такой подход наиболее эффективен при очень большом бэклоге для компании на b2c рынке. Там фишка в том, что 80% бэклога никогда не будет сделано и надо делать то, что горит прям сейчас ибо конкуренты не дремлют. Отсюда довольно простая логика сводящаяся к сравнению циферок.


          1. MikhailZakharov
            01.02.2023 18:04

            Готов поспорить, качественная модель будет быстрее для больших беклогов, так как параметр всего один или два. Количественная требует оцифровки. Для 1000 требований по модели RICE вам нужно будет оценить 4000 параметров. Рынок не имеет значения.

            Я вижу только два случая когда нужна количественная оценка: когда одна команда работает над несколькими продуктами, или когда менеджмент требует пояснений на основе цифр; фичу А надо делать так как она оценена в 300 попугаев, а фича Б, напротив, в 100. Не встречал других случаев. Поэтому и интересуюсь реальным применением. Возможно есть еще ситуации.


            1. acmnu
              02.02.2023 09:44

              Не очень понятно что вы понимаете под "качественной" моделью. Так-то I в ICE/RICE это тоже вполне себе качество.


              1. MikhailZakharov
                02.02.2023 10:30

                Оценки вида: будет ли удовлетворен пользователь, сможем ли мы реализовать фичу полностью. Сводится все к оценке удовлетворенности в итоге: понравится или нет результат. И опросы проводить проще.

                "I" это единственный параметр, который можно связать с качественной оценкой. Остальные нужно оцифровывать, т.е. сначала описать как вы начисляете баллы, а потом эти баллы считать. Надо ли это делать в вашем конкретном случае? Что произойдет если вы не будете использовать ICE/RICE, а просто разметите свой беклог тегами удовлетворенности пользователей, в зависимости от того будете ли вы делать эту фичу или нет?

                Пример


                1. SergeyT-hh
                  02.02.2023 12:41
                  +1

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


                  1. MikhailZakharov
                    02.02.2023 13:38

                    Разумно. Это аргумент в пользу количественных моделей. Получается, что если у продукта много разных групп пользователей, а главное если и экономика продукта построена на группах, то такие модели полезны.


                1. acmnu
                  02.02.2023 14:49

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


                  1. MikhailZakharov
                    02.02.2023 16:45

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


                    1. acmnu
                      02.02.2023 17:37

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


  1. acmnu
    01.02.2023 17:23

    При всех этих подходах необходимо разделение бэклогов (даже для одно приложения) на пользовательские и, скажем так, системные. Все что связанно с архитектурными изменениями, рефакторингами и т.д. должно оцениваться в разрезе снижения костов или повышения качества, а это уже не ICE/RICE.


  1. TyVik
    02.02.2023 06:16

    Так вот почему до рефакторинга дело никогда не доходит! Там же impact для пользователя как правило 0. А стабильность приложения почему-то воспринимается как данность, а не как фича, над которой тоже нужно работать.


  1. SergeyT-hh
    02.02.2023 12:52

    Не очень понятно зачем все параметры сворачивать в один показатель.

    Оценка бизнес-ценности все равно обладает большим весом в принятии решения и не нужно её размывать. Оценка трудоемкости, конечно нужна и влияет на принятие решений, но она вполне может жить отдельно, например, в виде оценки задач estimate.