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