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

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

Метод 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