MoSCoW Prioritisation Explained in English
Як використовувати метод MoSCoW для пріоритизації вимог — словник, фрази сприяння, і як пояснити Must Have, Should Have, Could Have, і Won't Have на зустрічах.
Приоритизація MoSCoW є однією з найпоширеніших технік в гнучкому аналізі вимог для категорізації функцій і вимог за важливістю. Назва є акронімом від чотирьох пріоритетних категорій. Якщо ви працюєте бізнес- аналітиком, менеджером продуктів або менеджером проектів у англомовній команді, вам слід володіти як термінологією, так і розмовною мовою, що використовується у цій команді. Цей посібник містить словник, методику та фрази, які допоможуть вам налагодити роботу семінарів MoSCoW.
Що таке мовний бар’єр?
| Letter | Category | Meaning |
|---|---|---|
| Mo | Must Have | Critical. The product cannot be delivered without this. |
| S | Should Have | Important but not critical. Can be delivered in a later iteration if necessary. |
| Co | Could Have | Nice to have. Will be included if time and budget permit. |
| W | Won’t Have | Explicitly out of scope for this release — but possibly a future priority. |
«Давайте пройдемо через кожну вимогу і погодимося на категорію MoSCoW — M, S, C або W»
Необхідно
Definition
Вимога Must Have є мінімальною реалізованою вимогою - без неї, система не може вважатися завершеною. Нездатність виконати завдання означає, що проект зазнав невдачі.
Запитайте: *“Чи буде продукт непридатним до використання, небезпечним або юридично несумісним без цього?” *
Якщо так, то має бути.
Загальна фраза:
- “Це обов’язково — це законно вимагає GDPR.”
-
- « Автентифікація є обов’ язковою — користувачі не зможуть отримати доступ до системи без неї. » *
- “Це не може бути Must Have для цього спринту — ми ніколи б нічого не відправили.”
** Попереджальний знак: ** Якщо все є обов’ язковим, приоритизація не працює. Необхідні елементи повинні становити не більше ~60% від загальної кількості зусиль.
Должен был
Definition
Вимога ** Слід мати ** має велике значення, але не є критичною для запуску. Продукт може працювати без нього, але це буде мати реальний вплив (розчарування користувача, неефективність, вручну обходження).
Запитайте: “Чи є болісне, але прийнятне рішення, якщо у нас цього немає?”
Якщо так, то треба.
Загальна фраза:
- “Пакетний експорт — це те, що вам слід мати — користувачі можуть експортувати поодинці, але це боляче в масштабі.”
- “Пуш-повідомлення повинні бути в цьому випуску — клієнти будуть скаржитися на їх відсутність, але програма працює.”
- “Ми знижили цей рівень з Must Have до Should Have — це важливо, але не блокує запуск.”
Можливо
Definition
Вимога ** Може бути ** має низький пріоритет. Це покращить продукт, але його відсутність не розчарує більшість користувачів. Часто називається «приємно мати»
Запитайте: “Чи зауважили б пересічні користувачі або зацікавились би, якби цього не було?”
Але рідко це вдається.
Загальна фраза:
- “Темний режим може бути корисним для деяких користувачів, але він не вплине на прийняття.”
- “Анімація є можливим елементом — це полірування, а не основна вимога.”
-
- “Ми помістимо це в “Могло бути” і переглянемо це, якщо у нас буде можливість.” *
Не будемо цього робити (англ
Definition
Вимога Не матиме явно виходить за межі цього випуску — не тому, що вона неважлива, а тому, що її свідомо відклали або знизили пріоритет.
Кваліфікатор “цей раз” важливий: Не матиме зараз не означає не матиме ніколи.
Почему не будет полезно:
- Вона явно управляє очікуваннями зацікавлених сторін
- Воно запобігає поширенню об’єктива
- Це створює документований план виконання
Загальна фраза:
- “Многомовна підтримка є Won’t Have для v1 — ми погодилися на англійську тільки для MVP.”
- “Ми встановили соціальний вход у Won’t Have для цього спринту — це не перешкода для пілота.”
- “Я хочу бути ясним: Не матиме не означає, що ми залишаємо його назавжди - це кандидат v2.”
Засновник робітничого руху в Могильові
Відкривається сеанс
“Ми будемо приоритизувати сьогоднішній відставання за допомогою методу MoSCoW. Мета полягає в тому, щоб залишити сьогодні, знаючи точно, що є в обсязі для наступного випуску, а що ні»
“Запомніть: “Маст Ів” означає, що ми не можемо відправити без нього. Якщо ми можемо доставити з обходом, це, ймовірно, має бути»
Справляясь с разногласиями
«Ми маємо два голоси за «Місце, де слід бути» і один за «Місце, де слід бути». Чи може виборець, який має право голосу, пояснити свої аргументи?»
«Я чув, що це дуже важливо для вас — але чи не провалиться бізнес без цього в цьому випуску?»
«Давайте відокремимо невідкладність від важливості — просто тому, що це невідкладно, не робить це автоматично Must Have»
Справляюсь с кривизной обзора
«Ми погодилися, що ця функція була не має для цього спринту. Чи є щось, що змінилося, що могло б підняти його?»
“Якщо ми додамо це як Must Have, щось ще має рухатися вниз. Що ми готові обміняти?»
Перевіряю баланс
“Можно сделать быстрый подсчет? У нас є 8 необхідних речей, 4 необхідних і 2 можливих. Якщо “необхідні” заповнять усі наші можливості, “необхідні” не будуть доставлені. Чи всі приймають це?»
Москвич — короткий варіант московського імені
| Term | Pronunciation | Usage |
|---|---|---|
| MoSCoW | MOSS-cow | ”Let’s run a MoSCoW prioritisation.” |
| Must Have | — | “This is a Must Have for compliance.” |
| Should Have | — | “Should Haves are high priority but not blocking.” |
| Could Have | — | “Dark mode is a Could Have / nice to have.” |
| Won’t Have | — | “That’s a Won’t Have for this release.” |
| Minimum viable | — | “What’s the minimum viable set of requirements?” |
| Scope creep | — | “Adding this mid-sprint is scope creep.” |
| Descope | — | “We may need to descope the dashboard for v1.” |
| Defer | — | “We’ve agreed to defer multi-currency to Q3.” |
Звичайні пастки
Все, що є, є обов’язковим
“Якщо все є Must Have, то пріоритизація не додає цінності. Я б хотів поставити під сумнів деякі з них — давайте запитаємо: «Чи могли б ми вийти на ринок без цього, навіть з обхідним шляхом?»
Можливо, це було пов’язано з тим, що він мав мати
«Потрібен повинен бути боляче, якщо його немає — користувачі будуть скаржитися або працювати навколо нього. Можливо, це те, що користувачі можуть навіть не помітити. У яку категорію це насправді входить?»
Не буде, стане забутою роботою
«Давайте задокументуємо те, що не буде в запізненні з поміткою: «Відкладено до v2.’ Так ми їх не втратим»
Practice
Перевірте ваші знання з лексики вимог за допомогою ** Набір вправ з англійської для бізнес- аналітиків. Name ** і досліджуйте всі ресурси BA за допомогою ** Підручник для студентів-економістів **.
Навігація Nuance: використовуючи MoSCoW з не-рідними мовцями
Метод приоритизації MoSCoW – Must have, Should have, Could have, Won’t have – це фантастичний інструмент для вирівнювання команд за пріоритетами. Однак, навіть коли сама концепція є ясною, тонкі відмінності у фразування і словниковий запас можуть створити плутанину, особливо для розробників, які не знають професійної англійської мови. Це не просто про те, щоб сказати «Має бути»; це про те, як ви пояснюєте цю необхідність. Давайте розглянемо, як уточнити мову навколо цієї структури, щоб переконатися, що всі розуміють, що саме запитується або оцінюється.
Одна з поширених областей нерозуміння виникає під час перегляду коду. Уявіть, що рецензент коментує запит на збирання: « Цю функціональність слід переробити — це * Must Have * ». Розробник, який не знайомий з цим нюансом, може інтерпретувати це як вимогу повного перепроектування, що призведе до оборони і розчарування. Замість цього, більш ефективною формулюванням було б: «Архітектура цієї секції не відповідає нашим вимогам до продуктивності. Це Must Have, який ми розглядаємо через рефакторинг, щоб забезпечити стабільність і масштабованість. “Зауважте додавання контексту - пояснення * чому * це Must Have зміцнює запит і заохочує співпрацю, а не конфронтацію. Аналогічно, при описі PR в Slack, кажучи «Це критичне виправлення помилки - * Must Have *», може сприйматися як звинувачення. Кращий підхід може бути: «Я надсилаю цей PR, щоб розв’язати проблему високого пріоритету, що впливає на функціональність користувача. Це позначено як Must Have через його вплив на стабільність системи ядра. ”
Іншою ключовою областю для уваги є використання кваліфікаторів. Сказати “Це * Слід *” може відчувати себе менш невідкладним, ніж це насправді є, що призводить до затримок. Щоб уникнути цього, розгляньте такі фрази, як: « Це значно поліпшить користувацькі відчуття і має бути пріоритетним поряд з * Необхідними * » або « Реалізація цього як * Потрібного * забезпечить значну цінність з точки зору [згадайте конкретну метрику — наприклад, залучення користувача ]. » Під час обговорення можливостей, які « Не будуть », важливо чітко вказати, що вони не входять до обсягу поточної ітерації. Використання таких тверджень, як: « Ми не будемо розглядати цю функціональність у цьому випуску; вона позначена як * Не буде * через обмеження ресурсів і зосередження на забезпеченні основних вимог », є більш точним, ніж просто стверджувати « Це * Не буде * ». Це уникнення неоднозначності щодо майбутніх можливостей.
Нарешті, пам’ятайте, що MoSCoW - це не просто список ярликів; це розмова. Активно запитувати зворотній зв’язок і прояснювати розуміння - такі фрази, як “Чи можете ви розібратися, чому це * Must Have * для вас?” або “Давайте обговоримо наслідки приоритизації цього як * Should Have *” - є безцінними, особливо при роботі з членами команди, які можуть пристосовуватися до конкретного словника і стилів спілкування, що використовуються в професійному середовищі. Сфокусування на спільному поясненні будує довіру і зменшує непорозуміння.