PM Stories » планиране

Приоритизация на изискванията по метода MoSCoW

Майк Рам — Wed, 04 Feb 2009 05:10:25 +0000

Приоритизацията на изискванията и задачите е едно от най-важните задължения на всеки един проектен мениджър. Независимо колко успешно е стартирал един проект, рано или късно стигаме до ситуация, в която трябва да изберем кои изисквания да изпълним и кои да откажем, за да успеем да се включим в поставените срокове.

Най-добре е това разпределение да бъде направено в самото начало и методът MoSCoW е един от най-простите, но за сметка на това най-ефективни подходи.

Той възниква за пръв път в методологията DSDM (Dynamic Software Development Method) – един от първите “гъвкави” подходи, но е приложим във всеки един проект, независимо от избраната управленска методология. “Московският метод” (двете “о”-та са поставени за благозвучие и така се е получило съвпадението с името на руската столица) е прост начин за категоризиране на изискванията по важност, за да може на всички участници в проекта да бъде ясно кое е важно за клиента и кое – не.

Съкращението MoSCoW означава:

Must have (задължително трябва да го има)
Should have (би трябвало да го има)
Could have (добре би било да го има)
Won’t have (няма да го има)

Какво означава това в детайли?

Must have. Това са изисквания и функционалности, без които основната цел на проекта не би могла да бъде постигната. Те са гръбнакът на системата, абсолютният минимум, за да има проекта някакъв смисъл.
Should have. Тези изисквания не са критични за съществуването на продукта, но са изключително важни и от голямо значение за клиента.
Could have. Това са изисквания, които е добре да ги има в системата, и биха могли да бъдат реализирани, ако не изискват някакви особени усилия. Но те са и първите, които ще бъдат отхвърлени от обхвата на проекта, ако се появи опасност от изпускане на сроковете.
Won’t have. Тези изисквания са категорично извън обхвата на текущия проект и дори не влизат в плана. Те се поддържат в списъка на изискванията, за да могат да бъдат реализирани евентуално в някоя от следващите версии на продукта.

Добрата практика изисква да има баланс между различните категории изисквания. Това дава възможност на проектния екип да бъде гъвкав във вземането на решения при екстремни ситуации и да има солидни аргументи в преговорите с клиента.

Много клиенти се изкушават да декларират всичките си изисквания като абсолютно задължителни (Must Have), но това почти винаги обрича проекта ако не на провал, то на изключително мъчително изкарване. Затова още в самото начало на проекта, екипът по бизнес анализ и проектният мениджър трябва да извършат това приоритизиране и да получат неговото потвърждение и от клиента.

Възможно е по време на работата по проекта да се променят някои от бизнес приоритетите на клиента. Това налага да се извърши наново и приоритизацията на изискванията. Добра практика е в края на всеки етап да се прави ревизия на приоритетите, за да може усилията на проектния екип да се фокусират във всеки един момент към най-важните задачи и да не се пилее енергия, време и пари по нещо маловажно.

Гласувайте за тази статия в Svejo.net:

Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.

Вижте и тези публикации:

Промяната – необходимото зло или естествена форма на прогреса

Майк Рам — Wed, 27 Feb 2008 10:54:23 +0000

Промяната е нещо, което повечето хора не обичат. Рутината и навика лесно завладяват нашето съзнание и винаги се чувстваме по-удобно в познатите коловози на ежедневието, отколкото в плашещите дебри на непознатото.

Промяната е най-големият страх за всички проджект мениджъри. Голяма част от методологиите и теориите на управлението разчитат, че нещата ще бъдат относително стабилни. Плановете, които правим постоянно, имат по-голяма стойност, ако обстоятелствата не се променят.

Така е, но животът постоянно ни показва, че е динамичен и променлив и колкото повече се съпротивляваме срещу този факт и не искаме да приемем промяната, която се случва около нас, толкова повече страдаме.

Този, който приеме промяната и я използва, има по-голям шанс за успех от онзи, който си затваря очите за нея или яростно я отрича. Промяната е това, което движи прогреса. Понякога е досадно неудобство, което нарушава собствения ни комфорт, а друг път е тежък стрес, който може да ни доведе до отчаяние, но в крайна сметка, това е животът и този, който не го разбира, губи.

Попаднах на един пост, озаглавен 50 причини да не се промениш, където авторите са събрали най-популярните оправдания за това да отречеш промяната и са ги представили като една стена от бележки. Колко пъти сте чували (или изричали):

Това не може да стане
Нямам време
Твърде сложно е
Твърде скъпо е
И така си ни е добре
Това не е моя работа

Дали тези оправдания не са защитна реакция на човек, който не иска да види промяната или просто се страхува от нея?

Гласувайте за тази статия в Svejo.net:

Рекламно съобщение: Посетете курса по основи на управлението на софтуерни проекти, който ще се проведе на 13.03.2008 г. в София. Повече информация за него можете да намерите тук, в блога Спри и помисли! и на официалния сайт на RammSoft.

Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.

Вижте и тези публикации:

Как оценяте бюджета на един проект? Резултати от анкетата

Майк Рам — Tue, 18 Dec 2007 09:35:00 +0000

Анкетата беше поставена преди доста време и я позадържах с надеждата, че повече хора ще се включат и ще получим малко по-представителна извадка, но забелязах, че напоследък няма нови гласуващи и затова реших да я прекратя и да разгледаме резултатите.

Въпросът беше: Как оценяте бюджета на един проект?
В анкетата гласуваха общо 65 човека. Ето и разпределението на гласовете:

На око – 28 гласа, 43%. Както предвиждаха моите лични наблюдения, това се оказа най-честият отговор. Ако приемем, че повечето участници са гласували сериозно, а не са си правили майтап, това е доста тревожен симптом. За мен, този отговор означава, че голяма част от проджект мениджърите не са запознати с основните задачи и методи на професията (главно поради случайно попадане в нея) и поради това работят основно на принципа на пробите и грешките, където грешките май са повече. На тези колеги им препоръчвам да четат по-активно материалите в този блог и да участват в дискусиите. Убеден съм, че ще им бъде много полезно.
По учебника – правим WBS, оценяме всяка една задача и отчитаме и рисковите фактори – 16 гласа, 25%. Очевидно това е добрата новина – има проекти, където нещата се правят на базата на утвърдени теории и практики за управление на проекти. За съжаление, такива примери все още са малко. Много ще се радвам, ако някой от подалите такъв глас сподели на страниците на този блог своя опит и примери от неговата успешна работа.
Не знам. Шефът се занимава с парите – 11 гласа, 17%. Това е най-неприятната ситуация за един проджект мениджър – поставят те в ситуация, в която някой друг е определил параметрите без да се допита до тебе, а ти си човекът, който трябва да избута проекта до успешен край. Добре е поне, че гласувалите по този начин са относително по-малко, но аз мисля, че този подход е много погрешен и истински прогрес ще имаме само тогава, когато такива проекти изчезнат напълно.
По друг начин – 10 гласа, 15%. За съжаление, участниците в анкетата, които са избрали този вариант, не са уточнили какъв точно е техният подход, с което само ни карат да гадаем. Но никога не е късно да се поправи този пропуск. Могат да споделят техния начин на оценка на бюджета в този или други постове като коментар. Всички са добре дошли!

В заключение, мисля, че положението с управлението на проекти у нас е зле. Малко се познава тази наука и много малко хора получават качествено обучение по управление на проекти. Добрата новина е, че нещата постепенно започват да се променят. Има хора и фирми, които започват да оценят важността на добрата подготовка на проджект мениджърите за успеха на един проект и че има все повече възможности за професионално обучение, където опитни специалисти предават знанието си на по-младите.

С това се занимавам и аз, така че ако искате да повишите вашите знания по управление на софтуерни проекти, ако искате успешните проекти във вашето портфолио да са повече от неуспешните, следете обявите на сайта на моята фирма – RammSoft – или в този блог и се запишете в курсовете и консултациите, които ние предлагаме. Няма да съжалявате!

Вижте и тези публикации:

Как оценяте бюджета на един проект? Нова анкета

Майк Рам — Wed, 19 Sep 2007 07:11:00 +0000

Искам да ви обърна внимание на новата анкета, която съм публикувал на сайдбара на сайта. Особено на тези, които са абонирани за RSS feed и не посещават самия сайт.

Въпросът този месец е: Как оценяте бюджета на един проект? Моите скромни наблюдения сочат, че в много софтуерни фирми не се правят предварителни сметки за необходимия бюджет на един проект или пък такива оценки се правят от висшия мениджмънт (от шефа) без участието на проджект мениджъра, а често се случва финансовите параметри на проекта да се държат в тайна от екипа, даже и от самия проджект мениджър, който по учебник би трябвало да отговаря за това.

Как е при вас? Любопитен съм да узная дали има фирми, където проджект мениджърите са получили доверието, което работата им изисква, или все още гледат на тях като на малки деца и не им разрешават да си играят с пари.

Гласувайте! Вашето мнение е важно!

Резултатите от анкетата можете да видите тук.

Вижте и тези публикации:

Туризъм и управление на проекти

Майк Рам — Sun, 26 Aug 2007 08:42:00 +0000

Glen Alleman е публикувал една доста провокативна статия в своя блог Herding Cats, озаглавена Agile Planning. Там той прави интересно сравнение между туристическите “проекти” и софтуерните такива и поставя сериозни въпроси към слепите последователи на т. нар. “гъвкави методологии”.

Той казва:

Туристическите походи изискват и планиране, и график, и следване на плана. Понякога се налагат алтернативни планове, промянта в графика се случва винаги и винаги има алтернативни опции по време на изпълнението. Защо е тогава този шум против планирането в софтуерното производство от страна на “гъвкавите”?

И още:

Подготовката е ключа към успешния туристически поход

Защо тогава…
Подготовката да не е ключ и към успешния софтуерен проект?

Да се отстоява обратното – че планирането, подготовката, подредбата и управлението на изпълнението на задачите не е необходимо – е опасно в сферата на туризма. Защо тогава смятаме, че тези дейности не са важни в сферата на проджект мениджмънта?

Добри въпроси, над които да се замислим, както и да отправим към онези религиозни фанатици, които смятат, че техният екстремен подход без никакво планиране и подготовка е винаги по-доброто решение, отколкото традиционните управленски методологии.

Цялата статия можете да прочетете тук.