🔝 Приоритизация задач по методу MoSCoW: как за 5 минут научиться грамотно расставлять приоритеты

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

Что такое приоритизация MoSCoW?

Приоритизация MoSCoW, также известная как метод MoSCoW или анализ MoSCoW, является популярным методом приоритизации для управления требованиями.

Аббревиатура MoSCoW представляет четыре категории инициатив: must-have, should-have, could-have и won’t-have. Некоторые компании также используют букву W в MoSCoW для обозначения wish.

История метода MoSCoW

Эксперт по разработке программного обеспечения Дай Клегг создал метод MoSCoW, работая в Oracle. Он разработал структуру, чтобы помочь своей команде расставить приоритеты задач во время разработки выпусков продукта.

Вы можете ознакомиться с подробным отчетом об использовании приоритизации MoSCoW в руководстве Dynamic System Development Method (DSDM). Но поскольку MoSCoW может расставлять приоритеты задач в рамках любого ограниченного по времени проекта, команды адаптировали этот метод для широкого спектра задач.

Как работает расстановка приоритетов MoSCoW?

Перед запуском анализа MoSCoW необходимо сделать несколько шагов. Во-первых, ключевые заинтересованные стороны и команда разработчиков продукта должны согласовать цели и факторы приоритизации. Затем все участники должны договориться о том, каким инициативам отдать приоритет.

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

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

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

Категории приоритетов

1. MUST-have требования

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

Категория must-have требует от команды выполнения обязательного задания. Если вы не уверены, относится ли что-то к этой категории, задайте себе следующие вопросы (см. рис. 2.).

MUST-have требования:

• Что произойдет, если это требование не будет включено в конкретный релиз?
• Есть ли более простой способ достичь этого?
  
• Будет ли продукт работать без него?
  

Если без требования продукт не заработает или без нее релиз станет бесполезен, требование, скорее всего, является must-have.

2. Should-have требования

Should-have требования всего лишь на шаг ниже must-have. Они важны для продукта, проекта или релиза, но не так сильно. Если их не включать, продукт или проект по-прежнему работают. Однако такие задачи могут принести значительную пользу.

Should-have инициативы отличаются от must-have тем, что их можно запланировать на будущий релиз, не влияя на текущий. Например, улучшение производительности, исправление мелких ошибок или новые функции могут быть should-have инициативами. Без них продукт все еще работает.

3. Could-have требования

Требования could-have можно описать как «хорошо бы иметь». Задачи could-have не являются необходимыми для основной функции продукта. Однако по сравнению с should-have инициативами они оказывают гораздо меньшее влияние на результат, если их не учитывать.

Таким образом, требования, помещенные в категорию could-have, часто теряют приоритет в первую очередь, если проект в категории should-have или must-have оказывается больше, чем ожидалось.

4. Will not have (в этот раз)

Одним из преимуществ метода MoSCoW является то, что он помещает несколько инициатив в категорию Will not have. Категория может управлять ожиданиями относительно того, что команда не будет включать в конкретный релиз (или другой временной интервал, который вы считаете приоритетным).

Помещение инициатив в категорию Will not have — это один из способов предотвратить расползание рамок. Если требования относятся к этой категории, команда знает, что они не являются приоритетными для данного конкретного периода времени.

Некоторые требования из группы Will not have будут иметь приоритет в будущем, в то время как другие, скорее всего, не осуществятся. Некоторые команды решают различать их, создавая подкатегории в этой группе.

Как команды разработчиков могут использовать MoSCoW?

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

Расставляйте приоритеты в зависимости от бюджетных ограничений.

Что если ограничивающим фактором для команды разработчиков является не крайний срок, а ограниченный бюджет, навязанный компанией? Работая с менеджерами по продукту, команда может сначала использовать MoSCoW, чтобы определить инициативы, которые представляют собой must-have и should-have. Затем, опираясь на бюджет отдела разработки, команда может выяснить, какие элементы они могут выполнить.

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

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

Расставьте приоритеты на основе конкурирующих потребностей в компании.

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

Каковы недостатки приоритезации MoSCoW?

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

1. Непоследовательный процесс оценки может привести к тому, что задачи будут помещены в неправильные категории

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

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

2. Отсутствие учета всех соответствующих заинтересованных сторон может привести к тому, что элементы будут помещены в неправильные категории.

Чтобы узнать, какие инициативы вашей команды must-have, а какие should-have, вам понадобится как можно больше контекста.

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

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

3. Командная предвзятость за (или против) требований может подорвать эффективность MoSCoW.

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

Один из рисков использования приоритезации MoSCoW заключается в том, что команда может ошибочно подумать, что MoSCoW сам по себе представляет собой объективный способ измерения элементов в их списке. Они обсуждают инициативу, соглашаются, что она «должна быть», и переходят к следующей.

Но вашей команде также потребуется объективная и последовательная структура для ранжирования всех инициатив. Это единственный способ свести к минимуму предвзятость вашей команды в пользу инициатив или против них.

Когда использовать метод MoSCoW для определения приоритетов?

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

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

Каковы передовые методы использования приоритизации MoSCoW?

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

1. Выберите объективную систему ранжирования или подсчета очков

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

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

• Взвешенная оценка (Weighted scoring).
• Ценность vs. сложность (Value vs. Complexity).
• Модель Кано (Kano model).
• Купи функцию (Buy-a-feature).
• Оценка возможностей (Opportunity scoring).

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

2. Запросить информацию у всех основных заинтересованных сторон

Чтобы убедиться, что вы помещаете каждую инициативу в правильную корзину — must-have, should-have, could-have или won’t-have — вашей команде нужно общее положение.

В начале вашего метода MoSCoW ваша команда должна рассмотреть, какие заинтересованные стороны могут предоставить ценное общее положение и идеи. Продажи? Успех клиента? Исполнительный состав? Менеджеры по продукту в другой области вашего бизнеса? Включите их в процесс оценки вашей инициативы, если вы считаете, что они могут помочь вам увидеть возможности или угрозы, которые ваша команда может упустить.

3. Распространите процесс MoSCoW в организации

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

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

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

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

Материалы по теме

• 👥🗺️ Product Discovery: что такое дискавери-команда и чем она занимается
• ✔️ Ключевые различия между Agile, Scrum и Kanban
  
• ✔️ Что такое методология Scrum простыми словами и как она работает
  

Источники

• https://www.productplan.com/glossary/moscow-prioritization/