Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
12 августа 2020 Product Management Все для начинающего РМа
2

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

Юлия Бажанова
Редактор проекта, РМР, ICP-PPM




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

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

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

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

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

Плюсы: просто, быстро, понятно заказчику (если это не технический специалист).

Минусы: не сильно объективно, не учитывается техническая сложность и риски.

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

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

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

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

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

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

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





комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

2комментария

сначала новые
по рейтингу сначала новые по хронологии
1
Светлана Дунаева

Юлия, добрый день. Случалось ли вам пользоваться в работе или встречать коллег, которые пользовались в ИТ Теорией ограничений Элияху Голдратта? Я читала несколько статей на Хабре (к примеру, https://habr.com/ru/post/482484/), о том как коллеги используют ее в своей практике. Книги я тоже читала, идеи понравились, но мне показалось, что для успешного применения данной теории нужно для начала принять всей рабочей команде (и владельцам ресурсов), разобраться всем вместе, и обкатать на не слишком рисковом проекте. То есть, точечное применение данной теории, наверное, большого успеха не даст.

Автор2
Юлия Бажанова

Светлана, добрый день! Ответ – и да, и нет=)) Прямо полноценный ТОС по книжке – не, не приходилось использовать или внедрять. Точечный, саму концепцию – да. Например, у меня так построена приоритизация проектов в портфеле – на УК при появлении нового проекта мы ставим его на конкретное место среди последовательности остальных (по убыванию приоритета), и вопросов о том, почему мы делаем проект номер 3, а не номер 10, больше не возникает (место выбирается в зависимости от сочетания “выгоды + ресурсы”). Плюс от этого же строится планирование конкретных проектов: наше узкое горлышко – это отдел архитектуры, и мы отталкиваемся от них, чтобы максимизировать пропускную способность. Т.е. если они по плану загружены – берутся проекты, где их экспертиза не нужна, а хватит, например, экспертизы саппорта, первое, что делается для любого проекта – это оценка загрузки архитектуры. Что забавно – все работает точно по книжке, как только мы убираем горлышко архитектуры – начинает валиться девопс (и мы спасаем уже его) и так далее=)) но прям полноценного бесшовного применения ТОС нету, все на ручном управлении.
А вообще мне очень нравится идея “ТОС применительно к себе”, вынесенная с какого-то семинара. Стараюсь об этом задумываться при планировании своих задач, чтобы раньше времени не выгореть на работе. Когда понимаешь, что у тебя тоже есть некая пропускная способность и решение “напихать больше, взять себя в руки, собраться и не быть тряпкой” и проч. – плохое, жить становится намного комфортнее, вот прямо намного. Имхо, осознание этой мысли – одна из самых хороших вещей по части личной эффективности из всех, что со мной случались=))

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: