Техніка встановлення пріоритетів MoSCoW
Будь-хто з нас знав би, як організувати відомих російських ляльок, впорядкувавши їх за розміром, а потім представивши найменший розмір у наступному найбільшому. Це схоже на дитячу гру, але в рамках управління вимогами ми не настільки зрозумілі. Техніка пріоритезування вимог MoSCoW може допомогти нам їх організувати та надати додаткову цінність класифікації, оскільки сама каталогізація вказує правильний спосіб досягнення рішення загадки проекту.
Коли ми читаємо, наскільки добре або погано розробляються проекти, цифри про успішні проекти лякають, особливо якщо ми розглядаємо великі проекти.
Техніка визначення пріоритетів вимог MoSCoW, допомогти всій команді розробників розуміти фактичні наслідки присвоєння критичності.
При розробці бізнес-вимог я вважаю хорошою практикою каталогізувати потреби користувачів з урахуванням пріоритетів, але в більшості організацій, які їх впроваджують, вони використовують цінності, які не мають реального значення для решти. Від команди розробників.
- 1 Високий пріоритет
- два Середній пріоритет
- 3 Низький пріоритет
Дозвольте мені пояснити, зрештою, не має значення рівень критичності, який присвоюється кожній вимозі, зрештою все повинно бути зроблено, і що передається команді, це те, що дуже критичні вимоги повинні бути перевірені дуже добре тому що, якщо вона не залишається повішеною в системі та тих, хто має низьку критичність, нічого не відбувається, тому що вони "трохи" зазнають збою.
MoSCoW або знання того, що важливо для бізнесу
MoSCoW - це скорочення, яке розшифровується як:
Повинен бути, повинен був, міг би і хотів би, але не отримає
Як бачимо, класифікація - це не просто підбір числа до кожної з вимог. Проводячи аналіз вимог, ми усвідомлюємо, що не все є обов’язковим і що є речі, які ми зараз робити не збираємось. Важливі 4 букви для команди розробників.
- М - ОБОВ'ЯЗКОВО Вимоги, які має мати рішення. Вони є мінімальними вимогами, які роблять рішення придатним для використання
- S - ПОВИНЕН Вимоги, які має містити рішення. Важливі, але не обов'язково необхідні вимоги
- С - МОЖНА Вимоги, які може містити рішення. Глазур на торті
- W - НЕ Вимоги, які не збираються виконувати (наразі), але які можуть бути включені в майбутньому
Багато ситуацій спадає на думку, коли техніка MoSCoW не застосовувалася. Але я хочу виділити ситуацію, яку я називаю: "Навчання".
У службі програмних показників великого банку вимоги до нових звітів переважали команду. Користувачами були старші менеджери організації, і все було важливим і необхідним.
Тож ми кажемо, встановіть контроль над усіма звітами, щоб обчислити використання, яке було надано звітам. Результат був очікуваним, деякі звіти ніколи не виконувались, інші припиняли використовувати незабаром після їх реалізації ... Не все було важливим і необхідним.
Ми припинили публікувати багато звітів, і ніхто не протестував і не пропускав їх, тож у нас було більше часу, щоб присвятити реальним покращенням сервісу.
Чи траплялося з вами у проекті, який ви пам’ятаєте про MoSCoW? Проекти, які так і не були реалізовані?
Старший ІТ-консультант | Цифрове перетворення | Спритний | Менеджер PMO | Блоггер | SMC, PMP. Якщо ви хочете знати мене більш детально, проконсультуйтеся з моєю біографією