4 способа приоритезировать беклог самому или с клиентом

hard_decisions

В Sigma Software каждую неделю проводим мероприятие – Management Excellence, где менеджеры обсуждают насущные проблемы управления проектами. После своего выступления оформил пост в блог.

С распространением agile, задача по приоритезации беклога перекладывается на плечи Product Owner-a. Product Owner хочет все и сразу и все задачи для него самые важные и нужные. Тут на сцене и должен появится менеджер, который сможет с одной стороны объяснить клиенту зачем задачи стоит ранжировать, а с другой стороны сможет помочь решить, что делать стоит, а что может и потерпеть до следующего релиза.

Ресурсы проекта – ограничены. Мир меняется слишком быстро и то, что было важно вчера, сегодня уже не имеет значения. Если делать все подряд и все считать самым важным, завтра ты окажешься на помойке. Есть ряд вопросов, на которые стоит ответить каждому менеджеру:

  • Какую ценность принесут эти фичи? Действительно ли это ценность?
  • В каком порядке стоит расположить задачи?
  • Можем ли сделать лучше?

Они дают возможность взглянуть на обстановку трезвым взглядом.

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

При подготовке к презентации я искал хороший пример визуализации существующих методов приоритезации беклога. И нашел пример ниже:

periodic

Периодическая таблица отлично категоризирует различные техники по 4 параметрам:

  • Внутренний-Внешний
  • Качественный-Количественный.

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

В своем докладе я рассмотрел 4 метода из каждого квадранта, где проанализировал слабые и сильные стороны метода присущие всему квадранту:

Фича от английского feature (ˈfiːtʃə/) – отличительный признак или аспект чего-то.

Classification Ranking

Простой, словно палка и надежный, как валенок. Если вам хоть раз в жизни приходилось приоритизировать задачи на день или на год, вы 100% использовали. Относится к квадранту Качественный-Внутренний. Метод не требует привлечения внешних участников – хватит только вашего участия. Оценка производится на основе экспертного мнения.
Суть – мы выбираем уровни классификации, например 1, 2, 3, 4. Или Высокий, Средний, Низкий. Каждый элемент мы прогоняем через эти определения присваивая ему тот или иной ярлык. Затем, если вы делаете это в Excel или подобном инструменте, самый важные элементы (1 или Высокий) поднимите наверх, а неважные оставить внизу.
Проблема заключается в том, что грань между Высокий и Средний пролегает только у вас в голове и вам тяжело договориться с другими участниками оценки. У всех разное понимание. Но плюс заключается в скорости и простоте. Затраты времени – минимальны и результат легко интерпретируется.

MoSCoW

Как решение проблемы с разграничением уровней классификации была предложена мнемоническая формула MoSCoW: Must, Should, Could, Wouldn’t.

g172_moscow

Мы сдвинулись в квадрант Качественный-Внешний и метод предполагает привлечения большего количества участников для оценки. Принцип остался прежним, но реализовать стало проще. Если вы хотите быстро с клиентом обсудить, что стоит включить в релиз, то данный подход отлично подойдет. Различие между Must, Should, Could, Wouldn’t интуитивно понятно, скорость внедрения остается высокой, а результат интерпретируется также быстро.

Хотя из практики, я бы советовал не заниматься такой важной задачей на скорую руку. Но для глубокой и детальной оценки задач MoSCoW не подойдет все из-за тех же изъянов, что присущи и Classification Ranking.

Scorecard

Количественные методы призваны решить проблему с рассинхронизацией мнений. Приводя все к общему знаменателю вы просто нивелируете различие во взглядах. В квадранте Количественные-Внутренние, метод Scorecard подойдет вам, если вы хотите подвести к показателям объективную базу. Метод предполагает определенную подготовку:

  • Определите критерии, по которым будет происходить оценка. Например, для разработки веб-продукта это может быть: Привлечение новых пользователей, Удержание старых пользователей, Влияние на покупки и т.д. Критерии стоит определять с владельцем продукта.
  • Установите вес для каждого из критериев. Так для вас Привлечение новых пользователей может быть важней, чем Удержание старых пользователей. Для первого поставьте 30%, а для второго – 20%.
  • Выпишите список элементов, которые нужно оценить. Если они слишком маленькие или слишком большие, возникнуть трудности. Держитесь золотой середины.

scorecard-table-884x255

Выполнив данные пункты, вы готовы к оценке. Обратите внимание, что Scorecard не станет бронзовым, когда вы закончите оценку. Его стоит пересматривать на регулярной основе. Сама оценка происходит следующим образом:

  • Вместе с участниками проекта вы поочередно проходите по списку задач и проставляете значение для каждого из критериев. Значение должно быть в диапазоне от 1 до 100.
  • Подсчитайте сумму значений для каждого из критериев умноженных на свой вес.
  • Сравните суммы, которые у вас получились в графе Итого и проранжируйте их по возрастанию.
  • Задача получившая наибольшее количество баллов получает первый приоритет.

Данный метод можно использовать не только для приоритезации задач, а для оценки удовлетворенности клиента. У меня был кейс, когда мы провели опрос клиентов удовлетворенностью работой команды, используя Scorecard. Результаты получались объективными и прозрачными.

Kano Model

Самый сложный метод в списке лично для меня. Краеугольным камнем данного подхода, является определения Удовлетворенности. Модель пытается ответить на следующие вопросы:

  • Что такое Удовлетворенность?
  • Что нужно сделать, чтобы ее достичь?
  • Что нужно сделать, чтобы удовлетворенность превратить в Наслаждение?

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

Метод исходит из следующих предпосылок:

  • Удовлетворение пользователей зависит от уровня Функциональности, предоставляемой нашим продуктом.
  • Все функции можно классифицировать в 4 категории.
  • Определить, что пользователь чувствует о каждой из функций можно с помощью опросника.

Удовлетворенность имеет градацию от фрустрации до восторга и ее можно расположить на вертикальной оси графика. Функциональность расположим на горизонтальной оси. Есть 4 категории: Performance, Must-be, Attractive, Indifferent.

  • Must-be – обязательные для продукта функции. Например, если мы говорим про телефон, то Must-be – это звонилка и смс. Если мы говорим про интернет-магазин, то это будет корзина, и оплата, и поиск.
  • Performance – это функции, которые обеспечивают производительность вашего продукта и отличают его от других. Например, если это магазин, то Performance – это wish-list и сравнение.
  • Attractive – это функции, которые позволяют отличить ваш продукт от конкурентов и привлечь новых пользователей. Например, у телефона Nextbit Robin такой функцией является неограниченный объем облачного хранилища. У айфона такой функцией выступают iMessages и FaceTime.
  • Indifferent – функции, которые совсем никак не влияют на уровень удовлетворенности клиента.

FullKanoModel

Определить, что клиент думает о вашем продукте, можно через опросник. Опросник Кано состоит из пары вопросов к каждой фиче, которую мы хотим оценить.

  • Один вопрос спрашивает, как клиент будет себя чувствовать, если фича будет в продукте.
  • Другой вопрос уточняет, как он будет себя чувствовать, если фичи в продукте не будет.

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

  • Мне это нравится
  • Я это ожидаю
  • Нейтрально отношусь
  • Могу потерпеть
  • Мне не нравится

Когда у нас есть ответы, мы будем использовать таблицу ниже, для анализа ответов.

EvalTable-Mod

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

  • Давайте возьмем ячейки помеченные как M. Эти фичи – Must Be. Т.е. фичи-продукты, которые должны быть в нем обязательно, и пользователи ожидают их там увидеть и очень расстроятся, если их там не будет.
  • Ячейка, обозначенная как Р – Performance. Т.е. пользователям нравится, что она есть в продукте и не понравится, если ее нет.
  • Ячейки, обозначенные как А – Attractive. Т.е. фичи, которые пользователи ожидают увидеть, но в случае чего, могут и потерпеть, если их не будет.
  • Ячейки, обозначенные как I – Indifferent. Т.е. фичи, чье наличие или отсутствие пользователь не заметит.

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

Общее правило, фичи нужно приоритезировать следующим образом: Must-Be > Performance > Attractive > Indifferent.

Таким образом, вы получаете следующее:

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

Подводя итоги, привожу 5 пунктов с главными выводами:

  • “Серебряной пули” не существует. Не ищите метода, который решить ваши проблемы, будет легок в использовании и давать точные результаты.
  • Начинайте приоритезировать использую верхниеуровневые задачи и постепенно опускайтесь ниже по WBS. Начните с эпиков, потом идите к пользовательским историям и только затем переходите к задачам.
  • Поймите зачем вы это делаете. Только с четкой целью перед глазами данный процесс принесет вам пользу. И не забывайте проверять цель на актуальность, ведь мир меняется.
  • Не делайте это в одиночку! Помните, что продукт принадлежит не только вам. Есть еще команда, Product Owner и конечные пользователи.
  • Автоматизируйте. Везде, где только можно, автоматизируйте рутину. Если можете настроит автоматическую сортировку по лейблам в Jira – делайте. Если процесс приоритезации занимает слишком много времени, значит вы что-то делаете не так.