# NUPP Nearly Universal Principles of Projects [image] Ez az online kézikönyv letölthető változata (https://omimo.org/hu/modules/nupp/), amely 2026‑07‑02 dátummal készült. Az újabb verziókért látogassa meg a weboldalt. A NUPP az OMIMO (https://omimo.org/hu/) projekt része, amely nyílt és minimalista modulok családja. Ez a kézikönyv szabadon használható és terjeszthető a Creative Commons Nevezd meg! 4.0 Nemzetközi (Attribution 4.0 International) licenc feltételei szerint. Az OMIMO az Európai Unió társfinanszírozásával valósul meg. A megfogalmazott nézetek és vélemények azonban kizárólag az OMIMO álláspontját tükrözik, és nem feltétlenül egyeznek meg az Európai Unió vagy az EPOS VZW nézeteivel. Ezekért sem az Európai Unió, sem a támogatást nyújtó hatóság nem vonható felelősségre. Fordította: Schwarz Vilmos ## Bevezetés A NUPP a projektek közel univerzális alapelveinek gyűjteménye: a legjobb lenne, ha minden projektben követnénk ezeket, függetlenül az általunk használt módszertanoktól és megközelítésektől, hogy maximalizáljuk azok sikerét. A projektek lebonyolításához rendelkezésre álló erőforrások és módszerek mindegyike ezen NUP-ok (közel univerzális alapelvek) némelyikén alapul. A következő pontokat azonban szem előtt kell tartani: - Általában nem minden (ezeken alapszik), de a gyakorló szakemberek számára hasznos lenne, ha az összes NUP-ot figyelembe vennénk, nem csak a NUP-ok egy részhalmazát. - A mögöttes alapelvek általában nem elég világosak a forrásokban és a módszerekben. A legtöbb gyakorló annyira elmélyed a gyakorlati részletekben, hogy megfeledkezik az elvekről, és olyan dolgokat tesz, amelyek nem kompatibilisek ezekkel az alapelvekkel. A NUPP kompatibilis az összes főbb módszerrel, rendszerrel, erőforrással és keretrendszerrel, mint például a PRINCE2^(®), PMBOK^(®) Guide, P3.express, PM², DSDM^(®), XP és Scrum. Előfordulhat azonban, hogy nem kompatibilis ezeknek a rendszereknek bizonyos értelmezéseivel. A NUPP éppen ezért arra próbálja ösztönözni a szakembereket, hogy gondolják át értelmezéseiket. A NUPP a következő NUP-ok gyűjteménye: - NUP1 — Az eredményeket és az igazságot részesítsd előnyben - NUP2 — Őrizd meg és optimalizáld az energiádat és az erőforrásaidat - NUP3 — Legyél mindig proaktív - NUP4 — Ne felejtsd, hogy egy lánc csak annyira erős, mint a leggyengébb láncszeme - NUP5 — Ne csinálj semmit nyilvánvaló ok nélkül - NUP6 — Használj megismételhető elemeket ## NUP1 Az eredményeket és az igazságot részesítsd előnyben [image] Mindannyiunkban megvan a csoportokhoz való tartozás természetes igénye. Ez a hajlam gyakran túlmutat az alapformáján, erős hovatartozást hoz létre, és ez problémákat okozhat. Sokkal többet veszítünk, mint amennyit nyerünk a kötődés miatt. Szakszerűbb és hatékonyabb szakértőkké válhatunk, ha nem korlátozzuk identitásunkat és preferenciáinkat bizonyos csoportokra. ### Példa: Agilis vs vízesés Egy nagyon lelkes csoport, akik elég bátrak voltak ahhoz, hogy kipróbálják az adaptív fejlesztési megközelítést az informatikai fejlesztésekben abban az időben, amikor a prediktív megközelítés használata volt jellemző, összegyűltek és “Agilis”-nak nevezték el a megközelítésüket. Ez egy nagyszerű kezdeményezés volt, hogy ne korlátozzuk a választási lehetőségeket arra, ami akkor szükségesnek tűnt. Még mindig sok lelkes és eredményorientált ember van az Agilis közösségben, de sajnos vannak olyanok is, akik az Agilitást kultusszá teszik, és minden kívülállót ellenségnek tekintenek. Ez több szempontból is problémákat okoz, beleértve a következőket: - Nem engedi, hogy a csoportjukon kívüliektől tanuljanak - Elveszi a kívülállók kedvét attól, hogy tanuljanak tőlük - Fontosabbá teszi a csoporthoz tartozást, mint a valódi célt, ami viszont sok tagot megakadályoz abban, hogy megtanulják az Agilitás valódi jelentését Ez a probléma jelentősen csökkenthető, ha nem is szüntethető meg, ha az “Agile”-t csak olyan címkeként használjuk, amely inkább a fejlesztési megközelítésre utal, nem pedig a tagokból álló közösségre. Illetve azáltal, hogy akik alkotónak, problémamegoldónak és vezetőnek tartják magukat, az Agile-t egyszerűen egy opciónak tekintik, nem pedig identitásuknak. Az igazi profik számára nincs agilis-vízesés háború. ### Példa: PRINCE2^(®) vs PMBOK^(®) Guide A közösségben sok olyan szakember van, aki a PRINCE2^(®)-hoz, vagy a PMBOK^(®) Guide-hoz köti magát (általában földrajzi helyzete miatt), és nem ismeri a másikat. Mindannyian preferálhatunk bizonyos erőforrásokat, de nem tekinthetünk rájuk identitásként, és ami még fontosabb, mindegyiket meg kell ismernünk, hogy kiszélesítsük perspektívánkat és választási lehetőségeinket. Az igazi szakember nyitott minden ötletre, keresi, megismeri, és szükség szerint, kötődés nélkül használja. ### Példa: Folyamatos tanulás A kötődés kielégíti az embert az általuk kiváltott összetartozás érzése miatt, de nem készteti megismerésre. Sőt néha távol is tartja a veszteségtől való félelem miatt. Ha szabad ember vagy, egy szakértő kötődések nélkül, akkor az esetleges hiányosságokat tanulással kell pótolnod: folyamatos tanulással. Amiben ma hiszünk, az nem az igazság. Ez csupán az eddigi legjobb megértésünk, amelyet tovább kell fejleszteni. Azzal valami baj van, ha valakinek az elképzelései pontosan ugyanazok, mint néhány évvel ezelőtt. Ez még a NUPP esetében is így van: ha néhány év múlva visszatérsz, és pontosan ugyanazt látod, akkor gyanakodnod kell. ### Példa: Nyitottság Amikor kifogásolsz valamit, ügyelj arra, hogy a kifogásod az ötletre irányuljon, és ne a személyre. Ez segít megelőzni a feszültséget. Hasonló módon, ha valaki kifogást emel ellened vagy rólad, próbáld meg ezt ne az ellened való támadásként értelmezni, hanem inkább az elképzeléseid megvitatásaként, és maradj nyitott ezekre. Ne azért figyelj, hogy válaszolj, hanem azért figyelj, hogy megérts; és dolgozz együtt a másik személlyel az ötlet javításán. Előfordulhat, hogy egyesek szándékosan Téged céloznak meg az ötlet helyett, ebben az esetben segíts nekik az ötletre összpontosítani, nem pedig Rád, mielőtt folytatnád. Próbáld meg ezt a beszélgetés során végig ebben a mederben tartani. ## NUP2 Őrizd meg és optimalizáld az energiádat és az erőforrásaidat [image] Az erőforrások korlátozottak. A projekt rendelkezésére álló erőforrások korlátozottak, csakúgy, mint a jó döntések meghozatalához szükséges mentális energia. Meg kell őrizned és optimalizálnod kell ezt az erőforrást saját magad és a projekt számára, és segítened kell a csapat többi tagjának is ebben. ### Példa: A 80/20 szabály A projektmenedzsment lehetséges eredményeinek nagy része elérhető az erőfeszítések egy kis részének felhasználásával. A legtöbb esetben a lehetséges eredmények 100%-ának megcélzása nagyon költséges és indokolatlan. Ezt a szabályt minden tevékenységében figyelembe kell venned, és másokat is erre kell ösztönöznöd. ### Példa: Döntési kimerültség Egyetlen mentális energiaforrást használunk mindenféle döntés meghozatalára, és az akaraterő kifejezésére is. Ha ebből a forrásból túl sokat használunk fel szükségtelen vagy lényegtelen döntések meghozatalára, kevesebb energiánk lesz a fontos döntésekre, ami gyenge eredményekhez vezethet. Ez az egyik oka annak, hogy kerülnünk kell a mikro-menedzsmentet (jó példa ennek elkerülésére a PRINCE2^(®) „kivételkezelés” elve). Az ötletekkel kapcsolatos konfliktusok hasznosak lehetnek, de azok, amelyek emberekről szólnak, általában károsak a projektre, és ennek egyik következménye az, hogy kiszívja a csapattagok mentális energiáját. Ha ilyen konfliktust észlelsz, mindent meg kell tenned annak érdekében, hogy megtaláld a kiváltó okot és azután feloldjad azt. ### Példa: Törődj magaddal! A meghozott döntések és az általad kifejezett akaraterő elhasználja mentális energiaforrásaidat. Ugyanakkor ez a forrás tele van energiával, ha megfelelően alszol és étkezel. Tehát nagyon vigyázz magadra: aludj, pihenj eleget, és étkezz helyesen. Ha káros szokásaid vagy problémáid vannak az alvással, nem kell egyedül megbirkóznod vele; sok szakember tud segíteni az ilyen helyzetek megoldásában. A fizikai aktivitás szintén segíthet az energiaforrások karbantartásában, bár a tanulmányok még nem meggyőzőek ebben a kérdésben. Próbáld ösztönözni a csapat tagjait, hogy ugyanazt tegyék, mint Te. Először is győződj meg arról, hogy fenntartható ütemben és nem túlzottan sok túlórával dolgoznak. Ezután, ha van lehetőséged, próbálj energikus, egészséges ételeket, harapnivalókat és italokat kínálni munkaidőben. ### Példa: Munka és magánélet egyensúlya Sokan szeretjük, amit csinálunk, de ez még mindig nem minden, amire az életben szükségünk van. Ugyanúgy, ahogy optimalizálod a munkádat, a magánéletedet is meg kell tervezned és meg kell valósítanod az ötleteidet, hogy az örömteli és boldog legyen. Ha boldogabb vagy, a munkában is sikeresebb lehetsz. Ha teheted, próbáld ösztönözni a csapattagokat is, hogy tegyék ugyanezt. ### Példa: Motiváció A motiváció összetett fogalom. Van néhány érdekes és hasznos forrás a témában, és számos nem igazán tudományos is. Ennek ellenére érdemes megismerni és folyamatosan használni, mert növeli a csapat mentális energiáját és a projektek jobb eredményének lehetőségét. A motiváció lehet olyan egyszerű, hogy egy kedves mosollyal vagy egy egyszerű „köszönöm”-mel tudatod az emberekkel, hogy elismered a munkájukat. Azonban óvatosnak kell lenned, mert a motiváció számos elterjedt formájának, például a kis pénzjutalmaknak negatív hatása van. ### Példa: Együttműködés és csapatmunka Az együttműködő emberek néha képesek jobb eredményeket elérni, de ami még fontosabb, az ember egy társas lény és élvezi, hogy egy csoporthoz tartozhat. Ha sikerül eltávolítani a csapatmunka negatív aspektusait, és kellemes környezetet teremteni, boldogabb csapattagok lesznek a projektben. Óvatosnak kell lenni azonban, mert az emberek különbözőek, és egyeseknek több pihenésre, összpontosításra és magányra van szükségük, mint másoknak; ez általában egy kiegyensúlyozási kérdés. ### Példa: Az egy-csapat kultúra A különböző érdekelt felek hajlamosak arra, hogy alcsoportokat alakítsanak ki, és feszültséget generáljanak más csoportokkal; például azok az emberek, akik a projekt üzleti vonatkozásaira összpontosítanak, szemben azokkal, akik a terméket építik. Ez a feszültség rengeteg energiát emészt fel mindkét oldalról, többek között ezért is érdemes az egy-csapat kultúrát kiépíteni, ahol mindenki közösen dolgozik ugyanazon cél érdekében. ### Példa: A tömeg bölcsessége Ha egy sokszínű embercsoport összegyűlik és facilitált környezetben dolgozik, akkor ez a csoport nagyon jó eredményeket, ötleteket és megoldásokat elérhet el, amelyek még annál is jobbak lehetnek, mint azok, amelyek egyetlen szakértőtől származnak. Ha megvan a lehetőséged, rendszeresen kérd meg a csapat tagjait, hogy segítsenek megoldani a projekt során felmerülő nagyobb problémákat. Amellett, hogy jó eredményeket érhetsz így el, azt is közvetítheted a csapattagok felé, hogy véleményüket értékelik, és fontos szerepet játszanak a projektben, ami pedig az energiaszintjük növekedését eredményezi. A P3.express E02. tevékenysége egy jó példa a tömeg bölcsességének projektekben való alkalmazására. ### Példa: A projekt fő-facilitátora Ha egy projektmenedzser vagy, akkor a legtöbb tevékenység, amit végzel, facilitációs jellegű (vagy legalábbis annak kellene lennie). Esetleg tapasztalhatod azt is, hogy a csapattagoknak rossz élményeik vannak korábbról a projektmenedzserekkel, és ezek a tapasztalatok hatással vannak az Veled való kapcsolatukra. Ennek következményeként az energiájuk egy részét arra fordítják, hogy elemezzék a viselkedésedet potenciális fenyegetéseket kutatva, ahelyett, hogy bíznának Benned. Ebben az esetben változtasd meg a beosztását projektmenedzserről a projekt fő-facilitátorává. Végül is ez az, amit valójában csinálsz a projektben. ## NUP3 Legyél mindig proaktív [image] Természetes hajlamunk van arra, hogy reaktívak legyünk. Ez segíthet megőrizni az energiánkat a lényegtelen ügyek kezelésében, vagy jobb végkifejletet eredményezhet, ha olyasmivel foglalkozunk, amiben teljesen inkompetensek vagyunk. Ezek a helyzetek eltérnek a mi projektjeinktől. Itt proaktív módon érhetünk el jobb eredményeket. ### Példa: Tervezés Ha új helyre szeretnél autózni, és késésben vagy, akár azonnal megkezdheted a vezetést, hogy “időt takaríts meg”, és az esetleges problémákat majd akkor kezeled, amikor azok felmerülnek. A proaktív megközelítés az, hogy már a tevékenységek elején szánunk egy kis időt, és úgy állítjuk be a navigációs rendszert, hogy a forgalom és az esetleges balesetek és dugók alapján a leggyorsabb útvonalat adja meg. Ezután indulunk el. Ez egy kis időráfordítást jelent a végrehajtás előtt, amelynek segítségével elkerülhetők a későbbi problémák, és így időt takaríthatunk meg. Ellentétben azzal, amit egyesek az Agilis projektekről gondolnak, a tervezés mindig szükséges, és ez csak a tervek típusában és részleteiben tér el. A végrehajtás előtti tervezés a proaktív megközelítés. Emlékezz az idézetre: adj hat órát, hogy kivágjak egy fát, és az első négyet a fejsze élezésével töltöm. Ha ez egy prediktív projekt, akkor 4 órát tölthetsz a fejszéd élezésével, mert biztos vagy abban, hogy egy fát fogsz kivágni. Egy Agilis projektben nem lehetsz biztos abban, hogy fát fogsz kivágni, letört ágakat fogsz összegyűjteni, gyepet fogsz gondozni, szenet fogsz bányászni vagy valami mást. Mindazonáltal ebben az esetben is szükség van egy általános felkészülésre (tudnod kell, hogy hol van a legközelebbi szerszámüzlet), és egy konkrét előkészületre (élezésre), ami után egy bizonyos megoldásra fogsz koncentrálni. Ez a tervezés. ### Példa: A tervezés tervezése A projekt végrehajtásának megtervezése egy proaktív megközelítés. Ez a proaktivitás akár ki is terjeszthető, ha megtervezzük a végrehajtás megtervezésének módját is. Ezt teszik a PMBOK^(®) Guide menedzsment terv koncepciója, a PRINCE2^(®) menedzsment stratégiái és a DSDM^(®) megközelítései. ### Példa: Folyamatos tervezés A valóság ritkán egyezik meg azzal, amit elterveztünk, és ez így rendben is van – de folyamatosan módosítanunk kell terveinket, hogy azok reálisak és praktikusak maradjanak. Ezt azonnal meg kell tennünk, amikor alkalmazkodásra van szükség, és nem akkor, amikor problémákba ütközünk. Ez egy proaktív megközelítés. ### Példa: Kockázatkezelés A kockázatkezelés teljes koncepciója a proaktivitáson alapul: amikor bizonytalan eseményekkel nézünk szembe, ahelyett, hogy megvárnánk, hogy mi történik, majd reagálunk rájuk, átgondoljuk a lehetőségeket és a hatásokat, megfontoljuk a válaszokat, és valószínűleg teszünk is valamit, mielőtt megtörténne. Vedd figyelembe, hogy amit a projektekben csinálunk, az komoly; néha az emberek életéről van szó. ### Példa: Meghatározott szerepek és felelősségek Hagyhatod a projektcsapat tagjait, hogy egyértelmű szerepek és felelősségek nélkül dolgozzanak, és előbb-utóbb megjelenik a szerepek és felelősségek egy formája, de ez túl költséges, és nem biztos, hogy jól működik. A proaktív megközelítés az, hogy ezeket korán meghatározzuk és szükség szerint módosítjuk. Ez mindenki számára megkönnyíti a munkát, és ahelyett, hogy eldöntenék, ki mit csináljon, az alkotásra összpontosíthatnak. A szerepek száma és változatossága a projekt típusától és méretétől függ; ez lehet egy egyszerű definíció, mint például a Scrumban, lehet mérsékelt, mint például a P3.expressben, vagy valami átfogó, mint a DSDM^(®)-ben és a PRINCE2^(®)-ban. Ne felejtsd el azonban, hogy ezekben a módszerekben a szerepleírások csak a vezetési tevékenységekre vonatkoznak. Mindig hozzá kell adnod a szerepleírásokat a technikai tevékenységekhez is. ### Példa: Döntési lehetőségek Törölni vagy folytatni kell a projektet? Ritkán fordul elő, hogy csak két lehetőség van, még akkor is, ha a kérdésből ez következik. Proaktív megközelítést kell alkalmaznod, és mérlegelned kell minden választását, mielőtt döntést hozol. Módosíthatod a projekt hatókörét; szüneteltetheted, amíg valami más nem tisztázódik; vagy esetleg megváltoztathatod a projekt megvalósításának módját (pl. kiszervezés) stb. ### Példa: Kritikus gondolkodás Mindannyiunknak számos előítélete van, amelyek egyrészt segítenek túlélni, másrészt rossz döntések irányába befolyásolnak bennünket. A projekttel kapcsolatos fontos döntések meghozatalakor a legjobb, ha egy kis szünetet tartunk, és mérlegelünk minden olyan torzítást, amely befolyásolhatja döntésünket, mielőtt problémákat okozna. Referenciaként használhatod a megerősítési torzítások listáját a Wikipédiában. Léteznek döntéshozatali keretrendszerek is, amelyek segítségével jobb döntéseket hozhatsz. Eleinte zavaró, sőt bosszantó lehet a használatuk, de hamarosan megszokod őket, és különösebb erőfeszítés nélkül alkalmazod majd ezeket. ### Példa: Átláthatóság Nem szeretünk késni a projektben, vagy bármilyen más problémába ütközni, de ez nem jelenti azt, hogy ezeket el kell titkolnunk. Legyél átlátható, és tájékoztasd az érintett feleket, mert lehet, hogy néhányan segíthetnek majd Neked. Előbb-utóbb amúgy is értesülnek a problémákról és azok következményeiről ők is. Ráadásul előfordulhat olyan, akinél korai intézkedésre lesz szükség (pl. a negatív következmények elfogadása). ### Példa: Hatékony kommunikáció Gyakran előfordulhat, hogy riportot küldesz az érintett feleknek, akik nem adnak semmilyen visszajelzést. Ilyen esteben hiheted azt, hogy minden rendben van csak azért, mert nincs negatív visszajelzés, bár lehet, hogy ez nem így van. Proaktívnak kell lenned, és ellenőrizned kell, hogy valóban tudomásuk van-e a riportban szereplő információról, és hogy az megfelelt-e a célnak. Használd fel a válaszokat a kommunikációs módszereid finomítására. Ellenkező esetben ez a rejtett probléma komoly fejfájást okozhat később, amikor már túl nehéz lesz javítani. ### Példa: Felelősség vállalás Könnyű másokat hibáztatni a rossz eredményekért. Például előfordulhat, hogy a szervezettől teljes felhatalmazást kérsz, hogy mindent megváltoztathass a projektben, és tökéletesen végezd a munkádat, de nem kapod meg, és ennek eredményeként a projekt meghiúsul. Ez nem proaktív megközelítés. A proaktív megközelítés a felelősségvállalás és ha mindent megteszel a korlátokon belül. Nem várhatod el a szervezettől, hogy teljes mértékben megbízzon benned, és mindent megadjon a jó eredmények reményében, különösen akkor, ha már sok sikertelen projektet láttak. Ilyen esetben azt teheted, hogy egy kis fejlesztést végzel a meghatározott korlátokon belül, és ezt egy kis bizalom megszerzésére használod fel. Például egy kicsit több erőforrásra és tűrőképességre a korlátokkal szemben. Majd ezt felhasználd egy kicsit nagyobb fejlesztésre, és így tovább, amíg el nem éred az optimális célt. ## NUP4 Ne felejtsd, hogy egy lánc csak annyira erős, mint a leggyengébb láncszeme [image] A projekteknek különféle területei vannak és mindegyikre oda kell figyelnünk, holisztikus perspektívából kell a projektekre tekintenünk. Nem elegendő csak egyetlen fontosabb tartományra (pl. az időre) figyelni, mert mindegyik tartomány kölcsönhatásban van a többivel. Nem működnek megfelelően, hacsak nem kap minden terület megfelelő figyelmet. ### Példa: Minden a határidőről szól! Tegyük fel, hogy építesz valamit az olimpiai játékokra. Ez egy nagyon kötött határidővel rendelkezik, ami nagyon fontossá teszi az időgazdálkodást. De igaz mindez? Mi van akkor, ha a minőség olyan alacsony lesz, hogy egy idő után meg kell ismételni az egész munkát. Ez hatással lenne az időre, tehát ez idő és minőség kérdéssé alakítja a problémát. Lehet, hogy van egy látványos kerted, amely a projekt eredeti leírásában szerepel, de tudod, hogy ha nincs elég idő rá, ezért egyszerűen kihagyhatod ezt az elemet, helyette fűvel boríthatod a területet, feltéve, hogy időben átgondoltad ezt a lehetőséget, és felkészültél rá. Tehát a hatókör menedzsmentje is fontos. Most a hatókör, az idő és a minőségi tartományok állnak a figyelmünk középpontjában. Hallottál már arról a híres példáról, amikor Kennedy elnök találkozik egy házmesterrel a NASA-ban, és megkérdezi tőle, hogy mit csinál, ő pedig azt válaszolja: “Segítek feltenni egy embert a Holdra”? Nem segít betartani a határidőt, ha ilyen típusú emberek vesznek részt a projektben? Ahogy továbbhaladsz, észreveszed majd, hogy a projekt minden egyes tartománya hozzájárul az időgazdálkodáshoz, és nem tudod elfogadható bizonyossággal betartani a határidőt, hacsak nem figyelsz minden területre. ### Példa: Szemezgetés Amikor az emberek sokféle módszerrel szembesülnek, néha elkezdenek szemezgetni, ezután összeszedik és összevegyítik mindazt, amit érdekesnek találnak a különböző rendszerekben. Ez általában nem működik, mert az elemek nem működnek elszigetelten, és kompatibilisnek kell lenniük egymással. A rendszer minden kiegészítését vagy módosítását holisztikus szempontból kell végrehajtani. Ezért látunk olykor egymásnak ellentmondó elemeket a különböző módszerekben; valami jól működik az egyik rendszerben, és az ellenkezője jól működik egy másik rendszerben. Ez az elem önmagában nem jó vagy rossz. A legbiztosabb megközelítés, ha kiválasztunk egy módszertant a projekthez, testreszabjuk, majd óvatosan új elemekkel egészítjük ki, figyelembe véve a teljes rendszer konzisztenciáját. ### Példa: A folyamatellenes megközelítés Az egyik legjobb dolog, amit az Agilis módszerek tettek, hogy kiemelt figyelmet szentelnek az emberi szempontokra. Az Agilis Kiáltvány több értéket ad az egyéneknek és az interakcióknak a folyamatokhoz és eszközökhöz képest, bár ez nem biztos, hogy tisztességes összehasonlítás. Szinte minden módszer azt mondja, hogy az emberi szempontok fontosak, és az igazi különbség az Agilis módszerekhez képest az, hogy az emberi szempontok a folyamatok szerves részei, nem pedig egyszerű javaslatok. Tehát nem az emberi szempontok és a folyamatok közötti versengésről van szó, hanem arról, hogyan jelennek meg az emberi szempontokat a rendszerben. Kétségtelen, hogy néhányan megpróbálják kifinomultabb eljárásokkal helyettesíteni az emberi szempontokat, de ez egy hibás megközelítés. Ennek az ellenkezője is létezik: néhányan megpróbálják emberi szempontokkal helyettesíteni a folyamatokat, ami szintén nem működik jól. ### Példa: Ez az összes tartomány, amire szükséged van Amikor a tartományokra gondolsz, ne feledkezz el egyikről sem. De melyek ezek? Ha megvizsgálod az alapvető szakirodalmi forrásokat, különböző válaszokat fogsz kapni, de egyik sem fedi a teljes igazságot. A PRINCE2^(®) témák tartományok, de ezek csak azok a tartományok, amelyek kulcsszerepet játszanak a módszertanban. A többi tartomány csak hallgatólagos. A PMBOK^(®) egy útmutató nem módszertan, és a tíz tudásterülettel sokkal jobban megfogalmazható. Ezek azonban csak a tartományok értelmezései a PMBOK^(®) Guide projektekre vonatkozó nézőpontja alapján, és nem pedig semlegesen (nem mintha szükségszerűen lenne semleges perspektíva). Például az emberi szempontok nem kapnak nagy figyelmet a PMBOK^(®) Guide-ban. A tartományokkal kapcsolatos jó információforrás az ICB. Ez azonban nem a tartományokról szól, hanem a projektben szükséges kompetenciákról. Nincs közvetlen kapcsolata a tartományokkal, de sokat segít a beazonosításukban. A NUPP-ben nincs tartománylista, elsősorban azért, mert ez egy metarendszer, nem pedig rendszer, valamint azért is, mert a tartományok kategorizálása a projekt típusától és környezetétől függ; Például egy rutin építési projektnek más nézőpontra lehet szüksége, mint egy kreatív kutatási projektnek. ## NUP5 Ne csinálj semmit nyilvánvaló ok nélkül [image] Ne tegyél semmit, hacsak nincs egyértelmű célja. Képzelj el két párhuzamos világot, ahol minden ugyanaz, kivéve azt a dolgot, amit éppen fontolgatsz: Mennyiben lennének mások ezek a világok? Megéri ez a különbség az erőfeszítést? Ha nincs világos célod, és csak azért csinálsz valamit, mert mindenki más csinálja, vagy mindenki azt mondja, hogy fontos, - nem biztos, hogy valódi haszna van a Te esetedben, és ezért lehet, hogy nem kapsz belőle semmit; vagy - előfordulhat, hogy a Te esetedben még mindig vannak potenciális előnyei, de mivel nem a célt tartod szem előtt, nem ismered fel az esetleges előnyöket. ### Példa: Portfóliók és programok Ha részt veszel a projektek kiválasztásában és kezdeményezésében, az előnyökre és a megoldandó problémákra összpontosíts, nem pedig arra a termékre, amely ezeket a dolgokat megvalósítja. A klasszikus példa a felvonók gyártója, akik korábban panaszokat kaptak felvonóik sebességével kapcsolatban, így több projektet is végrehajtottak a sebesség növelésére, bármiféle siker nélkül. Ez addig folytatódott, amíg úgy döntöttek, hogy a problémára (az emberek unalmára vagy kényelmetlenségére) összpontosítanak a “természetes” megoldás (gyorsabb liftek) helyett. Az eredmény az volt, hogy tükrökkel szerelték fel a lifteket, és ez egyszerűen és olcsón megoldotta a problémát. Ne felejtsd, hogy a projektmenedzsment főként a dolgok helyes elvégzéséről szól, míg a portfóliókezelés a helyes dolgokról. Nem számít, milyen jól vezeted a projektjeidet; nem fognak jól működni, ha nem a megfelelő projekteket csinálod. Az egész arról szól, hogy legyen egy cél. ### Példa: A projekt egésze A végtermék rugalmassága projektenként változó. Egyes informatikai fejlesztési projektekben a termék teljesen rugalmas, és a végleges formája attól függ, hogy a projekt során milyen visszajelzések érkeznek a termék korai verzióira. Ez egy adaptív (Agilis) megközelítést igényel, ami a gyakorlatban a portfólió, a program és a projekt rétegeinek kombinációja, és a végső célra való maximális figyelmet igényel. Ajánlott a célt dokumentálni és mindenki számára hozzáférhetővé tenni. Ez a “termék vízió” egyik célja az egyes Scrum projektekben. Az Agilis projektekben az üzleti értékre való figyelemmel a végcélhoz való igazodást biztosítják. Más típusú projekteknél, ahol a termék viszonylag rögzített, és más mechanizmusok is biztosítják, hogy az azonosított termék megfeleljen a célnak, a projektcsapat tagjai gyakran a fókuszuk nagy részét a célról a termékre helyezik át (innen ered a PRINCE2^(®) “fókuszálás a termékekre” alapelve). De az továbbra is szükséges, hogy a célt legalább minimális mértékben, de szem előtt tartsuk, hogy az épülő termék megfeleljen ennek a célnak, ami az előrejelzett termékelőnyök és a várható haszon összehasonlításával valósítható meg (mint a “folytatásos üzleti indoklás” elve és az “üzleti eset” témák a PRINCE2^(®)-ben). Ha egy projektet egy külső ügyfél számára készítenek, akkor az ügyfélnek lesz egy saját, a Te cégednek pedig egy másik célja ezzel. Mindkettőt értened és használnod kell a valódi siker eléréséhez. ### Példa: Projekt monitoring Szükséges a végső célra való összpontosítás, de ez esetleg túlságosan elvont lehet a mindennapi használathoz. Ezért van szükség az egyes mozgatórugók hierarchiájára, amely egy gyakorlatiasabb képet mutat a projektről. Először is a projekt indokoltságát és előnyeit a végső cél alapján kell meghatároznunk, majd explicit és implicit célokat kell kitűznünk az egyes projektváltozókra (pl. idő, költség és minőség) úgy, hogy azok kielégítsék az projekt indoklást, ami viszont így kielégíti a projektcélt. Ezek a projektváltozókra irányuló alacsonyabb szintű célok, amelyek számos napi feladatunknál hasznosak. Ami a monitoringot illeti, a projekt alacsony szintű monitorozása a legalacsonyabb szintű változók felhasználásával történik, mert előfordulhat, hogy nem lehet nyomon követni a végső célt. Ebben az esetben ezeket az alacsonyabb szintű célokat kell szem előtt tartanod. Mi a monitorozás célja? A normális és elfogadható válasz az, hogy megnézzük, jó úton járunk-e, és ha nem, akkor kiváltunk egy bizonyos reakciót, amely visszavezet minket a helyes útra, vagy módosítjuk a célokat, és megnézzük, hogy ez még mindig teljesíti-e a végső célt. Ennek megfelelően a méréseinknek támogatniuk úgy kell ezt az alacsony szintű célt, hogy a megfelelő mérések az egyes változók záráskori várható értékei legyenek. Pl.: Mikor tudnánk befejezni a projektet? Mennyi pénzre lenne szükségünk a projekt befejezéséhez? Az összes többi mérés, például az eddigi tervezett és tényleges értékek csak köztes értékek, amelyekre az előrejelzések kiszámításához van szükség, nem pedig a vezetői célokra használt végső adatok. ### Példa: Dokumentumok Nem számít, milyen fejlesztési megközelítést alkalmazol a projektben, a tervezés mindig szükséges. A lényeges kérdés az egyes tervek részletessége. Ha nincs elég részlet a tervben, a terv nem tud kellőképpen hozzájárulni a projekthez, és a végrehajtás ad-hoc döntéseken fog alapulni, nem pedig integrált, holisztikus megközelítésen. Másrészt sokan próbálnak óvatosak lenni, és túl részletes tervet készítenek, ami túlságosan megnehezíti az előkészítést és karbantartást, illetve túl merev a projekt bizonytalanságaihoz képest. Ennek eredményeként a terv irreálissá és haszontalanná válik. A részletesség meghatározásának legjobb módja, ha a terv minden eleméhez meghatározunk egy célt. Például, ha erőforrásokat rendelsz a tervhez, akkor annak legyen valami célja: Hogyan fogod ezt használni? Hogyan segíti a projektet? Mekkora erőfeszítést igényel? És megéri? Néha arról van szó, hogy egy bizonyos elemet beépítesz-e a terveidbe, néha pedig arról, hogy miként tervezel meg valamit. Legyen szó üzleti esetről, projektalapító dokumentumról vagy jelentésről: továbbra is fel kell tenned azt a kérdést magadban, hogy miért készíted el ezt a dokumentumot, és ez hogyan segítheti a projektet. A “sablon” keresése valamihez pont az ellentéte a céltudatosságnak. ### Példa: Státuszjelentés Sok projektnél gyakori eset, hogy nagyon hosszú státuszjelentések készülnek. Ezen NUP alapján fel kell tennünk magunknak a kérdést, hogy mi a jelentés célja, és hogyan érhetjük el ezt a célt, függetlenül attól, hogy a legtöbb ember mit csinál. Ez sok esetben oda vezethet, hogy nagyon egyszerű, egyoldalas jelentéseket készítünk, amelyeket az érintettek valóban elolvasnak és megértenek a hosszú jelentések helyett. Ez a célra való koncentrálás. Ha azonban egyoldalas jelentéseket készítesz, lesznek olyanok, akik tiltakoznak, és azt gondolhatják, hogy nincs “megfelelő” felügyeleti rendszered. A gyakorlatban ez egy második célt is generál a számodra (az első cél mellett, amely segít az érdekelt feleknek megérteni a projekt állapotát), és ennek kielégítésére egyszerűen létrehozhatsz egy új, második típusú jelentést, amely nagyon hosszú. Ezt azonban nem szabad összekeverni az első jelentéssel, mert a két cél nem ugyanaz. ### Példa: Üzleti eset és projektalapító dokumentum Az olyan dokumentumok elkészítése, mint például az üzleti eset és a projekt alapító általában unalmas, eredménytelen, bürokratikus szükséglet a legtöbb ember számára. Azonban ezek a dokumentumok mindegyike fontos céllal készül, és az adott projektre vonatkoznak. Ha megpróbálsz egy “sablont” keresni és kitölteni, a munkád csak időpocsékolás lesz. Inkább ellenőrizd ezeknek a dokumentumoknak a valódi célját. Vizsgáld meg, hogy hasznosak lehetnek-e, és ha igen, milyen módon. Ezután tetszőlegesen elkészítheted ezeket a dokumentumokat, hogy megfeleljenek a feladatnak: ez lesz a megfelelő dokumentum. Miközben azon gondolkozol, hogyan készítheted elő a dokumentumokat a céljaik kielégítésére, előfordulhat, hogy nem gondolsz minden eshetőségre és valamit kihagysz. Ennek elkerülése érdekében ellenőrizd, hogy milyen eszközöket javasolnak például a PRINCE2^(®), PMBOK^(®) Guide, P3.express és DSDM^(®), és értékeld ezeket a javaslatokat a célok alapján. ### Példa: Poszt-projekt Míg a projektnek meghatározott célja van, és ezt a célt a projekt során végig szem előtt tudjuk tartani, addig a cél megvalósulását elsősorban a projekt során készített előrejelzések alapján értékeljük. Azonban erről a projekt végeztével sem szabad megfeledkeznünk. Fontos, hogy a projekt befejezése után ellenőrizzük a célok megvalósulását, mert - láthatjuk, hogyan valósulnak meg a végső célok, és tanulhatunk ebből a jövőbeli projektekhez, és - néha a célok csak akkor valósulnak meg, ha a projekt befejezése után további feladatokat hajtunk végre, és ezek szükségességének megértése monitorozást igényel. A projekt utáni monitoring szükséges lépés a célorientált szemlélet eléréséhez. Ez elsősorban a program- és portfóliókezelési rendszerek felelőssége, és mivel a legtöbb vállalat nem rendelkezik ilyen szintű menedzsmenttel, ezt a lépést általában figyelmen kívül hagyják. Ezért az olyan módszerek, mint a P3.express és a DSDM^(®), hozzáadják ezt a lépést a projektmenedzsment módszertanához. ### Példa: Egyszerűség A világ összetett és kaotikus, de a modelljeink absztrakt közelítések, amelyek a világnak csak egyes részeit tükrözik, ezért lehetnek egyszerűek is. Másrészt az egyszerű rendszerek általában jobban működnek, mert a fő gondolatra tudnak koncentrálni. Sokan megpróbálunk jobb eredményeket elérni rendszereink komplexitásával, abban a reményben, hogy az megfelel a világ összetettségének, bár a gyakorlatban ez megnehezíti a rendszerrel való munkát, és általában megakadályozza a cél elérését. ### Példa: Testreszabás Egy zenei streamelésre szolgáló szoftver kialakítása nagyon eltér attól, amelyet egy kórházban vagy egy repülőgépen használnak olyan berendezésekhez, ahol emberek élete múlhat rajta vagy attól a szoftvertől, amelyet egy műholdon használnak majd, ahol évekig működnek anélkül, hogy összeomolnának. Ezenkívül ezeknek mindegyike különbözik attól, mint amikor egy nyaralót, egy tűzoltóállomást vagy egy feldolgozó üzemet építenek. Ha a célokat tartod szem előtt jobban megérted, hogyan szabhatod testre a rendszereket és az egyes dokumentumokat a különböző projektekhez. ## NUP6 Használj megismételhető elemeket [image] A projekt ad-hoc megközelítése túl sok energiát és erőforrást igényel, és mindig fennáll annak a veszélye, hogy néhány szükséges elem lemarad. A tennivalók leegyszerűsítésének legjobb módja az ismételhető elemek használata, és lehetőleg megismételhető ciklusokban történő alkalmazása. ### Példa: Minőségellenőrző listák Az ellenőrző lista egy egyszerű példa egy potenciálisan megismételhető elemre, amelyet sokan használnak magán- és szakmai életükben egyaránt. Vegyük egy szállítmány minőségi kritériumait, például: - Először is létrehozhatsz egy ellenőrző listát az összes kritériumról, ami a tervezés egy formája. - A NUP6 azt javasolja, hogy próbáljuk meg általánosítani: Vannak más hasonló termékek a projektben? Ebben az esetben készíts egy általános minőségellenőrző listát az adott termékkategóriához, és használd ezt mindegyikhez. Ha vannak eltérések, tartsd meg az általános listát, és készíts néhány további elemet az egyes leszállítandó termékekhez. Így megismételhető ellenőrző listáid lesznek. - Miután elkészítetted az általános ellenőrző listákat a különböző típusú leszállítandó anyagokhoz, néha ismétlődő elemeket találsz közöttük, ami egy virtuális szülőkategóriát von maga után. Ebben az esetben ahelyett, hogy megismételnéd az összes általános ellenőrzőlista elemeit, egy szülő ellenőrzőlistába gyűjtheted őket. A végén valószínűleg egyetlen általános ellenőrző listád lesz az egész projekthez. A Scrum “kész definíciója” egy példa a projektszintű minőségellenőrző listák használatára (többek között). Ezzel minden leszállítandó egy kategóriahierarchiába fog tartozni, és meg kell felelnie a láncukban szereplő összes kategória ellenőrzőlistájának. Ezzel a szülő ellenőrzőlista egy eleme megismételhetővé válik az alatta lévő összes szállítmányhoz, ami időt és energiát takarít meg a tervezésben és a végrehajtásban. Ennél is fontosabb, hogy miután ezt egy projektnél elkészítetted, testreszabhatod és a jövőben az összes hasonló projekthez használhatod, ami több projekt megismételhető tervezési formájává alakul. ### Példa: Munkafolyamatok Az egyes teljesítések vagy a hozzájuk kapcsolódó célok bizonyos lépéseket igényelnek, amelyek szabványossá és megismételhetővé válhatnak. Például, ha a szállítmányokat egyedileg kell megtervezni és jóváhagyni, készíthetsz egy egyszerű munkafolyamatot, amely egyértelművé teszi az összes lépést és átláthatóvá teszti minden érintett számára a hozzávetőleges időtartamokat, így sok probléma megelőzhetővé válik. Ügyelni kell azonban arra, hogy a munkafolyamatok ne legyenek túl bonyolultak vagy túl intenzívek a dokumentációban, mert ennek negatív következményei lesznek. A projektben részt vevő minden embernek olyannak kell tekintenie a munkafolyamatokat, amelyek támogatják a munkájukat és mindent megkönnyítenek számára, nem pedig olyan bürokratikus dokumentációnak, amely akadályozza a valódi munkáját. Az agilis projektek iteratív fejlesztési megközelítésükben ismételhető elemeket tartalmaznak, ahol bizonyos típusú fejlesztési tevékenységek minden funkció esetén megismétlődnek; például. az XP általános napi rutinja (eXtreme Programming): párosítás, elem kiválasztása, táblán való tervezés, tesztszkriptek és kód elkészítése, kód integrálása stb. A technikai tevékenységekhez használható megismételhető munkafolyamatok mellett a projektmenedzsment tevékenységek is rendelkezhetnek megismételhető elemekkel. A PMBOK^(®) Guide, a PRINCE2^(®) és a DSDM^(®) folyamatai, a P3.express tevékenységei és a Scrum eseményei jó példák erre a koncepcióra. ### Példa: Ciklusok A projektek menedzselésében alkalmazott megismételhető elemek nagyon hasznosak lehetnek. Méginkább megkönnyítheti a munkát, ha megismételhető ciklusokba szervezzük őket. Ezek a ciklusok jelentősen leegyszerűsítik a projekt irányításában és vezetésében részt vevő emberek napi tevékenységét. A PMBOK^(®) útmutatóban szereplő folyamatcsoportok ciklusokból (ha egy projekt több fázisból áll), a PRINCE2^(®) szakaszokból, a P3.express napi, heti és havi folyamatciklusokból, a DSDM^(®) iterációkból és idődobozokból, valamint a Scrum Sprintekből áll, amelyek mindegyike jó példa erre a koncepcióra. A rövidebb ciklusokat könnyebb megérteni és használni, mint a hosszabbakat; pl. Sprintek a Scrumban, ellentétben a PMBOK^(®) útmutató szerinti fázisokkal. Előfordulhat azonban, hogy a túl rövid ciklusok nem elegendőek bizonyos típusú projektek támogatásához. Ilyen esetben a megoldás több, egymásba ágyazott ciklus használata, például a DSDM^(®) rövid időkeret-ciklusok használata hosszabb iterációs ciklusokkal, vagy a P3.express használata napi, heti és havi folyamatciklusokkal. ### Példa: Módszerek Egy módszertan vagy keretrendszer alkalmazása egy projektben egy újabb példa az ismételhető elemek használatára. Ez lehet egy meglévő rendszer, például PRINCE2^(®), P3.express, DSDM^(®) vagy Scrum, vagy egy olyan, amelyet Te szabtál személyre vagy építettél fel. Általában azonban jobb ötlet a meglévő módszerek valamelyikével kezdeni, és az igényeidhez igazítani, mint a semmiből egy újat megépíteni. Minden megismételhető elem absztrakt, és testreszabásra szorul, hogy a valós világhoz igazítsd ezeket. Az absztrakciónak és a testreszabás igényének azonban számos spektruma van: a kicsi, viszonylag konkrét minőségellenőrző listák a spektrum egyik végén találhatók, ahol a legkevesebb absztrakció és testreszabás szükséges, míg a módszertanok a másik végén vannak, ahol a legnagyobb a testreszabás igénye. Mindig vedd figyelembe a testreszabás szükségességét, különben az ismételhető elem nem fog megfelelően illeszkedni az igényeidhez.