Освоение расстановки приоритетов: стратегии эффективного управления продуктами
12 января 2024 г.По мере того, как многие профессионалы размышляют о своем рабочем процессе и пытаются определить возможности для улучшения, становится все более очевидным, что во всех процессах, включая управление продуктами, расстановка приоритетов может стать точкой роста.
Плохая расстановка приоритетов может проявляться в, казалось бы, незначительных неудобствах, таких как попытка уместить чрезмерный объем работы в ограниченные сроки – затруднительное положение, знакомое всем нам.
Тем не менее, когда эти проблемы сохраняются постоянно, совокупный эффект превращает эти незначительные стрессы в серьезные препятствия, что приводит к созданию некачественной продукции и огромной трате драгоценного времени.
Тогда возникает вопрос: как можно активно решать проблемы расстановки приоритетов, не допуская их превращения в серьезные препятствия?
В этой статье мы рассмотрим проверенные методы определения приоритетов, которые могут помочь менеджерам по продуктам и командам принимать обоснованные решения. Каждый метод предлагает уникальную информацию о разработке продукта.
Метод MoSCoW сортирует функции на необходимые и полезные. Модель Кано фокусируется на удовлетворении потребностей клиентов. Матрица Эйзенхауэра уравновешивает срочность и важность.
Вместе эти методы образуют набор инструментов, который помогает командам разработчиков решать проблемы, разумно распределять ресурсы и создавать продукты, которые нравятся их аудитории.
1.Метод MoSCoW
Метод MoSCoW был предложен Дай Клеггом из Oracle UK Consulting в середине -1990-е годы. Это эффективный способ сортировки задач по критическим и некритическим категориям.
Аббревиатура MoSCoW означает:
Обязательные требования (M): Это основные функции или требования, без которых проект или продукт будут считаться неудачными. Они представляют собой основные функции, которые необходимо реализовать для успеха проекта.
Необходимо (S): Это важные функции, которые не имеют решающего значения для успеха проекта, но значительно повысят его ценность. Они расставляются по приоритету после рассмотрения необходимых вещей.
Может быть (C): Это полезные функции, которые желательны, но не обязательны для успеха проекта. Обычно они рассматриваются после рассмотрения обязательных и необходимых вещей.
Не хотелось бы или хотелось бы (W): Эти задачи желательны (например, «Хотелось бы иметь…»), но не включены в этот проект. Вы также можете использовать эту категорию для наименее важных действий.
Пример метода MoSCoW
Представьте, что мы разрабатываем новый веб-сайт электронной коммерции, поэтому у нас будет следующий список приоритетов:
Обязательные требования (M):безопасная система онлайн-платежей, список продуктов и функции поиска, регистрация пользователей и аутентификация.
Необходимо (S): отзывы и рейтинги клиентов, интеграция с социальными сетями для обмена продуктами, функциональность списка желаний.
Можно добавить (C): программа лояльности для постоянных клиентов, чат поддержки клиентов в режиме реального времени, фильтры расширенного поиска.
Нежелательно (W): функции дополненной реальности для виртуальной примерки продукта (считаются слишком сложными для первоначального выпуска), варианты оплаты криптовалютой (на данный момент считаются низким приоритетом).
Разделив функции на эти четыре группы, команда проекта может гарантировать, что в первую очередь они сосредоточатся на наиболее важных элементах. Мы также получаем четкое понимание того, что должно быть поставлено и что можно рассматривать как дополнительные улучшения.
Это помогает эффективно управлять ожиданиями и ресурсами заинтересованных сторон на протяжении всего жизненного цикла проекта.
Кроме того, метод MoSCoW обеспечивает гибкость при адаптации к меняющимся требованиям и приоритетам проекта.
2. Модель Кано
Модель Кано, разработанная профессором Нориаки Кано, представляет собой основу для понимания и определение приоритетов потребностей и ожиданий клиентов при разработке продукта. В ней функции подразделяются на три основных типа: Основные потребности, Требования к производительности и Интересующие потребности. Модель помогает командам разработчиков определить, какие функции приведут к повышению удовлетворенности клиентов.
Базовые потребности. Базовые потребности – это фундаментальные требования, которые при удовлетворении не обязательно повышают удовлетворенность клиентов, но могут вызвать неудовлетворение, если их не выполнить.
Потребности в производительности. Потребности в производительности — это характеристики, уровень удовлетворения которых прямо пропорционален степени реализации. Соответствие или превышение ожиданий в этих областях может положительно повлиять на удовлетворенность.
Потребности в возбуждении (наслаждающие): Потребности в возбуждении – это неожиданные или инновационные функции, которые могут значительно повысить удовлетворенность клиентов, если они присутствуют, но не вызывают недовольства в случае их отсутствия, поскольку клиенты их не ожидают.
Пример модели Кано
На этот раз давайте рассмотрим процесс разработки фитнес-приложения. Наша Основная потребность — точно отслеживать шаги и сожженные калории. Пользователи ожидают, что приложение предоставит надежные данные; если он постоянно не сможет этого сделать, возникнет недовольство.
Потребность в производительности – это персональная рекомендация по тренировкам, основанная на предпочтениях и целях пользователя. Поскольку приложение более точно адаптирует рекомендации по тренировкам, удовлетворенность пользователей возрастает.
Последний из них — это потребность в волнении – функции геймификации. Это могут быть виртуальные награды или испытания. Эти элементы не являются необходимыми для основных функций, но они могут значительно повысить удобство использования и удовлетворенность пользователей, если они присутствуют.
Выполнив пятиэтапный метод и получив список приоритетных функций, вы можете улучшить свое планирование, создав модель выгод и затрат для каждой функции. Этот шаг позволяет вам определить функции, реализация которых может принести существенную отдачу от инвестиций за счет увеличения продаж.
Эта информация становится особенно ценной при управлении циклом разработки продукта, особенно когда вы сталкиваетесь с ограничениями во времени и финансовых ресурсах.
3. Матрица Эйзенхауэра
Матрица Эйзенхауэра, также известная как Матрица срочно-важных задач, — это инструмент повышения производительности и расстановки приоритетов, названный в честь бывшего президента США Дуайта Д. Эйзенхауэра, который, как известно, сказал: «У меня есть два типа проблем: срочные и важные. Срочное не важно, а важное никогда не бывает срочным». Матрица распределяет задачи по четырем квадрантам в зависимости от их срочности и важности:
Срочно и важно (сделать в первую очередь): Срочным и важным задачам уделяется наивысший приоритет, и их следует решать немедленно. Это критически важные задачи, которые оказывают существенное влияние на проект или продукт.
Важные, не срочные (расписание): Задачи в этом квадранте важны для достижения долгосрочных целей, но не зависят от времени. Их следует планировать и планировать так, чтобы они не стали срочными в будущем.
Срочно, не важно (Делегировать): Срочные, но не важные задачи можно делегировать другим, если это возможно. Возможно, они не способствуют успеху проекта напрямую, но все же требуют внимания.
Не срочно и не важно (исключить или отложить): Задачи в этом квадранте не являются ни срочными, ни важными и могут быть отложены или исключены. Они не вносят существенного вклада в успех проекта. n
Пример матрицы Эйзенхауэра
Предположим, менеджер по продукту работает над программным обеспечением для системы управления взаимоотношениями с клиентами (CRM). Вот как они могут применить матрицу Эйзенхауэра для определения приоритетов требований к продукту:
Срочно и важно (сделать в первую очередь): В системе CRM имеется критическая уязвимость безопасности, требующая немедленного внимания для защиты данных клиентов. Это становится главным приоритетом для команды разработчиков.
Важно, не срочно (расписание): Улучшение пользовательского интерфейса для более интуитивно понятного взаимодействия с пользователем важно для удовлетворения клиентов, но не является немедленным. Менеджер по продукту планирует эту задачу на следующий спринт разработки.
Срочно, не важно (Делегировать): Обнаружена незначительная ошибка в менее критичной функции. Менеджер по продукту делегирует эту задачу младшему разработчику, пока он занимается более важными вопросами.
Не срочно и не важно (устранить или отложить): Предлагаемая функция, которая добавляет декоративный элемент в пользовательский интерфейс, но не вносит существенного вклада в функциональность, считается несрочной и неважной.
Менеджер по продукту решает отложить эту функцию до тех пор, пока не будут решены более важные задачи.
Как можно видеть, матрица Эйзенхауэра — это простой инструмент для рассмотрения долгосрочных результатов ваших задач и сосредоточения внимания на том, что сделает проект наиболее эффективным. Это помогает визуализировать все острые задачи в матрице срочных/важных и обеспечивает попадание всех задач более крупного проекта в один из четырех вышеупомянутых квадрантов.
Метод RICE
Метод оценки RICE – это система определения приоритетов, используемая для ранжирования и определения приоритетности функций или задач на основе их потенциального воздействия. Аббревиатура RICE расшифровывается как Охват, Влияние, Уверенность и Усилия. Каждому из этих факторов присваивается числовая оценка, а общая оценка используется для определения приоритета конкретного элемента.
Вот разбивка каждого компонента метода RICE:
Охват. Охват измеряет количество пользователей или клиентов, на которых будет влиять функция или задача. Он количественно определяет потенциальную аудиторию, на которую повлияет внедрение.
Оценка. Присвойте числовое значение от 1 до 10, где 1 – низкий охват, а 10 – высокий охват. Например, если функция затрагивает всех пользователей, она может получить оценку 10.
Воздействие. Влияние оценивает потенциальный положительный эффект или выгоду от реализации функции или задачи. Он количественно определяет уровень позитивных изменений или улучшений.
Оценка. Как и в случае с охватом, присвойте числовое значение от 1 до 10. Функция, которая значительно повышает вовлеченность пользователей или ключевые показатели эффективности, может получить высокую оценку воздействия.
Уверенность. Уверенность отражает уровень уверенности или уверенности команды в оценках охвата, воздействия и усилий. Он учитывает уровень неопределенности, связанный с расстановкой приоритетов.
Оценка. Назначьте процентную оценку от 1 % до 100 %. Объект с высокой степенью достоверности оценок может получить оценку 90 %, а более неопределенная оценка может получить более низкую оценку, например 50 %.
Усилия. Усилия измеряют ресурсы, время и сложность, необходимые для реализации функции или задачи. Он количественно определяет затраты или усилия, связанные с внедрением.
Оценка. Как и в случае с охватом и влиянием, присвойте числовое значение от 1 до 10, где 1 – низкие усилия, а 10 — высокие усилия. Простая задача может получить низкую оценку за трудозатраты, а сложная функция — высокую.
==Показатель RICE рассчитывается по формуле:==
==(Охват x Влияние x Уверенность) / Усилия.==
Пример метода RICE:
Теперь мы попробуем расставить приоритеты функций воображаемого мобильного приложения, используя метод RICE. Давайте сравним функцию А и функцию Б.
Заключение
Каждый метод в этой подборке служит общей цели: гарантировать, что ваше внимание будет постоянно сосредоточено на наиболее важных задачах. В конечном итоге выбранная конкретная техника становится вторичной.
Независимо от того, выбираете ли вы один метод, комбинируете различные методы или даже настраиваете свой подход, интегрируя аспекты разных методов, главное — выбрать подход, который резонирует с вашим рабочим процессом и наиболее подходит вашему продукту.
Первостепенным фактором является принятие мер и начало работы на основе метода, который соответствует предпочтениям и стилю работы вашей команды.
Оригинал