# NUPP Скоро Универзални Пројектни Принципи [image] Ово је верзија онлајн упутства за download (https://omimo.org/sr-cyrl/modules/nupp/), генерисана на 2026‑07‑02. Провери веб сајт за нове верзије. NUPP потиче од OMIMO (https://omimo.org/sr-cyrl/), што је породица отворених, минималистичких модула. Ово упутство може се користити и слободно дистрибуирати под Creative Commons Attribution 4.0 International лиценцом. ОМИМО је суфинансиран од стране Европске уније. Међутим, изнети ставови и мишљења су искључиво ставови организације ОМИМО и не одражавају нужно ставове Европске уније или ЕПОС ВЗВ. Ни Европска унија ни орган који је доделио средства не могу се сматрати одговорним за њих. Превео: Vladimir Majstorovic ## Увод “НУПП ” је скраћеница од „Nearly Universal Principles of Projects“ тј. означава збир “скоро универзалних принципа пројеката”: оних које би било добро следити у свим пројектима, без обзира на методологије и приступе које у њима употребљавамо, како би постигли максимални успех. Сваки од расположивих ресурса и метода за спровођење пројеката почива на НЕКИМ од ових “НУП”-ова (скоро универзалних принципа). Ипак, следеће ствари треба имати на уму: - “Почива на НЕКИМ” (подвучено у претходном пасусу): обично не на СВИМ, а практичарима пројектног менаџмента се управо препоручује да узму у обзир СВЕ “НУП”ове, а не само неке од њих. - У ресурсима и методима ови принципи (на којима се заснивају) нису довољно очигледни, па како је већина практичара пречесто фокусирана на практичне детаље, заборавља на принципе и ради ствари у нескладу са њима. “НУП ”ови су компатибилни са свим важним методима, системима, ресурсима и фрамеwорк-овима као што су: PRINCE2^(®), PMBOK^(®) Guidе, p3.express, PM², DSDM^(®), XP, и Scrum. Додуше , може се десити да нису компатибилни са одређеним интерпретацијама ових система, и управо у тим случајевима “НУП”ови треба да охрабре практичаре да преиспитају те интерпретације. “НУПП” је збир следећих “НУП”ова: - NUP1 — Резултати и истина пре припадности - NUP2 — Очувај и оптимизуј енергију и ресурсе - NUP3 — Увек буди проактиван - NUP4 — ланац је јак онолико колико његова најслабија карика - NUP5 — Не ради ништа без јасне сврхе - NUP6 — Користи поновљиве елементе ## NUP1 Резултати и истина пре припадности [image] Сви ми имамо природну тенденцију да припадамо групама, тенденцију која често превазилази своју основну форму, креирајући снажне везе које могу изазвати и проблеме. Може се чак десити да изгубимо много више због тих веза него што добијемо у одређеним ситуацијама. Не тргујмо сопственим професионалним интегритетом, идентитетом и склоностима, за рачун припадности одређеној групи. ### Пример : Agile против Waterfall-а Група изузетних ентузијаста која је била довољно храбра да користи адаптивне приступе развоју унутар ИТ развоја, у време када се доминантно користио предиктивни приступ, окупила се и назвала свој приступ “Agile”. Ово је била сјајна иницијатива да се избегне ограничавање избора само на оно што се чинило неопходним. Још увек је пуно ентузијаста усмерених на резултат у Agile заједници, нажалост у њој има и неких који теже да Agile претворе у култ, посматрајући све ван ње у непријатеље. Ово ствара вишеструке проблеме, укључујући и следеће: - Спречава их да уче од било кога ван групе - Обесхрабрује оне ван групе да уче од њих - Ставља припадност групи испред стварне сврхе, што као резулат спречава припаднике групе да науче о стварном смислу „Агилности“ Овај проблем се може значајно умањити (ако не и отклонити), употребом речи “Agile” САМО као ознаке која се односи на развојни приступ, а не на заједницу са својим члановима; даље , уз помоћ ЉУДИ који сматрају себе креаторима, решаваоцима проблема, и лидерима којии виде “Agile” једноставно као ЈЕДАН ОД СВОЈИХ АЛАТА, А НЕ КАО СВОЈ ИДЕНТИТЕТ. За праве професионалце не постоји рат “Agile” против “Waterfall”-а! ### Пример : PRINCE2^(®) против PMBOK^(®) Guide Многи професионалци у пројект менаџмент заједници се идентификују или са PRINCE2^(®) методологијом или са PMBOK^(®) framework-ом (често само због географске локације) и нису упознати са другом страном. Сви ми можемо нагињати одређеним ресурсима, али не доводећи свој професионални идентитет и интегритет у питање. Још важније, требало би да се фамилијаризујемо сва свима њима ширећи своје видике и могућности избора. Прави професионалци су отворени за све идеје, тражећи их, учећи о њима, и користећи их када је потребно, без стварања некритичке припадности тј. везивања за исте. ### Пример : Непрекидно учење Везивања за одређене идеје или заједнице, задовољавају особу због пратећег осећаја припадности, али је не подстичу да учи, понекад чак и обесхрабрују због страха од губитка те исте припадности. Ако је особа слободна, ако је експерт са интегритетом испред припадности, стално ће попуњавати празнине у свом схватању учењем: непрекидним учењем. ОНО У ШТА ДАНАС ВЕРУЈЕМО НИЈЕ ПОТПУНА ИСТИНА (ВЕЋ ВИШЕ НАШЕ ТРЕНУТНО РАЗУМЕВАЊЕ КОЈЕ ТРЕБА ПРОДУБИТИ), А СУТРА ВЕЋ МОЖЕ БИТИ ПОЛУИСТИНА. Ако су нечије идеје годинама фиксиране без икаквих промена, онда са њима нешто није реду. Ово је случај и за НУПП: ако се вратиш овде за неколико година и видиш потпуно исти садржај, треба да будеш сумњичав. ### Пример : Отвореност Када полемишеш или приговараш, буди сигуран да циљаш на идеју а не на особу. Ово ће помоћи да се смање тензије. Слично томе, када него полемише са тобом или ти приговара, не схватај то као рат против тебе, већ као дискусију о твојим идејама и остани отворен за примање. Не слушај да би одговорио, слушај да би разумео; ради са том особом на побољшању идеје. Неки људи ће можда намерно “гађати” твоју личност уместо идеје, у ком случају треба да им помогнеш да се фокусирају на идеју уместо на тебе пре наставка дискусије. Покушај да ово одржаваш и у наставку дискусије. ## NUP2 Очувај и оптимизуј енергију и ресурсе [image] Ресурси су ограничени. Ресурси расположиви пројекту су ограничени, баш као и ментална енергија коју имаш за доношење добрих одлука. Треба да очуваш и оптимизујеш овај ресурс за себе и пројекат, као и да помогнеш другим члановима тима да ураде исто. ### Пример : Правило 80/20 (Паретово правило) Највећи део потенцијалних бенефита (рецимо 80%) од пројекног менаџмента добија се трошењем мањег дела (рецимо 20%) од укупно планираног напора потребног за достизање 100% бенефита. У већини случајева, циљајући 100% могућих бенефита је скупо и неоправдано. Треба следити ово правило у свему што радите и охрабрити друге да исто тако раде. ### Пример : Замореност одлучивањем Ми користимо један извор менталне енергије за све врсте одлучивања, као и да изразимо снагу воље. Ако ову енергију трошиш на мање важне или небитне одлуке, имаћеш мање енергије за важне одлуке, што може довести до лоших резултата. Ово је један од разлога зашто треба избећи “микро-менаџмент” (“управљај према изузетку” принцип PRINCE2^(®)). Конфликти који настају око идеја, могу да буду корисни, али они који настају око/због људи обично штете пројекту, а једна од последица је „цеђење“ менталне енергије чланова тима. Ако приметиш такав конфликт, дај све од себе да нађеш главни узрок и решиш га. ### Пример : Побрини се за себе ! Одлуке које доносиш и снага воље коју изражаваш користе твој извор менталне енергије. Са друге стране, овај извор се допуњава када редовно спаваш и правилно се храниш. Дакле , потруди се око себе : спавај и одмарај довољно, храни се добро и правилно. Ако имаш штетне навике или проблеме са спавањем, не препуштај се сам себи ; постоје специјалисти који ти могу помоћи. Физичка активност такође помаже са овим извором енергије, иако истраживања по овом питању нису једногласна. Охрабри чланове тима да ураде исто што и ти. Прво , осигурај да раде одрживим темпом и без много прековременог рада. Затим , ако имаш ту врсту могућности, понуди им енергетску, здраву храну и пиће током радног времена. ### Пример : Равнотежа између приватног и пословног Многи од нас воле оно што раде, али то још увек није све што им треба у животу. На исти начин на који оптимизујеш свој посао треба да планираш и спроводиш идеје у свом приватном животу, тако да ти доносе радост и срећу. Када си срећнији, тада си и успешнији у послу. Охрабруј чланове тима да раде исто. ### Пример : Мотивација Мотивација је комплексан концепт. Постоје неки јако интересантни и корисни ресурси на ову тему, али још много више не-научно засновних. Ипак , треба да научиш о њима И непрекидно их користиш, јер тиме повећаваш менталну енергију тима И могућност постизања бољих резултата пројекта. Средства за мотивацију могу бити веома једноставна: дај људима на знање да препознајеш њихов добар рад, љубазним осмехом или једноставним “Хвала Ти!”. Опрез : многе честа средства за мотивацију, као што су мале новчане награде, могу имати и негативан ефекат. ### Пример : Сарадња и тимски рад Људи који сарађују могу некада имати моћ да побољшају резултате, али оно што је још важније, људи су друштвена бића и воле да су део групе. Ако им уклониш негативне аспекте тимског рада и направиш пријатно окружење, имаћеш срећније чланове тима у пројекту. Опрез : људи су различити, тако да је некима потребније опуштено, фокусирано и самостално време, него другима – овде говоримо о балансирању потреба унутар тима. ### Пример : Култура “један-тим” Постоји тенденција да различити појединци или интересне групе (stakeholders) стварају или подржавају “кланове” и стварање тензија унутар групе или са другим групама; на пример, “људи фокусирани на пословни аспект” наспрам “људи који праве пројектни производ”. Оваква тензија може “украсти” пуно енергије обеју страна, и то је разлог више да радимо на томе да направимо културу “једног-тима” где сви раде ка истом циљу без обзира на улогу унутар пројекта. ### Пример : Мудрост групе Ако се скупи на једном месту већи број људи различитих профила да ради у модерираном окружењу (састанак, радионица, презентација, конференција…), овде постоји потенцијал за стварање јако добрих резултата, идеја, решења, чак и бољих него она која долазе од појединачних експерата. Ако имаш ову могућност, користи је редовно да замолиш чланове тима да ти помогну у решавању сложених пројектних проблема. Осим добијања добрих резултата, друга предност је што тиме стављаш на знање члановима тима колико цениш њихово мишљење и да имају важну улогу у пројекту, што са друге стране подиже њихов ниво енергије и расположења. Активност E02 у P3.express је пример коришћења “мудрости групе” у пројектима. ### Пример : Главни пројектни модератор Ако си пројектни менаџер, већина ствари које радиш има природу модерације (или би требало да има). Са друге стране, можда приметиш да су чланови тима у прошлости имали лоша искуства са пројектним менаџерима, и да пројектују та искуства на садашњу ситуацију. То може утицати значајно на ваш однос:они троше значајан део енергије анализирајући твоје понашање, тражећи потенцијалне претње уместо да ти верују. У том случају, промени свој назив од “пројект менаџера” у “главног пројектног модератора”. На крају крајева, то је оно што стварно радиш у пројекту. ## NUP3 Увек буди проактиван [image] Постоји природна тенденција у нама да будемо реактивни. То нам помаже да очувамо енергију избегавајући бављење неважним стварима, или дати боље резултате у ситуацији када се суочимо са нечим где смо потпуно некомпетентни. Ове ситуације се разликују од пројеката, где проактивношћу постижемо много боље резултате. ### Пример : Планирање Ако возиш на неку нову локацију, а при томе касниш, започећеш вожњу ОДМАХ БЕЗ ПРИПРЕМЕ како би “уштедео време” и успут ћеш се хватати укоштац са евентуаним проблемима, онако како настају, импровизујући. Проактивни приступ би био: узети неко време пре почетка вожње, подесити навигациони систем да ти да најбржу руту засновану на густини саобраћаја, могућим инцидентима и блокадама дуж пута, ПА ТЕК ОНДА започети вожњу; то значи провести неко време пре ИЗВРШЕЊА путовања, да би избегао касније проблеме, и самим тим дошао до краја уз уштеду времена. Насупрот томе шта неки људи мисле о Agile пројектима, ПЛАНИРАЊЕ ЈЕ УВЕК НЕОПХОДНО, ради се само типу и нивоу детаља у плановима. ПЛАНИРАЊЕ ПРЕ ИЗВРШЕЊА ЈЕ ПРОАКТИВНИ ПРИСТУП. Сети се цитата: “Ако ми даш 6 сати да исечем цело дрво, првих сат времена провешћу у оштрењу секире”. Ако је Предиктиван пројекат у питању, можеш да проведеш и 4 сата оштрећи секиру, ако си унапред сигуран да је циљ исећи цело дрво. У Агилном пројекту, ниси унапред сигуран да ли ћеш сећи дрво, скупљати разбијене гране, остатке од жетве, копати угаљ из рудника, или нешто друго. Па ипак, још увек мораш да обавиш генералну припрему за све то (да знаш где је најближа продавница алата), нешто специјалне припреме (оштрење) када се будеш фокусирао на одређено решење – то се зове планирање! ### Пример : Планирање планирања Планирање начина на који ћемо извршити пројекат је проактиван приступ. Ова проактивност се чак може проширит планирањем начина на који ћемо да планирамо извршење; то су нпр. Следећи концепти: “пројект менаџмент плана” код PMBOK^(®) Gudie, менаџмент стратегија PRINCE2^(®), и приступа код DSDM^(®). ### Пример : Непрекидно планирање Реалност се ретко поклапа са оним што смо планирали, и то је ОК – али, морамо непрекидно да прилагођавамо наше планове како би били сигурни да остају реалистични и практични. То треба урадити одмах чим проценимо да је прилагођавање неопходно, а не тек онда када улетимо у проблеме. ТО ЈЕ ПРОАКТИВНИ ПРИСТУП. ### Пример : Управљање ризицима Цео концепт управљања ризицима се заснива на проактивности: када смо суочени са неизвесним догађајима, уместо да чекамо и гледамо шта ће се десити и тек онда регујемо на њих, ми већ унапред мислимо на ВЕРОВАТНОЋУ И УТИЦАЈЕ ових неизвесних догађаја, разматрамо одговоре на њих, и на крају и урадимо нешто унапред, како би их предупредили. Обратите пажњу да је оно што радимо у пројектима озбиљно; некада се ради и о људским животима. ### Пример : Дефинисање улога и одговорности Можеш препустити члановима пројектног тима да раде без јасних улога и одговорности, и пре или касније спонтано ће се искристалисати неки облик улога И одговорности. Међутим , то ће бити превише скупо и на крају можда неће ни добро функционисати. Проактивни приступ би био дефинисати их рано у пројекту, и прилагођавати временом по потреби. Ово ће уродити лакшим радом за свакога, тако да ће се моћи фокусирати на извршење нечега, уместо да одлучују ко ће шта да ради. Број и развноврсност рола зависи од типа и величине пројекта; најједноставнија дефиниција је у Scrum-у, нешто просечно сложености као у p3.express, или нешто опсежно као у DSDM^(®) и PRINCE2^(®). Ипак, не заборавите да су описи улога у овим методама битни само за менаџмент активности, а додатно је потребно дефинисати описе улога за техничке аспекте пројекта. ### Пример : Расположиве опције избора Да ли прерано затворити пројекат или га наставити? Избор ретко има само две опције, чак и када то само питање имплицира. Треба заузети проактиван став, и размотрити све опције пре доношења одлуке. Можда се може редефинисати сцопе пројекта; можда се може паузирати док се неке ствари не разјасне; можда се може променити пројектни приступ (нпр. Outsourcing ) , итд. ### Пример : Критичко мишљење Сви имамо неке предрасуде, и уврежене ставове које нам помажу да преживимо (са једне стране), али нас често и наводе на доношење лоших одлука (са друге стране). Када дође до доношења важних одлука о пројекту, најбоље је направити паузу на неко време, освестити све предрасуде које могу да утичу на наше одлучивање, пре него што проузрокују проблеме. Као референцу, можете користити листу когнитивних предрасуда дату на Википедији. Постоје чак и framework-ови за доношење одлука које можете користити као алате за боље одлучивање. На први поглед, они могу деловати збуњуће, па и иритантно, али ћете се брзо навићи на њихово коришћење и усвојити њихове предности, без пуно свесног напора. ### Пример : Транспарентност Не волимо кашњење у пројекту или било какву другу врсту проблема, али то не значи да то треба да кријемо. Треба бити транспарентан и упознати стакехолдер-е са тим, јер неки од њих ће можда моћи да помогну, штавише, сазнаће о проблемима и њиховим последицама пре или касније, а неки од њих ће са своје стране можда захтевати брзо дејство (нпр. прихватање негативних последица) ### Пример : Ефективна комуникација Може бити пуно случајева у којима шаљете извештаје стакехолдер-има, а они вам не дају никакву повратну информацију. Можда ћете мислити да је све у реду, јер нема негативне повратне информације, иако можда није тако. Треба бити проактиван и проверити да ли се извештај заиста користи и да ли користи сврси, користити повратне информације да би се побољшао метод комуникације; у супротном, скривена питања или проблеми могу касније проузроковати знатно озбиљније проблеме касније, када буде много теже да се поправе. ### Пример : Узимање одговорности Лако је окривити друге за лоше резултате. На пример, можда ћете желети да вам организација да пуно овлашћење да промените све у пројекту и да урадите све савршено, али то се не деси, и као резултат, пројекат пропадне. ОВО НИЈЕ ПРОАКТИВАН ПРИСТУП. Проактиван приступ подразумева узимање одговорности да се уради све што је у оквиру ваших пројектних ограничења (сцопе, време, буџет, квалитет итд..). Не можете очекивати да вам организација да пуно поверење и допусти све у циљу постизања добрих резултата, нарочито ако има претходна искуства са пропалим пројектима. Оно што треба да урадите је да направите мања побољшања унутар ограничења која су вам дата у пројекту , искористите то да добијете мало више поверења, нешто више ресурса и толеранције на пројектна ограничења, а онда то искористите за значајнија побољшања пројект , износећи га све док не досегнете оптимални таргет. ## NUP4 ланац је јак онолико колико његова најслабија карика [image] Постоје различити домени у пројектима сви они захтевају пажњу; морамо имати холистичку перспективу пројекта. Обраћање пажње на наизглед важне домене (нпр. време) није довољно, јер сви домени међусобно су зависни (интерагују) и не раде добро док не добију адекватну пажњу. ### Пример : Све је до рокова ! Рецимо да градите нешто за Олимпијске игре. Рок је изузетно близу, што даје на значају домену управљања временом. Да ли је баш тако? Шта ако квалитет неких производа пројект буде тако лош да је неопходно понављање после неког времена? То би свакако утицало на време, дакле важно је и време и квалитет. Можда сте замислили фантастичну башту у оригиналној дефиницији пројекта, али знајући да немате довољно времена, прескочићете китњасте детаље и само прекрити травом, уколико сте на на време предвидели овакву ситуацију и припремили се за њу. Све у свему, и управљање сцопе-ом је врло значајно. Да резимирамо: у центру наше пажње су сада сцопе, време и квалитет. Чули сте за познат пример када је председник САД Кенеди срео домара у НАСА-и, питајући га чиме се бави? Одговор је био: “Помажем да се човек попне на Месец”. Зар присуство оваквог типа људи у пројекту не помаже испуњавању рокова? Ако би наставили тако даље, приметили би да сваки појединачни домен у пројекту доприноси управљању временом, и не можете очекивати да ћете испоштовати рокове са прихватљивим нивом извесности, осим ако не обратите пажњу на све домене. ### Пример : Пристрасна (некритичка) селекција Када су људи суочени са широком лепезом избора (различити методи), понекад бирају некритички правећи микс свега што има делује интересантно из различитих система. Ово обично не функционише, јер елементи не раде у изолацији већ морају да су међусобно компатибилни. Сви додаци или промене система треба радити са холистичке тачке гледишта. Због тога понекад видимо контрадикторне елементе у различитим методама ; нешто ради добро у једном систему, а његова супротност у другом систему. Тај елеменат сам по себи није ни добар ни лош – ради се о контексту коришћења. Најсигурнији приступ: изабери методологију за пројекат, скроји је по потребама пројекта, а онда опрезно додај нове елементе, стално имајући на уму конзистентност целог система. ### Пример : Анти-процесни приступ Једна од најбољих ствари које су Agile методи остварили јесте указивање на људске аспекте. Agile манифест поклања већу пажњу индивидуама и интеракцијама него процесима и алатима, иако ово можда није фер поређење. Скоро све методе ће рећи да су људски аспекти важни, а стварна разлика са Агиле методама је да су људски аспекти уграђени део процеса, пре него пука сугестија. Дакле , не ради се о такмичењу између људских аспеката и процеса, ради се о начину на који су људски аспекти виђени од стране система. Нема сумње да неки људи покушавају да замене људске аспекте софистициранијим процесима, али у питању је неадекватна примена. Дешава се и супротно: људи покушавају да замене процесе људским аспектима, што такође не функционише добро. ### Пример : Ово су сви домени који ти требају Размишљајући о доменима, треба пазити да се не испусти ниједан од њих из разматрања. Али шта су они заправо ? Проверавајући фундаменталне ресурсе, добићемо различите одговоре; па ипак ниједан не садржи пуну истину. PRINCE2^(®) “Теме” су домени, али то су само домени коју играју кључну улогу у методологији. Остали домени се само наслућују. PMBOK^(®) Gudie није методологија и може да формулише то много боље помоћу 10 области знања. Ипак ово су интерпретације домена засноване на погледу PMBOK^(®) Gudie на пројекте, пре него неутрална перспектива (која у суштини и не постоји). На пример, људски аспекти не добијају много пажње у PMBOK^(®) Guide. Добар извор информација о доменима је ICB. Ипак , не ради се толико о доменима колико о потребним компетенцама за пројекат. Не постоји релација један-на-један са доменима, али прилично помаже у њиховој идентификацији. Нема листе домена у “НУПП”, примарно јер је у питању мета-систем пре него систем, такође и јер категоризација домена зависи од типа пројект и пројектног окружења; нпр. рутински грађевински пројекат можда захтева другу перспективу од креативног истраживачког пројекта. ## NUP5 Не ради ништа без јасне сврхе [image] Не би требало да радиш нешто осим ако нема јасну сврху. Замисли два паралелна света где је све исто осим тога што у једном свету размишљаш о ономе што радиш, а у другом не: колико би се разликовала та два света? Да ли је разлика вредна труда да се то (не) уради? Ако ти није јасна сврха и радиш нешто само зато што и сви остали то раде, или свако каже да је важно да се то ради, онда: * Можда у твом случају то нема стваран бенефит, па стога не добијаш ништа радећи то; или * Можда у твом случају има потенцијалне бенефите, али пошто ти није јасна сврха, начин на који то будеш радио можда ти неће помоћи да оствариш те бенефите. ### Пример : Портфолија и програми Ако си укључен у избор и иницијацију пројеката, фокусирај се на бенефите и проблеме који треба да се реше пре него на производ кој треба да реализује ове ствари. Класичан пример је произвођач лифтова који је примао жалбе на брзину својих лифтова, па је покренуо више пројеката да би поправио брзину лифтова, али без потпуног успеха. Ово се настављало све док нису одлучили да се фокусирају на проблем (досађивање или нелагодност у лифту) уместо “природног” решења (бржих лифтова). Резултат је био тај да су додали огледала у лифтове и решили проблем једноставно и јевтино. Запамти да је за пројектни менаџмент углавном важно “радити ствари на прави начин”, док је за портфолио менаџмент важно “радити праве ствари”. Није важно колико добро водиш своје пројекте; неће добро функционисати уколико радиш погрешне пројекте. Све је у сврси. ### Пример : Пројекат као целина Флексибилност производа варира од пројект до пројекта. У неким ИТ развојним пројектима, производ је потпуно флексибилан и његов финални облик зависи од повратне информације које ће уследити након инкременталних фаза производа кроз пројекат, што захтева адаптивни (Agile) приступ. У практичном смислу ово је комбинација слојева портфолија, програма и пројеката и потребан је максимум пажње посвећен крајњем циљу. Добра идеја је документовати сврху и имати је увек на дохват руке; то је једна од сврха “визије производа”, како се користи у неким Scrum пројектима. Акценат на пословну вредност у Agile пројектима је његов начин осигураног усклађивања са сврхом. У другим врстама пројекта, где је производ релативно фиксан и постоје други механизами контроле да производ задовољи сврху, могуће је да чланови пројектног тима помере фокус са сврхе на производ (отуда принцип “фокус на производе” PRINCE2^(®)), али у најмању руку минимум пажње посвећен сврси је још увек потребан да би се обезбедило да оно што се ствара служи сврси, што се може остварити поређењем предвиђених и очекиваних бенефита (отуда принцип “континуалног пословног правдања” и “business case” Тема у PRINCE2^(®)). Ако се пројекат ради за екстерног клијента, клијент жели своју сопствену сврху за пројекат, а ваша компанија ће имати своју сврху. Потребно је да разумете и користите обе да би стварно успели. ### Пример : Мониторинг пројекта Фокусирање на крајњу сврху је неопходно. Али можда и превише апстрактно за већину свакодневних примена. За практичну примену потребно је успоставити хијерархију покретача. Као прво, пословно оправдање и бенефити пројект дефинисани су сходно крајњој сврси, а сходно њима експлицитни и имплицитни таргети за пројектне варијабле (тј. време, трошак, квалитет) да би се задовољило пословно оправдање, што би на крају задовољило крајњу сврху. Ово су сврхе нижег нивоа које су корисне за многе од наших дневних задатака. Када се ради о мониторингу, мониторинг нижег нивоа у пројекту пратиће варијабле ниженг нивоа, јер можда неће бити могуће пратити крајњу сврху. У овом случају, не треба заборавити на сврху: шта је сврха мониторинга? Нормалан и прихватљив одговор је видети да ли добро пратимо план, ако не, иницирати одговарајућу реакцију која ће нас довести назад на у оквире плана или поново подесити таргете и видети да ли коначна сврха још увек може бити задовољена. Наша мерења стога треба да нам помогну око ове сврхе нижег нивоа, а одговарајућа мерења су прогнозе за пројектне варијабле на крају пројекта; нпр ., када ћемо моћи да завришимо пројекат? Колико новца нам је потребно да завршимо пројекат? Сва друга мерења, као што су планиране и актуелне вредност на дан, само су међувредности које су нам потребне да би калкулисали прогнозу, а не коначне вредности за сврхе менаџмента. ### Пример : Документи Без обзриа који девелопмент приступ користимо у пројекту, планирање је увек неопходно. Важно питање је ниво детаља у сваком типу плана. Ако нема довољно детаља у плану, план неће моћи довољно да допринесе, а извршавање пројект засниваће се на ад-хоц одлукама пре него на интегрисаним, холистичким. Са друге стране, пуно људи покушава да буде опрезно, па додаје превише детаља у план, што га чини тешким за припрему и одржавање, и превише ригидним за неизвесности у пројекту. Као резултат, план постаје нереалан и бескористан. Најбољи начин да се одлучи о нивоу детаља је имати сврху на уму за сваки елемент у плану. На пример, ако разматраш додавање ресурса у план, то треба да има сврху: како ћеш га користити? Како ће то помоћи пројекту? Колико напора ће то произвести? И да ли се исплати? Понекад се ради о томе да ли желиш неки елемент у својим плановима, а некад о начину на који планираш и припремаш нешто. Било да је business case, пројектна повеља, или извештај: увек се питај зашто припремаш тај документ и како може да помогне пројекту. Тражење разних “template”-а по wеб-у је сушта супротност чињења нечег базираног на сврси. ### Пример : Статусно извештавање Честа је појава предугих статусних извештаја у многим пројектима. Полазећи од овог НУП-а, треба да се запитамо која је сврха извештаја и како је можемо постићи без обзира шта други раде по том питању. Ово нас у много случајева може водити ка припреми веома једноставних извештаја на једној страници које ће stakeholder-и заиста читати и разумети, за разлику од дугих извештаја. Ово је поклањање пажње сврси. Ако припремаш извештај од једне стране, додуше неки људи могу да и то замере и мисле да немаш постављен адекватан мониторинг систем. У пракси, ово креира теби секундарну сврху (осим примарне, а то је помоћ стакехолдерима да разумеју статус пројекта), а да би то задовољили, можете просто креирати други тип извештаја који ће бити дугачак. Ипак , не мешајте ова два извештаја, јер им је и сврха различитиа. ### Пример : Business case и пројектна повеља Припреме докумената као што је business case и пројектна повеља обично је досадна, јалова, бирократска неопходност за већину људи, док сви ови документи имају ваљану сврху која важи за већину пројеката. Ако покушаш да пронађеш “темплате” и попуниш га, време је протраћено; уместо тога боље је да провериш праву сврху ових докумената, видиш да ли и како могу бити од помоћи у пројекту, а онда припремиш документ на начин како желиш, искључиво да задовољиш сврху: то ће онда бити прави документ. Док размишљаш о начину припреме докумената да би задовољили своју сврху, можда нећеш имати на уму сваки сценарио и зато нешто пропустити. Да би то избегао, провери све ресурсе, као нпр. PRINCE2^(®), PMBOK^(®) Gudie, p3.express, И DSDM^(®) сугестије, и онда евалуирај ове сугестије засновано на сврси. ### Пример : Пост-пројекат Све док пројекат има специфичну сврху (а сврху можемо преиспитивати током пројекта) , реализација сврхе углавном се вреднује на основу прогноза насталих током пројекта. Ипак , не смемо да заборавимо на то ни кад се пројекат заврши. Важно је проверити реализацију циљева након краја пројекта, јер: - Можемо видети како се постижу крајњи циљеви и учити из тога за будуће пројекте, и, - Понекад се циљеви остваре само ако се обаве неки додатни задаци након пројекта, а за разумевање неопходности ових екстра задатака потребан је мониторинг. Пост -пројектни мониторинг је неопходан корак ако смо вођени сврхом. Ово је углавном одговорност система за управљање прогама и портфолиа, а пошто већина компанија нема такве нивое менаџмента, овај корак се обично занемарује. Због тога методи као P3.express и DSDM^(®) додају овај корак у своје методологије пројектног менаџмента. ### Пример : Једноставност Свет је комплексан и хаотичан, али наши модели су апстрактне апроксимације које одражавају делове света, па су стога једноставне. Са друге стране, једноставни системи обично функционишу боље, јер можемо да се фокусирамо на главну идеју. Многи од нас покушавају да добију боље резултате додајући комплексност у систем, надајући се да ће одсликати комплексност света, чак и ако у пракси ово отежава рад са системом и обично нас спречава да задовољимо сврху. ### Пример : Прилагођавање – “кројење” Софтвер за streaming музике има различите услове од оног који се користи за опрему у болници или у авиону где од тога зависе људски животи, или од софтвера који ће се користити у сателитима где треба да раде много година без “пада система”. А сви поменути софтверски пројекти разликују се од изградње летње виле, ватрогасне станице, или постројења за прераду. Ако имате сврху на уму, боље ћете разумети како прилагодите – “скројите” системе и артефакте за различите пројекте. ## NUP6 Користи поновљиве елементе [image] Ad-hoc приступ пројекту узима превисе енергије и ресурса, а увек постоји и ризик изостављања неког од неопходних елемената. Најбољи начин да се поједностави оно што треба да буде се уради, јесте користити поновљиве елементе, и по могућству користити их у поновљивим циклусима. ### Пример : Чек-листа за квалитет Чек -листа је једноставан пример потенцијално поновљивог елемента који користи већина људи у свом приватном и професионалном животу. Узмимо критеријуме за квалитет испорученог пројектног производа, на пример: - Прво , може креирати чек-листу СВИХ критеријума, што је форма планирања. - НУП6 предлаже да покушате да генерализујете: има ли сличних испоручених производа у пројекту? У том случају, припремите генералну чек-листу за квалитет , за ту КАТЕГОРИЈУ испорученог производа и користите је за све њих. Ако буде неких варијација, држите се генеричке листе, па додајте неколико екстра ставки за поједине испоручене производе. Ето поновљивих чек-листи. - Чим сте припремили генеричку чек-листу за различите категорије испоручених пројектних производа, можете наћи понављајуће елементе међу њима, што сугерише виртуалну “родитељску” категорију. У том случају, уместо да понављате ставке за све генеричке чек-листе. Можете их извадити и ставити у „родитељску“ чек-листу. На крају ћете вероватно имати једну генеричку чек-листу за цео пројекат. “Дефиниција урађеног” у Scrum-у (“definition of done”) је пример коришћења чек-листа за квалитет на нивоу пројект (између осталог). Радећи ово, сваки пројектни производ ће припадати негде у хијерархији категорија и требаће при провери квалитета да задовољи ставке које се појављују у чек-листама свих категорија у њиховом ланцу. Радећи ово, ставка у родитељској чек-листи постаће поновљива за све производе испод ње, што штеди време и енергију у планирању и извршењу. Што је још важније, кад ово урадиш за један пројекат, можеш је прилагодити и користити за све сличне пројекте убудуће, што је поновљиви облик планирања за више пројеката. ### Пример : Процеси и токови рада Неки пројектни производи, или циљеви повезани са њима, изискују одређене кораке који могу постати стандардизовани и поновљиви. На пример, ако пројектни производи треба да се дизајнирају и одобравају индивидуално , можете припремити једноставан “workflow” који јасно приказује све кораке, укључене особе, и приближна трајања, тиме избегавајући многе потешкоће. Ипак треба пазити не учинити процесе превисе компликованим или превисе интензивним при документовању, јер ће имати негативне последице. Сви људи укључени у пројекат треба да схвате процесе и токове рада као нешто што подупире и олакшава њихов рад, а не као бирократско документовање које блокира практичан рад. Агилни пројекти имају поновљиве елементе у свом приступу итеративног развоја, при чему се одређен тип развојних активности понавља за сваку карактеристику производа (феатуре); нпр. иста дневна рутина у XP (еXтремно Програмирање):упарити, узети ставку, дизајнирати је на белој табли, направити тестне скрипте и код, интегрисати код, итд… Осим поновљивих процеса рада који се користе за техничке активности, можемо имати поновљиве елементе и за активности пројекног менаџмента. Процеси у PMBOK^(®) Guide, PRINCE2^(®), и DSDM^(®), активности у p3.express, и догађаји у Scrum су примери овог концепта. ### Пример : Циклуси Имати поновљиве елементе за управљање пројектом је од помоћи. Ово може бити још лакше стављајући их у поновљиве циклусе. Ови циклуси значајно упрошћавају свакодневне активности људи укључених у менаџмент и вођство пројекта. Циклуси процесних група у PMBOK^(®) Guide када се користе у пројекту у више фаза, фазе (стагес) у PRINCE2^(®), дневни, недељни, и месечни циклуси у p3.express, итерације и временске кутије у DSDM^(®), као и Спринтови у Scrum-у, све су примери овог концепта. Краћи цикулси су лакши за разумевање и употребу него дужи; нпр. Спринтови у Srum-у насупрот фазама по PMBOK^(®) Guide. Ипак , прекратки циклуси можда неће бити довољни да изнесу одређене типове пројеката, а решење може бити употреба вишеструких циклуса, као што је у DSDM^(®) употреба кратких циклуса “временске кутије” у комбинацији са дужим итеративним циклусима, или коришћење дневних, недељних и месечних циклус у p3.express. ### Пример : Методе Коришћење методологије или фрамеwорк-а за вођење пројект је још један случај коришћења поновљивих елемената. Ово може бити постојећи систем као што је PRINCE2^(®), p3.express, DSDM^(®), или Scrum, или сyстем који сте прилагодили или сами измислили. Нормално , за почетак је боља идеја стартовати са неким од постојећих метода и прилагодити је својим потребама, него направити једну “од нуле”. Сваки поновљиви елемент је апстрактан и изискује кастомизацију да би га прилагодили стварном свету. Постоји спектар апстракције и потребе за кастомизацијом, додуше: мале, релативно фиксне чек-листе квалитета стоје на једном крају спектра са малом количином апстракције И потребе за прекрајањем, док су методологије на другом крају, са високом потребом за прекрајање. Треба увек приметити потребу за прекрајањем, у супротном поновљиви елемент неће одгговарати вашим потребама на потребан начин.