Метод MoSCoW — это метод приоритизации, используемый в управлении проектами, разработке программного обеспечения и бизнес-анализе. Он помогает приоритизировать требования на основе их важности и срочности, позволяя менеджерам проектов распределять ресурсы и бюджет соответствующим образом. В этой статье мы рассмотрим метод MoSCoW и приведем пример его применения.
Что такое метод MoSCoW?
Метод MoSCoW — это метод приоритизации, который классифицирует требования на четыре группы: обязательные, желательные, возможные и нежелательные. Аббревиатура MoSCoW означает:
- Обязательные:критические требования, без которых проект не может быть успешным. Эти требования обязательны и должны быть включены в объем проекта.
- Желательные:важные требования, необходимые для успеха проекта, но которые могут быть отложены при необходимости. Эти требования важны, но не критичны, и могут быть отложены на более позднюю стадию проекта.
- Возможные:желательные требования, которые не являются необходимыми для успеха проекта, но могут повысить его ценность. Эти требования являются добровольными и могут быть включены при наличии времени и бюджета.
- Нежелательные:требования, которые не требуются для успеха проекта и не включены в его объем.
Метод MoSCoW помогает менеджерам проектов приоритизировать требования на основе их важности и срочности. Он позволяет им сосредоточиться на критических требованиях и распределять ресурсы и бюджет соответствующим образом.
Пример применения метода MoSCoW
Рассмотрим пример проекта разработки программного обеспечения, чтобы понять, как работает метод MoSCoW.
Предположим, что компания хочет разработать новое мобильное приложение для своих клиентов. Приложение должно позволять клиентам заказывать товары, отслеживать свои заказы и получать уведомления. Компания также хочет включить некоторые дополнительные функции, чтобы сделать приложение более привлекательным для клиентов.
Команда проекта определяет следующие требования:
- Обязательные: приложение должно позволять клиентам заказывать товары, отслеживать свои заказы и получать уведомления.
- Желательные: приложение должно иметь функцию поиска, позволяющую клиентам искать товары, и функцию оплаты, позволяющую клиентам оплачивать свои заказы с помощью различных способов оплаты.
- Возможные: приложение может иметь функцию программы лояльности, которая вознаграждает клиентов за покупки, и функцию реферальной программы, которая стимулирует клиентов рекомендовать приложение своим друзьям и членам семьи.
- Нежелательные: приложение не будет иметь функцию интеграции с социальными сетями, позволяющую клиентам делиться своими покупками в социальных сетях.
Используя метод MoSCoW, команда проекта приоритизировала требования на основе их важности и срочности. Требования, относящиеся к категории «обязательные», критически важны для успеха проекта и должны быть включены в приложение. Требования «желательные» важны, но могут быть отложены на более позднюю стадию проекта при необходимости. Требования «возможные» являются добровольными и могут быть включены при наличии времени и бюджета. Требования «нежелательные» не требуются для успеха проекта и не включены в его объем.
Пример из реальной жизни — система управления взаимоотношениями с клиентами (CRM)
Описание проекта: Разработка системы управления взаимоотношениями с клиентами (CRM)
Цель этого Agile-проекта — разработка системы управления взаимоотношениями с клиентами (CRM) для небольшого бизнеса, специализирующегося на предоставлении индивидуальных решений для своих клиентов. Система CRM будет разработана для оптимизации процесса продаж и улучшения взаимодействия с клиентами, что позволит бизнесу повысить удовлетворенность и лояльность клиентов.
Проект будет реализован по методологии Agile, которая предполагает итеративную и поэтапную разработку. Команда Agile будет тесно работать с клиентом для сбора требований, разработки прототипов и предоставления функциональных частей программного обеспечения в коротких итерациях, как правило, по две недели.
Определите список пользовательских историй
Чтобы создать список пользовательских историй, можно рассмотреть различные роли, которые будут взаимодействовать с системой, например, представителей продаж, менеджеров и клиентов, и подумать о различных задачах, которые им необходимо выполнить для достижения своих целей. Также можно рассмотреть различные типы данных, которые необходимо хранить и управлять в системе, например, информацию о клиентах, данные о продажах и маркетинговые кампании.
На основе этого анализа можно затем сформировать список пользовательских историй, охватывающих широкий спектр функциональности — от отслеживания потенциальных клиентов и обслуживания клиентов до подготовки коммерческих предложений и отчетности. Список пользовательских историй предназначен для того, чтобы стать отправной точкой для команды разработки при приоритизации и планировании разработки системы CRM.
Вот список пользовательских историй для проекта разработки системы CRM:
- Как представитель продаж, я хочу иметь возможность отслеживать все свои контакты в одном месте, чтобы легко управлять своим продажным процессом.
- Как менеджер по продажам, я хочу иметь возможность просматривать и отслеживать прогресс своей команды в режиме реального времени, чтобы вовремя оказывать наставничество и поддержку.
- Как представитель службы поддержки клиентов, я хочу иметь возможность просматривать все взаимодействия клиента с нашей компанией, чтобы предоставлять персонализированную поддержку.
- Как менеджер по маркетингу, я хочу иметь возможность сегментировать наших клиентов на основе их предпочтений и поведения, чтобы направлять на них релевантные кампании.
- Как клиент, я хочу иметь возможность просматривать историю своих покупок и информацию о своем аккаунте, чтобы легко управлять отношениями с компанией.
- Как представитель службы поддержки клиентов, я хочу иметь возможность фиксировать и отслеживать жалобы и запросы клиентов, чтобы обеспечить своевременное их решение.
- Как представитель продаж, я хочу иметь возможность быстро и легко создавать коммерческие предложения и предложения, чтобы быстрее закрывать сделки.
- Как администратор, я хочу иметь возможность управлять правами доступа пользователей и уровнями доступа, чтобы контролировать, кто имеет доступ к конфиденциальной информации.
- Как представитель продаж, я хочу иметь возможность планировать и управлять встречами с клиентами, чтобы оставаться организованным и в курсе своего графика.
- Как менеджер, я хочу иметь возможность генерировать отчеты по показателям продаж, удовлетворенности клиентов и другим метрикам, чтобы принимать обоснованные бизнес-решения.
Эти пользовательские сценарии охватывают широкий спектр функциональности, которую должна предоставлять система CRM. Команда разработки может использовать эти пользовательские сценарии для определения приоритетов наиболее важных функций системы и обеспечения соответствия потребностей всех заинтересованных сторон.
В табличной форме давайте представим четкое и краткое резюме 10 пользовательских сценариев, связанных с бизнес-сценарием, чтобы дать обзор пользовательских сценариев.
| Пользовательский сценарий | Роль пользователя | Цель |
|---|---|---|
| 1 | Представитель продаж | Отслеживать все контакты в одном месте для управления продажным процессом |
| 2 | Менеджер по продажам | Просматривать и отслеживать прогресс команды в режиме реального времени для наставничества и поддержки |
| 3 | Представитель службы поддержки клиентов | Просматривать все взаимодействия с клиентами для предоставления персонализированной поддержки |
| 4 | Менеджер по маркетингу | Сегментировать клиентов на основе предпочтений и поведения для целевых кампаний |
| 5 | Клиент | Просматривать историю покупок и информацию об аккаунте для простого управления |
| 6 | Представитель службы поддержки клиентов | Вести журнал и отслеживать жалобы и запросы клиентов для своевременного решения |
| 7 | Представитель по продажам | Быстро и легко создавать коммерческие предложения и предложения для более быстрого закрытия сделок |
| 8 | Администратор | Управлять разрешениями пользователей и уровнями доступа к конфиденциальной информации |
| 9 | Представитель по продажам | Планировать и управлять встречами с клиентами, чтобы оставаться организованным |
| 10 | Менеджер | Генерировать отчеты по результативности продаж, удовлетворенности клиентов и другим метрикам для принятия обоснованных бизнес-решений |
В таблице содержится информация о роли пользователя, конкретной цели, которую он хочет достичь, и номере пользовательской истории, чтобы легко ссылаться на каждую историю. Организуя пользовательские истории в таблице, легче понять и приоритизировать функции, которые необходимо разработать, чтобы удовлетворить потребности заинтересованных сторон проекта. Эта таблица может служить справочником для команды разработки при проектировании и реализации функций, соответствующих потребностям конечных пользователей и заинтересованных сторон.
Приоритизировать пользовательские истории
Важно приоритизировать пользовательские истории на основе их бизнес-ценности и влияния на цели проекта. Это гарантирует, что усилия по разработке сосредоточены на наиболее важных и ценных функциях, а проект будет завершен вовремя и в рамках бюджета.
Приоритизация может быть выполнена с использованием различных методов, таких как метод MoSCoW, который классифицирует пользовательские истории как «обязательные», «желательные», «возможные» и «недоступные». Пользовательские истории, отнесенные к категории «обязательные», являются наиболее критичными и должны быть разработаны в первую очередь, тогда как «желательные» и «возможные» могут быть реализованы позже в последующих итерациях или релизах.
Вот таблица для десяти пользовательских историй, упомянутых ранее, с соответствующей информацией и приоритизацией на основе метода MoSCoW:
Важно приоритизировать пользовательские истории на основе их бизнес-ценности и влияния на цели проекта. Это гарантирует, что усилия по разработке сосредоточены на наиболее важных и ценных функциях, а проект будет завершен вовремя и в рамках бюджета.
Приоритизация может быть выполнена с использованием различных методов, таких как метод MoSCoW, который классифицирует пользовательские истории как «обязательные», «желательные», «возможные» и «недоступные». Пользовательские истории, отнесенные к категории «обязательные», являются наиболее критичными и должны быть разработаны в первую очередь, тогда как «желательные» и «возможные» могут быть реализованы позже в последующих итерациях или релизах.
Вот таблица для десяти пользовательских историй, упомянутых ранее, с соответствующей информацией и приоритизацией на основе метода MoSCoW:
| Пользовательская история | Описание | Приоритет |
|---|---|---|
| 1 | Как представитель по продажам, я хочу иметь возможность отслеживать все свои потенциальные клиенты в одном месте, чтобы легко управлять своим продажным процессом. | Обязательное |
| 2 | Как менеджер по продажам, я хочу иметь возможность просматривать и отслеживать прогресс моей команды в режиме реального времени, чтобы иметь возможность оказывать наставничество и поддержку при необходимости. | Обязательно |
| 3 | Как представитель службы поддержки клиентов, я хочу иметь возможность просматривать все взаимодействия клиента с нашей компанией, чтобы предоставлять персонализированную поддержку. | Обязательно |
| 4 | Как менеджер по маркетингу, я хочу иметь возможность сегментировать наших клиентов на основе их предпочтений и поведения, чтобы направлять на них соответствующие кампании. | Хорошо бы |
| 5 | Как клиент, я хочу иметь возможность просматривать историю своих покупок и информацию о своем аккаунте, чтобы легко управлять отношениями с компанией. | Хорошо бы |
| 6 | Как представитель службы поддержки клиентов, я хочу иметь возможность регистрировать и отслеживать жалобы и запросы клиентов, чтобы обеспечить своевременное их решение. | Хорошо бы |
| 7 | Как представитель продаж, я хочу иметь возможность быстро и легко создавать коммерческие предложения и предложения, чтобы быстрее закрывать сделки. | Можно было бы |
| 8 | Как администратор, я хочу иметь возможность управлять разрешениями пользователей и уровнями доступа, чтобы контролировать, кто имеет доступ к конфиденциальной информации. | Можно было бы |
| 9 | Как представитель продаж, я хочу иметь возможность планировать и управлять встречами с клиентами, чтобы оставаться организованным и в курсе своего графика. | Можно было бы |
| 10 | Как менеджер, я хочу иметь возможность создавать отчеты по показателям продаж, удовлетворенности клиентов и другим метрикам, чтобы принимать обоснованные бизнес-решения. | Не будет |
В этой таблице пользовательские истории перечислены в порядке приоритета, сначала перечислены функции «обязательно», затем «хорошо бы» и «можно было бы». Функция «не будет» не планируется к реализации в этом проекте, но может быть рассмотрена для будущей разработки.
Приоритизация пользовательских историй позволяет команде разработки обеспечить, что наиболее важные функции будут разработаны в первую очередь, обеспечивая ценность для заинтересованных сторон и позволяя проекту достигнуть своих целей в рамках временных и бюджетных ограничений.
Пример: план разработки Scrum для CRM
Вот общий план разработки Scrum для начала агILE-проекта. Однако конкретные детали плана зависят от требований проекта, структуры команды и других факторов. Вот пример плана разработки Scrum:
- Определите бэклог продукта: Первым шагом является определение бэклога продукта, который представляет собой приоритизированный список всех функций, возможностей и требований, которые необходимо реализовать в проекте. Этот бэклог будет поддерживаться на протяжении всего проекта и будет постоянно уточняться и обновляться в соответствии с изменяющимися потребностями заинтересованных сторон.
- Проведите планирование спринта: После того как бэклог продукта будет определен, команда проведет совещание по планированию спринта, чтобы выбрать набор пользовательских историй из бэклога, которые будут разработаны в предстоящем спринте. Команда оценит усилия, необходимые для каждой пользовательской истории, и выберет те истории, которые могут быть завершены в течение срока спринта.
- Проведите ежедневные встречи скрам:: После начала спринта команда проведет ежедневные встречи скрам для обзора прогресса, выявления возможных препятствий или трудностей и корректировки плана при необходимости. Ежедневные встречи скрам должны быть краткими и сосредоточенными, при этом каждый член команды должен предоставить отчет о своем прогрессе.
- Разработайте продукт инкремент: В течение спринта команда будет работать над разработкой выбранных пользовательских историй, делая акцент на предоставлении рабочего продукта инкремент к концу спринта. Команда будет тесно сотрудничать, при этом разработчики, тестировщики и другие члены команды будут работать вместе для предоставления продукта инкремент.
- Проведите обзор спринта: В конце спринта команда проведет совещание по обзору спринта, чтобы продемонстрировать продукт инкремент заинтересованным сторонам, собрать обратную связь и проанализировать прогресс, достигнутый в ходе спринта.
- Проведите ретроспективу спринта: После обзора спринта команда проведет ретроспективу спринта, чтобы проанализировать процесс спринта, выявить области для улучшения и спланировать следующий спринт.
- Повторите процесс: Команда будет повторять этот процесс для каждого последующего спринта, продолжая уточнять и обновлять бэклог продукта, а также сосредотачиваться на предоставлении рабочего продукта инкремент к концу каждого спринта.
Этот план разработки по Scrum предоставляет основу для управления агILE-проектом, с регулярными встречами и обзорами, чтобы обеспечить, что проект находится на правильном пути и приносит ценность заинтересованным сторонам.
Заключение
В статье рассматривается метод MoSCoW, который является методом приоритизации, используемым в управлении агILE-проектами для приоритизации требований к проекту. Метод MoSCoW делит требования на четыре категории: необходимо иметь, следует иметь, можно иметь и не будет иметь. В статье приводится реальный пример агILE-проекта и способ определения пользовательских историй для проекта. Затем пользовательские истории приоритизируются с использованием метода MoSCoW, при этом требования «необходимо иметь» получают наивысший приоритет.
В статье также описывается план разработки по Scrum, который включает определение бэклога продукта, планирование спринта, ежедневные встречи скрам, разработку продукта инкремент, обзор спринта, ретроспективу спринта и повторение процесса. План разработки по Scrum предоставляет основу для управления агILE-проектом, обеспечивая, что проект находится на правильном пути и приносит ценность заинтересованным сторонам.