2 уровня и 5 техник приоритизации проектов Big Data и цифровизации
Сегодня мы поговорим про одно из ключевых понятий управления проектами и бизнес-анализа: что такое приоритизация, почему это важно в цифровизации и внедрении технологий больших данных (Big Data). Также рассмотрим основные методы и практические техники расстановки приоритетов, которые будут полезны каждому менеджеру (руководителю) и любому специалисту: аналитику, разработчику, инженеру и исследователю данных (Data Scientist).
Что такое приоритизация и зачем она нужна в Big Data и цифровизации
Начнем с определения, которое приводит BABOK, профессиональный стандарт бизнес-аналитика [1]: приоритизация – это процесс определения относительной важности объекта (информации, задачи, требования и пр.) на основе предварительной оценки его значения, рисков, сложности реализация или других четких критериев. В свою очередь, дисциплина управления (Project Management) проектами также рассматривает
Таким образом, можно выделить 2 уровня приоритизации:
- стратегический, когда, например, директор по цифровизации или C-менеджер (CEO, CTO, CFO или другой руководитель высшего звена) формируют портфель проектов, определяя долгосрочную программу развития предприятия или управления изменениями в рамках цифровой трансформации;
- тактический, когда бизнес-аналитик или менеджер проекта определяет важность отдельных задач или требований к проектируемому решению, например, системе прогнозирования потребительского спроса на основе технологий Big Data и Machine Learning.
При том, что для каждого из этих уровней существуют свои методы расстановки приоритетов, они все направлены на определение важности каждого компонента. Это необходимо, чтобы в первую очередь инвестировать ресурсы (финансы, время и силы) именно в компоненты с наивысшим приоритетом. Для рассматриваемых нами примеров проекта цифровизации и внедрения Big Data продукта, стоит отталкиваться от главной цели проекта или основного назначения программного продукта, а также учитывать их эффективность
Цифровизация: как рассчитать приоритет проекта
С точки зрения бизнес-аналитика в рамках управления требованиями к разработке программного обеспечения, приоритет – это атрибут (свойство) самого требования. Этот показатель определяет важность каждого требования относительно других. Например, к реализации какой функции стоит приступить прежде всего [4]. При этом BABOK выделяет 4 подхода к приоритизации [1]:
- группировка – объединение требований в категории с высоким, средним и низким приоритетом;
- ранжирование – составление упорядоченного списка, например, бэклог продукта (backlog) в Agile-подходе к разработке ПО;
- ресурсные ограничения (время и/или бюджет) – расстановка приоритетов на основе объема работ, которую команда проекта способна выполнить за установленный период времени или за фиксированное количество денег (бюджет). Этот подход чаще всего используется, когда необходимо соблюсти четкий срок или для решений, которые улучшаются на регулярной и частой основе;
- мнение заинтересованных лиц (стейкхолдеров) — установление консенсуса между заинтересованными сторонами относительно того, какие требования будут наиболее важными. На практике достичь такого согласия весьма проблематично
В портфельном управлении чаще всего используются следующие подходы к приоритизации [2]:
- весовое ранжирование – попарное сравнение проектов по одному критерию с помощью матрицы или таблица многокритериального сравнения;
- скоринг – численные методы для объединения ранжированных компонентов внутри каждой категории;
- экспертная оценка, основанная на анализе подобных случаев в данной предметной области.
На практике для оценки важности проекта используются составные формулы для расчета приоритетов на основе классификационных признаков и мультипликаторов. Например, инновационность, рискованность, объем сторонних инвестиций, стратегическая важность, наличие подтвержденного финансирования и т.д.
Разумеется, приоритизация в портфельном управлении и в анализе требований – это разные процессы. Обычно проекты цифровизации представляют собой можно комплексные организационно-технические мероприятия с большими бюджетами и различным содержанием. Поэтому наиболее эффективно сравнивать эти неоднородные компоненты по финансовым показателям. В свою очередь, отдельный проект по реализации или внедрению Big Data системы представляет собой набор взаимосвязанных задач, которые уже можно считать более-менее однородными по содержанию. Таким образом, приоретизировать их можно по степени влияния на общий результат. Для этого используются практические подходы (техники), самые популярные из которых мы рассмотрим далее.
5 популярных техник приоритизации
Итак, на практике наиболее часто используются следующие техники расстановки приоритетов среди однородных задач [7]:
- Impact/Effort [8] – как потраченные на реализацию задачи усилия соотносятся с нужным бизнесу результатом. В отличие от финансового показателя по возврату вложенных инвестиций (ROI), данный подход рассчитывается не в денежном выражении. Усилия можно оценивать в человеко-часах или пункты пользовательских историй b и вариантов использования (use case). Влияние может распределяться по шкале 1-5или категориям высокое/среднее/низкое.
- Модель Кано, основанная на эмоциональном восприятии пользователем той или иной функциональности, например, [9]:
- Must Be— минимальные требования, при отсутствии которых пользователь не удовлетворен;
- Indifferent— требования с неоднозначной реакцией пользователей, которым, в основном, все равно, реализованы они или нет;
- Satisfiers (Performance)— функции, которые вызывают удовлетворенность, если они реализованы хорошо, или разочарование в противном случае.
- Exciters (Attractive) – дополнительные функции, которые повышают удовлетворенность пользователя, если они есть. Но их отсутствие не вызовет недовольства.
В первую очередь следует реализовать задачи уровней Must be, затем — Satisfiers и только потом перейти к Exciters. Похожей на Kano техникой приоритизации считается метод MosCow, который делит требования на 4 категории: must, should, could, would
- Must – то, что необходимо сделать в любом случае. Без выполнения этих задач продукт не будет работать в принципе;
- Should – не самые важные требования, но они тоже должны быть выполнены после реализации «must»;
- Could – желательные требования, которые можно сделать, если останется время и будут ресурсы;
- Would – требования, которые хотелось бы сделать, но их можно проигнорировать или перенести на следующие релизы без вреда для продукта.
- Подход RICE, предложенный ИТ-корпорацией Intercom для оценки продуктовых изменений
- Reach (охват) — сколько пользователей охватит это нововведение;
- Impact (эффект)— насколько оно улучшит или ухудшит жизнь/работу пользователей;
- Confidence (уверенность)— степень уверенности в том, что вообще можем что-то улучшить;
- Effort (усилия)— сколько времени и других ресурсов понадобится, чтобы реализовать задуманное.
- Метод Карла Вигерса (Karl Wiegers), когда по шкале от 1 до 9 оцениваются польза (benefit), вред (penalty), расходы (cost) и риски (risk). Пользователи оценивают пользу от присутствия функциональной возможности (фичи) и вред от ее отсутствия. А разработчики оценивают стоимость реализации этой фичи и риск, связанный с ее разработкой. Полученные таким образом предварительные оценки подставляются в заранее составленную формулу и рассчитывается коэффициент приоритетности
- Feature Bucket (ведро фич) – подход от экс-СEO соцсети LinkedIn Адама Нэша (Adam Nash). Все фичи условно делятся на 3 категории [13]:
- Metric Movers – наиболее востребованные бизнесом функции и продуктовые метрики (охват, доход и пр.).
- Customer Requests – нужные пользователям функции.
- Customer Delight – фичи, которые не обязательно запрашивают пользователи, но которые будут им полезны.
Подводя итог тому, что такое приоритизация и рассмотренным подходам к расстановке приоритетов, отметим, что многие из них применимы не только к ИТ-сфере и управлению проектами по цифровизации, включая разработку и внедрение Big Data систем. По сути, приоритизация – это ежедневная задача каждого бизнес-аналитика, менеджера проектов и руководителя. Поэтому знание методов и техник расстановки приоритетов, как и подходов к экспресс-анализу, будет полезно и для начальника любого уровня.
Другие прикладные вопросы практического применения системного и бизнес-анализа рассматриваются на наших образовательных курсах в лицензированном учебном центре обучения и повышения квалификации ИТ-специалистов (менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data) в Москве:
Источники
- https://analytics.infozone.pro/babok/chapters-of-babok-version-3/
- https://ru.wikipedia.org/wiki/Расстановка_приоритетов_в_портфеле_проектов
- https://www.advanta-group.ru/blog/kak-rasstavlat-prioritety-sredi-proektov-vasej-kompanii/
- https://analystpages.ru/2018/11/12/requirements-prioritization/
- https://pmjournal.ru/articles/keysy/kak-rasschitat-prioritet-proekta/
- https://pmexpert.ru/press-center/news-world/detail.php?ID=11401
- https://dou.ua/lenta/articles/prioritization-approach/
- https://medium.com/@itamargilad/why-impact-effort-prioritization-doesnt-work-57d141fafc2c
- https://foldingburritos.com/kano-model/
- https://vc.ru/hr/63226-metod-moscow-kak-sfokusirovatsya-na-glavnom-i-stat-effektivnee
- https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
- https://www.processimpact.com/articles/prioritizing.pdf
- https://adamnash.blog/2009/07/22/guide-to-product-planning-three-feature-buckets/
5 техник определения приоритетов для IT команд / Блог компании Hygger / Хабр
Всегда ли просто определить приоритеты в задачах крупного проекта? А если в приоритете находятся пять срочных задач? Десять?Опытные менеджеры проектов и собственники продуктов знают, что одной интуицией здесь не обойтись. Для того, чтобы не подвести команду и уложиться в сроки, сегодня на помощь менеджерам приходят полезные методологии определения приоритетов, а также современные инструменты, которые помогают визуализировать данные и ничего не упустить в своих рабочих процессах.
Рассмотрим подробнее 5 известных методологий, которые помогают прийти к успеху.
Существует ли идеальная методология, которая раз и навсегда расставит приоритеты в рабочих задачах и личных делах? У каждого менеджера проектов или менеджера продукта на этот вопрос, наверняка, есть свой ответ. Однако есть методы приоритизации, которые зарекомендовали себя во всем мире, а их авторы получили заслуженное уважение в среде менеджеров проектов и топ-руководителей. Вот 5 таких методологий: три общие и две для внутриорганизационных целей.
5 методов приоритизации для менеджеров проектов и IT команд
Метод MoSCoW для категоризации задач
Методологию MoSCoW сегодня знают во всем мире и применяют широко в разных областях управления. С известной столицей технику ничего не связывает.
Согласные буквы в акрониме MSCW — это степени приоритетности:
- M – задачи и требования, которые имеют самый высокий приоритет и должны быть первоочередно применимы к продукту в первую очередь. Без них релиз не будет выполнен (это must).
- S – важные требования, но не с самой высокой приоритетностью. Обычно они не имеют решающего значения, но все равно обязательны к исполнению (это should).
- C – требования и задачи, желательные для релиза (это could).
- W – наименее критичные требования, их можно проигнорировать или перенести до следующих релизов (это would).
На примере задач платформы для управления Hygger.io (реализованных или только планируемых) рассмотрим, как можно определить приоритеты, согласно методологии MoSCoW:
Метод предлагает быстрое и простое решение для определения приоритетов. Однако часто такой классификации по категориям может быть недостаточно. Поэтому, считается, что MoSCoW лучше подходит для внутренних проектов, а не для продуктов с большим количеством клиентов.
Модель Кано
Модель Кано — технология, разработанная японцем Нориаки Кано в 1984 году. Именно тогда он опубликовал статью, в которой расписал методологию.
С помощью модели Кано можно наглядно описывать удовлетворение каких потребностей оставляет потребителей неудовлетворенными или же приводит в восторг.
Кано предлагает систему координат, где по оси Y измеряется удовлетворенность, по оси Х — уровень выполнения. В модели Кано выделены 3 основные составляющие профиля качества, влияющие на удовлетворенность потребителя: ожидаемое, основное, и привлекательное, вызывающее восхищение.
Ожидаемые свойства по Кано — это базовые свойства продукта или услуги. Они есть по умолчанию. Покупатель вряд ли будет задумываться об этих свойствах, поскольку воспринимает их как что-то само собой разумеющееся.
Часто в качестве примера ожидаемых свойств приводят работу авиалиний. Гарантия того, что всем хватит места в салоне самолета – это ожидаемое свойство.
Ожидаемым свойством платформы для управления продуктами Hygger может быть возможность планировать задачи отдельного проекта. Почти всегда превратить ожидаемое свойство в конкурентное преимущество является сложной задачей, а вот его отсутствие ни к чему хорошему не приведет.
Основные свойства — это желаемое. Их выполнение влияет напрямую на удовлетворенность потребителя. Именно на основных свойствах продукты пытаются выделится и создать конкурентное преимущество.
В примере с авиалиниями, основным свойством может быть отсутствие пересадок на длительном маршруте.
Свойства, вызывающие восхищение — это неожиданные для потребителя свойства: дополнительные, необычные, носящие характер сюрприза.
Ваш любимый десерт на борту авиаперевозчика – пример такого свойства.
Уровень выполнения подобных свойств не влияет на удовлетворенность потребителей напрямую (как и в случае с основными свойствами). Если неожиданное свойство отсутствует, потребитель не должен расстроиться, поскольку и не ожидал его в рядах ожидаемых свойств. Но если же потребитель будет приятно впечатлен – это принесет приятные бонусы продукту или услуге, как минимум, о них узнает ближний круг обрадованного потребителя.
Со временем, требования клиента могут меняться и то, что сегодня вызывало восторг, уже завтра может превратиться в стандарт, а послезавтра стать обязательным условием качества.
Отличный пример применения метода Кано расписан в статье про телевизионный пункт, где автор решил разделить множество замысловатых кнопок пульта по приоритетности, используя принцип Кано.
Техника Story Mapping
Методология Story Mapping стала известна в начале века из статьи Джеффа Паттона.
Смысл метода в том, что бэклога в продукте мало для определения приоритетов в работе. Паттон считает, что необходима более развернутая структура и предлагает следующую механику:
Горизонтальная ось представляет последовательность использования. Задачи на ней размещаются в последовательности, в которой они выполняются пользователем.
Вертикальная ось означает критичность. По вертикали задачи располагаются относительно того, насколько они важны сверху вниз. Одинаково важные задачи можно определять на одной высоте.
Группы связанных историй группируются как активности.
Сильные стороны методологии Story Mapping
Это относительно простое визуальное представление, которое позволяет команде, клиентам, заказчику или другим заинтересованным сторонам делиться общим пониманием происходящего.
Метод четко определяет, как постепенно выпускать итерации продукта.
Внутриорганизационные методологии
Методология KJ
Методологию, придуманную Jiro Kawakita (отсюда — KJ) часто используют на различных тренингах и групповых занятиях по менеджменту. Суть технологии — в групповом процессе установления приоритетов.
Метод KJ — это процесс, состоящий из 8 этапов для групп любого размера. Для реализации такого метода понадобится не менее одного часа. Участникам следует подготовиться:
- Выбрать ведущего (модератора).
- Приготовить много стикеров разных цветов.
- Найти помещение со свободной стеной или большой доской.
- Разместить флип-чарт или отдельную доску для результатов.
8 этапов методологии KJ
- Выберите центральный вопрос, который будет стимулировать результаты. Каждый сеанс предполагает свой центральный вопрос.
- Организуйте рабочую группу. Участники группы должны быть из различных отделов компании.
- “Выгрузите данные” Для этого понадобятся стикеры. Каждому участнику группы предлагается инициировать мозговой штурм в разных направлениях.
- Разместите стикеры на стенке в рандомном порядке. Каждый участник, при необходимости, может добавить новые стикеры на дальнейших этапах.
- Сгруппируйте похожие тематики. Когда все стикеры на стене добавлены, вся группа начинает группировать похожие темы.
- Присвойте имена. Участники должны присвоить имя каждой группе, используя стикеры другого цвета.
- Проголосуйте за наиболее важные, с вашей точки зрения, группы, которые помогут ответить на центральный вопрос.
- Оцените самые важные из групп. Все стикеры помещаются на доске и располагаются по количеству голосов. Участники могут объединять подобные группы, что добавляет их голоса и поднимает их рейтинг. Когда 3-4 группы очевидно опережают остальные, активность завершается.
Техника приоритезации Feature Buckets
Автор методологии — Адам Нэш предложил свою аналогию для определения приоритетов. По его мнению, приоритетность функций сильно различается в разных продуктах и сферах. Поэтому Нэш подчеркивает, что метод был разработан именно под потребительские онлайн-продукты.
Согласно методу, функции нужно распределить в четыре ведра.
Metrics Мovers — функции-двигатели, которые способны сильно повлиять на целевые показатели продукта и бизнеса. Должны быть конкретные цели и стратегии решения инвестировать в продукт или функцию (пример показателя — фреймворк Pirate Metrics).
Customer Requests — это функции-запросы. Они запрошены самими клиентами. Обычно являются дополнительными улучшениями.
Delight — функции, которые создаются внутри компании на основе понимания дизайна или технологии. Работа над ними важна для приятного удивления клиентов.
Strategic — функции, которые важные по стратегическим причинам, связанным с будущими целями.
У каждого метода приоритизации свои особенности и, вероятно, не все они могут быть адаптированы под условия жизнедеятельности вашего продукта или компании. Тогда стоит попробовать современные сервисы, помогающие работать с приоритетами — современные онлайн инструменты для определения приоритетов и отслеживания статусов задач. Они облегчают планирование и помогают приоритезировать все задачи продукта быстро и просто.
Backlog Priority Chart — один из таких инструментов, который предлагает полноценная платформа для product менеджеров Hygger.io.
В сервисе вы можете найти систему оценки Value & Efforts и 4 квадранты-критерия для определения степени приоритета:
- Quick Wins – идеи первоочередного порядка.
- Big Bets – идеи с высоким приоритетом, но которые могут быть выполнены после Quick Wins.
- Maybes – идеи с меньшей ценностью и срочностью.
- Time sinks – идеи, которые вовсе можно отложить или удалить.
Hygger позволяет структурировать бэклог с помощью универсальных Scrum и Kanban досок, лейблов и Swimlanes.
А как вы справляетесь с приоритизацией своих дел? Пользуетесь ли эффективными методологиям и полезными инструментами? Возможно, есть супер эффективный метод, которым вы можете поделиться.
Надеюсь, описанные выше методологии определения приоритетов помогут вам расставить акценты и научиться определять самые важные задачи и выявлять те, которые могут тормозить рабочие процессы. Экспериментируйте и добивайтесь хороших результатов!
Как быстро и эффективно работать с приоритетами по методу Lean Prioritization?
Постоянная работа с приоритетами является необходимостью в управлении продуктами, неотъемлемой частью процесса разработки. Если хватает времени, можно изучить и попробовать использовать сложные и интересные методы для определения приоритетов. Техника Lean Prioritization — один из простых и доступных подходов, который помогает менеджерам продуктов управлять бэклогом задач, особенно, когда нужно это сделать быстро и эффективно.
В идеальном мире управления продуктами каждый менеджер стремиться узнать как можно больше о том, как стать гуру в приоритизации и уметь применять максимальное количество популярных методологий и профессиональных техник для этого.
Любому члену команды, участвующему в разработке и позиционировании продукта, также важно уметь принимать правильные решения и грамотно распределять приоритеты. Однако очень часто на практике мы сталкиваемся с отрицательными примерами принятия решений. На помощь приходят популярные методологии и техники.
Какие цели процесса установления приоритетов?
Приоритизация функций в разработке продукта помогает определить ключевые моменты, научиться эффективно планировать дорожную карту (product roadmap), определять границы работ и различать желаемое и необходимое.
Эффективное управление приоритетами — это процесс балансировки между доставкой ценности и доступными ресурсами. Что может стать причиной плохой приоритизации?
Менеджерам продуктов и собственникам, работающим с приоритетами, могут помешать многие факторы. Например, недобросовестные члены команды или лица, принимающие решения. Они могут оказать негативное влияние на процессы установления приоритетов. Это может быть кто-то, кто влияет на принятие решений, основываясь на его старшинстве в бизнесе, кто навязывает неправильные идеи, кто активно выступает против мнения других, или пытается самостоятельно внедрить заведомо неэффективное решение.
Также причиной плохой приоритизации может стать применение непригодного инструмента или методологии (которые не подходят для глобальной цели продукта).
С первым пунктом вы можете справиться самостоятельно и достаточно быстро, а выбор релевантных инструментов и методов потребует особого внимания и изучения, наработанных навыков в управлении продуктом.
Приоритизация функций в управлении продуктом — серьезный процесс, требующий тщательного подхода и внимания PM. Опытные менеджеры продуктов применяют различные простые и сложные подходы и методы для определения приоритетов и работы с ними.
Распространенные методологии для определения приоритетов
Метод Кано
Это популярная во всем мире методология определения удовлетворенности клиентов функциями продукта. Теория позволяет четко описать удовлетворение каких потребностей оставляет потребителей равнодушными, неудовлетворенными или полностью счастливыми.
Моделирование метода потребует наличие выборки пользователей, которые расскажут о своем эмоциональном состоянии при виде определенной функции продукта, а также при ее отсутствии.
Так можно будет определить функции, без которых пользователи смогут обойтись и наиболее важные для них. Когда-то именно с помощью этого метода проходило тестирование функции Wi-Fi в самолетах.
Метод приоритизации MoSCoW
Это техника, широко используемая в управлении проектами, бизнес-анализе и разработке программного обеспечения. В основе методологии – четыре категории приоритетов:
- Must — наиболее важное и срочное
- Should — важное
- Could — может быть отложено на некоторое время
- Would — не является приоритетным вообще
Первые буквы этих категорий определили название метода (MSCW).
Метод QFD: сопоставление желаний клиента и компании
QFD (Quality Function Deployment) – это методика структурирования функции качества, техника принятия решений, которую часто используют разработчики продуктов.
В основе методики, зарожденной в Японии в 1966 году, — построение матрицы, которая включает распределенные по приоритету пользовательские требования и рейтинг характеристик определенных функций. Матрица также отображает информацию о характеристиках продуктов-конкурентов.
Матрица QFD помогает менеджерам продуктов и разработчикам понять реальную целесообразность реализации определенных требований: если функция присутствует у конкурента и считается его преимуществом, то есть смысл подумать о ее реализации.
Самое главное по QFD — помочь сосредоточиться на характеристиках продукта, рассматриваемых с позиции клиента и компании. Матрицу сравнивают с фигурой дома, называя ее «домом качества».
Этот «дом» — это таблица, столбцы которой соответствуют техническим характеристикам, а строки потребительским.
- В крыше — данные о корреляции между техническими характеристиками.
- В левом крыле — приоритеты пользовательских характеристик.
- В правом крыле — рейтинги потребительских характеристик.
- В подвале — результаты анализа технических характеристик продуктов конкурентов, результаты стратегии изменения технических характеристик продукта, а также оценки важности.
User Story Mapping
Методология Story Mapping – построение карты пользовательских историй. Метод был впервые описан в 2005 году, после чего имел ряд доработок и уточнений.
Суть Story Mapping в том, что одностраничный бэклог — это недостаточный способ расстановки приоритеты в работе. Необходима более основательная структура.
Карта историй организована так:
- Горизонтальная ось представляет последовательность использования. Вдоль нее размещаются истории пользователей или задачи в той последовательности, в которой они выполняются пользователями.
- Вертикальная ось означает критичность. По ней расположены истории пользователей относительно того, насколько они важны (сверху вниз).
Группы связанных историй могут быть сгруппированы в Activities (связанные действия).
Эти и многие другие методологии активно используются для планирования стратегии продуктов, хотя, часто, требуют много времени и ресурсов. Если вам нужно применить быстрый подход для определения приоритетов на ежедневной основе, то отличным вариантом будет методика Lean Prioritization.
Lean Prioritization и универсальная матрица Value and Effort
Метод Lean Prioritization представляет собой применение матрицы 2×2, которая помогает в принятии решений и определяет, что важно, что рискованно, и в каком направлении нужно направлять свои усилия. Предприниматели в стартапах также активно используют эту матрицу для определения приоритетности разработки продукта.
Почему эту матрицу используют для определения приоритетов? Она может помочь менеджерам продуктов разобраться во всех задачах и привести все дела в порядок.
Согласитесь, если вы не будете актуализировать и поддерживать в нормальном состоянии бэклог, он может быстро стать «свалкой» для десятков, сотен и даже тысяч функций и багов.
Естественно, приоритизировать станет сложнее, если пренебрегать своевременным определением неприемлемых функций. Они просто будут упускаться из виду.
Для работы с матрицей можно использовать большую доску и просто нарисовать на ней большой знак плюс «+», задать направления осей Value (ценность) и Effort (усилие) и размещать задач согласна этим критериям.
Правда, все это гораздо удобнее делать с помощью готового инструмента, который предлагают многие платформы для управления продуктами.
Параметры Value и Efforts могут быть применимы для каждой идеи или задачи. Сравнение этих комбинаций поможет вам лучше определить приоритеты задач и выбрать наиболее важные их для разработки.
- Оценка Value покажет, какую ценность для бизнеса может принести ваш продукт или бизнес.
- Оценка Effort измерит ресурсы, необходимые для выполнения задачи.
При определении ценности задачи, обратите внимание на следующие показатели:
- Acquisition (привлечение). Поможет ли конкретная функция привлечь новых клиентов?
- Activation (активация). Когда клиенты поймут ценность этой функции?
- Reach (охват). Сколько клиентов охватит такая функция?
- Revenue (доход). Как функция поможет зарабатывать деньги?
- Retention (удержание). Как функция поможет удержать или вернуть клиентов, чтобы они оставались активными?
- Virality (виральность). Как функция повлияет на виральность продукта?
В универсальной платформе для управления продуктами Hygger.io она визуализируется с помощью диаграммы Backlog Priority Chart:
Похожую матрицу для определения приоритетов можно найти в ProdPad:
Пересматривайте матрицу
Скорее всего, ваш продукт будет развиваться и меняться с течением времени, поэтому лучше пересматривать и актуализировать матрицу регулярно.
Наверняка, вы узнаете еще больше о своем продукте и клиентах с помощью аналитики, обратной связи, A/B тестов, дополнительной информации о клиентах и так далее. Возможно, вам придется вносить серьезные изменения в матрицу, потому может оказаться, что вопросы, которые оценивались достаточно низко в прошлом месяце, могут теперь стать приоритетными.
Заключение
Подход Lean Prioritization сегодня является востребованным во многих сферах, поскольку все компании и продукты стремятся развиваться и оставаться конкурентоспособными.
Представленная матрица – это простой и понятный инструмент для определения приоритетности вашего продукта. Он может прийти на помощь, когда не хватает времени работать с более сложными техниками и методологиями. Lean Prioritization помогает сосредоточиться на функциях, которые наиболее ценны для клиентов, по сравнению с усилиями, необходимыми для их доставки.
Что вы думаете об этом подходе и более сложных методологиях?
Как принимать решения и приоритизировать задачи при создании продукта / Хабр
Основное занятие product-менеджера – принятие решений по тому или иному вопросу. В этой статье мы поговорим, на основе чего принимаются решения, как формируется пул гипотез для этих решений, и какие инструменты лучше применять.Два основных блока:
- Откуда взять идею (фидбек, метрики, конкуренты).
- Как выбрать нужную идею, приоритизация.
Как происходит процесс
Выстраиваем иерархию целей. На верхнем уровне находятся:
- Цели компании: чего на данный момент хочет компания (владельцы, стратегический менеджмент), в том числе, от вас, как от одного из руководителей. Далее, у компании есть набор сервисов, внутренних или внешних, и следующий уровень —
- цели и метрики конкретного сервиса, который вы представляете. На третьем уровне определяем
- идеи под цели и метрики сервиса – фичи, которые хотели бы реализовать, и которые скоррелированы с метриками вашего сервиса. Этапы:
а) сбор,
б) категоризация,
в) приоритизация.После этого получаем
- планы по релизам, которые уже отправляем в разработку.
1. Цели компании
Цели меняются с ростом продукта. Продукт проходит несколько стадий (от зарождения до стагнирования), и на каждой стадии фокусные метрики меняются вместе с целями.
1 стадия: хороший продукт
У нас появилась какая-то идея, и есть цель – сделать качественный продукт, убедиться, что он пользуется спросом, и что люди готовы за него платить. У цели есть метрики, на которые смотрит компания: это могут быть показатели:
- активации — сколько из тех, кто пришел, начинает пользоваться сервисом,
- удержания аудитории — сколько из тех, кто пришел – остались,
- метрики конверсии, и когортный анализ.
Это примеры метрик хорошего продукта на ранней стадии. Компании нужно найти что-то, что было бы интересно пользователю, за что пользователи готовы были бы платить.
2 стадия: хороший рост
У нас уже есть хороший продукт, теперь нужно сделать так, чтобы приходило больше людей, чтобы мы могли расти быстрее. Метрики сдвигаются в сторону роста числа пользователей:
- привлечение – насколько хорошо приходят новые пользователи,
- referral — как хорошо текущие пользователи приводят своих друзей,
- A/B – тест — вы увидели, что 100 человек зашли на страницу, и только 2 совершили целевое действие, тогда вы что-то меняете и 50 человек отправляете на старую версию, а вторую половину на новую, и сравниваете,
- оптимизация конверсии — работа с воронкой платных лидов,
- тестирование различных каналов и аудитории.
Это стадия перестройки продукта от аудитории начинающих к массовому пользователю.
3 стадия: монетизация
Компания подросла, заняла часть рынка, есть много пользователей. Компания хочет быть более рентабельной, больше зарабатывать с одного пользователя. На данном этапе ключевыми целями становятся:
- доход, в первую очередь,
- масштабируемость глобальная,
- партнёрства, которые нужно расширить, и
- инфраструктура, которую нужно проработать для ещё более быстрого роста дохода. Например, можно построить хаб, к которому другие приложения будут подключаться, и компания будет что-то с этого иметь.
Важно понимать, на каком этапе находится ваша компания.
2. Цели и метрики сервиса. Являются частью целей компании
Теперь, смотрим, как соотнести цели компании и цели конкретного сервиса. В качестве примера возьмём видеосервис ВКонтакте. Сама компания находится на третьей стадии, ключевые цели компании:
- метрика монетизации – количество денег, которые мы зарабатываем, и
- активность, показывает, насколько сервис продолжает быть интересным для удержания и привлечения пользователей.
Под эти метрики компании мы подстраиваем метрики видеосервиса, это:
- монетизация видео и
- среднее время просмотра видеозаписи.
В целом, это можно визуализировать – применяется инструмент иерархия метрик.
Мы берём глобальную метрику – активность пользователей, и смотрим, из каких частей она состоит, что влияет на эту метрику и отражает активность, например, частота создания постов или частота отправления сообщения или время прослушивания музыки на сервисе.
Из вариантов активностей пользователя конкретно к нашему видеосервису относится время просмотра видео. Что влияет на эту метрику сервиса, от чего зависит время просмотра видео среднего пользователя? Оно зависит от того:
- сколько видеозаписей пользователь посмотрел сегодня и
- длительность просмотра каждой видеозаписи, в среднем.
Это уже метрики первого уровня. Спрашиваем себя, что влияет уже на эти метрики, например, на длительность просмотра влияет:
- длительность видео и
- % досмотра каждого видео.
Это уже метрики второго уровня.
Далее, каждую из метрик расписываем вглубь, разбиваем на составные метрики, которые детализируют составные части сервиса. Запуская фичу, мы уже сможем видеть, на какую метрику она повлияет напрямую. Допустим, запустили качество 1080 для видео. Это метрика качества видео, она влияет на качество контента, что, в свою очередь, повлияет на длительность просмотра и, следовательно, на активность пользователя. 2 уровень влияет на 1 уровень, а 1 влияет на метрики сервиса – направление именно такое.
Дополнительные моменты:
- Схему рисуем вместе с руководителем и аналитиками. Это можно делать при помощи MindMaster или Mind42 – и там, и там можно работать онлайн вместе с командой.
- Если продукта ещё нет, кажется, что иерархию делать не надо? Надо, ведь мы решаем, какие функции в нём будут нужны – иерархия метрик особенно актуальна!
- Если компания большая, а продукт 25 уровня – расписываем все 24 уровня от глобал до уровня сервиса, и потом уже расписываем конкретно уровни продукта.
- Если продукт новый – важно не угадать числа и значения метрик, а понимать, откуда возьмутся деньги, и какие действия будут происходить. Если это интернет-магазин – будут заказы, будут заходы в каталог, добавления в корзину и т.д. Для каждого экрана нового сервиса нужно сказать, какая там ключевая метрика –нужна иерархия метрик.
- Чтобы понять какая именно фича повлияла на метрики – пригодится A/B-тест.
- Качественные метрики лучше переводить в количественные, по возможности.
- Метрики можно заимствовать от бизнесов из других отраслей, со схожими воронками.
3. Идеи под цели и метрики
А. Сбор идей. Откуда брать идеи
- Пользователи: они есть, они в курсе продукта, и они хотят что-то от продукта получить.
- Команда: долго живет на проекте, долго слушала пользователя, и, по-хорошему, является одним из пользователей сервиса, который мы создаём.
- Конкуренты, другие рынки, ребята из нашей области: можно подглядеть, подумать, почему они делают то или иное, какие фичи запускают.
Идеи от пользователей
Как можно с ними общаться, какие есть инструменты. Основные:
— Фидбек, который прилетает в обратной связи: в мэйлах, звонках, сообщениях в техподдержку, и который обрабатывается и, в идеале, структурируется в компании.
— Отзывы в сторах, где пользователи могут высказать, что они думают о продукте, что им нравится или не нравится, и почему.
— Тулы:
- Userbrain.net (закупаете трафик – пользователь получает задание, и вы можете смотреть, как он используют продукт, понимать, насколько хорошо он справляется с кейсами и получать моментальную обратную связь,)
- Flinto.com (рисуете в фотошопе прототип, закидываете в тул и проставляете кликабельные области – наблюдаете за поведением)
- UserVoice (ставится на сайт и собирает фидбек: люди голосуют за фичи, и популярные поднимаются наверх)
- KanoSurvey (приоритизация фичей)
- optimizely.com (A/B эксперименты)
- wootric.com (опросы на сервисе)
- Отзывы и форумы
- Обзвон (мессенджеры, Skype)
Что нужно понимать на данном этапе?
- Важно не только получать обратную связь от пользователей, но и давать им обратную связь – запускать цикл обратной связи, когда пользователь вам что-то предложил, вы это услышали, зафиксировали, и ответили пользователю. Можно это делать как публично, так и лично, главное, дать понять, что вы учитываете пожелания, иначе поток фидбека со временем иссякнет – так что важно поддерживать канал и относится к нему бережно.
- Будьте готовы, что нее все рады фичам (большинство не рады). Что с этим делать?
- если фича небольшая – внедрять её нужно мягко, не ломая сценарий пользователя;
- если большая — готовить людей заранее, открытость вам только в плюс. Даже для больших изменений обычно достаточно 15-20 касаний продукта пользователем.
Есть качественные и количественные методы сбора информации от пользователей.
Качественные методы 10-20 человек:
- фокус-группы — собираем 5-10 пользователей для работы в группе и смотрим, как они обсуждают, — способ помогает выиграть в скорости получения информации
- наблюдения — при запуске прямых трансляций ВК выдавали пользователям телефон и смотрели, как они себя ведут, что получается и не получается, что обсуждают друг с другом, а также, полезен
- CustDev (интервью + UX) – показываем продукт и просим пользователя прогнать несколько кейсов, или когда нет продукта – тестируем проблематику и спрашиваем, как он раньше решал свою проблему.
Количественные методы 100-1000 человек.
- Опрос — почему используете эту функциональность + варианты ответа, которые по метрикам не увидеть.
- A/B тесты, смотрим, какой фидбек приносят пользователи + количественное отражение поведения пользователей.
Как получить бесплатных тестировщиков, если сервис ещё не раскручен? — Можно найти тематические группы ВК или в других соцсетях и сделать запросы туда: проектируем новый сервис, хотите посмотреть и рассказать, как и что получается, либо за просто так, либо за небольшой бонус. Наблюдение должно происходить в максимально комфортной атмосфере для пользователя. Если делаем В2В продукт, садимся в гости к разработчику и смотрим как он использует вашу среду программирования.
Чем качественные методы отличаются от количественных исследований? Во-первых, тут разные цели; во-вторых, качественные более быстрые. Гораздо быстрее опросить десять людей и получить фидбек, который, скорее, расширит воронку идей, однако, на основании 10 человек принимать какое-то решение – неправильно, так как, выборка незначительная. Зато, можно подсмотреть нестандартные идеи, о которых вы не думали и которые нужны, возможно, другим пользователям. Количественные же методы – это больше про сужение и определение. Они делаются на большом масштабе, и им уже можно доверять.
Идеи команды
Важно: у команды должен быть а) интерес и б) возможность высказывать свои идеи по продукту, этому способствует дружелюбная атмосфера, а иногда для получения идей команду нужно потормошить. Какие есть инструменты:
- брейншторм – выделяем определённую тему или метрику и час или два обсуждаем, как её прокачать. Сначала проводим генерацию идей, потом постепенно выбираем идеи, которые нам больше нравятся или которые можно раскрыть. После чего уже приоритизируем задачи, и часть из них берем в релиз. Иногда полезно посмотреть под другим углом, когда не очень понятно, как прокачать более сильные гипотезы. Для этих целей применяется инструмент
- Impact Mapping, делается совместно с командой и выглядит так:
У нас есть ключевые цели, удовлетворяющие принципам SMART, и понимание, что мы хотели бы сделать со своим сервисом. Например, увеличить число просмотров видео на 30%, тогда задаём себе вопрос:
- кто? Кто во всём мире, необязательно в команде разработки, может повлиять на эту цель? Часто на этом этапе мы кого-то упускаем. Задав вопрос, можно обнаружить, что влияет маркетинг и авторы блогов. Расширили число групп влияния на метрику. Далее:
- как, каким способом они могут на это повлиять? Авторы могут заливать чаще контент. Они могут рассказывать своим коллегам. После этого уже смотрим,
- что мы можем сделать для этого? И расписываем, какой следующий шаг. Чтобы авторы чаще заливали контент, возможно, стоит сделать отложенный постинг, когда они подготовят много видеозаписей, и потом, когда будут заняты – им можно будет не пропускать публикацию своих готовых постов. Если хотим, чтобы они делились с коллегами, надо сделать для них, например, доступную статистику, чтобы они могли ею поделиться и т.д.
Идеи от конкурентов, их пользователей и с других рынков
Составляем список конкурентов. Где их посмотреть? Источники:
- топ запросов из поисковиков, это самое стандартное;
- топ стора для нашего приложения — находим крупного конкурента;
- рекомендации стора, обычно всплывают более мелкие проекты, не настолько известные, но с классной интересной функциональностью, чтобы выделиться;
- опросы аудитории и
- обзоры рынка.
Ещё есть пара инструментов для слежения за новостями и конкурентами.
Первый сервис называется Feedly, с помощью него можно подписываться на нужные тематики, например, прямые трансляции, или на определённое слово, например «стриминг», и отслеживать посты только с этой тематикой. Это очень удобно, можно в одном фиде смотреть все посты с тех ресурсов которым вы доверяете, именно, с определенным словом, с утра или раз в неделю открыли, почитали всё, что вам нужно.
Вторая история – Owletter, где можно посмотреть, что рассказывают ваши конкуренты пользователям, как общаются с ними. Сервис подписывается на все рассылки массы крупных и средних сервисов, и вы можете ввести название компании конкурента и посмотреть, какие мейлы он своей аудитории отправляет — классный способ подсматривать за конкурентами, узнавать, какие фичи они используют и как они промоутируют эти функциональности.
Третья история про открытые отчёты, которые публикуют все публичные компании. И если кто-то из ваших конкурентов – публичная компания – то можно за ними подглядывать. Например, по теме прямых трансляций представлял интерес один китайский видео-дейтинг-сервис, Момо. В их финансовой отчетности было видно, как компания зарабатывала каждый год стабильно немного, а потом внезапно в 16 году резко заработала много — оказалось, они встроили себе фичу, которая принесла много денег. Полезно узнать о таком – можно проследить механики, которые конкуренты внедрили и которые принесли им существенный доход.
Б. Категоризация
Составляем таблицу с фичами.
Мы определили ключевые метрики из иерархии, которые хотим прокачивать: кол-во просмотров, авторов, уникальные зрители и время просмотра. Теперь, по каждой метрике в таблице определяем количественный показатель, который мы хотим получить по метрике и, далее, раскладываем идеи/проекты из пула по выбранным метрикам, делая развесовку по проектам. Затем, нужно провести приоритизацию фич, составить план по месяцам и определить, что из них пойдёт в ближайший релиз.
В. Приоритизация
Приоритизация разбивается на 2 шага: быстрая и медленная. Быстрая помогает отбросить наиболее неподходящие, из 100 фичей получается 10, самых важных, а при медленной уже из десяти определяем две-три, которые запустим в ближайшую работу.
1 шаг. Быстрая приоритизация.
Для быстрой – полезен инструмент poker planning. Польза против трудозатрат.
- По каждой фиче участники команды (продакты, тимлиды и разработчики, если они разбираются в продукте в контексте пользовательских сценариев) выставляют оценку от 1 до 3 для пользы фичи.
- По каждой фиче разработчики выставляют оценку временных затрат.
- Считаются средние величины, и в итоге, столбец 4 показывает отношение пользы к затратам — у каких фич больше процент, те и берем во вторую оценку, медленную.
Есть ещё более долгий формат быстрого способа — больше факторов, которые нужно просчитать, используется дополнительно – rice scoring.
По столбцам вписываем
- проект / фичу,
- количество людей, которых затронет эта функциональность — Reach,
- насколько для них это будет полезно, от 1 до 3 – Impact,
- насколько вы уверены в этой идее – Confidence, в процентах, и
- затраты со стороны разработки, в часах или днях, — Effort, и считаем Rice score – путём умножения первых трех показателей друг на друга и деления их производного на затраты.
Смотрим, какая из фичей вылетает в топ. Из 50-100 останется 10-15.
Также, для быстрой оценки, мы можем использовать иерархию метрик. Смотрим фичу, и на что она влияет, на какой уровень. Чем ближе к глобалу – тем фича полезнее.
Ещё есть модель кано. Используется для того, чтобы мы могли фичи разделить по нескольким типам и из них собирать корзинки. Фичи делятся на обязательные, линейные, wow-фичи, нежелательные фичи. Прогоняем пользователя по двум вопросам: как относишься к тому, чтобы этой фичи не было на сервисе, и к тому, что она будет на сервисе. В итоге, мы получаем матрицу интерпретации результатов опроса.
2 шаг. Медленная приоритизация.
С помощью этого инструмента мы считаем, сколько конкретная фича принесет профита, с учётом возможных рисков, сравниваем полученные значения и принимаем решение, какие фичи возьмем в итоге в разработку. Алгоритм следующий:
- Составляем формулу оценки прибыльности фичи, закладываем количество людей и денег. Коэффициенты, которые мы точно не знаем, например, сколько людей попробуют новую фичу, мы выделяем жёлтым – их прогоним через вероятности.
- При помощи экспертов или коллег прикидываем сценарии для пессимистичного, реалистичного и оптимистичного вариантов исхода – что произойдет, и какова вероятность, что произойдёт именно так – после чего считаем среднюю величину, и подставляем в формулы, уже понимая, сколько фича принесет с учетом вероятности.
- Оцениваем стоимость разработки.
- Считаем ROI, и если он нас устраивает, заносим фичу в план релиза по месяцам.
Резюме по приоритизации
- Выбираем топ 3 ключевые метрики, на месяц или на квартал, видим, что эти метрики влияют на деньги и понимаем, что можем прокачать эти метрики.
- Собираем гипотезы для их прокачки (пользователи, аналитика, команда, конкуренты).
- Если рынок новый и аналитики нет – больше делаем акцент на качественный метод, общаемся с пользователями и смотрим на конкурентов.
- Делаем быструю оценку и отбрасываем слабых кандидатов.
- Делаем детальную оценку оставшихся кандидатов (например, по ROI).
На этом, основной материал подошёл к концу. Далее, мы подготовили для вас интересные вопросы и ответы, не вошедшие в текст.
Вопросы и ответы
- Как выкручиваться, если CEO и инвесторы хотят доработку, а я знаю, что проект не взлетит? – 1) пообщаться детальнее и понять их мотивы; 2) предложить альтернативу, которая может быть полезна и вам и им 3) пройтись вместе по модели rice score.
- Как быстро можно увидеть эффект от запуска новой фичи? – Зависит от того, какую фичу вы внедряете, если делаете что-то для улучшения позиции сайта в поисковиках – раньше чем через две недели бессмысленно. А если функциональность, которую пользователи увидят моментально – то сразу. Может быть и такое, что в краткосрочном периоде увеличится глубина, а в долгой перспективе пользователи начнутт отказываться. Мерить нужно не только краткосрочно, но и вдолгую. Срок удлиняется, когда мы фичей хотим переучить пользоваться. Привыкание может длится пару месяцев.
- Как рассказывать про продукт внутри компании? – Внутренний блог, в котором регулярно освещаем: что делаем, зачем делаем, как делаем. Коммуникация есть периодическая, а есть регулярная. Есть механизм рассылок – это оперативная коммуникация. Может быть что угодно: рассказы, отстраненные в виде отчета либо живые – объявления, развешенные по офису, посиделки с пирожками.
- Для подсчёта объёма аудитории по каждой фиче требуется огромное количество времени, как вы с этим живёте? – Оценка может быть долгой только в начале, затем драйверы все уже видны и легко считаемы, и работает накопительный эффект. Можно, задав себе ряд вопросов, просчитать пессимистический вариант и дальше уже прикидывать. Один раз разработал Фреймворк – потом есть эксель, где всё просчитывается. Главное, задавайте себе вопрос: что я могу сделать, чтобы в следующий раз всё было быстрее. Ни один план не высечен в камне – всё постоянно меняется, нужно быть готовым регулярно переприоритизировать.
- Методы проверки гипотез? – Опросы, черновые прототипы.
- Если нет целей? – Надо придумать.
- Как мотивировать внешних тестировщиков? – 1. Признание от вашей команды. 2. Определённая тусовочка прикольных ребят. 3. Если вы топ – возможность попасть к вам в штат будет мотивацией. 4. Сувенирка. 5. Внимание, в обмен на профессионализм.
Простая приоритезация для Product-менеджеров / Блог компании OTUS. Онлайн-образование / Хабр
Перевод статьи подготовлен специально для студентов курса «Product Manager IT-проектов»Проблемой, которая возникает постоянно при построении дорожной карты продукта, является распределение приоритетов. Как вы решаете над чем нужно работать в первую очередь?
Если вы вложили достаточно усилий в мозговой штурм, поиск возможностей для улучшения и получения обратной связи, вы сможете создать хорошую дорожную карту продукта. Однако порядок, в котором вы будете заниматься воплощением новых идей, тоже заслуживает внимания. Вам необходимо найти время, чтобы правильно расставить приоритеты.
Приоритезация – это сложно
Почему так сложно определить приоритеты в дорожной карте продукта? Давайте я перечислю причины:
- Над своими идеями работать приятнее, чем над громоздкими проектами;
- Интереснее сосредотачиваться на продуманных идеях, чем просто на проекте, который приведет вас к цели;
- Увлекательнее погружаться в решение новых идей с головой, а не в проекты, в которых вы уже уверены.
- Легко сбросить со счетов дополнительные усилия, которые требуется приложить к одному проекту, который является частью другого.
Даже если вы пройдете через это ментальное минное поле целым и невредимым, перед вами встанет сложная задача последовательного объединения и сравнения этих факторов для каждой идеи в проекте. К счастью, вы не должны делать все это прямо у себя в голове.
Оценка RICE: простой инструмент для расстановки приоритетов
Именно в этот момент в игру вступает балльная система. Хорошая структура приоритезации поможет вам оценить каждую идею и объединить их в строгую последовательность для выполнения.
Использование балльной системы для определения приоритетов в управлении продуктами, безусловно, не новая идея. Систем, предназначенных для обеспечения баланса между издержками и выгодами предостаточно. Но вам может быть трудно найти ту, которая позволит вам с пользой последовательно сравнивать различные идеи.
В качестве решения, мы начали разрабатывать собственную систему подсчета баллов для определения приоритетов, исходя из первых принципов. После долгих итераций испытаний мы остановились на четырех факторах и нашли метод их сочетания.
RICE: 4 фактора оценки приоритета
RICE – это аббревиатура четырех факторов, которые мы используем для оценки каждой идеи проекта: Reach, Impact, Confidence и Effort.
Reach
Чтобы избежать предвзятого отношения к функциям, которые вы использовали бы сами, оцените, как повлияет проект на множество людей в течение определенного периода. Моя команда понимает это как «На скольких людей этот проект окажет влияние в течение одного квартала?»
Reach (Охват) измеряется количеством людей/событий за период времени. Это могут быть «количество клиентов в квартал» или «количество транзакций в месяц». Насколько это возможно, используйте реальные измерения из метрик продукта вместо того, чтобы просто брать цифры с потолка.
Пример:
- Проект 1: 500 клиентов достигают определенной точки в воронке регистрации каждый месяц, и 30% выбирают определенный вариант. Охват составляет 500 х 30% = 450 клиентов в квартал.
- Проект 2: Каждый клиент, который использует конкретную функцию каждый квартал будет видеть внесенное изменение. Охват составит 2000 клиентов в квартал.
- Проект 3: Определенное изменение один раз повлияет на 800 существующих клиентов и не будет иметь постоянного эффекта. Охват за квартал составит 800 клиентов.
Impact
Чтобы сосредоточиться на проектах, которые двигают вас к вашей цели, оцените impact (влияние) на каждого конкретного человека. Моя команда понимает это так: «Насколько этот проект увеличит конверсию, когда клиент с ним столкнется?». Ваша команда может интерпретировать это иначе, вроде «как увеличить применение» или «максимизировать удовольствие от использования».
Влияние трудно измерить. Поэтому я буду выбирать из шкалы множественного выбора: 3 – «массовое влияние», 2 – «высокое», 1 – «среднее», 0.5 – «низкое» и, наконец, 0.25 – «минимальное». Эти показатели будут умножаться на конечный результат, чтобы масштабировать его в большую или меньшую сторону.
Выбор числа для масштабирования может показаться ненаучным. Но у вас всегда есть альтернатива: запутанный клубок из смешанных чувств по отношению к идее.
Пример:
- Проект 1: На каждого клиента, который увидит этот проект, он окажет большое влияние. Балл влияния – 3.
- Проект 2: Этот проект будет иметь меньшее влияние на каждого клиента. Оценка влияния – 1.
- Проект 3: Этот проект окажет среднее влияние. Оценка влияния – 2.
Confidence
Чтобы обуздать энтузиазм к захватывающим, но плохо определенным идеям, учитывайте свой уровень уверенности в своих оценках (confidence). Если вы считаете, что проект может оказать огромное влияние на клиентов, но не имеете данных для того, чтобы это подтвердить, мера уверенности позволит вам это проконтролировать.
Уверенность – это процентное соотношение. Я использую шкалу множественного выбора, чтобы не парализовывать решения. 100% — «высокая уверенность», 80% — «средняя», 50% — «низкая». Все, что ниже этих показателей – просто авантюра. Будьте честны с собой: насколько вы действительно верите в свою оценку?
Пример:
- Проект 1: У нас есть количественные показатели охвата, пользовательские исследования для уверенности в показателе влияния и оценка требуемых усилий для реализации. Такой проект получает 100% уверенности.
- Проект 2: У меня есть данные для оценки охвата и требуемых усилий, но в факторе влияния я не уверен. Такой проект получает 80% уверенности.
- Проект 3: Охват и влияние могут оказаться ниже, чем предполагалось, а затраты усилий могут оказаться выше. Такой проект получит 50% уверенности.
Effort
Чтобы двигаться вперед быстро и оказывать большое влияние с меньшими усилиями, оцените общее количество времени, которое займет выполнение проекта у всех членов вашей команды: на дизайн, проектирование и разработку.
Усилия (effort) оцениваются как количество «человеко-месяцев» — то есть работа, которую один член команды может выполнить за месяц. Здесь есть много неизвестных переменных, поэтому я ставлю грубые оценки, придерживаясь целых чисел (или значения 0.5 для половины месяца). В отличие от других положительных факторов, большой показатель усилий – это плохо, поэтому он будет делителем для общего воздействия.
Пример:
- Проект 1: На этот проект потребуется неделя планирования, 1-2 недели на проектирование, 2-4 недели на разработку. Я поставлю оценку в 2 человеко-месяца.
- Проект 2: На этот проект понадобится несколько недель планирования, большое количество времени на проектирование, и как минимум два месяца на разработку. Я дам этому проекту оценку в 4 человеко-месяца.
- Проект 3: Проект потребует недели на планирование, никаких затрат на создание архитектуры и несколько недель на разработку. Я поставлю оценку в 1 человеко-месяц.
Как выставляется итоговый балл по методологии RICE?
Чтобы быстро просуммировать все четыре фактора:
Reach: На какое количество человек это повлияет? (Оценивается за определенный период времени)
Impact: Насколько сильно это повлияет на каждого человека? (Очень сильно – 3х, сильно – 2х, средне – 1х, мало – 0.5х, минимально – 0.25х )
Confidence: Насколько вы уверены в своих оценках? (Очень уверен – 100%, средне – 80%, не особо уверен – 50%.)
Effort: Сколько «человеко-месяцев» это займет? (Используйте целые числа и минимум полмесяца – не лезьте в дебри при оценке.)
После того, как вы оценили эти факторы, объедините их в одну оценку, чтобы вы могли предварительно оценить имеющиеся проекты. Вот простая формула:
(Reach x Impact x Confidence)/Effort=RICE Score
Итоговая оценка будет показателем «итогового воздействия за время работы» — именно то, что нужно максимизировать. Я настроил таблицу, чтобы автоматически вычислить итоговую оценку при изменении каждого фактора.
Можете спокойно использовать эту таблицу для своих нужд или скачать ее в .xls.
Когда изначальная оценка произведена, отсортируйте свой список и просмотрите его снова. Есть ли такие проекты, где оценка кажется чрезмерно завышенной или заниженной? Если да, то пересмотрите свои оценки и внесите необходимые изменения, или примите то, что ваш инстинкт подсказывает вам неверно.
RICE может очень помочь при выборе между трудносопоставимыми идеями. Эта методология заставит вас задуматься о том, почему идея проекта будет иметь большое влияние и честно рассчитывать усилия, которые необходимы для ее реализации.
Как эффективно использовать методологию RICE
Конечно же, оценка RICE не должна использоваться как быстрое и жесткое правило. Есть множество причин, по которым вы можете начать работать над проектом с более низким приоритетом в первую очередь. Один проект может зависеть от другого, поэтому он должен быть воплощен в жизнь первым, или же можно поставить высокую ставку на другую функция, чтобы продать ее определенным клиентам.
Иногда так может случиться, что вам нужно работать над задачами проекта не в строго определенном порядке. И это нормально! С балльной системой вы сможете четко определить, в какой момент нужно прибегнуть к компромиссу.
Система определения приоритетов, такая как RICE, поможет вам принимать более обоснованные решения о том, над чем нужно работать в первую очередь, и защищать эти решения перед другими. Дайте RICE шанс распределить приоритеты в вашей задаче и посмотрите, насколько эта методология вам подходит.
Техники скоринга и приоритизации бэклогов / Хабр
Ну что, как там ваши планы на изоляцию? Зимние вещи убрали? Желанные киношки посмотрели? Пылящиеся книжки прочитали? А до полезностей, как всегда, нет времени. Да ладно, не оправдывайтесь — для тех, кто никак не выкроит часок для просмотра видео с нашего канала на Ютубе, мы сделали быстроусвояемую статью. Имейте совесть, всего-то 15 минут вместо 60:)Сегодня коснёмся продуктового менеджмента и разберём приоритизацию бэклогов. Продуктовый менеджмент стоит чуточку выше, чем проджект-менеджмент: он больше про управление продуктами в целом и тесно связан с маркетингом. На закуску посмотрим техники скоринга и оценку задач.
Ситуация
Когда есть есть бэклог, менеджеру нужно каким-то образом расставлять в нем приоритеты. Скрам говорит, что первыми должны идти самые важные с точки зрения бизнеса задачи. Но тут возникает две проблемы.
Первая — справедливый момент субъективизма: часто приоритеты выставляются так, как владельцу бизнеса взбредет. в голову. Но иногда владелец может сильно «галлюцинировать» и нести откровенную чушь, но при этом быть уверен, что все так и есть.
Вторая проблема: слишком много стейкхолдеров верхнего уровня со стороны бизнеса на больших проектах или в крупных компаниях. У каждого из них могут быть свои противоречивые требования. Если собрать, например, пять топов большой компании и попросить их приоритизировать свои требования, скорее всего, каждый будет утверждать, что его задачи имеют нулевой приоритет, и их нужно делать прямо сейчас.
Хорошие новости — есть несколько методик, которые помогают в этом случае:
- договариваться о приоритетах — выбирать, что важнее, а что можно отложить;
- устанавливать критерии приоритизации бэклога (чуть менее субъективные, чем чья-то галлюцинация — увы, совсем без субъективизма не получится).
Методы приоритизации задач
Как выглядит бэклог?
Бэклог — это таблица. В одной колонке — список чего-либо (какие-то хотелки), есть колонка с оценкой (estimate) и есть колонка с приоритетами. Приоритеты — это какие-то числа, как правило, большие. Большие для того, чтобы между приоритетами оставались «дырки», куда можно добавлять новые задачи (или чтобы легко менять приоритетность).
По классике приоритеты выставляются с точки зрения Business Value (ценности для бизнеса) — того, что для бизнеса нужно в первую очередь, оно и пойдет в работу на первом этапе. Но есть другие способы приоритизации, которые бывают удобнее — особенно, если у вас есть ворох разношерстных задач.
Story Mapping
Допустим, у вас есть очень много задач, они мелкие и вообще без приоритетов и привязки к каким-то группам. Что с ними делать? Разбейте их на Story Mapping. Как это работает:
Шаг 1. Строим последовательность того, как юзеры будут пользоваться вашим продуктом, и какие шаги они будут предпринимать. Простой пример:
Шаг 2. На стикеры выписываем, какие по каждому из этих процессов есть детали — чем ниже висит стикер у каждого этапа, тем ниже у него приоритет.
Результат: весь список задач разбит по шагам пути пользователя, плюс у каждой фичи есть приоритеты (чем ниже фича висит в листе, тем у неё ниже приоритет с точки зрения всего пути пользователя).
Где и как применять
Допустим, у вас действительно набралось очень-очень много задач. Тогда вы выписываете их все на стикеры и делаете Story Mapping. Лучше — в команде.
Другой вариант — у вас идёт брейншторм, вы придумываете, каким дальше будет ваш продукт и какие фичи брать в работу. У команды много идей, какие-то хотелки вам «насыпал» маркетинг — нужно понять, каким образом это всё вообще кластеризовать. Story Mapping особенно хорошо работает в такой ситуации.
Оговорка: этот метод применим именно с точки зрения продуктового менеджмента, когда есть много задач, непонятно, какие из них первыми брать в проработку. Грубо, когда мы только продумываем сам продукт и то, какой функционал он будет включать. Дальше это уже режется на кусочки, из которых можно создавать спринты, и забирается в работу.
Плюсы Story Mapping
- Метод позволяет построить связи в системе, на основе которых потом проще формировать спринты.
- Когда много стейкхолдеров и много людей, у которых есть интересы в проекте, метод позволяет договориться о реальных приоритетах — что более важно, а что менее.
Value & Effort (или Lean Prioritization) для идей
Другой хороший метод, который позволяет построить приоритеты на шкале — Value & Effort (или Lean Prioritization).
Шаг 1. Сначала вы берете 2 шкалы:
- Значимость фичи
Значимость каждой фичи с точки зрения бизнеса — это примерно то же, что и «ценность для бизнеса» в обычном бэклоге. Величина оценивается в условных единицах, лучше всего — в деньгах. В целом, любой параметр, который вы оптимизируете, можно брать за Value. Это может быть количество пользователей, которых вы привлечете в проект, или уменьшение оттока пользователей в проекте.
- Количество усилий, которое необходимо затратить на каждую из фич
Тоже можно считать, что это оценка в часах (estimate), как в бэкглоге. Но можно измерять и в Story Point-ах (сравнительная оценка требований относительно друг друга) или в человеко-часах.
Шаг 2. Вы оцениваете все фичи по этим двум параметрам: по значимости и трудоемкости. Есть внешние системы (вроде Hygger или Airfocus Priorities&Roadmaps), которые позволяют в автоматическом режиме раскидать каким-то образом ваши фичи на такой вот доске. Оси при этом идут не от нуля — они подстраиваются под статистические данные, которые у вас получились.
Какие фичи забирать в первую очередь? Самые значимые и лёгкие, которые ближе всего к осям — они и по значимости в топе, и по стоимости адекватные:
Если в первую очередь мы забираем дешевые и хорошие, то потом — дорогие, но крутые:
Следом — все остальные. Фичи, которые слишком дороги и не имеют никакого смысла, вы либо оставляете «на потом», либо выбрасываете.
Где и как применять
При заказной разработке такую штуку имеет смысл проделывать с клиентом, если:
- он сам запутался,
- он генерирует странные идеи и требования,
- у него есть определенное ограничение по бюджету, и он не понимает, как лучше его распределить.
Последняя ситуация — частая. Мы всегда ограничены либо бюджетами, либо ресурсами, и нужно понимать, на основе чего их распределять. Более того, управляя проектами, мы можем управлять только вниманием нашей команды и
нашего заказчика — большим ничем, по сути. Этот метод позволяет концентрироваться на самом важном и самом дешевом либо на дорогом, но очень важном, и помогает выбрать, на что именно сделать ставку в данный момент.
Эта методика не заставляет вас слепо верить алгоритму и брать именно рекомендованные им задачи, но благодаря ей у вас хотя бы будет подсказка, в каком направлении двигаться. Если в систему добавить новых задач, она может перестроиться. Ведь бывает, что вы сильно не уверены в своих оценках, и с течением времени аналитики их уточняют, либо вы сами уточняете оценки трудоемкости у программистов — в этом случае система также может перестраиваться в динамике. За счёт этого у вас будет более адекватная и картина мира.
MoSCoW
Еще один способ категоризации фич по нескольким группам — метод MoSCoW. Внутри — очень простые параметры:
M — Must Have: функционал, без которого вообще нельзя обойтись. Без него вы не сможете выпуститься, ваш продукт не заработает и вообще не будет нужен.
S — Should Have: функционал, который должен быть в проекте, но при прочих равных без него как-то можно обойтись.
C — Could Have: функционал, желательный для релиза.
W — Would Have: наименее практичный функционал — так скажем, «всё остальное».
ПримерДопустим, вы разрабатываете автомобиль. Must Have будут колеса, руль, ходовая часть, двигатель. Should Have — освещение ночью, сидения вместо стульев, двери и всё такое прочее. Could Have — автоматическая коробка передач и так далее. Таким же образом можно разобрать любой проект, где Must Have будет эдаким MVP.
Часто бывает, что приоритеты спускают сверху, от бизнеса, и они сконцентрированы на каких-то «хотелках» из Should Have, Could Have, Would Have, забивая на ключевые вещи (Must Have). Обычно мы это наблюдаем, например, на разработке дизайна интернет-магазина или дизайна какого-то проекта, где на систему оплаты доставки или чего-то, что на самом деле генерирует выгоду бизнесу, ставка делается в последнюю очередь. Почему? Потому что работать с Must Have больно и страшно: надо думать о том, как это будет монетизироваться, а в это никто не любит лезть, хотя это и неправильно.
Kano
Ещё один способ категоризации фичей, пришедший из маркетинга. Суть простая: есть две оси: «удовлетворенность пользователей» и «функциональность», и есть деление функционала на группы. Для каждой группы фич нужно понять, как меняется удовлетворенность пользователя от добавления этого функционала.
Первая группа — обязательный функционал: тот же Must Have из MoSCoW. Если эти фичи есть — уже хорошо. Об удовлетворенности речи не идёт: без них продукт никому не нужен. Более того, с течением времени функции, которые сначала были «изюминкой» проекта, становятся всё более обязательными. Пример: для серверного ПО канбан-доска когда-то была чем-то эдаким, а сейчас это тот самый мастхэв.
Другая группа — одномерные функции. Это значит, что есть прямая зависимость удовлетворенности пользователя от наличия этой функции. Как только функция появляется, удовлетворенность растет линейно. Если вернуться к примеру с созданием автомобиля, там это может быть климат-контроль.
Третья группа — функции, которые привлекательны. Это то, чего пользователь не ожидал, но когда он увидел хоть какую-то реализацию этого в вашем продукте, он офигел и сказал «о, круто!». Кто летал аэрофлотом, наверняка видел, как детям раздают «взятки», чтобы эмоционально привязать их к бренду.
Подарки для детей на борту «Аэрофлота» — источник
Как только такая функция появляется даже в посредственной реализации, удовлетворенность растет. А чем круче реализация, тем выше стремится график удовлетворенности.
Ещё одна группа — неважные функции. Их можно делать, можно не делать — всем будет безразлично.
Последняя группа — нежелательные функции. Когда их нет — все хорошо, как только они появляются — все становится плохо. Эдакие антифичи 🙂
Этот метод несколько сомнителен, поскольку непонятно, каким образом выбираются приоритеты у фич. По идее, нужно опрашивать пользователей: как они считают, хороша эта фича или не очень, а потом кластеризовать на основе мнения пользователей. При этом, еще и самих пользователей нужно разбивать на целевые группы и смотреть, как каждая функция к какой целевой группе относится.
Люди при опросах часто говорят ерунду и попросту врут. Они могут говорить, что это очень важная фича, но по факту они никогда не заплатят за неё деньги. Более того, если опрашивать пользователей, обратная связь по продукту может быть очень токсичной.
ПримерВы планируете делать следующие релизы и опрашиваете группу людей. Кто-то из них может сказать: «А вот вы там платную функцию сделали, из-за неё продукт стал хуже, фи!» Только потому, что она за деньги, эта функция покажется кому-то ненужной. Хотя для бизнеса это может быть ключевая вещь, которая приносит прибыль.
Поэтому метод Kano — абсолютно из маркетинга, но как долгосрочная стратегия имеет место быть.
Классический метод приоритизации баг-листов
В основе — список приоритетов от 0 до 8:
0 — Критические баги
Когда тестер уткнулся и не может дальше проверять, когда система падает либо что-то ломается — в общем, когда дальше невозможно.
1 — Критичное юзабилити и забытые фичи
Здесь мы применяем в том числе метод покраски бэклога, технического задания, либо прототипа (в зависимости от того, что у нас есть на руках), чтобы определить, не пропустили ли мы что-то.
2 — Некритичные баги
Баги есть, но они не мешают тестировать продукт дальше, либо они позволяют пройти полностью по цепочке либо заказа, либо чего-то еще — то есть, дают полностью проверить наш продукт.
3 — Некритичное юзабилити
4 — Тексты
8 — Хотелки / не будем делать / на усмотрение менеджера
Да, промежуток между 4 и 8 сделан намеренно — менеджер при необходимости может докидать туда ещё какие-то задачи.
Для баг-листов способ хороший, но у него есть проблема. По большому счету мы в баг-листах оптимизируем метрику «готово — не готово». Объем работ понятен. Но часто встречается, что в некритичное юзабилити пытаются пропихнуть что-то такое, что находится на грани — вроде бы, юзабилити и вроде бы неплохо такое сделать, но по факту оно тянет на какую-то очень серьезную фичу.
Другая проблема — субъективизм тестировщика, который часто приходится перепроверять. Иногда это довольно трудоемкая история, когда вы лично просматриваете все баг-листы: смотрите, чего он там такого понаписал, и принимаете решение, что выкинуть, а что оставить.
Для приоритизации бэклогов такой метод не годится — для них нужны совсем другие критерии.
Оценка задач
Любая приоритизации должна отталкиваться от тех оценок, которые нам дали. Ведь трудоемкость действительно влияет на приоритетность какой-то функции. Но как определить трудоёмкость и в какой момент стоит обсуждать трудозатраты с программистом? Ведь до этого менеджеру всё равно нужно выставить хотя бы примерные оценки.
А если серьезно, обычно есть три варианта.
- Игра престолов
Приходит какой-то «верховный босс» и говорит, что из бэклога должно быть сделано прямо сейчас, и спускает вам оценки сверху. Это может быть технический директор, который расставляет оценки всех задач и говорит, что какая-то задача делается за столько-то, такая-то за столько-то. Или это можете быть вы сами 🙂
Такое часто встречается (хотя сами мы так стараемся не делать). Обычно по ходу декомпозиции какие-то вещи уточняются, появляются какие-то детали и нюансы. Часто с этими оценками могут быть не согласны разработчики или реальность может быть немножко сложнее, чем вы себе запланировали. Плюс у бизнеса всегда есть подсознательное понимание, за какое количество часов он готов купить эту фичу, а за какое уже не готов (и это всегда где-то на грани).
- Оценка из теории вероятности
Берутся три оценки по времени: оптимистичная, пессимистичная и реалистичная, и строится график, называемый Гауссианой.
Для расчета наиболее вероятной оценки применяют формулу: (Оптимистичная + (Реалистичная * 3) + Пессимистичная) / 6.
В идеале наиболее вероятная оценка будет чуть дальше, чем реалистичная.
Нюанс в том, что не доказано, что в результате у нас получится нормальное распределение. Например, если взять группу людей и измерить их рост, то получится кривая, как на графике ниже: очень маленьких людей мало, очень высоких людей — тоже мало. И они не входят в норму. Остальные в выделенном диапазоне — и есть нормальное распределение.
Гауссиана подразумевает, что варианты, когда задача выйдет за отметку пессимистичной оценки или вообще никогда не будет сделана, стремительно уменьшаются. Но в ИТ-среде часто бывают задачи, которые, на первый взгляд, сделать «невозможно» — программисты для них требуют поменять постановку либо продолжают доказывать эту невозможность. Другая ситуация — человек оценил задачу в 1 час, потратил всё мыслимое и немыслимое время и пришёл к выводу, что не может сделать эту задачу.Поэтому опираться на этот метод можно, но по факту это та же «игра престолов», да и сложновато по каждой задаче давать три оценки плюс считать по формуле. И нет никакой гарантии, что в итоге всё не выйдет за рамки этих оценок и расчётов.
- Planning Poker
Это наиболее простой и «чистенький» способ получить нормальные оценки, обсудить какие-то фичи, нюансы, детали. Даже на верхнем уровне по бэклогу можно такое проделать.
Минус Planning Poker — это довольно ресурсоемкая операция, поскольку нужно собирать всю команду вместе и читать бэклог. Но если вы применяете методы вроде Story Mapping, вам всё равно нужно собираться командой и делать предварительные оценки (хотя бы в днях, неделях — крупных величинах).
Плюсы Planning Poker
- оценки распределяются в зависимости от опыта сотрудника, и здесь можно договориться;
- оценки даются сначала закрыто, и только потом открываются — нет давления авторитета (как в случае с оценками, спущенными «сверху»).
Техники скоринга
Помогают с определением приоритетов задач в бэклоге в условиях неопредленности — когда вы только планируете и оцениваете эффект от внедрения той или иной функции.
ICE Scoring
Аббревиатура состоит из трех параметров:
- Impact — влияние на продукт либо с точки зрения бизнеса, либо сколько денег принесет, либо что эта фича даст, насколько она крутая. Параметр задается в диапазоне от 1 до 10.
- Confidence — уверенность в оценке сложности или в оценке влияния фичи. Например, вы придумали какую-то функцию и думаете, что она хорошо повлияет на проект. Аналитики не было, данные неточные и пока приоритет основывается только на вашем личном мнении. Чем ниже уверенность в вашем личном мнении, тем ниже показатель. Задается также в диапазоне от 1 до 10.
- Ease — трудозатраты или простота реализации. Также задается от 1 до 10. Чем проще функция, тем у нее выше балл.
Влияние
Чтобы оценить влияние той или иной фичи, стоит учесть несколько критериев:
- она улучшает конверсии,
- она привлекает новых пользователей,
- она удерживает существующих пользователей,
- она добавляет ценности продукту.
Если функция им отвечает, то у неё высокое влияние на продукт. Для оценки можно брать шкалу от 1 до 10, можно от 1 до 100. Последняя удобнее, поскольку есть разбег.
Уверенность
Может основываться на:
- личном мнении, мнении команды, мнении сторонних экспертов;
- UX-исследованиях;
- опросах;
- интервью;
- наблюдениях, в том числе — за конкурентами;
MVP; - A/B-тестах;
- сторонних исследованиях;
- аналитике;
- топовых обращениях в техподдержку;
- топовых запросах от сейлз-менеджеров;
- топовых запросах клиентов.
Лучше использовать те, где есть конкретные метрики и цифры, мнение людей оставлять на «потом».
Как измерять уровень уверенности — источник
Для получения ICE нужно умножить эти три параметра — это и будет приоритет на реализацию.
Плюсы: быстро и просто.
Минусы: у метода довольно ограниченная шкала — можно получить много задач высокого приоритета, потому что по ним будут понятны и постановки, сами задачи будут простые и будут казаться важными.
RICE Scoring
Здесь используется 4 параметра:
- Reach — охват: сколько пользователей у нас от этой фичи получат хоть какое-то удовлетворение, либо заметят эту фичу, либо будут ей пользоваться. Можно измерять количественно: например, 500 миллионов пользователей ощутят на себе эту функцию. Можно измерять в процентном отношении — например, 30% пользователей будет использовать эту фичу.
- Impact — влияние: насколько эта функция на самом деле нам нужна, насколько она нам поможет, насколько функция крутая.
- Confidence — уверенность: аналогично с ICE Scoring, уверенность в наших оценках и прогнозе влияния.
- Effort — трудоемкость.
Функции, которые дают большой охват, в которых мы уверены и которые хорошо влияют на продукт и при этом дешевые по трудозатратам, находятся в топе по приоритетности в бэклоге.
Софт для приоритизации
Есть несколько программ для автоматической приоритизации — например, Hygger. Это система для Product Owner-ов, где есть много разных моделей, которые позволяют «поиграться» задачами.
Как выглядит Hygger изнутри — источник
То же самое проделать в любом гуглдоке: просто добавить три параметра, собрать данные — он посчитает. Это и будут ваши приоритеты. А дальше вы уже сами выбираете, что именно брать в спринт.
Иногда менеджеры для хранения всех тикетов и задач используют Jira. К сожалению, она не очень удобна для приоритизации — заточена на то, что кто-то расставляет приоритеты вручную, просто перетаскивая тикеты вверх-вниз по бэклогу. Это прикольно, если бэклог не на 1000 строк, но в какой-то момент вам станет утомительно делать это руками.
В Jira есть определенные способы классификации задач на эпики, компоненты, релизы, можно какими-то тегами задачи размечать. Есть несколько плагинов для скоринга (Issue Score for Jira, Priority Scoring Calculator), но по функциональности они не очень.
Из более-менее адекватных — внешние системы Hygger и Airfocus. Они интегрируются с Jira, но и стоят примерно столько же, сколько она сама. Поэтому самый простой способ — сделать интеграцию гуглдоков и Jira: выгружать туда бэклоги синхронно и уже там применять свои формулы, как вам нужно.
Как подружить Jira и Google Docs для приоритизации
Кроме приоритетов всегда есть проблема, как распределить по времени реализацию тех или иных задач. Когда есть только приоритеты, нет гарантии, что мы получим связанную систему (например, вы запланировали сделать корзину, а оказалось, что каталога еще нет). Поэтому помимо приоритетов также стоит использовать диаграммы Гантта, чтобы чтобы посмотреть связи в системе, насколько она корректно работает по компонентам и насколько оптимально вы распределяете ресурсы команды по времени.
В Jira, к сожалению, из «коробки» эта опция не очень хорошо реализована, поэтому тоже могут пригодиться несколько плагинов:
Как итог
Мы не избавляемся от субъективности — она остается на всех уровнях. В тот момент, когда мы говорим «это важная функция» или «это неважная функция» и когда мы даем какие-то оценки, субъективность сохраняется. Но благодаря перечисленным методам мы можем разбить эту субъективность на компоненты: по крайней мере, картинка будет более ясная.
Если вы используете такой параметр как «уверенность в оценке», вы можете с течением времени эту уверенность «докрутить». Например, у вас есть хорошая функция, которая и влияет на продукт позитивно, и дешевая, и охват дает большой, но уверенность в ней низкая. Проверьте её через метрики, аналитику, запрос экспертов, вопросы программистам — и уточните.
Для оценок хорош Planning Poker, плюс мы посмотрели несколько методик для категоризации задач. Если у вас идёт стратегическая сессия с клиентом, попробуйте Story Mapping со стикерами и распределением их по шагам пользователя. На внутренних продуктах тот же метод поможет выбрать функции, которые стоит взять в следующие релизы. Для бэклогов лучше остальных подходит RICE Scoring, чтобы оценить, какие задачи куда пойдут.
Но помните, что конечное решение — всегда за менеджером, а полученные с помощью методов циферки только задают направление.
До встречи в новых видео на нашем YouTube-канале!
простые техники приоритизации для продвинутых менеджеров продукта / Блог компании Hygger / Хабр
Каждый менеджер продукта рано или поздно сталкивается с вопросом приоритизации при планировании стратегии и роадмапа продукта. Всегда ли просто и быстро можно решить над чем работать в первую очередь?Product roadmap требует четкого порядка. Только качественно разложив все «по полочкам» можно получить достойный и успешный релиз продукта. В этом случае не обойтись без удобного способа приоритизации.
Качественная система определения приоритетов поможет рассмотреть каждую фичу или идею, каждый проект или задачу и последовательно объединить все эти факторы.
Сегодня к услугам PM — множество популярных методологий для приоритизации от игровых до самых сложных, количественных и качественных. Все они помогают менеджерам и командам ответить на очень важный вопрос: как правильно выбрать фичи для разработки?
В этой статье мы рассмотрим две простые, но весьма полезные техники — RICE Scoring и метод определения приоритетов ICE.
Метод RICE Score
Если у вас в плане для реализации есть несколько важных и срочных фичей, как понять к какой приступить сначала?
Этот важный вопрос установления приоритетов лежит в основе всего product management. Плата за выбор неправильного варианта может быть слишком высокой.
RICE — это метод приоритизации идей и фич продукта. Аббревиатура включает 4 фактора, которые менеджер продукта может смело использовать для оценки и приоритизации продуктовых фич:
- Reach — это охват
- Impact — влияние
- Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат
- Effort — трудозатраты
Чтобы получить оценку по RICE, вам необходимо объединить эти факторы.
Reach (Охват)
Уровень охвата измеряется количеством людей/событий за определенный период времени. Этот фактор предназначен для оценки того, на какое количество людей каждая фича или проект повлияет в течение определенного периода времени, и сколько ваших пользователей увидят такие изменения.
Важно акцентировать внимание на реальных метриках, а не использовании непонятных чисел.
Например:
Фичей будет пользоваться 800 пользователей в месяц.
1000 пользователей вовлечены в онбординг, и 70% — только 700 пользователей увидят эту фичу.
Impact (Влияние)
Влияние показывает какой вклад приносит эта фича продукту.
Ценность понимается по-разному в каждом продукте. Например, в Hygger (B2B SaaS) для текущего квартала фичи получают высокое значение, если они:
1. Улучшают trial-to-paid конверсию (metric movers)
Исходя из ваших текущих целей у вас будут свои метрики.
2. Помогают привлечь новых пользователей
Это фичи, которые помогают нам получить новых пользователей во время онбординга. Но не стоит забывать о том, что большинство пользователей «отпадают» на второй день.
Например, в SaaS отличным индикатором удержания в первый день является показатель 15%. Это означает, что 85% людей просто уходят на второй день. Поэтому здесь вы должны подумать о фичах, которые большинство новых пользователей смогут увидеть в первой сессии.
3. Помогают сохранить текущих пользователей
Клиенты купили подписку и теперь просят сделать некоторые фичи. Мы не «спешим» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов просили об этом. И тогда мы реализуем самые популярные фичи.
4. Добавляют ценности продукту и отстраивают нас от конкурентов
На рынке сегодня более пяти сотен систем для управления проектами. Чтобы выжить и добиться успеха, нам нужно сделать что-то совершенно новое, желательно увеличить срок службы для пользователей или сократить затраты в несколько раз. Здесь мы ищем возможности, которые могут дать нам конкурентное преимущество, создадут причину, по которой клиенты конкурентов перейдут к нам. Это конкурентное преимущество должно быть уникальным, трудно повторяемым и, в идеале, не воспроизводимым.
К слову, влияние трудно измерить точно. Так, мы выбираем из шкалы с множеством вариантов: 3 для «массового влияния», 2 для «высокого», 1 для «среднего», 0,5 для «низкого» и, наконец, 0,25 для «минимального». Эти цифры умножаются на итоговый результат, чтобы масштабировать его ниже или выше.
Confidence (Уверенность в оценке)
Если вы считаете, что фича может иметь огромное влияние, но у вас нет данных для доказательства этого, Confidence позволяет проконтролировать этот момент. Confidence измеряют в процентах.
Например
Проект A: У менеджера продукта есть количественные показатели для влияния фичи, и оценка трудозатрат. Таким образом, проект получает 100% -ную оценку уверенности.
Проект B: У менеджера продукта есть данные по охвату и трудозатратам, но он не уверен в отношении фактора влияния. Проект получает коэффициент доверия в 80%.
Проект C: Данные охвата и влияния могут быть ниже, чем предполагалось. Трудозатраты могут быть выше. Проект получает 50%-ную оценку доверия.
Effort (Трудозатраты)
Трудозатраты оцениваются как количество «человеко-месяцев», недель или часов, в зависимости от потребностей.
Например:
Проект A займет около недели планирования, 2 недели дизайна и 3 недели для разработки, поэтому трудозатраты составят 2 человеко-месяца.
Для проекта B потребуется только неделя планирования, 1-2 недели для разработки и не потребует дизайна. Трудозатраты будут равны 1 человеко-месяцу.
Метод оценки ICE
Метод определения приоритетов ICE был придуман Шоном Эллисом, который известен авторством термина Growth Hacker.
Первоначально ICE был предназначен для приоритизации экспериментов по росту. Позже ICE стали использовать и для приоритизации фичей.
ICE Scoring: Как это работает?
Рассчитайте оценку для каждой фичи или идеи, согласно формуле:
- Влияние показывает, насколько ваша идея положительно повлияет на ключевой показатель, который вы пытаетесь улучшить.
- Легкость реализации — это о простоте реализации. Это оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.
- Уверенность показывает, насколько вы уверены в оценках влияния и легкости реализации.
В ICE используется шкала от 1 до 10 чтобы все факторы сбалансированно влияли на итоговый бал. Вы можете подразумевать под 1-10 то что вам нужно, лишь бы значения были согласованы между собой.
В качестве примера, применим это к фиче «Виджеты для Dashboard»:
- Влияние: насколько это будет эффективно? Что это даст нашим пользователям и их целям и задачам?
- Легкость реализации: насколько легко будет разрабатывать, тестировать и запускать эту фичу?
- Уверенность: как я могу быть уверен, что эта фича приведет к такому улучшению, которое я описал в Impact и займет столько-то времени?
Недостатки ICE
ICE Scoring иногда подвергается критике за его субъективность:
- одна и та же фича может оцениваться по-разному одним и тем же лицом в разное время. Это может повлиять на окончательный список приоритетов.
- если разные люди оценивают фичи — все они будут оценивать ее по-разному.
- члены команды, которые хотят, чтобы их фичи были приоритетными, могут манипулировать результатами, чтобы получить аппрув.
Как использовать RICE и ICE Scoring?
Рассмотрим пример использования обеих моделей в сервисе для управления продуктами и проектами Hygger.io.
С чего начать?
Во-первых, у вас должны уже быть собранными необходимые фичи и идеи продукта на вашей Kanban-доске. Используя Hygger, вы можете структурировать их с помощью горизонтальных колонок Swimlanes, а также применяя Labels. Вы также можете настроить процесс работы с фичами с помощью Columns. К примеру, можно создать следующий рабочий процесс:
- Backlog — здесь вы собираете все идеи и фичи
- Next Up — сюда вы перемещаете фичи, над которыми хотите работать в ближайшее время
- Specification — тут вы собираете требования и пишите спеки на фичи
- Development — фичи находятся в разработке, и здесь вы можете отслеживать их текущий статус
- Done — фичи были успешно залиты на прод и теперь доступны вашим пользователям.
В меню Hygger вы найдете варианты моделей для оценки и приоритизации фичей, в том числе, RICE и ICE:
Оценка в Hygger по RICE
Сперва вам нужно оценить каждую фичу по критерию Reach, Impact, Confidence и Effort.
Все фичи также можно увидеть в таблице:
Так вы сортируете все фичи, оценивая их и выбираете “победителей” из верхушки списка, затем отправляя их в разработки с помощью фичи Push.
Push работает так:
- создается задача по реализации фичи на доске разработке — на Канбан или Спринт доске внутри Hygger (да-да, Hygger поддерживает Kanban и Scrum). В будущем мы добавим интеграцию с Jira и с другими трэкерами задачи, так как прекрасно понимаем, что многие команды используют для разработки Jira и уйти с нее на что-то другое — анрил
- задача на бэклог-доске и задача на доске разработки линкуются между собой
- когда задача на доске разработке будет полностью выполнена, задача на бэклог-доске также будет перенесена в done-колонку.
Если у вас Еpic на бэклог-доске, то вы можете сослаться из него на несколько задач по разработке (например, одна задача — на frontend разработку, вторая — backend, третья — мобильное приложение для ios, четвертая — для Android). Epic будет «выполнен» тогда, когда будут «выполнены» все задачи по разработке, на которые он ссылается.
Оценка в Hygger по ICE
Такой же алгоритм и в случае с выбором модели оценки ICE.
Вам нужно оценить каждую фичу по критериям Impact, Confidence и Ease.
Удобная таблица также визуализирует все ваши фичи:
Другие способы приоритизации в Hygger
Приоритизация Value & Effort (aka Lean Prioritization)
Это простой способ приоритизации, основанный на матрице 2×2 с двумя осями: Сложность и
Ценность:
- Value — это то, какой вклад приносит конкретная фича.
- Effort — это усилия, необходимые для реализации фичи.
Как правило мы используем и рекомендуем использовать Value & Effort приоритизацию для оценки идей или первичного отбора фичей для последующей оценки по ICE/RICE или по своим критериям (Weighted Scoring).
В Hygger, визуализировать матрицу помогает инструмент Priority Chart (доступен только для Value & Effort приоритизации):
- Сперва мы разрабатываем Quick Wins. Это фичи, которые приносят больше всего ценности, но которые можно быстро и легко реализовать.
- Далее – Big Bets. Эти фичи могут принести много ценности, но их сложно реализовать.
- Потом – Maybes – задачи или фичи, которые не дадут много ценности, но их легко внедрить. Их можно оставить на потом.
- Наконец, Time Sinks. На эти фичи вообще не стоит обращать внимания.
Кроме того, в меню Hygger вы можете выбрать приоритизацию по собственным критериям — Weighted Scoring. Но об этой системе оценки и ее преимуществах мы обязательно расскажем подробнее в одной из следующих статей.
Как расставить приоритеты для проектов за 5 простых шагов
Независимо от того, на кого вы работаете и насколько велик ваш проект, любому руководителю проекта сложно понять, чем заняться в первую очередь, когда у вас много шансов.
Приоритезация проекта дает вам и вашей команде простой и понятный план работы, которую необходимо выполнить, а также устанавливает четкие ожидания для вашего клиента или организации. Другими словами, это настраивает всех на успех!
Вот как расставить приоритеты для проектов за 5 простых шагов:
- Начните расставлять приоритеты по проектам на основе бизнес-ценности
- Устанавливайте приоритеты, определяя срочные и важные проекты
- Оценивайте собственную пропускную способность
- Научитесь говорить проектам «нет»
- Будьте гибкими с процессом определения приоритетности проекта
1.Начните расставлять приоритеты по проектам на основе бизнес-ценности
Начните с рассмотрения каждого проекта в вашем списке, задав один простой вопрос: как этот проект повлияет на бизнес? Хотя вы, безусловно, хотите принять во внимание прибыль организации, вам также необходимо учитывать, как проект повлияет на людей. Например, упростит ли это жизнь нашим клиентам или членам команды?
Имейте в виду, что этот шаг может потребовать разговоров с вашими менеджерами, клиентами или другими ключевыми заинтересованными сторонами.Не бойтесь задавать подробные вопросы, чтобы добиться успеха в проектах, которые принесут наибольший успех.
2. Установите приоритеты, определив срочные и важные проекты
Теперь пришло время сделать еще один шаг в процессе определения приоритетов. Имея в руках свой список важных проектов, вернитесь к нему, учитывая срочность. Легко спутать важность с срочностью, поэтому давайте проведем четкое различие:
- Важный проект приносит пользу вашему бизнесу, независимо от того, чувствуете ли вы его влияние сегодня или спустя годы.
- Срочный проект требует немедленного внимания, чтобы не сбиться с пути или поддерживать бизнес.
Эта матрица тайм-менеджмента, разработанная Стивеном Кови, позволяет легко распределять приоритеты по 4 простым сегментам.
Вот как работать с каждым сегментом приоритета:
- Приоритет 1 — срочно и важно: Сможет ли проект удержать бизнес от остановки? Есть ли жесткий дедлайн, который нельзя пропустить? Сначала займитесь этими проектами.
- Приоритет 2 — не срочно, но важно: Запланируйте время для продолжения работы над проектами, у которых нет срочных сроков, но которые все равно имеют значение для бизнеса.
- Приоритет 3 — срочно, но не важно: Эти проекты могут требовать быстрого внимания, но не служат общим бизнес-целям. Если такая работа не может ждать, попробуйте делегировать ее.
- Приоритет 4 — не срочно и не важно: Не бойтесь дать этим проектам загрузку, чтобы высвободить время и ресурсы для более достойной работы.
3. Оцените собственную пропускную способность
Итак, что вы будете делать, если у вас останутся 3 срочных и важных проекта? Если в жесткие сроки не объявлен победитель, взвесьте усилия, которые потребует каждый приоритетный проект.
В TeamGantt нам нравится в первую очередь заниматься более крупными проектами. Таким образом, после этого все кажется быстрой победой. Но если очистка простых проектов помогает вам сосредоточиться на более сложных, дерзайте.
Просто имейте в виду, что штабелирование тяжелых проектов друг за другом может быстро истощить проектную энергию. По возможности старайтесь чередовать большие проекты с маленькими, чтобы ваша команда оставалась свежей и мотивированной.
4. Научитесь говорить «нет» проектам.
Давайте прямо скажем: «Нет» — неплохое слово.Фактически, эти две маленькие буквы могут повлиять на вашу способность к успеху как руководителя проекта.
Как бы странно это ни звучало, говорить «да» на каждый проектный запрос — это рецепт риска. Взяв на себя больше, чем вы можете справиться, ваша команда не только упадет на землю, но и рассердит клиента из-за пропущенных сроков и некачественных результатов.
Хотя отказ может потребовать от вас жесткого разговора, он защищает вашу способность выполнять наиболее важные проекты.И будьте уверены: вы можете отказать клиенту или заинтересованному лицу, не закрывая полностью дверь. Это может просто означать делегирование задач другой команде, у которой есть ресурсы для выполнения работы вовремя.
5. Будьте гибкими в процессе определения приоритетов проекта.
Если вы хоть раз занимались управлением проектами, вы знаете следующее: все меняется. Проект, который когда-то был срочным и важным, может быть проигнорирован внезапной чрезвычайной ситуацией. Заинтересованная сторона может решить, что проект больше не приносит ценности для бизнеса.Ключевой игрок может неожиданно заболеть, что снизит пропускную способность вашей команды.
Как руководитель проекта вы можете гнуться или сломаться. Ваша задача — оставаться начеку и постоянно переоценивать приоритеты проекта, чтобы вы могли при необходимости корректировать фокус своей команды. Узнайте, почему план может помочь вам в этом.
Быстро и легко расставляйте приоритеты в работе с TeamGantt.
Самая сложная часть процесса расстановки приоритетов — это выяснить, на что стоит потратить время вашей команды, и посвятить себя только самым ценным, срочным и важным проектам.Как только вы решили, на чем сосредоточить свою энергию, вы готовы составить план и приступить к работе.
И вот здесь TeamGantt может облегчить вашу нагрузку. С TeamGantt вы можете оставаться гибкими при смене приоритетов и держать свою команду и заинтересованные стороны в курсе, чтобы ничего не провалилось и все были довольны результатом.
Хотите испытать TeamGantt? Зарегистрируйтесь сегодня и попробуйте свой первый проект бесплатно!
.Как расставить приоритеты для проектов вашей компании
Каждая организация нуждается в том, что я называю «иерархией целей». Без него практически невозможно эффективно расставить приоритеты.
Когда я только начал работать в BNP Paribas Fortis, например, два молодых и более динамичных банка только что обогнали нас. Хотя мы были лидером рынка в течение многих лет, наши новые продукты были выпущены на несколько месяцев позже, чем у конкурентов — фактически, время вывода на рынок удвоилось по сравнению с предыдущими тремя годами.За этой проблемой стояла более глубокая проблема: у нас было более 100 крупных проектов (каждый стоимостью более 500 000 евро). Никто не имел четкого представления о статусе этих инвестиций или даже об ожидаемых выгодах. Банк использовал инструмент управления проектами, но отсутствие дисциплины в его обновлении сделало его практически бесплодным. Возможности, а не стратегия определяли, какие проекты запускать и когда. Если были люди, проект запускался. В противном случае он остановился или был убит.
Расстановка приоритетов на стратегическом и операционном уровне часто является залогом успеха или неудачи.Но многие организации делают это плохо.
Возьмем другой реальный пример: компания почтовых услуг доставляет посылки клиентам. Как и многие другие почтовые службы, компания изо всех сил пытается выжить в эпоху растущей конкуренции и цифровых заменителей. Руководители высшего звена собрали сотрудников на серии общих мероприятий, на которых генеральный директор попросил их сосредоточить внимание на двух операционных приоритетах: эффективности (сокращение сроков поставки) и удовлетворенности клиентов (обеспечение хорошего впечатления клиентов).
Одна из служащих, Мэри, получила сообщение. И это работало нормально, пока она не разносила посылки и не была встречена у дверей пожилым человеком, который попросил ее войти и немного поговорить. Естественным желанием Мэри было провести немного времени с одиноким стариком. Это было бы добрым делом, и, несомненно, это также повысило бы удовлетворенность клиентов. Но потом она замерла. А как насчет эффективности? Если она потратит хотя бы несколько минут на беседу со своим клиентом, сроки доставки пострадают.Что ей было делать? Тысячи сотрудников этой компании ежедневно сталкивались с подобными компромиссами.
Трудное положение типичное. Высшее руководство почтовой компании считало, что они изложили четкие приоритеты, но на самом деле они создали операционную дилемму, возникшую в результате стратегической неразберихи.
Сравните это с другими успешными компаниями. Европейская бюджетная авиакомпания Ryanair, например, абсолютно ясно заявляет, что это операция без излишеств, в которой эффективность является приоритетом, а эффективность важнее обслуживания клиентов.Люди, которые работают в Ryanair, знают, что является приоритетом, и поэтому знают, как распределять свое время на работе.
Расстановка приоритетов увеличивает вероятность успеха стратегических проектов, повышает согласованность и сосредоточенность команд высшего руководства на стратегических целях, устраняет все сомнения для операционных групп, когда они сталкиваются с решениями, и, что наиболее важно, формирует образ мышления и культуру исполнения.
Конечно, иногда лидеры просто принимают неправильные решения; они отдают приоритет неправильному.Но за 20 лет работы на руководящей должности я чаще вижу проблему в том, что лидеры вообще не принимают решений. Они не ясно выражают свои намерения по поводу важного. Короче говоря, они не расставляют приоритеты.
Среди организаций, с которыми я работал, а также других организаций, таких как Apple, Amazon, Lego, Ikea и Western Union, у которых очень развито чувство приоритетов, отдача значительна. Компании, которые начинают расставлять приоритеты, могут ощутить значительное сокращение затрат (по моему опыту, примерно на 15%), поскольку менее важные виды деятельности сокращаются, а дублирующиеся усилия объединяются.
Показательно количество приоритетов, признанных организацией. Примечательно, что если аппетит к риску у высшего руководства очень низок (или если они не могут или не склонны делать трудный выбор), они, как правило, имеют щедрый портфель приоритетов; они не хотят рисковать несоблюдением требований, упускать рыночные возможности, не обладать новейшими технологиями и т. д. Но по моему опыту, наиболее успешные руководители склонны больше рисковать и фокусироваться на небольшом количестве приоритетов, как лазер.Эти руководители знают, что важно сегодня и завтра. В крайнем случае, это может означать просто наличие одного приоритета. Чем больше внимания, тем лучше.
Иерархия целей
У меня более 20 лет опыта в определении приоритетов, выборе и управлении проектами. За это время я разработал простую структуру, которую я назвал «Иерархией целей». Это инструмент, который управленческие команды могут использовать, чтобы помочь им определить приоритеты стратегических инициатив и проектов:
- Назначение. Какова цель организации и как ее лучше всего добиваться? Какое стратегическое видение поддерживает эту цель?
- Приоритеты. Учитывая заявленную цель и видение, что наиболее важно для организации сейчас и в будущем? Каковы его приоритеты сейчас и на ближайшие два-пять лет?
- Проекты. На основании ответов на первые два пункта, какие проекты являются наиболее стратегическими и должны быть полностью обеспечены ресурсами? Какие проекты соответствуют цели, видению и приоритетам, а какие следует остановить или свернуть?
- чел. Теперь, когда есть ясность в отношении стратегических приоритетов и наиболее важных проектов, кто лучше всех выполнит эти проекты?
- Производительность. Традиционно показатели эффективности проекта привязаны к вводимым ресурсам (например, объему, стоимости и времени). Их намного легче отслеживать, чем результаты (например, выгоды, влияние и цели). Однако, несмотря на трудности, с которыми компании сталкиваются при отслеживании результатов, важны именно результаты. Каковы точные цели, связанные с результатами, которые будут определять реальную производительность и создание ценности? Уменьшите внимание на вводимые данные и вместо этого сосредоточьтесь на них.
В лучшем случае приоритезация усиливает стратегический диалог и выравнивание на высшем уровне организации, откуда он затем каскадно передается остальной части организации. Как только вы приведете команду руководителей к пониманию этого, приоритеты станут неотъемлемой частью организации и ее корпоративной культуры.
Подумайте о приоритетах вашей организации. Приоритет ли ваша разнообразная деятельность в интересах организации в целом? Как наилучшим образом использовать существующие и будущие финансовые и операционные возможности организации? Как изменились бы ваши приоритеты в случае внезапного экономического спада?
Четкое понимание приоритетов организации помогает согласовать большинство проектов и программ организации с ее стратегиями.Но реальность организации намного сложнее, чем многие предполагают. Иногда стратегические цели неясны или отсутствуют. Часто наблюдается разрыв и несогласованность между корпоративными стратегическими целями и целями различных бизнес-единиц, отделов или функций.
В действительности невозможно согласовать все проекты и программы организации со стратегическими целями. Обеспечение того, чтобы по крайней мере наиболее важные проекты и программы — скажем, 20 лучших — полностью соответствовали стратегическим целям, является более достижимым.
Применяя Иерархию целей, руководители узнают, что изменение приоритетов — это факт жизни организации. Действительно, каждый раз, когда организация прекращает выполнение приоритета, она становится более сфокусированной. Каждый прерванный приоритет — это возможность научиться и добиться большего успеха в следующий раз. Приоритеты меняются, и при успешном управлении они могут коренным образом изменить организацию, но только в том случае, если высшее руководство сделает трудный выбор.
.5 стратегий для определения приоритетов ваших проектов
Для управления сложным проектом требуются определенные навыки и знания. Менеджер проекта должен управлять неотъемлемыми рисками, взаимозависимыми задачами, ограничениями, распределением ресурсов, бюджетами и графиками, которые идут со всеми проектами, независимо от их размера и сложности.
Итак, как вы решаете, какие задачи расставить по приоритетам, чтобы получить наилучшие результаты от ваших проектов? Давайте посмотрим, как работает процесс приоритизации проекта и зачем он вам нужен.
Зачем вам нужен процесс определения приоритетов проекта?
Для управления одним сложным проектом использование систематического процесса, основанного на лучших практиках, разработанных в отрасли за несколько десятилетий, экономит ваше время и усилия. Зачем изобретать велосипед, если вы можете взять лучшее, чему научились другие, и применить его в своих проектах?
Опытные менеджеры проектов часто развивают навыки и знания, необходимые для определения приоритетов проектов, благодаря как практическому опыту, так и формальному обучению и обучению для получения таких квалификаций, как APM, PMP или PRINCE2.
Но в бизнесе в любой момент времени редко бывает только один проект. Скорее всего, на ходу будет несколько проектов, и менеджер портфеля или менеджер программы будет нести общую ответственность за ряд проектов, которые конкурируют за внимание и, следовательно, требуют эффективного процесса приоритизации проектов. Это может оказаться трудным даже для опытных менеджеров проектов, не имея эффективных методов.
Прежде чем мы рассмотрим различные способы определения приоритетов проектов, давайте посмотрим на разницу между управлением портфелем и программой.Это две области, тесно связанные с управлением проектами, но со своими обязанностями и проблемами и требующие особого набора навыков управления проектами.
Что такое управление программами?
Управление программами — это просто процесс одновременного управления группой проектов. Обычно это происходит потому, что они связаны друг с другом и все необходимы как часть более широкой стратегической цели в организации.
Одно из основных преимуществ управления проектами в рамках программы изменений заключается в том, чтобы избежать разрозненной работы групп и, возможно, получения конечных результатов, которые не работают вместе.
Это также полезно для обеспечения использования адекватных ресурсов там, где это необходимо, и использования этих навыков в проектах
Что такое управление портфелем?
Если менеджер проекта отвечает за один проект, а менеджер программы отвечает за группу связанных проектов, то менеджер портфеля, с другой стороны, несет еще большую ответственность по надзору за гораздо более широкой группой проектов и программ; целью является достижение более широких бизнес-целей.
Менеджер портфеля отвечает за бюджеты, ресурсы и графики в гораздо более широком сегменте бизнеса или даже за все предприятие. Они, как правило, несут ответственность за проекты в самых разных областях бизнеса. По этой причине управление портфелем в большей степени сосредоточено на стратегии и видении и, следовательно, на будущих проектах, которые могут потребоваться для достижения долгосрочных целей.
Таким образом, менеджеры портфелянесут ответственность за определение относительного приоритета отдельных проектов в организации.И, конечно же, необходимость систематического процесса определения приоритетности этих проектов.
Процессы приоритизации проектов
Совершенно очевидно, что проекты должны иметь приоритет, потому что мы не можем делать все — или не все одновременно. Бюджет, талант или и то, и другое ограничивают большинство организаций.
Таким образом, требуется методический процесс, чтобы определить, какие проекты могут быть реализованы с максимальной отдачей, учитывая бюджетные и ресурсные ограничения. Существует широкий спектр методов, которые могут помочь с расстановкой приоритетов, и обычно они охватывают:
- Бизнес-цели
- Финансовый анализ
- Риск
- Стоимость
- Значение
Давайте взглянем на парочку из них:
Метод MoSCoW
Это хорошо известный метод определения того, что необходимо заинтересованным сторонам.Он быстр и прост в использовании, но его способность точно классифицировать требования заинтересованных сторон ограничена. По этой причине он лучше всего подходит для менее сложных проектов.
MoSCoW — это аббревиатура (с добавленными буквами «o» для облегчения запоминания) следующих требований заинтересованных сторон:
- Должен иметь — критические элементы, без которых проект не может быть успешным.
- Должен иметь — важные элементы, которые могут повлиять на успех проекта.
- Может быть — элементы «приятно иметь», которые не являются существенными для успеха проекта.
- Не будет — дополнительных элементов, которые можно убрать.
Модель Кано
Модель Кано основана на предположении, что удовлетворенность конечного пользователя конечным результатом проекта связана с доступными характеристиками и функциями. Уровень удовлетворенности обычно определяется с помощью стандартной анкеты.Модель разбивает элементы на четыре отдельные категории:
- Производительность — простота использования и скорость являются типичными показателями производительности
- Должен быть — это основные функции, которые оправдывают ожидания
- Привлекательный — не обязательно, но функции, которые являются бонусом
- Безразлично — эти функции не являются необходимыми и не упускаются из-за их отсутствия
Чистая приведенная стоимость
Чистая приведенная стоимость относится к разнице между суммой денег в настоящий момент и стоимостью денег в будущем.Когда дело доходит до приоритезации, предпочтение отдается проектам с более высокой NPV. Наличные сегодня стоят больше, чем наличные в последующие годы. Это означает, что проекты с более длительным сроком службы могут иметь более низкую NPV, чем проект с более коротким сроком службы.
Срок окупаемости
Срок окупаемости — это время, необходимое для окупаемости инвестиций в проект. Он рассчитывается путем деления стоимости проекта на среднегодовые поступления денежных средств. Использование этой формулы помогает отделу управления проектами определить, какой из проектов быстрее окупит первоначальные инвестиции.Тем не менее, использование только этого метода для определения приоритетности проектов снижает риск, поскольку он не учитывает риски, связанные с осуществлением проекта, или временную стоимость денег.
Подрезная модель
Скоринговая модель — это гибкий способ определения приоритетов проектов. Критерии оценки могут быть адаптированы к ценностям и потребностям вашего PMO, а процесс может быть как неформальным, так и настолько тщательным, насколько это необходимо. Процесс выглядит следующим образом:
- Выберите три или четыре критерия оценки (например, выгоды, размер, риск, влияние, маржа, стоимость, осуществимость)
- Назначьте диапазоны критериям для ранжирования проектов (например,г., 0-5 или 0-10)
- Присвойте веса каждой категории (например, риск может быть более важным решающим фактором, чем влияние)
- Протестируйте модель с различными бизнес-подразделениями, чтобы оценить, дает ли модель значимые результаты
Это всего лишь несколько методов приоритизации проектов с использованием различных критериев. Есть еще много других, включая Story Mapping и Internal Rate of Return, если вы заинтересованы в поиске дополнительных методов приоритизации, которые вы могли бы попробовать.
Перед вами
Управление одним проектом может быть непростым делом, а поддержание нескольких проектов может быть… ну, горсткой! Таким образом, без сомнения, управление проектом требует использования хорошо понятных процедур и процессов, чтобы проект был успешным.
Читатели, пробовали ли вы какой-либо из этих процессов приоритизации проектов — какой вы предпочитаете?
Хотите улучшить свои навыки управления проектами? Узнайте, как выполнять эффективное планирование и многое другое, из курса Project Management for Experts.
Хотите узнать больше?
Поднимите свои навыки управления проектами на новый уровень с помощью нашей всеобъемлющей (и бесплатной) электронной книги!
Мишель Саймондс
Мишель Саймондс — консультант по цифровому маркетингу и основатель Ditto Digital. Она также является квалифицированным менеджером проектов PRINCE2 и редактором блога по управлению проектами Project Management Works.
.Процесс приоритизации проектов: определение и критерии ранжирования
Необходимость в приоритезации проекта возникает, когда в организации есть два или более независимых или зависимых (портфельных) проекта, которые выполняются параллельно. Чтобы обеспечить достижение стратегических целей и задач, этой организации необходимо сосредоточиться на правильных проектах среди множества. Но как они могут это сделать? Как определить наиболее предпочтительные проекты для реализации в данный момент времени? Наконец, как быть уверенным, что выполняются нужные проекты? В этой статье мы собираемся ответить на эти важные вопросы.Мы сосредоточимся на определении процесса приоритезации проектов, объясним, какие критерии использовать для ранжирования одновременных проектов, и подытожим, как сделать портфели проектов успешными.
Процесс приоритезации
Проще говоря, процесс приоритизации проектов — это действие для определения того, какие проекты в портфеле следует выполнять в какой последовательности. Это попытка сделать портфель проектов более эффективным за счет определения наиболее эффективного способа реализации проектов.Вот более широкое определение:
Процесс приоритезации проектов — это структурированная и последовательная деятельность, направленная на анализ текущей операционной среды для выявления любых проектов, выполняемых параллельно в рамках одного и того же портфеля, разработка модели оценки, включая критерии ранжирования, и применение этой модели для определения приоритетности проектов в порядок определения порядка исполнения, обеспечивающего максимальную эффективность всего портфеля. Этот процесс служит основой для управления эффективностью параллельных проектов.
Процесс определения приоритетов проекта сложный и повторяющийся, поэтому его можно повторять несколько раз в течение одного и того же срока действия портфеля. Он ориентирован на конечный результат, что означает, что он дает определенный результат, который жизненно важен для успеха дальнейшего управления портфелем. Процесс ранжирует проекты в рамках одной и той же операционной среды, чтобы устранить разрывы в мультимодальных возможностях и связях, которые могут существовать между экологическими компонентами.
Мы разделяем процесс определения приоритетов на , следующие ключевые шаги :
- Сборник — вы должны собрать и собрать все данные о своих проектах.
- Ранжирование — вы должны разработать и использовать модель ранжирования, которая включает критерии для определения приоритетов.
- Проверка — необходимо одобрить ранжированные проекты.
В одной из следующих статей мы подробно опишем все шаги. Ключевым моментом этой статьи является объяснение того, как разработать подходящую модель сгребания, которая могла бы позволить определить правильные критерии для определения приоритетов портфельных проектов.
Установить критерии ранжирования
Ниже мы предлагаем список показателей, которые вы можете использовать в качестве критерия ранжирования для приоритизации параллельных или портфельных проектов.Обратите внимание, что список не является полным и может быть дополнен другими элементами (например, безопасность, интеграция, возможность подключения, мобильность, экономическая эффективность, возможность реализации и т. Д.). В этой публикации мы описываем только ключевые критерии. При необходимости вы можете разработать свои собственные критерии при расстановке приоритетов вашего проекта.
КПД . Показатель эффективности показывает способность проекта давать желаемый результат при минимальном возможном потреблении ресурсов, доступных для проекта.Если проект может превратить входы в выход, потребляя меньше ресурсов, то этот проект окажется эффективным. Общая формула расчета эффективности проекта:
Фактический выход
———————————– x 100%,
Стандартный выход
Возможность изменения . Это доказывает способность проекта реализовывать запланированные изменения, а также адекватно реагировать на любые новые изменения, которые кажутся жизненно важными для успеха проекта. Чем выше изменчивость, тем большее влияние проект оказывает на изменяющуюся среду.Это означает, что ваш проект легко адаптируется к изменениям, поэтому у проекта появляется больше шансов достичь желаемого результата при заданных или изменяющихся требованиях.
Управляемость . Этот элемент определяет, в какой степени проект можно вести и направлять с помощью существующих элементов управления. Мера характеризуется:
- Планирование
- Мониторинг
- Ведущий
- Контроллинг
Эти характеристики определяют управляемость ваших проектов.Чем выше управляемость, тем выше эффективность.
Координация . Этот показатель показывает, хорошо ли скоординирован проект и соответствует ли он принятому плану управления. Это связано с эффективностью проекта. Менеджер проекта эффективно координирует проект, если этот человек может гарантировать, что ресурсы проекта используются и потребляются для достижения указанных целей и задач. Помните: ваш проект будет более ценным, если он хорошо согласуется с .
Устойчивое развитие . Он показывает, может ли проект поддерживать непрерывное развитие без значительного ухудшения существующей среды. Ваш проект является устойчивым, если он дает желаемые результаты без снижения его текущей производственной мощности. Устойчивые проекты должны получить более высокий рейтинг.
Разработка модели ранжирования
Теперь пришло время разработать модель оценки, которая объясняет, как вы будете проводить процесс ранжирования.Это означает, что вам необходимо решить, какие критерии использовать и какие данные требуются для оценки. Мы предлагаем вам использовать все перечисленные здесь критерии. Также вы можете разработать свои собственные меры, которые впишутся в ваше конкретное портфолио. Помните: чем больше критериев вы используете, тем более точным и подходящим будет рейтинг вашего проекта.
Теперь по поводу данных, необходимых для ранжирования. Вот список источников данных , которые необходимо просмотреть, чтобы получить данные, необходимые для анализа и ранжирования проекта:
- Текущее состояние проекта по сравнению с планом (вы можете получить эти данные из отчетов о состоянии и встреч)
- Доставки приняты / не приняты в любой момент времени
- Объем ползучести
- Уровень вовлеченности заинтересованных сторон (можно получить из матрицы заинтересованных сторон)
- Требования к пользователю
- Цели и задачи проекта и их статус
- Журналы ошибок и рисков
- Обучение и возможности команды
- Другие важные документы и записи, объясняющие текущую эффективность каждого отдельного проекта.
Вы должны собрать как можно больше информации о проектах вашего портфолио, чтобы получить четкое представление о том, что происходит в среде портфолио. Ниже мы приводим пример таблицы оценки проекта .
В этом примере Проект 3 получает более высокий балл (320) по сравнению с Проектом 1 (222) и Проектом 2 (253). Столбец «Оценка» таблицы используется в качестве основы для определения приоритетов проектов. Фактически, Проект 3 получает наивысший приоритет, в то время как остальные два проекта получают более низкий приоритет.
Обратите внимание, что здесь мы не объясняем, как рассчитывать данные в таблице. Команда управления портфелем вашего проекта решает, какой подход или методологию скоринга использовать для оценки по критериям. В данном примере мы использовали наш собственный метод .
Заключение
Подводя итог всему сказанному в этой публикации, можно сказать, что процесс приоритезации параллельных или портфельных проектов сложен и требует от управленческой команды больших аналитических способностей.Во-первых, команде необходимо определить, какие проекты ранжировать, затем разработать критерии ранжирования и, наконец, создать модель, объясняющую, как оценивать проекты по критериям, а также какие формулы и параметры использовать для ранжирования. В результате создается матрица приоритетов, которая показывает предпочтительный порядок выполнения и последовательность проектов, организованных в программу или портфель.
.
Добавить комментарий