Как расставить приоритеты с помощью метода MoSCoW

Вам нужна помощь в расстановке приоритетов задач при управлении проектом? Для этого есть аббревиатура! Это называется методом MoSCow, и это отличная техника для помощи в расстановке приоритетов.

Как расставить приоритеты с помощью метода MoSCoW:

Управление проектом часто заключается в управлении тем, что вы хотите и чего не хотите! – выполнить в установленные сроки проекта. Когда приоритеты не установлены, проекты могут быстро стать бесплатными для всех, когда самые громкие голоса в комнате получают приоритет над другими, часто не в интересах проекта или организации.

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

Вот список, поясняющий, что это за требования:

Обязательные требования

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

Чтобы понять, имеете ли вы дело с MUS, спросите себя: «Что произойдет, если это не будет выполнено?» Если ответ «Проект терпит неудачу», то у вас есть MUS. Любой обходной путь, который можно придумать, чтобы продолжить проект и не поставить под угрозу его успех, означает, что это не MUS.

Обязательные требования

Этот тип требований почти так же важен, как MUS, но он не является жизненно важным для успеха проекта. Другими словами, проект не зависит от этого требования. Возможно, вам не захочется упускать это, так как это может сильно повлиять на проект, но, в конце концов, это можно сделать, не причинив непоправимого вреда. Опять же, отсутствие этого требования означает много работы⁠ (поиск решения, изменение ожиданий заинтересованных сторон, возможно, некоторая неэффективность⁠), но проект может продолжаться.

Возможные требования

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

Чего у нас не будет на этот раз

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

Сбор требований

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

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

Связанный: Бесплатный шаблон сбора требований

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

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

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

Как ProjectManager поддерживает качество вашего проекта

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

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

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

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

Посмотрите, как наш эксперт по лидерству объясняет метод MoSCoW

Гуру лидерства Сюзанна Мэдсен ведет этот обучающий видеоролик о том, как использовать метод MoSCoW для определения приоритетности ваших требований в проекте.

Вот скриншот для справки.

Спасибо за просмотр!

Совет: московская методика — отличный способ построить беседу с клиентами, понять, чего они хотят и что им просто приятно иметь. Таким образом, вы не тратите время зря, и они не остаются неясными. Это беспроигрышный вариант для начала проекта с клиентами.

Стенограмма:

Привет, я Сюзанна Мэдсен. Добро пожаловать на сеанс интерактивной доски о том, как расставить приоритеты требований с помощью метода MoSCoW.

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

«S» означает «должно быть требование», если это вообще возможно, у нас должно быть это.

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

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

Давайте посмотрим на пример. Представьте, что вы руководитель проекта конференции. Вы садитесь со своими заинтересованными сторонами и спрашиваете их: «Что должно быть на этой конференции? Каковы все ваши обязательные требования?»

И ваш клиент говорит: «Хорошо, нам нужно место в пяти километрах от центра города».

«Хорошо, что мы должны иметь, если это вообще возможно?»

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

«Хорошо, что мы могли бы иметь?»

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

— Чего у нас не будет?

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

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

А вы говорите: «Хорошо, нам нужна копия программы конференции».

"Отлично. Что у нас там должно быть?

«Ну, у нас действительно должен быть фирменный предмет, может быть, как ручка или что-то в этом роде».

— Ладно, что у нас там может быть?

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

— Чего у нас не будет?

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

Итак, вы видите, что вы можете использовать «MoSCoW» на очень высоком уровне, но также и на низком уровне. Когда вы используете его на низком уровне, это помогает вам лучше делегировать задачи.

Спасибо за просмотр, пожалуйста, посетите нас снова в ProjectManager.