Визначення пріоритетів MoSCoW або аналіз MoSCoW
- Oleh Voroniak
- 22 січ.
- Читати 9 хв
У проєкті DSDM(dynamic systems development method), де час зафіксовано, вкрай важливо розуміти відносну важливість роботи, яку треба виконати, аби просуватися вперед і дотримуватися дедлайнів. Пріоритизацію можна застосувати до вимог/User Stories, завдань, продуктів, варіантів використання (use cases), критеріїв прийняття і тестів, хоча найчастіше це стосується саме вимог/User Stories.(User Stories — це дуже ефективний спосіб формулювати вимоги в гнучкому (Agile) стилі; докладніше про це див. у пізнішому розділі про Вимоги та User Stories.)
MoSCoW — це техніка пріоритизації, яка допомагає зрозуміти й керувати пріоритетами. Літери означають:
Must Have (обов’язково має бути)
Should Have (варто, бажано мати)
Could Have (можна мати)
Won’t Have this time (цього разу не буде)
Використання MoSCoW особливо добре працює в межах проєктів. Воно також дає змогу уникнути проблем, пов’язаних зі спрощеними методами пріоритизації, побудованими на відносних пріоритетах:
Просте поділення на “високий, середній чи низький” є слабшим, оскільки зазвичай відсутні або потребують формулювання чіткі визначення цих пріоритетів. Також такий підхід не дає бізнесу чіткої обіцянки, що саме буде зроблено. Окрім того, єдиний середній варіант (“середній пріоритет”) часто призводить до невизначеності.
Просте послідовне пріоритизування (1, 2, 3, 4…) також є менш ефективним, бо погано працює в ситуаціях, коли декілька пунктів є однаково важливими. Можуть виникати довгі та емоційні обговорення щодо того, чи потрібно певний пункт змістити на одну позицію вгору чи вниз.
Натомість чітке використання підходу Must Have, Should Have, Could Have, Won’t Have this time дає зрозуміле уявлення про місце кожного пункту й очікування щодо його виконання.
Правила MoSCoW (The MoSCoW Rules)
Must Have
Ці вимоги формують MUST (Minimum Usable SubseT) — мінімальний робочий набір вимог, який проєкт гарантує доставити. Вони можуть визначатися через такі фактори:
Немає сенсу постачати рішення у визначений термін без цієї функції/вимоги. Якщо її не буде, тоді немає сенсу взагалі розгортати рішення у заплановану дату.
Це порушує закон, якщо не реалізувати цю вимогу.
Це небезпечно, якщо не реалізувати цю вимогу.
Неможливо надати життєздатне рішення без цього.
Задайте питання: “Що буде, якщо цю вимогу не виконати?” Якщо відповідь: “Тоді проєкт треба скасувати — немає сенсу впроваджувати рішення без цієї вимоги”, — це справді Must Have. Якщо все ж є якийсь спосіб обійтися (навіть якщо він ручний і незручний), то це вимога рівня Should Have або Could Have. Важливо розуміти, що віднесення вимоги до Should Have чи Could Have не означає, що вона взагалі не буде реалізована. Це лише означає, що гарантованої поставки саме цих пунктів немає.
Should Have
Вимоги рівня Should Have визначаються як:
Важливі, але не життєво необхідні.
Їх “боляче” виключати, але рішення все ще залишиться працездатним без них.
Можливо, будуть потрібні певні “обхідні шляхи”, наприклад, управління очікуваннями користувачів, певна неефективність, використання наявного рішення, додаткові паперові процедури тощо. Іноді це може бути тимчасовим заходом.
Як відрізнити Should Have від Could Have? Зазвичай це можна зробити, проаналізувавши, наскільки болючим буде відсутність цієї вимоги з погляду цінності для бізнесу або кількості людей, на яких це вплине.
Could Have
Вимоги рівня Could Have визначаються як:
Бажані, але менш важливі.
Вплив від їх невиконання менший, ніж у випадку із Should Have.
Ці вимоги часто є основним “запасом часу” — якщо виникають проблеми й дедлайн під загрозою, саме Could Have стають першими кандидатами на відкладення.
Won’t Have this time
Це вимоги, які команда чітко визначила як такі, що не будуть реалізовані в цей часовий проміжок (timeframe). Вони фіксуються в “Списку пріоритизованих вимог” (Prioritised Requirements List), щоб уникнути неформального повернення цих вимог пізніше. Це також допомагає керувати очікуваннями бізнесу: частина вимог не ввійде до рішення (принаймні цього разу).
Won’t Have може бути дуже корисним, оскільки дає команді можливість зосередитися на важливіших вимогах (Could Have, Should Have, а особливо Must Have).
MoSCoW у прив’язці до конкретного часовго інтервалу (Relating to a Specific Timeframe)
У традиційному проєкті всі вимоги вважаються Must Have, бо з самого початку йде припущення, що все буде виконано, і, зазвичай, якщо виникають проблеми, терміни (дата завершення) зрушуються. У DSDM-проєктах підхід відрізняється: час, вартість і якість фіксуються, а функціонал (кількість вимог) можна варіювати. До кінця фази Foundations остаточно визначаються кінцеві дати проєкту та першого Project Increment.
Щоби дотриматися цих термінів, проєкти DSDM повинні мати певний запас гнучкості у пріоритетах. Основна увага спочатку приділяється встановленню пріоритетів MoSCoW для проєкту загалом. Далі, коли вирішується, що саме увійде до першого Project Increment, визначаються пріоритети MoSCoW саме для цього інкремента. Так вимога може мати два пріоритети:
MoSCoW для проєкту
MoSCoW для інкремента
Зрештою, коли планується конкретний Timebox (на початку кожного Timebox), Solution Development Team визначає специфічний пріоритет для вимог саме на цей Timebox. На цьому етапі для більшості вимог пріоритет — це Won’t Have (на цей Timebox). Тільки ті вимоги, над якими команда планує працювати безпосередньо зараз, отримують статус Must Have, Should Have або Could Have.
Отже, кожна вимога може мати три рівні пріоритетів:
MoSCoW для проєкту.
MoSCoW для поточного Project Increment.
MoSCoW для поточного Timebox.
Приклад.Якщо Must Have є вимогою для IT-рішення “функціонал архівування старих даних”, можливо, що це рішення можна ефективно використовувати кілька місяців без цієї можливості. У такому випадку до першого Project Increment цю вимогу можна віднести до Should Have або Could Have, хоча загалом, у масштабах проєкту, вона залишиться Must Have перед фінальним завершенням. Аналогічно, якщо щось є Must Have для поточного інкремента, для раннього Timebox це може стати Should Have, Could Have або навіть Won’t Have.
Важливо не забувати про загальну картину (завершення всього проєкту чи інкремента), коли працюєте над деталями окремого Timebox.
Один зі способів спростити це — створити окремий PRL (Prioritised Requirements List) для кожного Timebox, який є підмножиною PRL у масштабах усього проєкту. І при цьому не змінювати пріоритети у основному PRL.
10.4 Забезпечення ефективної пріоритизації (Ensuring effective prioritisation)
10.4.1 Балансування пріоритетів (Balancing the priorities)
Визначаючи зусилля, потрібні для Must Have, варто пам’ятати, що будь-які інші категорії (Should, Could) слугують резервом: Must Have формують мінімальний робочий набір (Minimum Usable SubseT), який гарантовано буде виконано.
DSDM рекомендує:
Тримати частку Must Have вимог у розмірі не більше ~60% від загального обсягу робіт, щоб команда була впевнена, що їх можна вчасно виконати.
Домовитися, що приблизно 20% зусиль припадатиме на Could Have як основний резерв, — це налаштовує адекватні очікування з боку бізнесу. Бізнес розуміє, що Could Have можуть бути реалізовані (за умови позитивного сценарію й відсутності проблем), але фокус завжди буде на Must Have і Should Have.
Такий розподіл пріоритетів дає достатній резерв, аби гарантувати успішне завершення проєкту.
Важливо: коли обчислюється сумарний обсяг робіт на часовий період, Won’t Haves (для цього періоду) не включаються.
Рекомендації DSDM відображають типовий випадок. Головне, щоб існувала видима гнучкість у вимогах, які потрібно виконати (тобто Must Have не забирають усіх 100%).
Якщо частка Must Have перевищує 60%, це підвищує ризик невдачі за винятком проєктів, де:
Оцінки дуже точні.
Підхід і технології добре зрозумілі.
Команда демонструє високу продуктивність (згідно з моделлю Такмана (Tuckman model)).
Зовнішні ризики мінімальні.
У деяких випадках частка Must Have може бути набагато меншою за 60%, що може бути навіть вигідно для бізнесу (більше простору для реалізації Should/Could).
Загалом, співвідношення між Must, Should і Could щоразу визначається індивідуально, проте 20% Could Have зазвичай рекомендовано. Ефективна пріоритизація MoSCoW — це баланс між ризиком і прогнозованістю для кожного окремого проєкту.
10.4.2 Попереднє узгодження, як саме працюватимуть пріоритети
DSDM пропонує визначення пріоритетів — це “Правила MoSCoW”. Проте, якщо межа між Should і Could доволі розмита, то краще заздалегідь домовитися в команді (і з бізнес ролями), як розрізняти ці два рівні. Це зніме багато суперечок у майбутньому.
Приклад: Яка кількість людей має бути під впливом проблеми, щоб вимогу вважати Should Have замість Could Have? Яку величину вигоди (benefits) потрібно отримати, щоб знизити пріоритет із Should до Could?
Найкраще вирішити це до того, як почнуть детально збирати вимоги.
Коли варто пріоритизувати?
Кожен пункт роботи має свій пріоритет. Пріоритети визначаються до початку роботи над ними. Більшість пріоритизації відбувається під час фази Foundations. Проте перегляд пріоритетів має тривати постійно, адже в процесі:
Можуть з’являтися нові вимоги.
Може виявитися додаткова робота над наявними вимогами.
Тоді варто оцінювати: “Наскільки це критично?” і застосовувати правила MoSCoW. Важливо слідкувати, щоб частка Must Have не перевищувала погоджений рівень. Вимоги, які ще не реалізовані, також мають періодично переглядатися, принаймні в кінці кожного Timebox і кожного проєктного інкремента.
Обговорення та перегляд пріоритетів
Усі Must Have є критичними для успіху проєкту. Project Manager, Business Analyst чи інший учасник Solution Development Team мають обговорювати ці вимоги відкрито (особливо якщо Must Have не є очевидним). Остаточне слово за Business Visionary або Business Ambassador: вони мають пояснити, чому вимога є Must Have.
Рівень ескалації прийняття рішень (хто до кого звертається, коли потрібне схвалення) бажано визначити заздалегідь. Наприклад, Business Ambassador → Business Analyst → Business Visionary → Business Sponsor. Також варто домовитися про рівень повноважень у прийнятті рішень.
У кінці кожного Project Increment вимоги, які не були реалізовані, переглядаються знову. Наприклад, Could Have, не виконані в одному інкременті, можуть стати Won’t Have у наступному — якщо вони вже не такі важливі, — або, навпаки, піднятися до Must Have, якщо тепер їхня реалізація стала критично необхідною.
Використання MoSCoW для керування очікуваннями бізнесу (Using MoSCoW to Manage Business Expectations)
Правила MoSCoW створені так, щоб можна було гарантувати доставку MUST (мінімального робочого набору). Як команда, так і бізнес більш упевнені в цьому завдяки достатньому обсягу вимог рівнів Should і Could, які створюють резерв і забезпечують успішність Must Have.
Must Have — гарантовано, але цілком імовірно, що більшість Should Have теж буде реалізовано (якщо все йде без значних ускладнень). У кращому випадку Could Have також можуть бути завершені.
Проте Solution Development Team не може гарантувати, що всі Must, Should і Could будуть реалізовані, адже на початку складно оцінити точну складність усіх пунктів і можуть виникати непередбачувані фактори. Тиск із вимогою “гарантувати виконання Must, Should і Could” часто призводить до “підстраховочних” завищених оцінок, що створюють ілюзію успіху (“Ми завжди виконуємо 100%, бо дуже сильно завищили оцінки”).
Комбінація ефективної пріоритизації та timeboxing робить поставку більш прогнозованою й підвищує довіру. При цьому якість рішення також залишається захищеною. Корисно збирати метрики: який відсоток Should Have і Could Have вдається виконати в кожному інкременті або Timebox. Це дає ранній сигнал, якщо з’являються труднощі.
Як MoSCoW співвідноситься з бізнес-візією (How does MoSCoW Relate to the Business Vision)
Погляд Business Sponsor
Відправна точка будь-якого проєкту — бізнес-візія (business vision) з набором пріоритизованих вимог, які допомагають цю візію реалізувати. Із цією візією пов’язаний Business Case, що описує проєкт із погляду вартості й вигоди (ROI — повернення інвестицій).
MoSCoW-пріоритети потрібні, щоб визначити мінімальний робочий набір і відносну важливість кожної вимоги. Business Visionary зобов’язаний впевнитися, що ці вимоги пріоритизовані, оцінені з точки зору бізнесу й реалізовані так, аби досягти ROI, закладеного в Business Case.
Як ефективно застосовувати MoSCoW (Making MoSCoW Work)
Вимоги ідентифікуються на різних рівнях деталізації. Спочатку — на високому рівні (під час фази Feasibility), потім — більш детально (у Evolutionary Development). Високорівневі вимоги часто можна поділити на підвимоги, і тоді стає простіше пріоритизувати окремі менш важливі деталі. Це важливо, щоб забезпечити гнучкість і можливість відмовитись від чогось менш важливого, якщо виникнуть проблеми.
Якщо, на перший погляд, усі вимоги здаються Must Have, це зазвичай свідчить про недостатню деталізацію й розбиття вимог.
Якщо справді все Must Have, тоді немає резерву для коригування, а це суперечить принципам DSDM, де фіксується час і бюджет, а варіюється склад функціональності. Занадто велика кількість Must Have — часта проблема команд, які не вдаються до детальної декомпозиції вимог.
Також пам’ятайте, що учасники команди можуть мимоволі розширювати обсяг робіт, беручись за цікаві завдання замість найважливіших. MoSCoW допомагає уникати цього.
Поради щодо встановлення пріоритетів (Tips for Assigning Priorities)
Переконайтеся, що всі бізнес-ролі, зокрема Business Visionary та Business Analyst, розуміють, чому і як DSDM пріоритизує вимоги.
Спробуйте почати з того, що всі вимоги позначаються як Won’t Have, а потім доводиться, чому потрібен вищий пріоритет.
Для кожної вимоги, яку пропонують як Must Have, питайте:
“Що буде, якщо цю вимогу не реалізують?”Якщо відповідь: “Закрити проєкт, бо немає сенсу впроваджувати рішення без цього”, тоді це Must Have. Якщо ні — то Should Have або Could Have (або навіть Won’t Have).
Ще один варіант питання:
“Якщо напередодні впровадження я скажу, що Must Have-вимогу неможливо реалізувати, ви зупините розгортання?”Якщо так — це Must Have. Якщо ні — то Should/Could.
Чи існує обхідний шлях (навіть якщо він ручний)? Якщо так, це не Must Have. Визначати, чи це Should, чи Could, варто через порівняння вартості такого “обходу” та вартості реалізації функціоналу.
Питайте: “Чому ця вимога потрібна зараз для цього проєкту й цього інкремента?”
Чи залежить ця вимога від інших? Must Have не може залежати від Should/Could, адже ті можуть не бути доставлені.
Дозволяйте різні пріоритети для критеріїв прийняття всередині однієї вимоги.
Приклад: “Поточні резервні процедури мають забезпечувати максимально швидке відновлення сервісу.” Наскільки швидко? Іноді краще прописати, що Should бути відновлено за 4 години, але Must за 24.
Запитайте себе: чи можна декомпозувати вимогу? І чи всі складники однаково пріоритетні?
Прив’яжіть вимогу до конкретної цілі проєкту. Якщо ціль проєкту не Must, то, найімовірніше, пов’язана з нею вимога також не Must.
Чи змінюється пріоритет із часом? Для початкового випуску це може бути Should, а для другого — Must.
Пріоритизуйте тестування також, використовуючи MoSCoW.
MoSCoW можна застосовувати й до списку завдань, а не лише до вимог.
Висновок
MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) здебільшого використовується для пріоритизації вимог, але може бути корисним і в інших напрямках. Для типового проєкту DSDM рекомендує мати не більше 60% від загального обсягу робіт як Must Have і близько 20% Could Have. Якщо частка Must Have перевищує 60%, зростає ризик невиконання проєкту (якщо тільки середовище не є дуже передбачуваним, технологія — знайомою, а команда — надзвичайно досвідченою).
Сутність MoSCoW полягає в тому, щоб збалансувати ризик і прогнозованість, забезпечуючи простір для маневру й гарантуючи, що справді критичні вимоги будуть виконані без зриву дедлайнів та бюджету.
Основні моменти, на які варто звернути увагу при вивченні MoSCoW: Пріоритети Must Have визначають мінімальний критично необхідний набір функціоналу. Should Have і Could Have дають команді запас часу й можливість адаптації, залишаючись важливими для бізнесу. Won’t Have фіксує вимоги, які цього разу не робитимуть, щоб вони не поверталися “несподівано” пізніше. Збалансований підхід — близько 60% Must, близько 20% Could, решта — Should і Won’t. Декомпозиція вимог допомагає відрізнити дійсно критичне від менш важливого. Пріоритети можуть змінюватися з часом (для різних інкрементів чи Timebox).
Коментарі