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

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

Один из таких инструментов — метод MoSCoW. Расскажу о его принципах и о том, как он помогает руководителям проектов и их командам.

Что такое метод MoSCoW

MoSCoW — это аббревиатура, определяющая четыре категории приоритетов:

• must-have — обязательно должно быть сделано;
• should-have — должно быть сделано;
• could-have — могло бы быть сделано;
• won't-have — не должно быть сделано.

Буквы О вставлены между заглавными для облегчения произношения 🙂

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

Категории MoSCoW

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

Расшифрую аббревиатуру более подробно:

• Must-have — это требования, которые определяют успех проекта. Они критичны для основной функциональности или цели проекта, и без них проект не может быть продолжен;
• Should-have — эти требования важны, но не абсолютно необходимы. Они не являются решающими для успеха, но добавляют значительную ценность и должны быть выполнены, если это возможно;
• Could-have — это требования, которые полезно, но не обязательно выполнять. Это желательные фичи или апгрейды, но их отсутствие не повлияет на основную функциональность проекта. Их можно даже не включать, если они негативно влияют на соблюдение дедлайнов или затраты;
• Won’t-have — это требования, которые должны быть исключены из объема проекта. Это функции или усовершенствования, которые невыполнимы, слишком дороги или не соответствуют целям проекта. Как мониторы в нетленной «Тачке на прокачку».

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

Ключевые преимущества MoSCoW

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

Недостатки расстановки приоритетов в MoSCoW

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

MoSCoW и Time-blocking

Time-blocking  — это техника управления временем, которая устанавливает фиксированные периоды, в течение которых вы должны заниматься задачами. Менеджеры используют блокировку времени, чтобы гарантировать, что работа будет выполнена в срок.

Совместное использование MoSCoW и time-blocking позволяет создавать высококачественные продукты, управлять объемом и определять приоритеты требований в рамках запланированных сроков и бюджетов.

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

Особенно эффективен метод MoSCow при создании нового продукта, будь то приложение для смартфона или новая коллекция одежды.

Метод MoSCoW прекрасно сочетается с cust-dev для обеспечения соответствия продукта реальным потребностям клиентов и их ожиданиям, а заодно — бизнес-целям.

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

Метод MoSCoW в Shtab

Shtab — это сервис для управления проектами, который помогает организовать как индивидуальную работу, так и деятельность команд любого размера.

https://www.youtube.com/watch?v=g3IDg8Q0oXg\u0026pp=ygUs0JzQtdGC0L7QtCDQv9GA0LjQvtGA0LjRgtC40LfQsNGG0LjQuCBNb1NDb1c%3D

В Shtab с помощью Меток вы можете обозначить задачи в соответствии с их категориями по MoSCoW. Для удобства задайте им «говорящие» цвета, например, самые важные можно выделить красным, необязательные – серым.

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

Кроме того, в Shtab есть прямая альтернатива методу MoSCow — матрица Эйзенхауэра. В ней вы делите задачи на важные/неважные и срочные/несрочные. Четырехсегментная матрица позволяет сконцентрироваться на важных и срочных задач и не отвлекаться на то, что может подождать.

Заключение

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

5 техник определения приоритетов для IT команд

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

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

Рассмотрим подробнее 5 известных методологий, которые помогают прийти к успеху. Существует ли идеальная методология, которая раз и навсегда расставит приоритеты в рабочих задачах и личных делах? У каждого менеджера проектов или менеджера продукта на этот вопрос, наверняка, есть свой ответ.

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

5 методов приоритизации для менеджеров проектов и IT команд

Метод MoSCoW для категоризации задач

Методологию MoSCoW сегодня знают во всем мире и применяют широко в разных областях управления. С известной столицей технику ничего не связывает. Согласные буквы в акрониме MSCW — это степени приоритетности:

• M – задачи и требования, которые имеют самый высокий приоритет и должны быть первоочередно применимы к продукту в первую очередь. Без них релиз не будет выполнен (это must).
• S – важные требования, но не с самой высокой приоритетностью. Обычно они не имеют решающего значения, но все равно обязательны к исполнению (это should).
• C – требования и задачи, желательные для релиза (это could).
• W – наименее критичные требования, их можно проигнорировать или перенести до следующих релизов (это would).

На примере задач платформы для управления Hygger.

io (реализованных или только планируемых) рассмотрим, как можно определить приоритеты, согласно методологии MoSCoW:

• Must Have — внедрить Priority Chart — график, на котором можно отбирать самые ценные идеи и отдавать их в разработку, ранжировать идеи по метрикам Value / Efforts, обеспечить поддержку разработки с помощью Kanban и Sprint досок, добавить Burndown Chart для трекинга прогресса по спринту.
• Should Have — внедрить функцию Time tracking для учета отработанного времени, Cycle /Lead Time Report для контроля над процессом, сделать интеграцию со Slack для получения обновлений на досках.
• Could have — добавить раздел My Tasks, где можно посмотреть все задачи в разных статусах, внедрить Client Access для приглашения клиентов в проект.
• Would Have — обеспечить SAML SSO /G Suite SSO для единого входа сотрудников в приложение, добавить Calendar View для доски, добавить интеграцию с системами управления проектами (JIRA, PivotalTracker, Trello, и др.)

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

Модель Кано

Модель Кано — технология, разработанная японцем Нориаки Кано в 1984 году. Именно тогда он опубликовал статью, в которой расписал методологию.

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

В модели Кано выделены 3 основные составляющие профиля качества, влияющие на удовлетворенность потребителя: ожидаемое, основное, и привлекательное, вызывающее восхищение.

Ожидаемые свойства по Кано — это базовые свойства продукта или услуги.

Они есть по умолчанию. Покупатель вряд ли будет задумываться об этих свойствах, поскольку воспринимает их как что-то само собой разумеющееся.

Часто в качестве примера ожидаемых свойств приводят работу авиалиний. Гарантия того, что всем хватит места в салоне самолета – это ожидаемое свойство.

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

Основные свойства — это желаемое. Их выполнение влияет напрямую на удовлетворенность потребителя. Именно на основных свойствах продукты пытаются выделится и создать конкурентное преимущество.

• В примере с авиалиниями, основным свойством может быть отсутствие пересадок на длительном маршруте.
• Свойства, вызывающие восхищение — это неожиданные для потребителя свойства: дополнительные, необычные, носящие характер сюрприза.
• Ваш любимый десерт на борту авиаперевозчика – пример такого свойства.

Уровень выполнения подобных свойств не влияет на удовлетворенность потребителей напрямую (как и в случае с основными свойствами). Если неожиданное свойство отсутствует, потребитель не должен расстроиться, поскольку и не ожидал его в рядах ожидаемых свойств. Но если же потребитель будет приятно впечатлен – это принесет приятные бонусы продукту или услуге, как минимум, о них узнает ближний круг обрадованного потребителя. Со временем, требования клиента могут меняться и то, что сегодня вызывало восторг, уже завтра может превратиться в стандарт, а послезавтра стать обязательным условием качества.

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

Техника Story Mapping

Методология Story Mapping стала известна в начале века из статьи Джеффа Паттона. Смысл метода в том, что бэклога в продукте мало для определения приоритетов в работе.

Паттон считает, что необходима более развернутая структура и предлагает следующую механику:

Горизонтальная ось представляет последовательность использования.

Задачи на ней размещаются в последовательности, в которой они выполняются пользователем.

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

Группы связанных историй группируются как активности.

Сильные стороны методологии Story Mapping

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

Внутриорганизационные методологии

Методология KJ

Методологию, придуманную Jiro Kawakita (отсюда — KJ) часто используют на различных тренингах и групповых занятиях по менеджменту. Суть технологии — в групповом процессе установления приоритетов. Метод KJ — это процесс, состоящий из 8 этапов для групп любого размера.

Для реализации такого метода понадобится не менее одного часа. Участникам следует подготовиться:

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

8 этапов методологии KJ

1. Выберите центральный вопрос, который будет стимулировать результаты. Каждый сеанс предполагает свой центральный вопрос.
2. Организуйте рабочую группу. Участники группы должны быть из различных отделов компании.
3. “Выгрузите данные” Для этого понадобятся стикеры. Каждому участнику группы предлагается инициировать мозговой штурм в разных направлениях.
4. Разместите стикеры на стенке в рандомном порядке. Каждый участник, при необходимости, может добавить новые стикеры на дальнейших этапах.
5. Сгруппируйте похожие тематики. Когда все стикеры на стене добавлены, вся группа начинает группировать похожие темы.
6. Присвойте имена. Участники должны присвоить имя каждой группе, используя стикеры другого цвета.
7. Проголосуйте за наиболее важные, с вашей точки зрения, группы, которые помогут ответить на центральный вопрос.

Метод MoSCoW для приоритизации задач в бэклоге

Было бы здорово иметь возможность сделать все хотелки заказчика (причем еще вчера, конечно), но обычно все-таки приходится как-то ставить приоритеты. Симпатичный и простой способ выбрать, а что же делать в первую очередь из огромного бэклога – метод MoSCoW.

Категории приоритизации легко запомнить, они скрыты в мнемоническом названии метода:

1. M – Must – делаем в любом случае, без вариантов.
2. О
3. S– Should – делаем при первой возможности, очень нужная вещь.
4. C – Could – было бы очень и очень неплохо сделать, но нет – так нет.
5. О
6. W – Would – могли бы сделать, но, скорее всего, не будем.

Как выполнить приоритезацию по методу MoSCoW

Просто берем в охапку владельца продукта и вместе с ним для каждого пункта в бэклоге проставляем соответствующую букву. После этого сортируем бэклог так, чтобы все задачи были в указанной последовательности (M-S-C-W) и делаем все подряд.

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

Пример применения метода MoSCoW

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

1. M – полки, фасады, столешница, фурнитура Blum (да, для меня это must), двухсекционная раковина, смеситель.
2. S – подсветка по периметру шкафов (я жила без подсветки, и это было очень неудобно), кран с вытягивающимся шлангом, автоматический подвод воды к кофемашине.
3. C – розетки, встроенные в нижнюю часть шкафов, чтобы они не выделялись, и мое чувство прекрасного не страдало, измельчитель для бытовых отходов, встроенный в раковину (на практике, к сожалению, оказался бессмысленным), крутящаяся полка для углового шкафа.
4. W – сервоприводы для ящиков (это обалденная вещь для открывания ящиков легким касанием, видела у подруги и теперь это моя мечта, но что-то мне подсказывает, что в N тысяч я точно не уложусь, один привод 25 тысяч стоит. Но если за время изготовления кухни американская бабушка оставит мне наследство – обязательно сделаю!), подсветка внутри шкафов.

Ну вот и все, приоритеты понятны, можно делать кухню.

Используете MoSCoW в работе? Расскажите в х!

P.S. Если эта техника вам не подошла – посмотрите еще пост про модель Кано.

На кофе и новые материалы для читателей блога 🙂

Оценка проектов в Agile по методу MoSCoW

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

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

Но за такую гибкость приходится платить неопределённостью.

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

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

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

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

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

Чтобы этого избежать, необходимо провести оценку ценности для каждого элемента. Для этого существует метод MoSCoW.

MoSCoW – это аббревиатура для четырёх основных этапов приоритизации элементов в процессе разработки:

• «MUST». Первая буква означает те элементы, которые непременно должны быть включены в продукт, иначе он не будет выполнять наиболее важные функции и приносить пользователю ценность. Также к данной категории относятся требования законодательства, необходимые для реализации проекта. Эта категория имеет наивысший приоритет.
• «SHOULD». В данной группе находятся те элементы, которые следует включить в финальную версию продукта. Это те элементы, которые важны для заказчика, и продукт не будет полноценным, но при этом будет работать. Вторая группа по уровню приоритета.
• «COULD». Те элементы и опции, которые клиент хотел бы видеть в своём продукте. Наличие опций из этой группы приносит наибольшее удовлетворение клиенту или заказчику. Эти опции можно сказать, «вишенка на торте», имеют низкий приоритет, но для удовлетворения заказчика, необходимы.
• «WON’T». В эту группу включаются те опции, которые решено было не включать в нынешнюю версию продукта.

По аналогии с пирамидой Маслоу, эти группы также можно расположить в виде пирамиды, где на верхнем уровне будут находиться необходимые опции, а внизу — самые необязательные (см. Рисунок 1). Соответственно, чем ближе к верху пирамиды, тем меньше количество элементов в группе.

Рисунок 1. Пирамида MoSCoW

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

На первом этапе выбирается элемент, для выполнения которого требуется наименьшее количество времени или сил. Сложность его выполнения принимается за 1 story point. То, что именно брать за базу, полностью зависит от команды и её особенностей.

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

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

1. Из элементов продукта выбираются 3-4 элемента с наименьшей степенью неопределённости.
2. Команда проводит декомпозицию работ по каждому элементу, чтобы затем провести оценку времени, стоимости и ресурсов для реализации данного элемента в продукте. В данном случае требуется «идеальная» оценка времени и затрат, при самых благоприятных условиях.
3. По результатам данной оценки определяется стоимость 1 story point’a в часах. Время работы над элементом делится на количество story point’ов. Если у взятых 3-4 элементов эти значения немного расходятся, чаще всего берут среднее значение. То же самое повторяется для оценки затрат.
4. Сумма story point’ов по продукту умножается на стоимость в часах – таким образом получается предварительная оценка проекта. Аналогично проводится оценка затрат.

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

Мультипликаторы:

• Х*1.25 – Типовой проект. Такое значение авторы предлагают для случая, когда команда реализует привычный для них продукт, который они производили уже не раз, с минимальными отличиями. В таком случае степень неопределённости невысока, а команда уже знает о возможных трудностях, а потому их оценка требует лишь небольшой корректировки.
• Х*1.5 — Чётко определённый проект. Чтобы получить такой мультипликатор, проект должен иметь невысокую неопределённость, но не быть типовым для команды. Например, если у команды не так много опыта с конкретным типом продукта или клиент просить серьёзно модифицированный продукт, что вносит некоторую степень риска.
• Х*2.0 – Новые разработки. Данный мультипликатор используется в случае, если команда вынуждена столкнуться с чем-то абсолютно новым для себя в рамках работы над продуктом.
• Х*2.0 и выше – Быстрый старт. Используется тогда, когда нет времени на тщательную декомпозицию работ и проработку проекта. В таком случае проводится грубая оценка проекта с подобным мультипликатором.

В заключении приведём пример, как примерно выглядит этот процесс:

1. Пусть суммарная оценка всего проекта составляет 150 story point’ов.
2. Если проект чётко определён, то с учётом мультипликатора, оценка станет 225 story point’ов.
3. Пусть 1 story point будет равен 10 часам. Тогда по плану, вся работа над нашим проектом должна уложиться в 2250 часов, или 282 рабочим дням.

Таким же образом можно произвести оценку затрат проекта или потребности в ресурсах.

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

Метод MoSCoW: как сфокусироваться на главном и стать эффективнее — Карьера на vc.ru

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

{«id»:63226,»gtm»:null}

Метод MoSCoW позволяет разделить все активности, «хотелки» и вновь прилетающие задачи на 4 категории, что намного эффективнее.

Этот метод чаще всего используется проектными менеджерами, владельцами продуктов, it-менеджерами, agile-командами и бизнес-аналитиками.

Но он так же хорошо может применяться и вне профессиональной деятельности для ежедневного и еженедельного планирования. Для более длительных периодов он обычно не применяется (за исключением категории must).

Основным недостатком считается сложность определения приоритетов из-за субъективности оценки: часто «обязательные» функции для заказчика видятся «желательными» для исполнителя, так что лучше потратить дополнительное время и договориться.

Впервые этот метод стали применять в Oracle UK в 1994 году, после чего он стал неотъемлемой частью DSDM (Dynamic Systems Development Method). Сейчас его использование рекомендуется и другими проектными фреймворками, например, P3express.

Чтобы лучше понять суть метода, предлагаю посмотреть короткое видео:

Метод MoSCoW: ка к

Все задачи или требования делятся на 4 категории: must, should, could, would.

• Must – то, что необходимо сделать в любом случае. Без выполнения этих задач продукт не будет работать в принципе.
• Should – не самые важные требования, но они тоже должны быть выполнены. Естественно, после реализации «must».
• Could – желательные требования, которые можно сделать, если останется время и будут ресурсы.
• Would – требования, которые хотелось бы сделать, но их можно проигнорировать или перенести на следующие релизы без вреда для продукта.

Рассмотрим на примере. Допустим, нам необходимо в конце месяца выпустить приложение для отслеживания списка дел.

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

После обсуждения приоритетов выяснилось, что:

• Абсолютный must – функции добавления и редактирования списков и наглядный календарь
• Should – push-уведомления и функция поиска
• Could – совместное редактирование списков и возможность делиться календарем
• Безболезненно можно перенести на следующие релизы (would) все остальное, так как оно несет меньшую ценность

Собственно, так оно и работает. Главное, чтобы видение приоритетов совпадало.

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

Чтобы получать больше полезных материалов из мира проектного менеджмента, подписывайтесь на наш telegram-канал @pmclub

Метод MoSCoW: определение приоритетов проекта

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

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

Именно в этот момент полезно применить инструмент расстановки приоритетов — метод MoSCoW. Этот простой подход к управлению проектами поможет вам, вашей команде и заинтересованным сторонам выделить задачи, которые имеют решающее значение для успеха проекта. Он также определяет задачи, от которых можно отказаться при нехватке времени или ресурсов.

https://www.youtube.com/watch?v=g3IDg8Q0oXg\u0026pp=YAHIAQE%3D

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

Что такое метод MoSCoW

Метод MoSCoW был разработан Дай Клеггом из компании Oracle® UK в 1994 году в целях сортировки задач проекта по категориям с различной степенью критичности.

Аббревиатура MoSCoW расшифровывается следующим образом:

• Обязаны (M, must). «Обязательные» требования необходимы для успеха проекта и не подлежат обсуждению. Если эти задачи отсутствуют или не выполнены, проект постигает неудача.
• Должны (S, should). Это важные, высокоприоритетные задачи, которые вы должны выполнять при первой возможности. Они очень важны, но при крайней необходимости могут быть реализованы на втором этапе проекта.
• Можем (C, could). Решение таких задач очень желательно, но их можно отложить, если есть ограничения, связанные со временем или ресурсами.
• Хотели бы (W, would or won’t this time). Эти задачи выражают устремления (например, «хотелось бы иметь …»), но они не включены в этот проект. Также можно использовать эту категорию для наименее важных действий.

Буквы «о» в аббревиатуре нужны только для того, чтобы сделать ее произносимой.

Метод MoSCoW часто используется в гибком управлении проектами Agile. Однако его можно применить к любому типу проектов.

Метод MoSCoW помогает управлять изменениями в масштабах проекта, чтобы ограничить его «расползание». Это особенно полезно при работе с несколькими заинтересованными сторонами, потому что помогает расставить приоритеты. Четыре четко обозначенные категории позволяют быстро определить приоритет задачи, устраняя путаницу, непонимание, конфликты и разочарования.

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

Но у членов команды мнения о том, что означает каждая из этих группировок, могут не совпадать. Кроме того, многие задачи помечаются как «высокоприоритетные», потому что кажутся важными.

Это может отнять много времени и ресурсов и в конечном итоге привести к провалу проекта.

Использование метода MoSCoW

Чтобы получить максимальную отдачу от метода MoSCoW, выполните следующие шаги. (Ниже описано использование MoSCoW в обычном проекте каскадной модели (“Водопад”), однако подход аналогичен в гибких проектах Agile.)

Шаг 1. Организуйте проект

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

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

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

Шаг 2. Составьте список задач

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

Шаг 3. Расставьте приоритеты в списке задач

Пообщайтесь со всеми заинтересованными сторонами, чтобы расставить приоритеты задач по четырем категориям MoSCoW: «Обязаны», «Должны», «Можем» и «Хотели бы». Такие дебаты зачастую проходят тяжело, поэтому заранее улучшите свои навыки разрешения конфликтов, принятия коллективных решений и ведения переговоров!

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

Шаг 4. Обработайте список MoSCoW

После распределения задач по категориям MoSCoW критически оцените каждую классификацию.

Будьте особенно осмотрительны при формировании «обязательного» списка. Помните, что он зарезервирован исключительно для тех задач, невыполнение которых скорее всего приведет к провалу проекта.

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

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

Шаг 5. Сообщите о результатах

Последний шаг — поделиться списком приоритетов с членами команды, заинтересованными сторонами и клиентами.

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

Пример

Юлия — менеджер проекта в крупной ИТ-организации. Она работает с командой дизайнеров, маркетологов и разработчиков над редизайном сайта крупного корпоративного клиента.

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

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

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

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

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

Она начинает с ключевого вопроса: «Если бы я пришла к вам накануне запуска, а рассматриваемая задача не выполнена, вы бы остановили запуск?» Этот вопрос помог всем членам группы определить самый важный приоритет проекта.

После чего группа согласовала следующие приоритеты:

• Обязательно веб-сайт должен быть модифицирован для удобства просмотра на мобильных устройствах.
• Должна быть организована лента социальных сетей.
• Может быть на сайте и потоковое видео для помощи пользователям.
• Хотелось бы — личная информация будет собираться для будущих маркетинговых разработок, но не сейчас.

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

Читайте о других методах приоритизации в нашей статье “Расстановка приоритетов”.

Что такое Модель приоритизации MoSCoW

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

Как работает приоритезация MoSCoW

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

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

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

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

1. Обязательные инициативы (Must-have)

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

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

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

2. Необходимые инициативы (Should-have)

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

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

3. Возможные инициативы (Could-have initiatives)

Еще один способ описания Could-have initiatives инициатив — Nice to have. Could-have initiatives инициативы не являются необходимыми для основной функции продукта. Однако по сравнению с Must-have инициативами, они имеют гораздо меньшее влияние на результат, если их не учитывать.

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

4. Не будет (Will-not-have)

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

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

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

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

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

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