# NUPP Skoro Univerzalni Projektni Principi [image] Ovo je verzija online uputstva za download (https://omimo.org/sr-latn/modules/nupp/), generisana na 2026‑07‑02. Proveri veb sajt za nove verzije. NUPP potiče od OMIMO (https://omimo.org/sr-latn/), što je porodica otvorenih, minimalističkih modula. Ovo uputstvo može se koristiti i slobodno distribuirati pod Creative Commons Attribution 4.0 International licencom. OMIMO je sufinansiran od strane Evropske unije. Međutim, izneti stavovi i mišljenja su isključivo stavovi organizacije OMIMO i ne odražavaju nužno stavove Evropske unije ili EPOS VZW. Ni Evropska unija ni organ koji je dodelio sredstva ne mogu se smatrati odgovornim za njih. Preveo: Vladimir Majstorovic ## Uvod “NUPP” je skraćenica od „Nearly Universal Principles of Projects“ tj. označava zbir “skoro univerzalnih principa projekata”: onih koje bi bilo dobro slediti u svim projektaim, bez obzira na metodologije i pristupe koje u njima upotrebljavamo, kako bi postigli maksimalni uspeh. Svaki od raspoloživih resursa i metoda za sprovođenje projekata počiva na NEKIM od ovih “NUP”-ova (skoro univerzalnih principa). Ipak, sledeće stvari treba imati na umu: - “Počiva na NEKIM” (podvučeno u prethodnom pasusu): obično ne na SVIM, a praktičarima projektanog menadžmenta se upravo preporučuje da uzmu u obzir SVE “NUP”ove, a ne samo neke od njih. - U resursima i metodima ovi principi (na kojima se zasnivaju) nisu dovoljno očigledni, pa kako je većina praktičara prečesto fokusirana na praktične detalje, zaboravlja na principe i radi stvari u neskladu sa njima. “NUP”ovi su kompatibilni sa svim važnim metodima, sistemima, resursima i framework-ovima kao što su: PRINCE2^(®), PMBOK^(®) Guide, P3.express, PM², DSDM^(®), XP, and Scrum. Doduše, može se desiti da nisu kompatibilni sa određenim interpretacijama ovih sistema, i upravo u tim slučajevima “NUP”ovi treba da ohrabre praktičare da preispitaju te interpretacije. “NUPP” je zbir sledećih “NUP”ova: - NUP1 — Rezultati i istina pre pripadnosti - NUP2 — Očuvaj i optimizuj energiju i resurse - NUP3 — Uvek budi proaktivan - NUP4 — Zapamti – lanac je jak onoliko koliko njegova najslabija karika - NUP5 — Ne radi ništa bez jasne svrhe - NUP6 — Koristi ponovljive elemente ## NUP1 Rezultati i istina pre pripadnosti [image] Svi mi imamo prirodnu tendenciju da pripadamo grupama, tendenciju koja često prevazilazi svoju osnovnu formu, kreirajući snažne veze koje mogu izazvati i probleme. Može se čak desiti da izgubimo mnogo više zbog tih veza nego što dobijemo u određenim situacijama. Ne trgujmo sopstvenim profesionalnim integritetom, identitetom i sklonostima, za račun pripadnosti određenoj grupi. ### Primer: Agile vs waterfall Grupa izuzetnih entuzijasta koja je bila dovoljno hrabra da koristi adaptivne pristupe razvoju unutar IT razvoja, u vreme kada se dominantno koristio prediktivni pristup, okupila se i nazvala svoj pristup “Agile”. Ovo je bila sjajna inicijativa da se izbegne ograničavanje izbora samo na ono što se činilo neophodnim. Još uvek je puno entuzijasta usmerenih na rezultat u Agile zajednici, nažalost u njoj ima i nekih koji teže da Agile pretvore u kult, posmatrajući sve van nje u neprijatelje. Ovo stvara višestruke probleme, uključujući i sledeće: - Sprečava ih da uče od bilo koga van grupe - Obeshrabruje one van grupe da uče od njih - Stavlja pripadnost grupi ispred stvarne svrhe, što kao rezulat sprečava pripadnike grupe da nauče o stvarnom smislu „Agilnosti“ Ovaj problem se može značajno umanjiti (ako ne i otkloniti), upotrebom reči “Agile” SAMO kao oznake koja se odnosi na razvojni pristup, a ne na zajednicu sa svojim članovima; dalje, uz pomoć LJUDI koji smatraju sebe kreatorima, rešavaocima problema, i liderima kojii vide “Agile” jednostavno kao JEDAN OD SVOJIH ALATA, A NE KAO SVOJ IDENTITET. Za prave profesionalce ne postoji rat “Agile” protiv “Waterfall”-a! ### Primer: PRINCE2^(®) vs PMBOK^(®) Guide Mnogi profesionalci u projekt menadžment zajednici se identifikuju ili sa PRINCE2^(®) metodologijom ili sa PMBOK^(®) framework-om (često samo zbog geografske lokacije) i nisu upoznati sa drugom stranom. Svi mi možemo naginjati određenim resursima, ali ne dovodeći svoj profesionalni identitet i integritet u pitanje. Još važnije, trebalo bi da se familijarizujemo sva svima njima šireći svoje vidike i mogućnosti izbora. Pravi profesionalci su otvoreni za sve ideje, tražeći ih, učeći o njima, i koristeći ih kada je potrebno, bez stvaranja nekritičke pripadnosti tj. vezivanja za iste. ### Primer: Neprekidno učenje Vezivanja za određene ideje ili zajednice, zadovoljavaju osobu zbog pratećeg osećaja pripadnosti, ali je ne podstiču da uči, ponekad čak i obeshrabruju zbog straha od gubitka te iste pripadnosti. Ako je osoba slobodna, ako je ekspert sa integritetom ispred pripadnosti, stalno će popunjavati praznine u svom shvatanju učenjem: neprekidnim učenjem. ONO U ŠTA DANAS VERUJEMO NIJE POTPUNA ISTINA (VEĆ VIŠE NAŠE TRENUTNO RAZUMEVANJE KOJE TREBA PRODUBITI), A SUTRA VEĆ MOŽE BITI POLUISTINA. Ako su nečije ideje godinama fiksirane bez ikakvih promena, onda sa njima nešto nije redu. Ovo je slučaj i za NUPP: ako se vratiš ovde za nekoliko godina i vidiš potpuno isti sadržaj, treba da budeš sumnjičav. ### Primer: Otvorenost Kada polemišeš ili prigovaraš, budi siguran da ciljaš na ideju a ne na osobu. Ovo će pomoći da se smanje tenzije. Slično tome, kada nego polemiše sa tobom ili ti prigovara, ne shvataj to kao rat protiv tebe, već kao diskusiju o tvojim idejama i ostani otvoren za primanje. Ne slušaj da bi odgovorio, slušaj da bi razumeo; radi sa tom osobom na poboljšanju ideje. Neki ljudi će možda namerno “gađati” tvoju ličnost umesto ideje, u kom slučaju treba da im pomogneš da se fokusiraju na ideju umesto na tebe pre nastavka diskusije. Pokušaj da ovo održavaš i u nastavku diskusije. ## NUP2 Očuvaj i optimizuj energiju i resurse [image] Resursi su ograničeni. Resursi raspoloživi projektu su ograničeni, baš kao i mentalna energija koju imaš za donošenje dobrih odluka. Treba da očuvaš i optimizuješ ovaj resurs za sebe i projekat, kao i da pomogneš drugim članovima tima da urade isto. ### Primer: Pravilo 80/20 (Paretovo pravilo) Najveći deo potencijalnih benefita (recimo 80%) od projeknog menadžmenta dobija se trošenjem manjeg dela (recimo 20%) od ukupno planiranog napora potrebnog za dostizanje 100% benefita. U većini slučajeva, ciljajući 100% mogućih benefita je skupo i neopravdano. Treba slediti ovo pravilo u svemu što radite i ohrabriti druge da isto tako rade. ### Primer: Zamorenost odlučivanjem Mi koristimo jedan izvor mentalne energije za sve vrste odlučivanja, kao i da izrazimo snagu volje. Ako ovu energiju trošiš na manje važne ili nebitne odluke, imaćeš manje energije za važne odluke, što može dovesti do loših rezultata. Ovo je jedan od razloga zašto treba izbeći “mikro-menadžment” (“upravljaj prema izuzetku” princip PRINCE2^(®)). Konflikti koji nastaju oko ideja, mogu da budu korisni, ali oni koji nastaju oko/zbog ljudi obično štete projektu, a jedna od posledica je „ceđenje“ mentalne energije članova tima. Ako primetiš takav konflikt, daj sve od sebe da nađeš glavni uzrok i rešiš ga. ### Primer: Pobrini se za sebe ! Odluke koje donosiš i snaga volje koju izražavaš koriste tvoj izvor mentalne energije. Sa druge strane, ovaj izvor se dopunjava kada redovno spavaš i pravilno se hraniš. Dakle, potrudi se oko sebe : spavaj i odmaraj dovoljno, hrani se dobro i pravilno. Ako imaš štetne navike ili probleme sa spavanjem, ne prepuštaj se sam sebi ; postoje specijalisti koji ti mogu pomoći. Fizička aktivnost takođe pomaže sa ovim izvorom energije, iako istraživanja po ovom pitanju nisu jednoglasna. Ohrabri članove tima da urade isto što i ti. Prvo, osiguraj da rade održivim tempom i bez mnogo prekovremenog rada. Zatim, ako imaš tu vrstu mogućnosti, ponudi im energetsku, zdravu hranu i piće tokom radnog vremena. ### Primer: Ravnoteža između privatnog i poslovnog Mnogi od nas vole ono što rade, ali to još uvek nije sve što im treba u životu. Na isti način na koji optimizuješ svoj posao treba da planiraš i sprovodiš ideje u svom privatnom životu, tako da ti donose radost i sreću. Kada si srećniji, tada si i uspešniji u poslu. Ohrabruj članove tima da rade isto. ### Primer: Motivacija Motivacija je kompleksan koncept. Postoje neki jako interesantni i korisni resursi na ovu temu, ali još mnogo više ne-naučno zasnovnih. Ipak, treba da naučiš o njima I neprekidno ih koristiš, jer time povećavaš mentalnu energiju tima I mogućnost postizanja boljih rezultata projektaa. Sredstva za motivaciju mogu biti veoma jednostavna: daj ljudima na znanje da prepoznaješ njihov dobar rad, ljubaznim osmehom ili jednostavnim “Hvala Ti!”. Oprez: mnoge česta sredstva za motivaciju, kao što su male novčane nagrade, mogu imati i negativan efekat. ### Primer: Saradnja i timski rad Ljudi koji sarađuju mogu nekada imati moć da poboljšaju rezultate, ali ono što je još važnije, ljudi su društvena bića i vole da su deo grupe. Ako im ukloniš negativne aspekte timskog rada i napraviš prijatno okruženje, imaćeš srećnije članove tima u projektu. Oprez: ljudi su različiti, tako da je nekima potrebnije opušteno, fokusirano i samostalno vreme, nego drugima – ovde govorimo o balansiranju potreba unutar tima. ### Primer: Kultura “jedan-tim” Postoji tendencija da različiti pojedinci ili interesne grupe (stakeholders) stvaraju ili podržavaju “klanove” i stvaranje tenzija unutar grupe ili sa drugim grupama; na primer, “ljudi fokusirani na poslovni aspekt” naspram “ljudi koji prave projektani proizvod”. Ovakva tenzija može “ukrasti” puno energije obeju strana, i to je razlog više da radimo na tome da napravimo kulturu “jednog-tima” gde svi rade ka istom cilju bez obzira na ulogu unutar projektaa. ### Primer: Mudrost grupe Ako se skupi na jednom mestu veći broj ljudi različitih profila da radi u moderiranom okruženju (sastanak, radionica, prezentacija, konferencija…), ovde postoji potencijal za stvaranje jako dobrih rezultata, ideja, rešenja, čak i boljih nego ona koja dolaze od pojedinačnih eksperata. Ako imaš ovu mogućnost, koristi je redovno da zamoliš članove tima da ti pomognu u rešavanju složenih projektanih problema. Osim dobijanja dobrih rezultata, druga prednost je što time stavljaš na znanje članovima tima koliko ceniš njihovo mišljenje i da imaju važnu ulogu u projektu, što sa druge strane podiže njihov nivo energije i raspoloženja. Aktivnost E02 u P3.express je primer korišćenja “mudrosti grupe” u projektaima. ### Primer: Glavni projektani moderator Ako si projektani menadžer, većina stvari koje radiš ima prirodu moderacije (ili bi trebalo da ima). Sa druge strane, možda primetiš da su članovi tima u prošlosti imali loša iskustva sa projektanim menadžerima, i da projektuju ta iskustva na sadašnju situaciju. To može uticati značajno na vaš odnos:oni troše značajan deo energije analizirajući tvoje ponašanje, tražeći potencijalne pretnje umesto da ti veruju. U tom slučaju, promeni svoj naziv od “projekt menadžera” u “glavnog projektanog moderatora”. Na kraju krajeva, to je ono što stvarno radiš u projektu. ## NUP3 Uvek budi proaktivan [image] Postoji prirodna tendencija u nama da budemo reaktivni. To nam pomaže da očuvamo energiju izbegavajući bavljenje nevažnim stvarima, ili dati bolje rezultate u situaciji kada se suočimo sa nečim gde smo potpuno nekompetentni. Ove situacije se razlikuju od projekata, gde proaktivnošću postižemo mnogo bolje rezultate. ### Primer: Planiranje Ako voziš na neku novu lokaciju, a pri tome kasniš, započećeš vožnju ODMAH BEZ PRIPREME kako bi “uštedeo vreme” i usput ćeš se hvatati ukoštac sa eventuanim problemima, onako kako nastaju, improvizujući. Proaktivni pristup bi bio: uzeti neko vreme pre početka vožnje, podesiti navigacioni sistem da ti da najbržu rutu zasnovanu na gustini saobraćaja, mogućim incidentima i blokadama duž puta, PA TEK ONDA započeti vožnju; to znači provesti neko vreme pre IZVRŠENJA putovanja, da bi izbegao kasnije probleme, i samim tim došao do kraja uz uštedu vremena. Nasuprot tome šta neki ljudi misle o Agile projektaima, PLANIRANJE JE UVEK NEOPHODNO, radi se samo tipu i nivou detalja u planovima. PLANIRANJE PRE IZVRŠENJA JE PROAKTIVNI PRISTUP. Seti se citata: “Ako mi daš 6 sati da isečem celo drvo, prvih sat vremena provešću u oštrenju sekire”. Ako je Prediktivan projekat u pitanju, možeš da provedeš i 4 sata oštreći sekiru, ako si unapred siguran da je cilj iseći celo drvo. U Agilnom projektu, nisi unapred siguran da li ćeš seći drvo, skupljati razbijene grane, ostatke od žetve, kopati ugalj iz rudnika, ili nešto drugo. Pa ipak, još uvek moraš da obaviš generalnu pripremu za sve to (da znaš gde je najbliža prodavnica alata), nešto specijalne pripreme (oštrenje) kada se budeš fokusirao na određeno rešenje – to se zove planiranje! ### Primer: Planiranje planiranja Planiranje načina na koji ćemo izvršiti projekat je proaktivan pristup. Ova proaktivnost se čak može proširit planiranjem načina na koji ćemo da planiramo izvršenje; to su npr. Sledeći koncepti: “projekt menadžment plana” kod PMBOK^(®) Guide, menadžment strategija PRINCE2^(®), i pristupa kod DSDM^(®). ### Primer: Neprekidno planiranje Realnost se retko poklapa sa onim što smo planirali, i to je OK – ali, moramo neprekidno da prilagođavamo naše planove kako bi bili sigurni da ostaju realistični i praktični. To treba uraditi odmah čim procenimo da je prilagođavanje neophodno, a ne tek onda kada uletimo u probleme. TO JE PROAKTIVNI PRISTUP. ### Primer: Upravljanje rizicima Ceo koncept risk menadžment se zasniva na proaktivnosti: kada smo suočeni sa neizvesnim događajima, umesto da čekamo i gledamo šta će se desiti i tek onda regujemo na njih, mi već unapred mislimo na VEROVATNOĆU I UTICAJE ovih neizvesnih događaja, razmatramo odgovore na njih, i na kraju i uradimo nešto unapred, kako bi ih predupredili. Obratite pažnju da je ono što radimo u projektaima ozbiljno; nekada se radi i o ljudskim životima. ### Primer: Definisanje uloga i odgovornosti Možeš prepustiti članovima projektanog tima da rade bez jasnih uloga i odgovornosti, i pre ili kasnije spontano će se iskristalisati neki oblik uloga I odgovornosti. Međutim, to će biti previše skupo i na kraju možda neće ni dobro funkcionisati. Proaktivni pristup bi bio definisati ih rano u projektu, i prilagođavati vremenom po potrebi. Ovo će uroditi lakšim radom za svakoga, tako da će se moći fokusirati na izvršenje nečega, umesto da odlučuju ko će šta da radi. Broj i razvnovrsnost rola zavisi od tipa i veličine projektaa; najjednostavnija definicija je u Scrum-u, nešto prosečno složenosti kao u P3.express, ili nešto opsežno kao u DSDM^(®) i PRINCE2^(®). Ipak, ne zaboravite da su opisi uloga u ovim metodama bitni samo za menadžment aktivnosti, a dodatno je potrebno definisati opise uloga za tehničke aspekte projektaa. ### Primer: Raspoložive opcije izbora Da li prerano zatvoriti projekat ili ga nastaviti? Izbor retko ima samo dve opcije, čak i kada to samo pitanje implicira. Treba zauzeti proaktivan stav, i razmotriti sve opcije pre donošenja odluke. Možda se može redefinisati scope projektaa; možda se može pauzirati dok se neke stvari ne razjasne; možda se može promeniti projektani pristup (npr. Outsourcing) , itd. ### Primer: Kritičko mišljenje Svi imamo neke predrasude, i uvrežene stavove koje nam pomažu da preživimo (sa jedne strane), ali nas često i navode na donošenje loših odluka (sa druge strane). Kada dođe do donošenja važnih odluka o projektu, najbolje je napraviti pauzu na neko vreme, osvestiti sve predrasude koje mogu da utiču na naše odlučivanje, pre nego što prouzrokuju probleme. Kao referencu, možete koristiti listu kognitivnih predrasuda datu na Wikipedii. Postoje čak i framework-ovi za donošenje odluka koje možete koristiti kao alate za bolje odlučivanje. Na prvi pogled, oni mogu delovati zbunjuće, pa i iritantno, ali ćete se brzo navići na njihovo korišćenje i usvojiti njihove prednosti, bez puno svesnog napora. ### Primer: Transparentnost Ne volimo kašnjenje u projektu ili bilo kakvu drugu vrstu problema, ali to ne znači da to treba da krijemo. Treba biti transparentan i upoznati stakeholder-e sa tim, jer neki od njih će možda moći da pomognu, štaviše, saznaće o problemima i njihovim posledicama pre ili kasnije, a neki od njih će sa svoje strane možda zahtevati brzo dejstvo (npr. prihvatanje negativnih posledica) ### Primer: Efektivna komunikacija Može biti puno slučajeva u kojima šaljete izveštaje stakeholder-ima, a oni vam ne daju nikakvu povratnu informaciju. Možda ćete misliti da je sve u redu, jer nema negativne povratne informacije, iako možda nije tako. Treba biti proaktivan i proveriti da li se izveštaj zaista koristi i da li koristi svrsi, koristiti povratne informacije da bi se poboljšao metod komunikacije; u suprotnom, skrivena pitanja ili problemi mogu kasnije prouzrokovati znatno ozbiljnije probleme kasnije, kada bude mnogo teže da se poprave. ### Primer: Uzimanje odgovornosti Lako je okriviti druge za loše rezultate. Na primer, možda ćete želeti da vam organizacija da puno ovlašćenje da promenite sve u projektu i da uradite sve savršeno, ali to se ne desi, i kao rezultat, projekat propadne. OVO NIJE PROAKTIVAN PRISTUP. Proaktivan pristup podrazumeva uzimanje odgovornosti da se uradi sve što je u okviru vaših projektanih ograničenja (scope, vreme, budžet, kvalitet itd..). Ne možete očekivati da vam organizacija da puno poverenje i dopusti sve u cilju postizanja dobrih rezultata, naročito ako ima prethodna iskustva sa propalim projektaima. Ono što treba da uradite je da napravite manja poboljšanja unutar ograničenja koja su vam data u projektu , iskoristite to da dobijete malo više poverenja, nešto više resursa i tolerancije na projektana ograničenja, a onda to iskoristite za značajnija poboljšanja projektaa, iznoseći ga sve dok ne dosegnete optimalni target. ## NUP4 Zapamti – lanac je jak onoliko koliko njegova najslabija karika [image] Postoje različiti domeni u projektaima svi oni zahtevaju pažnju; moramo imati holističku perspektivu projektaa. Obraćanje pažnje na naizgled važne domene (npr. vreme) nije dovoljno, jer svi domeni međusobno su zavisni (interaguju) i ne rade dobro dok ne dobiju adekvatnu pažnju. ### Primer: Sve je do rokova ! Recimo da gradite nešto za Olimpijske igre. Rok je izuzetno blizu, što daje na značaju domenu upravljanja vremenom. Da li je baš tako? Šta ako kvalitet nekih proizvoda projekta bude tako loš da je neophodno ponavljanje posle nekog vremena? To bi svakako uticalo na vreme, dakle važno je i vreme i kvalitet. Možda ste zamislili fantastičnu baštu u originalnoj definiciji projektaa, ali znajući da nemate dovoljno vremena, preskočićete kitnjaste detalje i samo prekriti travom, ukoliko ste na na vreme predvideli ovakvu situaciju i pripremili se za nju. Sve u svemu, i upravljanje scope-om je vrlo značajno. Da rezimiramo: u centru naše pažnje su sada scope, vreme i kvalitet. Čuli ste za poznat primer kada je predsednik SAD Kenedi sreo domara u NASA-i, pitajući ga čime se bavi? Odgovor je bio: “Pomažem da se čovek popne na Mesec”. Zar prisustvo ovakvog tipa ljudi u projektu ne pomaže ispunjavanju rokova? Ako bi nastavili tako dalje, primetili bi da svaki pojedinačni domen u projektu doprinosi upravljanju vremenom, i ne možete očekivati da ćete ispoštovati rokove sa prihvatljivim nivom izvesnosti, osim ako ne obratite pažnju na sve domene. ### Primer: Pristrasna (nekritička) selekcija Kada su ljudi suočeni sa širokom lepezom izbora (različiti metodi), ponekad biraju nekritički praveći miks svega što ima deluje interesantno iz različitih sistema. Ovo obično ne funkcioniše, jer elementi ne rade u izolaciji već moraju da su međusobno kompatibilni. Svi dodaci ili promene sistema treba raditi sa holističke tačke gledišta. Zbog toga ponekad vidimo kontradiktorne elemente u različitim metodama ; nešto radi dobro u jednom sistemu, a njegova suprotnost u drugom sistemu. Taj elemenat sam po sebi nije ni dobar ni loš – radi se o kontekstu korišćenja. Najsigurniji pristup: izaberi metodologiju za projekat, skroji je po potrebama projektaa, a onda oprezno dodaj nove elemente, stalno imajući na umu konzistentnost celog sistema. ### Primer: Anti-procesni pristup Jedna od najboljih stvari koje su Agile metodi ostvarili jeste ukazivanje na ljudske aspekte. Agile Manifest poklanja veću pažnju individuama i interakcijama nego procesima i alatima, iako ovo možda nije fer poređenje. Skoro sve metode će reći da su ljudski aspekti važni, a stvarna razlika sa Agile metodama je da su ljudski aspekti ugrađeni deo procesa, pre nego puka sugestija. Dakle, ne radi se o takmičenju između ljudskih aspekata i procesa, radi se o načinu na koji su ljudski aspekti viđeni od strane sistema. Nema sumnje da neki ljudi pokušavaju da zamene ljudske aspekte sofisticiranijim procesima, ali u pitanju je neadekvatna primena. Dešava se i suprotno: ljudi pokušavaju da zamene procese ljudskim aspektima, što takođe ne funkcioniše dobro. ### Primer: Ovo su svi domeni koji ti trebaju Razmišljajući o domenima, treba paziti da se ne ispusti nijedan od njih iz razmatranja. Ali šta su oni zapravo ? Proveravajući fundamentalne resurse, dobićemo različite odgovore; pa ipak nijedan ne sadrži punu istinu. PRINCE2^(®) “Teme” su domeni, ali to su samo domeni koju igraju ključnu ulogu u metodologiji. Ostali domeni se samo naslućuju. PMBOK^(®) Guide nije metodologija i može da formuliše to mnogo bolje pomoću 10 oblasti znanja. Ipak ovo su interpretacije domena zasnovane na pogledu PMBOK^(®) Guide na projektae, pre nego neutralna perspektiva (koja u suštini i ne postoji). Na primer, ljudski aspekti ne dobijaju mnogo pažnje u PMBOK^(®) Guide. Dobar izvor informacija o domenima je ICB. Ipak, ne radi se toliko o domenima koliko o potrebnim kompetencama za projekat. Ne postoji relacija jedan-na-jedan sa domenima, ali prilično pomaže u njihovoj identifikaciji. Nema liste domena u “NUPP”, primarno jer je u pitanju meta-sistem pre nego sistem, takođe i jer kategorizacija domena zavisi od tipa projekta i projektanog okruženja; npr. rutinski građevinski projekat možda zahteva drugu perspektivu od kreativnog istraživačkog projektaa. ## NUP5 Ne radi ništa bez jasne svrhe [image] Ne bi trebalo da radiš nešto osim ako nema jasnu svrhu. Zamisli dva paralelna sveta gde je sve isto osim toga što u jednom svetu razmišljaš o onome što radiš, a u drugom ne: koliko bi se razlikovala ta dva sveta? Da li je razlika vredna truda da se to (ne) uradi? Ako ti nije jasna svrha i radiš nešto samo zato što i svi ostali to rade, ili svako kaže da je važno da se to radi, onda: - Možda u tvom slučaju to nema stvaran benefit, pa stoga ne dobijaš ništa radeći to; ili - Možda u tvom slučaju ima potencijalne benefite, ali pošto ti nije jasna svrha, način na koji to budeš radio možda ti neće pomoći da ostvariš te benefite. ### Primer: Portfolija i programi Ako si uključen u izbor i inicijaciju projekata, fokusiraj se na benefite i probleme koji treba da se reše pre nego na proizvod koj treba da realizuje ove stvari. Klasičan primer je proizvođač liftova koji je primao žalbe na brzinu svojih liftova, pa je pokrenuo više projekata da bi popravio brzinu liftova, ali bez potpunog uspeha. Ovo se nastavljalo sve dok nisu odlučili da se fokusiraju na problem (dosađivanje ili nelagodnost u liftu) umesto “prirodnog” rešenja (bržih liftova). Rezultat je bio taj da su dodali ogledala u liftove i rešili problem jednostavno i jevtino. Zapamti da je za projektani menadžment uglavnom važno “raditi stvari na pravi način”, dok je za portfolio menadžment važno “raditi prave stvari”. Nije važno koliko dobro vodiš svojе projektae; neće dobro funkcionisati ukoliko radiš pogrešne projektae. Sve je u svrsi. ### Primer: Projekat kao celina Fleksibilnost proizvoda varira od projekta do projektaa. U nekim IT razvojnim projektaima, proizvod je potpuno fleksibilan i njegov finalni oblik zavisi od povratne informacije koje će uslediti nakon inkrementalnih faza proizvoda kroz projekat, što zahteva adaptivni (Agile) pristup. U praktičnom smislu ovo je kombinacija slojeva portfolija, programa i projekata i potreban je maksimum pažnje posvećen krajnjem cilju. Dobra ideja je dokumentovati svrhu i imati je uvek na dohvat ruke; to je jedna od svrha “vizije proizvoda”, kako se koristi u nekim Scrum projektaima. Akcenat na poslovnu vrednost u Agile projektaima je njegov način osiguranog usklađivanja sa svrhom. U drugim vrstama projektaa, gde je proizvod relativno fiksan i postoje drugi mehanizami kontrole da proizvod zadovolji svrhu, moguće je da članovi projektanog tima pomere fokus sa svrhe na proizvod (otuda princip “fokus na proizvode” PRINCE2^(®)), ali u najmanju ruku minimum pažnje posvećen svrsi je još uvek potreban da bi se obezbedilo da ono što se stvara služi svrsi, što se može ostvariti poređenjem predviđenih i očekivanih benefita (otuda princip “kontinualnog poslovnog pravdanja” i “business case” Tema u PRINCE2^(®)). Ako se projekat radi za eksternog klijenta, klijent želi svoju sopstvenu svrhu za projekat, a vaša kompanija će imati svoju svrhu. Potrebno je da razumete i koristite obe da bi stvarno uspeli. ### Primer: Monitoring projektaa Fokusiranje na krajnju svrhu je neophodno. Ali možda i previše apstraktno za većinu svakodnevnih primena. Za praktičnu primenu potrebno je uspostaviti hijerarhiju pokretača. Kao prvo, poslovno opravdanje i benefiti projekta definisani su shodno krajnjoj svrsi, a shodno njima eksplicitni i implicitni targeti za projektane varijable (tj. vreme, trošak, kvalitet) da bi se zadovoljilo poslovno opravdanje, što bi na kraju zadovoljilo krajnju svrhu. Ovo su svrhe nižeg nivoa koje su korisne za mnoge od naših dnevnih zadataka. Kada se radi o monitoringu, monitoring nižeg nivoa u projektu pratiće varijable niženg nivoa, jer možda neće biti moguće pratiti krajnju svrhu. U ovom slučaju, ne treba zaboraviti na svrhu: šta je svrha monitoringa? Normalan i prihvatljiv odgovor je videti da li dobro pratimo plan, ako ne, inicirati odgovarajuću reakciju koja će nas dovesti nazad na u okvire plana ili ponovo podesiti targete i videti da li konačna svrha još uvek može biti zadovoljena. Naša merenja stoga treba da nam pomognu oko ove svrhe nižeg nivoa, a odgovarajuća merenja su prognoze za projektane varijable na kraju projektaa; npr., kada ćemo moći da zavrišimo projekat? Koliko novca nam je potrebno da završimo projekat? Sva druga merenja, kao što su planirane i aktuelne vrednost na dan, samo su međuvrednosti koje su nam potrebne da bi kalkulisali prognozu, a ne konačne vrednosti za svrhe menadžmenta. ### Primer: Dokumenti Bez obzria koji development pristup koristimo u projektu, planiranje je uvek neophodno. Važno pitanje je nivo detalja u svakom tipu plana. Ako nema dovoljno detalja u planu, plan neće moći dovoljno da doprinese, a izvršavanje projekta zasnivaće se na ad-hoc odlukama pre nego na integrisanim, holističkim. Sa druge strane, puno ljudi pokušava da bude oprezno, pa dodaje previše detalja u plan, što ga čini teškim za pripremu i održavanje, i previše rigidnim za neizvesnosti u projektu. Kao rezultat, plan postaje nerealan i beskoristan. Najbolji način da se odluči o nivou detalja je imati svrhu na umu za svaki element u planu. Na primer, ako razmatraš dodavanje resursa u plan, to treba da ima svrhu: kako ćeš ga koristiti? Kako će to pomoći projektu? Koliko The best way to decide about the level of detail is to have a purpose in mind for every element in the plan. For example, if you’re considering the addition of resources to the plan, you should have a purpose for it: How are you going to use it? How will it help the project? Koliko napora će to proizvesti? I da li se isplati? Ponekad se radi o tome da li želiš neki element u svojim planovima, a nekad o načinu na koji planiraš i pripremaš nešto. Bilo da je business case, projektana povelja, ili izveštaj: uvek se pitaj zašto pripremaš taj dokument i kako može da pomogne projektu. Traženje raznih “template”-a po web-u je sušta suprotnost činjenja nečeg baziranog na svrsi. ### Primer: Statusno izveštavanje Česta je pojava predugih statusnih izveštaja u mnogim projektaima. Polazeći od ovog NUP-a, treba da se zapitamo koja je svrha izveštaja i kako je možemo postići bez obzira šta drugi rade po tom pitanju. Ovo nas u mnogo slučajeva može voditi ka pripremi veoma jednostavnih izveštaja na jednoj stranici koje će stakeholderi zaista čitati i razumeti, za razliku od dugih izveštaja. Ovo je poklanjanje pažnje svrsi. Ako pripremaš izveštaj od jedne strane, doduše neki ljudi mogu da i to zamere i misle da nemaš postavljen adekvatan monitoring sistem. U praksi, ovo kreira tebi sekundarnu svrhu (osim primarne, a to je pomoć stakeholderima da razumeju status projektaa), a da bi to zadovoljili, možete prosto kreirati drugi tip izveštaja koji će biti dugačak. Ipak, ne mešajte ova dva izveštaja, jer im je i svrha različitia. ### Primer: Business case i projektana povelja Pripreme dokumenata kao što je business case i projektana povelja obično je dosadna, jalova, birokratska neophodnost za većinu ljuid, dok svi ovi dokumenti imaju valjanu svrhu koja važi za većinu projekata. Ako pokušaš da pronađeš “template” i popuniš ga, vreme je protraćeno; umesto toga bolje je da proveriš pravu svrhu ovih dokumenata, vidiš da li i kako mogu biti od pomoći u projektu, a onda pripremiš dokument na način kako želiš, isključivo da zadovoljiš svrhu: to će onda biti pravi dokument. Dok razmišljaš o načinu pripreme dokumenata da bi zadovoljili svoju svrhu, možda nećeš imati na umu svaki scenario i zato nešto propustiti. Da bi to izbegao, proveri sve resurse, kao npr. PRINCE2^(®), PMBOK^(®) Guide, P3.express, I DSDM^(®) sugestije, i onda evaluiraj ove sugestije zasnovano na svrsi. ### Primer: Post-projekat Sve dok projekat ima specifičnu svrhu (a svrhu možemo preispitivati tokom projektaa) , realizacija svrhe uglavnom se vrednuje na osnovu prognoza nastalih tokom projektaa. Ipak, ne smemo da zaboravimo na to ni kad se projekat završi. Važno je proveriti realizaciju ciljeva nakon kraja projektaa, jer: - Možemo videti kako se postižu krajnji ciljevi i učiti iz toga za buduće projektae, i, - Ponekad se ciljevi ostvare samo ako se obave neki dodatni zadaci nakon projektaa, a za razumevanje neophodnosti ovih ekstra zadataka potreban je monitoring. Post-projektani monitoring je neophodan korak ako smo vođeni svrhom. Ovo je uglavnom odgovornost sistema za upravljanje progama i portfolia, a pošto većina kompanija nema takve nivoe menadžmenta, ovaj korak se obično zanemaruje. Zbog toga metodi kao P3.express and DSDM^(®) dodaju ovaj korak u svoje metodologije projektanog menadžmenta. ### Primer: Jednostavnost Svet je kompleksan i haotičan, ali naši modeli su apstraktne aproksimacije koje odražavaju delove sveta, pa su stoga jednostavne. Sa druge strane, jednostavni sistemi obično funkcionišu bolje, jer možemo da se fokusiramo na glavnu ideju. Mnogi od nas pokušavaju da dobiju bolje rezultate dodajući kompleksnost u sistem, nadajući se da će odslikati kompleksnost sveta, čak i ako u praksi ovo otežava rad sa sistemom i obično nas sprečava da zadovoljimo svrhu. ### Primer: Prilagođavanje – “krojenje” Softver za streaming muzike ima različite uslove od onog koji se koristi za opremu u bolnici ili u avionu gde od toga zavise ljudski životi, ili od softvera koji će se koristiti u satelitima gde treba da rade mnogo godina bez “pada sistema”. A svi pomenuti softverski projektai razlikuju se od izgradnje letnje vile, vatrogasne stanice, ili postrojenja za preradu. Ako imate svrhu na umu, bolje ćete razumeti kako prilagodite – “skrojite” sisteme i artefakte za različite projektae. ## NUP6 Koristi ponovljive elemente [image] Ad hoc pristup projektu uzima previse energije i resursa, a uvek postoji i rizik izostavljanja nekog od neophodnih elemenata. Najbolji način da se pojednostavi ono što treba da bude se uradi, jeste koristiti ponovljive elemente, i po mogućstvu koristiti ih u ponovljivim ciklusima. ### Primer: Ček-lista za kvalitet Ček-lista je jednostavan primer potencijalno ponovljivog elementa koji koristi većina ljudi u svom privatnom i profesionalnom životu. Uzmimo kriterijume za kvalitet isporučenog projektanog proizvoda, na primer: - Prvo, može kreirati ček-listu SVIH kriterijuma, što je forma planiranja. - NUP6 predlaže da pokušate da generalizujete: ima li sličnih isporučenih proizvoda u projektu? U tom slučaju, pripremite generalnu ček-listu za kvalitet , za tu KATEGORIJU isporučenog proizvoda i koristite je za sve njih. Ako bude nekih varijacija, držite se generičke liste, pa dodajte nekoliko ekstra stavki za pojedine isporučene proizvode. Eto ponovljivih ček-listi. - Čim ste pripremili generičku ček-listu za različite kategorije isporučenih projektanih proizvoda, možete naći ponavljajuće elemente među njima, što sugeriše virtualnu “roditeljsku” kategoriju. U tom slučaju, umesto da ponavljate stavke za sve generičke ček-liste. Možete ih izvaditi i staviti u „roditeljsku“ ček-listu. Na kraju ćete verovatno imati jednu generičku ček-listu za ceo projekat. “Definicija urađenog” u Scrum-u (“definition of done”) je primer korišćenja ček-lista za kvalitet na nivou projekta (između ostalog). Radeći ovo, svaki projektani proizvod će pripadati negde u hijerarhiji kategorija i trebaće pri proveri kvaliteta da zadovolji stavke koje se pojavljuju u ček-listama svih kategorija u njihovom lancu. Radeći ovo, Stavka u roditeljskoj ček-listi postaće ponovljiva za sve proizvode ispod nje, što štedi vreme i energiju u planiranju i izvršenju. Što je još važnije, kad ovo uradiš za jedan projekat, možeš je prilagoditi i koristiti za sve slične projektae ubuduće, što je ponovljivi oblik planiranja za više projekata. ### Primer: Procesi i tokovi rada Neki projektani proizvodi, ili ciljevi povezani sa njima, iziskuju određene korake koji mogu postati standardizovani i ponovljivi. Na primer, ako projektani proizvodi treba da se dizajniraju i odobravaju individualno , možete pripremiti jednostavan “workflow” koji jasno prikazuje sve korake, uključene osobe, i približna trajanja, time izbegavajući mnoge poteškoće. Ipak treba paziti ne učiniti procese previse komplikovanim ili previse intenzivnim pri dokumentovanju, jer će imati negativne posledice. Svi ljudi uključeni u projekat treba da shvate procese i tokove rada kao nešto što podupire i olakšava njihov rad, a ne kao birokratsko dokumentovanje koje blokira praktičan rad. Agilni projektai imaju ponovljive elemente u svom pristupu iterativnog razvoja, pri čemu se određen tip razvojnih aktivnosti ponavlja za svaku karakteristiku proizvoda (feature); npr. ista dnevna rutina u XP (eXtremno Programiranje):e.g. the common daily routine in XP (eXtreme Programming): upariti, uzeti stavku, dizajnirati je na beloj tabli, napraviti testne skripte i kod, integrisati kod, itd… Osim ponovljivih procesa rada koji se koriste za tehničke aktivnosti, možemo imati ponovljive elemente i za aktivnosti projeknog menadžmenta. Procesi u PMBOK^(®) Guide, PRINCE2^(®), i DSDM^(®), aktivnosti u P3.express, i događaji u Scrum su primeri ovog koncepta. ### Primer: Ciklusi Imati ponovljive elemente za upravljanje projektaom je od pomoći. Ovo može biti još lakše stavljajući ih u ponovljive cikluse. Ovi ciklusi značajno uprošćavaju svakodnevne aktivnosti ljudi uključenih u menadžment i vođstvo projektaa. Ciklusi procesnih grupa u PMBOK^(®) Guide kada se koriste u projektu u više faza, faze (stages) u PRINCE2^(®), dnevni, nedeljni, i mesečni ciklusi u P3.express, iteracije i vremenske kutije u DSDM^(®), kao i Sprintovi u Scrum-u, sve su primeri ovog koncepta. Kraći cikulsi su lakši za razumevanje i upotrebu nego duži; npr. Sprintovi u Scrum-u nasuprot fazama po PMBOK^(®) Guide. Ipak, prekratki ciklusi možda neće biti dovoljni da iznesu određene tipove projekata, a rešenje može biti upotreba višestrukih ciklusa, kao što je u DSDM^(®) upotreba kratkih ciklusa “vremenske kutije” u kombinaciji sa dužim iterativnim ciklusima, ili korišćenje dnevnih, nedeljnih i mesečnih ciklus u P3.express. ### Primer: Metode Korišćenje metodologije ili framework-a za vođenje projekta je još jedan slučaj korišćenja ponovljivih elemenata. Ovo može biti postojeći sistem kao što je PRINCE2^(®), P3.express, DSDM^(®), ili Scrum, ili system koji ste prilagodili ili sami izmislili. Normalno, za početak je bolja ideja startovati sa nekim od postojećih metoda i prilagoditi je svojim potrebama, nego napraviti jednu “od nule”. Svaki ponovljivi element je apstraktan i iziskuje kastomizaciju da bi ga prilagodili stvarnom svetu. Postoji spektar apstrakcije i potrebe za kastomizacijom, doduše: male, relativno fiksne ček-liste kvaliteta stoje na jednom kraju spektra sa malom količinom apstrakcije I potrebe za prekrajanjem, dok su metodologije na drugom kraju, sa visokom potrebom za prekrajanje. Treba uvek primetiti potrebu za prekrajanjem, u suprotnom ponovljivi element neće odggovarati vašim potrebama na potreban način.