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

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

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

Должен иметь

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

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

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

  1. Требуется ли функция в соответствии с государственными нормами?
  2. Может ли продукт поставляться без этой функции?
  3. Безопасен ли этот продукт без этой функции?

Обязательные функции иногда рассматриваются как аббревиатура от Minimum Usable SubseT (MUST), охватывающая функции, которые гарантированно предоставляются. Например, способность текстового процессора принимать и сохранять вводимые пользователем данные.

Должен иметь

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

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

Мог бы иметь

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

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

Не будет

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

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

История

Приоритизация в Москве (иногда называемая MoSCoW методом или анализом) была разработана в середине 1990-х годов Даем Клеггом как метод быстрой разработки приложений (RAD). Этот новый формализованный метод должен был помочь справиться с так называемыми ускоренными проектами (R). Он нашел широкое применение в ранних итерациях платформы AGILE и был ключевым аспектом метода разработки динамических систем (DSDM).

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

Проблемы

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

Статья Расстановка приоритетов в Москве: сверхпростая 4-шаговая структура управления проектами для поддержания вашего следующего проекта в нужном руслепервоначально появилась на Веб-сайте Overcoded и была опубликована здесь с разрешения.