# NUPP Niemal uniwersalne zasady projektów [image] To jest wersja do pobrania podręcznika online (https://omimo.org/pl/modules/nupp/), wygenerowana 2026‑07‑02. Nowsze wersje znajdziesz na stronie internetowej. NUPP pochodzi z OMIMO (https://omimo.org/pl/), rodziny otwartych i minimalistycznych modułów. Ten podręcznik można swobodnie używać i rozpowszechniać na licencji Creative Commons Attribution 4.0 International. OMIMO jest współfinansowane przez Unię Europejską. Wyrażone poglądy i opinie są jednak wyłącznie poglądami OMIMO i niekoniecznie odzwierciedlają stanowisko Unii Europejskiej ani EPOS VZW. Ani Unia Europejska, ani organ przyznający dofinansowanie nie ponoszą za nie odpowiedzialności. Przetłumaczone przez: Artur Kasza ## wprowadzanie NUPP to zbiór niemal uniwersalnych zasad projektów, którymi powinniśmy się kierować w wszystkich różnych projektach, niezależnie od stosowanych przez nas metodyk i podejść, aby zmaksymalizować szanse sukcesu projektu. Każda z dostępnych metod prowadzenia projektów oraz przeróżne zasoby przydatne w pracy projektowej opierają się na niektórych z tych niemal uniwersalnych zasad. Należy jednak pamiętać o następujących zastrzeżeniach: - Zwykle nie są to wszystkie z nich, niemniej wskazane jest rozważenie wszystkich zasad zamiast jakiegoś podzbioru. - Podstawowe zasady zwykle nie są wystarczająco jasne w metodach i zasobach projektowych, a większość praktyków jest tak zaabsorbowana szczegółami praktycznymi, że zapomina o zasadach i podejmuje działania, które nie koniecznie są z nimi zgodne. NUPP są kompatybilne ze wszystkimi głównymi metodykami, systemami, zasobami i frameworkami, takimi jak PRINCE2^(®), PMBOK^(®) Guide, P3.express, PM², DSDM^(®), XP i Scrum. Może to jednak nie być zgodne z niektórymi interpretacjami tych systemów i właśnie w tym miejscu intencją zawartą w NUPP jest zachęcić praktyków do ponownego rozważenia swoich interpretacji. NUPP to zbiór następujących pryncypiów: - NUP1 — Preferuj rezultaty oraz rzetelność a nie przynależności - NUP2 — Oszczędzaj i optymalizuj energię i zasoby - NUP3 — Zawsze bądź proaktywny - NUP4 — Pamiętaj, że łańcuch jest tak mocny, jak jego najsłabsze ogniwo - NUP5 — Nie rób niczego bez wyraźnego celu - NUP6 — Używaj elementów powtarzalnych ## NUP1 Preferuj rezultaty oraz rzetelność a nie przynależności [image] Wszyscy mamy naturalną skłonność do szukania przynależności do jakiejś grupy. Czasami jednak ta tendencja może być zbyt silna i powodować różne problemy. Możemy stracić dużo więcej niż zyskać dzięki takim ograniczającym afiliacjom. I przeciwnie, możemy stać się bardziej profesjonalni i skuteczni jako menadżerowie projektów, jeśli nie ograniczymy naszej tożsamości i preferencji do określonej grupy. ### Przykład: zwinność i kaskadowość W czasie gdy normą było stosowanie metod predykcyjnych (kaskadowych), grupa doświadczonych entuzjastów zebrała się i z dużą odwagą zaproponowała podejście adaptacyjne w rozwoju oprogramowania. Podejście to nazwano zwinnym. To była świetna inicjatywa, poszerzająca dostępny zestaw metod pracy projektowej. W społeczności Agile wciąż jest wielu zaangażowanych i zorientowanych na wyniki ludzi, ale niestety są też w tej społeczności tacy, którzy zamieniają Agile w kult i uważają wszystkich poza nią za wrogów. Powoduje to problemy na wiele sposobów, w tym: - nie pozwala im to uczyć się od nikogo spoza ich grupy - zniechęca innych do uczenia się od nich - sprawia, że przynależność do grupy jest ważniejsza niż prawdziwy cel, co z kolei uniemożliwia wielu jej członkom poznanie głębokiego znaczenia zwinności Ten problem można znacznie zmniejszyć, jeśli nie usunąć, używając słowa „zwinne” tylko jako etykiety odnoszącej się do podejścia wytwórczego, a nie do społeczności oraz poprzez angażowanie osób kreatywnych, rozwiązujących problemy i liderów, którzy postrzegają zwinność jako jeden z wielu zestawów narzędzi pracy i jedną z wielu filozofii nadających ramy pracy projektowej. Dla profesjonalistów nie ma konfliktu pomiędzy podejściem zwinnym i kaskadowym. ### Przykład: Przewodnik po PRINCE2^(®) i PMBOK^(®) Guide W społeczności jest wielu profesjonalistów, którzy kojarzą się z PRINCE2^(®) lub PMBOK^(®) Guide (zwykle ze względu na swoje położenie geograficzne) i nie są zaznajomieni z innymi. Wszyscy możemy mieć preferencje co do pewnych metod, nie traktując ich w kategoriach tożsamości, a co ważniejsze, musimy zapoznać się z nimi wszystkimi, aby poszerzyć naszą perspektywę i możliwości wyboru. Autentyczny profesjonalista jest otwarty na wszystkie idee i propozycje, szuka ich, poznaje i wykorzystuje w razie potrzeby, bez przynależności. ### Przykład: Ciągłe uczenie się Afiliacje satysfakcjonują niektórych ze względu na poczucie przynależności, którą zapewniają, ale nie skłaniają ich do nauki, a czasem nawet zniechęcają do nauki w obawie przed utratą tejże afiliacji. Kiedy jesteś osobą wolną, ekspertem bez przynależności, musisz wypełnić lukę ciągłym uczeniem się. To, w co dzisiaj wierzymy nie jest prawdą absolutną. To tylko nasze najlepsze dotychczasowe rozumienie, które musi być doskonalone w miarę rozwoju. Nie jest dobrze, jeśli czyjaś wiedza i idee są dokładnie takie same jak kilka lat temu. Tak też jest w przypadku NUPP: jeśli wrócisz tu po kilku latach i zobaczysz dokładnie to samo co dziś, powinieneś nabrać podejrzeń. ### Przykład: Otwartość Podejmując z kimś polemikę warto kierować sprzeciw na pomysł, a nie na osobę. Pomaga to uniknąć wielu napięć. W podobnym duchu, gdy ktoś oponuje wobec ciebie, postaraj się nie interpretować tego jako atak na siebie, ale raczej jako dyskusję na temat twoich pomysłów i pozostań na to otwarty. Nie słuchaj, żeby odpowiedzieć, słuchaj, żeby zrozumieć i współpracuj z drugą osobą, aby ulepszyć pomysł. Niektórzy ludzie mogą celowo kierować zastrzeżenia lub krytykę na ciebie zamiast na pomysł lub propozycję, w takim przypadku powinieneś pomóc im skupić się na pomyśle, a nie na tobie, zanim przejdziesz dalej, i staraj się, aby tak było przez całą rozmowę. ## NUP2 Oszczędzaj i optymalizuj energię i zasoby [image] Zasoby dostępne dla projektu są ograniczone, podobnie jak energia mentalna niezbędna do podejmowania odpowiednich decyzji. Warto je oszczędzać i optymalizować dla siebie jak i dla projektu oraz wspierać innych członków zespołu w tym samym. ### Przykład: Reguła 80/20 Dużą część możliwych korzyści z zarządzania projektami można uzyskać, przeznaczając na to niewielką część wysiłku. W większości przypadków ukierunkowanie na 100% możliwych korzyści jest bardzo kosztowne i nieuzasadnione. Musisz brać pod uwagę tę zasadę we wszystkim, co robisz i zachęcać innych do tego samego. ### Przykład: zmęczenie decyzją Używamy tego samego źródła energii mentalnej do podejmowania wszelkiego rodzaju decyzji, a także do wyrażania i realizowania naszej woli. Jeśli zużyjesz dużo tego zasobu na podejmowanie niepotrzebnych lub nieistotnych decyzji, będziesz mieć mniej energii na ważne decyzje, co może prowadzić do słabych wyników. To jeden z powodów, dla których powinieneś unikać mikrozarządzania (zasada „zarządzania przez wyjątki” PRINCE2^(®)). Konflikty, które dotyczą pomysłów, mogą być pomocne, ale te, które dotyczą ludzi, są zwykle szkodliwe dla projektu, a jedną z konsekwencji jest to, że wyczerpuje się energia mentalna członków zespołu. Jeśli zauważysz taki konflikt, powinieneś zrobić wszystko, aby znaleźć pierwotną przyczynę i go rozwiązać. ### Przykład: Dbaj o siebie! Decyzje, które podejmujesz i wola, którą wyrażasz, zużywają twoje zasoby energii mentalnej. Z drugiej strony to źródło odnawia się kiedy śpisz i jesz prawidłowo. Dlatego powinieneś zadbać o siebie: zapewnij sobie odpowiednią ilość snu i odpoczynku oraz dobrze się odżywiaj. Jeśli masz szkodliwe nawyki lub problemy ze snem, nie musisz sobie z tym radzić sam. Jest wielu specjalistów, którzy mogą pomóc w rozwiązaniu takich problemów. Aktywność fizyczna może również pomóc w odtwarzać źródła energii, chociaż badania w tej sprawie nie są jeszcze rozstrzygające. Postaraj się zachęcić członków zespołu do robienia tego samego. Po pierwsze, zapewnij zrównoważone tempo pracy, bez nadgodzin. Następnie, jeśli masz wybór, postaraj się oferować energetyczne, zdrowe jedzenie, przekąski i napoje w czasie pracy. ### Przykład: równowaga między życiem zawodowym a prywatnym Wielu z nas kocha to, co robi, ale to wciąż nie wszystko, czego potrzebujemy w życiu. W taki sam sposób, w jaki optymalizujesz swoją pracę, powinieneś planować i wdrażać pomysły w swoim życiu osobistym, tak aby było radosne, szczęśliwe. Kiedy jesteś szczęśliwszy, możesz odnosić większe sukcesy w pracy. Jeśli możesz, spróbuj zachęcić członków swojego zespołu, aby robili to samo. ### Przykład: Motywacja Motywacja to złożona koncepcja. Istnieje kilka interesujących i przydatnych opracowań opartych na badaniach na ten temat, a także wiele innych nienaukowych. Niemniej jednak powinieneś poznawać motywację własną i innych, oraz wzmacniać ją, gdyż zwiększa to energię psychiczną zespołu i poszerza możliwość osiągania lepszych wyników projektu. Motywacja może być tak prosta, jak poinformowanie ludzi, że uznajesz ich pracę za dobrą, życzliwym uśmiechem lub prostym „dziękuję”. Musisz jednak uważać, ponieważ wiele powszechnych form motywacji, takich jak niewielkie nagrody pieniężne, ma negatywny wpływ. ### Przykład: Współpraca i praca zespołowa Ludzie, którzy współpracują, mogą mieć wspólną moc osiągania świetnych wyników, ale co równie ważne, ludzie to istoty społeczne i lubią być częścią grupy. Jeśli możesz usunąć negatywne aspekty pracy zespołowej i stworzyć pozytywne środowisko, znajdziesz w projekcie szczęśliwych członków zespołu. Powinieneś być jednak ostrożny, ponieważ ludzie są różni, a niektórzy potrzebują więcej czasu na relaks, skupienie i samotność niż inni; zwykle jest to szukanie równowagi. ### Przykład: kultura jednego zespołu Różni interesariusze mają skłonność do tworzenia podgrup i powodowania napięć z innymi grupami. Dość powszechny przykład to ‘biznes kontra deweloperzy’. To napięcie pochłania wiele energii po obu stronach, co jest jednym z powodów, dla których powinniśmy starać się budować kulturę jednego zespołu, w której wszyscy pracują razem, aby osiągnąć ten sam cel. ### Przykład: inteligencja wspólna Kiedy pewna liczba różnych osób spotyka się i pracuje w sprzyjającym środowisku, pojawia się możliwość wypracowania wartościowych wyników, pomysłów i rozwiązań, które mogą być lepsze niż te pochodzące od indywidualnych ekspertów. Jeśli masz taką możliwość, możesz regularnie z niej korzystać, prosząc członków zespołu o pomoc w rozwiązaniu trudnych problemów w projekcie. Oprócz możliwości osiągania dobrych wyników, daje to też członkom zespołu poczucie, że ich opinie są doceniane i że odgrywają ważną rolę w projekcie, co z kolei zwiększa ich poziom energii. Działanie E02 P3.express to przykład wykorzystania inteligencji wspólnej w projektach. ### Przykład: Główny facylitator projektu Jeśli jesteś kierownikiem projektu, większość rzeczy, które robisz, ma charakter facylitacyjny (a przynajmniej powinna mieć). Z drugiej strony, jeśli członkowie zespołu mieli w przeszłości złe doświadczenia z kierownikami projektów, te doświadczenia mogą mieć negatywny wpływ na ich relacje z Tobą: zamiast tego część ich energii jest poświęcana na analizę Twojego zachowania pod kątem potencjalnych zagrożeń, zamiast budowania zaufania. W takim przypadku możesz zmienić swój tytuł z kierownika projektu na głównego facylitatora projektu. W końcu to właśnie robisz w projekcie. ## NUP3 Zawsze bądź proaktywny [image] Jest w nas naturalna skłonność do reaktywności. Może nam to pomóc w zachowaniu energii na zajmowanie się nieistotnymi sprawami lub może dać nam lepsze rezultaty, gdy mamy do czynienia z czymś, w czym jesteśmy całkowicie niekompetentni. Te sytuacje różnią się od naszych projektów i tutaj możemy osiągnąć lepsze wyniki, działając proaktywnie. ### Przykład: Planowanie Jeśli chcesz dojechać do nowej lokalizacji i jesteś już na starcie spóźniony, możesz od razu rozpocząć jazdę, aby „oszczędzić czas” i rozwiązać ewentualne problemy, gdy się pojawią. Proaktywne podejście polega na poświęceniu trochę czasu na początku i ustawieniu systemu nawigacji tak, aby zapewniał najszybszą trasę w oparciu o ruch uliczny, możliwe wypadki i blokady, a następnie jazdę; to przeznaczenie czasu przed wykonaniem na planowanie, aby uniknąć późniejszych problemów, a tym samym zaoszczędzić czas na końcu. W przeciwieństwie do tego, co niektórzy myślą o projektach w podejściu zwinnym, planowanie jest zawsze konieczne i różnie tylko można podchodzić do rodzaju i poziomu szczegółowości planów. Planowanie przed działaniem to podejście proaktywne. Zapamiętaj cytat: daj mi sześć godzin na ścięcie drzewa, a pierwsze cztery spędzę na ostrzeniu siekiery. Jeśli jest to projekt sekwencyjny, możesz spędzić 4 godziny na ostrzeniu swojej siekiery, ponieważ masz pewność, że zetniesz drzewo. W projekcie Agile nie masz pewności, czy zamierzasz ścinać drzewo, zbierać połamane gałęzie, zbierać torf, wydobywać węgiel, czy coś innego. Niemniej jednak nadal musisz mieć ogólne przygotowanie na wszystkie te rzeczy (wiedzieć, gdzie jest najbliższy sklep ze sprzętem) i mieć konkretne przygotowanie (ostrzenie), gdy zamierzasz skupić się na określonym rozwiązaniu. To jest planowanie. ### Przykład: Planowanie planowania Planowanie sposobu realizacji projektu to też podejście proaktywne. Tę czynność można nawet rozszerzyć, planując sposób, w jaki zamierzamy zaplanować wykonanie; to koncepcja planu zarządzania w PMBOK^(®) Guide, strategie zarządzania w PRINCE2^(®) i podejścia w DSDM^(®). ### Przykład: Planowanie ciągłe Rzeczywistość rzadko pasuje do tego, co zaplanowaliśmy, i to jest w porządku – ale musimy stale dostosowywać nasze plany, aby były realistyczne i praktyczne. Powinniśmy to zrobić, gdy tylko potrzebna jest adaptacja, a nie wtedy, gdy natkniemy się na problemy. To jest proaktywne podejście. ### Przykład: Zarządzanie ryzykiem Cała koncepcja zarządzania ryzykiem opiera się na proaktywności: w obliczu niepewnych wydarzeń, zamiast czekać, co się stanie, a następnie reagować na nie, myślimy o możliwościach i skutkach, rozważamy reakcje i prawdopodobnie coś z tym robimy, zanim to nastąpi. Zauważ, że to, co robimy w projektach, jest niemałej wagi; czasami chodzi o życie ludzi. ### Przykład: Zdefiniuj role i obowiązki Nawet jeśli pozostawisz członków zespołu projektowego w pracy bez jasnych ról i odpowiedzialności, prędzej czy później pojawi się pewien układ ról i odpowiedzialności, ale jest to zbyt kosztowne i może nie działać dobrze. Proaktywne podejście polega na ich wczesnym zdefiniowaniu i dostosowaniu w razie potrzeby. Ułatwia to pracę wszystkim i pozwala skupić się na wytwarzaniu oczekiwanego produktu, zamiast decydować, kto co robi. Liczba i różnorodność ról zależy od rodzaju i wielkości projektu; może to być prosta definicja, jak ta w Scrum, umiarkowana, jak ta w P3.express, lub rozbudowana, jak te w DSDM^(®) i PRINCE2^(®). Nie zapominaj jednak, że opisy ról w tych metodach dotyczą tylko działań związanych z zarządzaniem i że zawsze musisz dodać opisy ról również dla działań technicznych. ### Przykład: Dostępne opcje Czy należy przedwcześnie zamknąć projekt, czy kontynuować? Rzadko są tylko dwie możliwości, nawet jeśli pytanie to sugeruje. Warto jest mieć proaktywne podejście i rozważyć wszystkie opcje przed podjęciem decyzji. Można zmienić zakres projektu; można go wstrzymać, aż coś innego się wyjaśni; a może można też zmienić samo podejście do projektu (np. poprzez outsourcing) itp. ### Przykład: myślenie krytyczne Wszyscy mamy pewne nastawiania, które z jednej strony pomagają nam przetrwać, a z drugiej nakłaniają nas do podejmowania złych decyzji. Jeśli chodzi o podejmowanie ważnych decyzji dotyczących projektu, najlepiej zatrzymać się na chwilę i rozważyć nasze nastawienie, które może wpłynąć na naszą decyzję, zanim spowodują problemy. Jako odniesienie możesz użyć listy błędów poznawczych podanej w Wikipedii. Istnieją nawet ramy podejmowania decyzji, które można wykorzystać do podejmowania lepszych decyzji. Na początku korzystanie z nich może być rozpraszające, a nawet denerwujące, ale wkrótce przyzwyczaisz się do nich i zyskasz dzięki nim przewagę bez większego świadomego wysiłku. ### Przykład: Przejrzystość Nie lubimy spóźniać się w projekcie lub mieć innego rodzaju problem, ale to nie znaczy, że powinniśmy to ukrywać. Warto jest być transparentnym i poinformować interesariuszy, ponieważ niektórzy z nich mogą być w stanie Ci pomóc, a ponadto prędzej czy później i tak się dowiedzą o problemach i ich konsekwencjach, a niektórzy z nich mogą stanąć przed koniecznością wczesnych działań z ich strony (np. aby zaakceptować negatywną konsekwencję). ### Przykład: komunikuj się skutecznie Nierzadko zdarza się, że wysyłasz raporty do interesariuszy, a oni nie przekazują Ci żadnych informacji zwrotnych. Możesz wierzyć, że wszystko jest w porządku tylko dlatego, że nie ma negatywnych reakcji, chociaż może być zupełnie inaczej. Musisz być proaktywny i sprawdzić, czy rzeczywiście zapoznali się z raportem i czy spełnił on swoje zadanie, a także wykorzystać dane wejściowe, aby dostosować metodę komunikacji; w przeciwnym razie ten ukryty problem komunikacyjny może później spowodować poważne problemy, i będzie on już zbyt trudny do naprawienia. ### Przykład: Weź odpowiedzialność Łatwo obwiniać innych za słabe wyniki. Na przykład możesz chcieć, aby Twoja organizacja dała Ci pełne uprawnienia do zmiany wszystkiego w projekcie i robienia tego perfekcyjnie, ale tak się nie dzieje i w rezultacie projekt kończy się niepowodzeniem. To nie jest proaktywne podejście. Proaktywne podejście polega na wzięciu odpowiedzialności i zrobieniu wszystkiego, co możliwe, w ramach ograniczeń. Nie możesz oczekiwać, że organizacja w pełni Ci zaufa i zapewni wszystko w nadziei na osiągnięcie dobrych wyników, zwłaszcza gdy widziała tak wiele nieudanych projektów. Musisz dokonać jednej małej poprawy w ramach ustalonych ograniczeń, użyć tego, aby zdobyć trochę zaufania, trochę więcej zasobów i trochę większą tolerancję, a następnie użyć tego, aby uzyskać nieco większą zakres modyfikacji i korekt w projekcie, aż do osiągnięcia stanu optymalnego. ## NUP4 Pamiętaj, że łańcuch jest tak mocny, jak jego najsłabsze ogniwo [image] W projektach są różne aspekty i wszystkie one wymagają uwagi; musimy mieć holistyczną perspektywę projektu. Zwracanie uwagi na jeden pozornie najważniejszy aspekt (np. czas) nie wystarczy, ponieważ wszystkie aspekty wchodzą w interakcje i mogą nie działać prawidłowo. Chyba że wszystkie otrzymają odpowiednią uwagę. ### Przykład: Chodzi o termin! Powiedzmy, że budujesz coś na Igrzyska Olimpijskie. Projekt ma bardzo sztywny termin, co sprawia, że zarządzanie czasem jest bardzo ważne. Czy to prawda? A co, jeśli jakość jest tak niska, że po pewnym czasie wymaga powtórzenia pracy. To miałoby wpływ na czas, więc to sprawia, że jest to czas i jakość. Możesz mieć fantazyjny ogród opisany w pierwotnej definicji projektu, ale wiesz, że jeśli nie ma wystarczająco dużo czasu, możesz go pominąć i po prostu przykryć trawą, o ile rozważyłeś tę możliwość na czas i przygotowałeś się na to. Dlatego ważne jest również zarządzanie zakresem. Teraz w centrum naszej uwagi znajduje się zakres, czas i domeny jakości. Czy słyszałeś o tej słynnej sytuacji, w której prezydent Kennedy spotyka woźnego w NASA i pyta go, co robi, a on odpowiada: „Pomagam umieścić człowieka na Księżycu”? Czy tego typu osoby w projekcie nie pomagają dotrzymać terminu? Idąc dalej, zauważasz, że każda domena w projekcie przyczynia się do zarządzania czasem i nie możesz dotrzymać terminu z akceptowalnym poziomem pewności, jeśli nie zwrócisz uwagi na wszystkie domeny. ### Przykład: wybieranie wisienek Kiedy ludzie mają do czynienia z różnymi metodami, czasami zaczynają wybierać wisienki i tworzą mieszankę wszystkiego, co wydaje się interesujące z różnych systemów. To zwykle nie działa, ponieważ elementy nie działają w izolacji i muszą być ze sobą kompatybilne. Wszelkie dodatki lub zmiany w systemie powinny być dokonywane z holistycznego punktu widzenia. Dlatego czasami widzimy sprzeczne elementy w różnych metodach; coś działa dobrze w jednym systemie, a jego przeciwieństwo działa dobrze w innym. Ten element sam w sobie nie jest dobry lub zły. Najbezpieczniejszym podejściem jest wybór metodyki dla projektu, dostosowanie jej, a następnie ostrożne dodawanie do niego nowych elementów, biorąc pod uwagę spójność całego systemu. ### Przykład: podejście antyprocesowe Jedną z ważnych rzeczy, jakie wprowadziły metody zwinne, jest zwrócenie uwagi na aspekty ludzkie. Manifest Agile nadaje większą wartość jednostkom i interakcjom w porównaniu z procesami i narzędziami, chociaż nie jest to być może najbardziej uczciwe zestawienie. Prawie wszystkie metody mówią, że aspekty ludzkie są ważne, a prawdziwa różnica w stosunku do metod Agile polega na tym, że aspekty ludzkie są częścią ich procesów, a nie prostą sugestią. Nie chodzi więc o rywalizację między ludzkimi aspektami i procesami, ale raczej o sposób, w jaki aspekty ludzkie są postrzegane w systemie. Nie ma wątpliwości, że niektórzy ludzie próbują zastąpić ludzkie aspekty bardziej wyrafinowanymi procesami, ale to tylko nadużycie. Istnieje nawet coś odwrotnego: ludzie próbujący zastąpić procesy aspektami ludzkimi, co też nie działa dobrze. ### Przykład: to są wszystkie domeny, które są niezbędne Myśląc o domenach, należy uważać, aby nie pominąć żadnej z nich. Ale czym one są? Jeśli sprawdzisz w różnych źródłach, otrzymasz różne odpowiedzi; a jednak żadne z nich nie oferuje kompletnego obrazu. Tematy PRINCE2^(®) są domenami, ale to są tylko domeny które odgrywają kluczową rolę w tej metodyce. Pozostałe domeny są tylko dorozumiane. Przewodnik PMBOK^(®) Guide nie jest metodyką, jest to raczej kompendium, na które składa dziesięć obszarów wiedzy. Są to jednak interpretacje wszystkich dziedzin oparte na perspektywie PMBOK^(®) Guide na projekt, a nie na perspektywie neutralnej (niekoniecznie istnieje coś takiego jak neutralna perspektywa). Na przykład w przewodniku PMBOK^(®) Guide nie poświęca się wiele uwagi aspektom ludzkim. Dobrym źródłem informacji o domenach jest ICB (IPMA). Nie chodzi jednak o domeny, ale o kompetencje, które są wymagane w projekcie. Nie ma relacji jeden do jednego z domenami, ale takie ramy bardzo pomagają w ich identyfikacji. W NUPP nie ma listy domen, głównie dlatego, że jest to metasystem, a nie system, a także dlatego, że kategoryzacja domen zależy od typu projektu i jego środowiska; np. rutynowy projekt budowlany może wymagać innej perspektywy niż kreatywny projekt badawczy. ## NUP5 Nie rób niczego bez wyraźnego celu [image] Nie powinieneś robić niczego, co nie ma jasnego celu. Wyobraź sobie dwa równoległe światy, w których wszystko jest takie samo, z wyjątkiem tego, co zamierzasz zrobić: Jak różne byłyby te światy? Czy różnica jest warta wysiłku koniecznego, aby to zrobić? Jeśli nie masz jasnego celu i robisz coś tylko dlatego, że wszyscy to robią lub wszyscy mówią, że jest to ważne, to może to nie przynieść żadnej realnej korzyści. Możesz więc nic z tego nie uzyskać; lub może to nadal mieć potencjalne korzyści, ale ponieważ nie masz na myśli konkretnego celu, twój sposób na zrobienie tego może nie być pomocny w osiągnięciu korzyści. ### Przykład: Portfele i programy Jeśli jesteś zaangażowany w wybór i inicjowanie projektów, powinieneś mieć pewność, że koncentrujesz się na korzyściach i problemach, które należy rozwiązać, a nie na produkcie, który ma te rzeczy umożliwić. Klasycznym przykładem jest producent wind, który otrzymywał skargi na prędkość swoich wind, a więc przeprowadził wiele projektów mających na celu zwiększenie prędkości. Bez pełnego sukcesu. Trwało to, dopóki nie zdecydowali się skupić na problemie (nuda lub dyskomfort w windzie) zamiast „naturalnego” rozwiązania (szybsze windy). W rezultacie zainstalowano w windach lustra, co rozwiązało problem w prosty i tani sposób. Pamiętaj, że zarządzanie projektami polega głównie na robieniu rzeczy właściwie, podczas gdy zarządzanie portfelem polega na robieniu właściwych rzeczy. Nie ma znaczenia, jak dobrze prowadzisz swoje projekty, jeśli są to nieodpowiednie projekty. Chodzi o to, by mieć wyraźny cel. ### Przykład: projekt jako całość Elastyczność produktu różni się w zależności od projektu. W niektórych projektach informatycznych produkt jest całkowicie elastyczny, a jego ostateczna forma zależy od informacji zwrotnych, które są generowane przez przyrosty produktu w trakcie projektu. Wymaga to podejścia adaptacyjnego (Agile). W praktyce jest to połączenie warstwy portfela, programu i projektu, które wymaga poświęcenia maksymalnej uwagi ostatecznemu celowi. Dobrym pomysłem jest udokumentowanie celu i udostępnienie go. Jest to jeden z celów „wizji produktu”, używanej w niektórych projektach Scrum. Dbałość o wartość biznesową w projektach Agile jest ich sposobem na zapewnienie zgodności z celem. W innych typach projektów, gdzie produkt jest stosunkowo stały i istnieją inne mechanizmy zapewniające, że zidentyfikowany produkt spełni cel, członkowie zespołu projektowego mogą przenieść dużą część swojej uwagi z celu na produkt (stąd zasada „koncentracji na produktach” w PRINCE2^(®)), ale przynajmniej minimalna dbałość o cel jest nadal przydatna, aby zapewnić, że to, co jest budowane, pozwoli osiągnąć cel. Można to zrobić porównując prognozowane korzyści z oczekiwanymi korzyściami (stąd zasada „ciągłego uzasadnienia biznesowego” i temat „uzasadnienia biznesowego” w PRINCE2^(®)). Gdy projekt jest prowadzony dla klienta zewnętrznego, klient zwykle ma swój własny cel dla projektu, a Twoja firma jako dostawca może mieć inny cel. Powinieneś zrozumieć i wykorzystać oba te elementy, aby naprawdę odnieść sukces projektu. ### Przykład: Monitorowanie projektu Skupienie się na celu finalnym jest konieczne, ale może być zbyt abstrakcyjne dla wielu codziennych działań. Dlatego potrzebna jest hierarchia czynników biznesowych. Najpierw uzasadnienie i korzyści z projektu są definiowane na podstawie ostatecznego celu, a następnie zarysują się wyraźne i ukryte cele dla poszczególnych parametrów projektu (np. czas, koszt i jakość), których osiągniecie będzie konieczne dla utrzymania zasadności biznesowej, co z kolei pozwoli osiągnąć cel ostateczny. Są to cele niższego poziomu, które są przydatne w wielu naszych codziennych zadaniach. Jeśli chodzi o monitorowanie projektu, na niskim poziomie będzie się ono odbywać przy użyciu zmiennych o najniższym poziomie, ponieważ śledzenie ostatecznego celu może nie być możliwe. W takim przypadku nadal powinieneś mieć na uwadze cel. Jaki jest inny cel monitorowania? Normalną i akceptowalną odpowiedzią jest sprawdzenie, czy jesteśmy na dobrej drodze, a jeśli już nie jesteśmy, przeprowadzenie pewnej reakcji, która sprowadzi nas z powrotem na właściwy tor lub modyfikacja celów i sprawdzenie, czy nadal jest osiągalny cel ostateczny. Nasze pomiary powinny zatem pozwolić nam w realizacji celów niskiego poziomu i dają prognozy dla zmiennych na zakończenie projektu, w tym: kiedy będziemy mogli domknąć projekt? Ile pieniędzy potrzebowalibyśmy na ukończenie projektu? Wszystkie inne pomiary, takie jak dotychczasowe wartości planowane i rzeczywiste, są tylko wartościami pośrednimi, które są potrzebne do obliczenia prognoz, a nie wartościami końcowymi, które stosujesz do celów zarządczych. ### Przykład: Dokumenty Bez względu na to, jakie podejście do rozwoju produktu zastosujesz w projekcie, planowanie jest zawsze konieczne. Ważną kwestią jest poziom szczegółowości każdego rodzaju planu. Jeśli w planie nie ma wystarczająco dużo szczegółów, plan nie zapewni wystarczających informacji, a realizacja projektu będzie oparta na decyzjach doraźnych, a nie zintegrowanych i całościowych. Z drugiej strony wiele osób stara się być ostrożnym, dodając do planu zbyt wiele szczegółów, co sprawia, że jest on zbyt trudny zarówno w przygotowaniu jak i utrzymaniu, a przy tym zbyt sztywny, zważając na niepewność projektu. W rezultacie plan staje się nierealny i bezużyteczny. Najlepszym sposobem na określenie poziomu szczegółowości jest uwzględnienie celu dla każdego elementu planu. Na przykład, jeśli rozważasz dodanie zasobów do planu, powinieneś mieć dla tego cel: Jak zamierzasz z niego korzystać? Jak to pomoże projektowi? Ile wysiłku to wymaga? Czy warto? Czasami chodzi o podjęcie decyzji, czy chcesz mieć jakiś element w swoich planach, a czasami o sposób, w jaki chcesz coś zaplanować lub przygotować. Niezależnie od tego, czy jest to uzasadnienie biznesowe, karta projektu, czy raport: nadal powinieneś zadać sobie pytanie, dlaczego przygotowujesz ten dokument i jak może on pomóc projektowi. Szukanie „szablonu” jest przeciwieństwem robienia czegoś w określonym celu. ### Przykład: raportowanie stanu projektu W wielu projektach często pojawiają się naprawdę długie raporty o stanie projektu. W oparciu o NUPP powinniśmy zadać sobie pytanie, jaki jest cel raportu i jak możemy go osiągnąć, niezależnie od tego, co robi wiele innych osób. W wielu przypadkach może to prowadzić nas do przygotowania bardzo prostych, jednostronicowych raportów, które interesariusze naprawdę czytają i rozumieją, zamiast długich raportów. To zwrócenie uwagi na cel. Jeśli jednak przygotowujesz jednostronicowe raporty, niektóre osoby mogą mieć do ciebie zastrzeżenia i sądzić, że nie masz „właściwego” systemu monitorowania. W praktyce tworzy to dla ciebie drugi cel (oprócz pierwszego celu, którym jest pomoc interesariuszom w zrozumieniu statusu projektu), i aby go zaspokoić, możesz po prostu utworzyć drugi rodzaj raportu, który jest bardzo długi. Jednak nie powinieneś mieszać tego z pierwszym raportem, ponieważ te dwa cele są zupełnie inne. ### Przykład: uzasadnienie biznesowe i karta projektu Przygotowanie dokumentów, takich jak uzasadnienie biznesowe i karta projektu, jest nierzadko postrzegane jak nudna, bezowocna, biurokratyczna konieczność, podczas gdy wszystkie te dokumenty mają uzasadnione cele, które odnoszą się do większości projektów. Jeśli spróbujesz znaleźć „szablon” i go wypełnić, praca jest po prostu zmarnowana; podczas gdy zamiast tego możesz sprawdzić prawdziwy cel tych dokumentów, zobaczyć, czy i jak mogą być pomocne w twoim projekcie, a następnie przygotować dokument w dowolny sposób, aby spełnić te cele. I to będzie właściwy dokument. Gdy zastanawiasz się, w jaki sposób możesz dostosować dokumenty, aby spełniały ich cele, możesz nie przewidzieć każdego możliwego scenariusza i możesz coś przeoczyć. Aby tego uniknąć, warto sprawdzić, co sugerują różne metodyki i kompendia , takie jak PRINCE2^(®), PMBOK^(®) Guide, P3.express i DSDM^(®), a następnie ocenić te sugestie w oparciu o cele. ### Przykład: post-projekt Chociaż projekt ma określony cel i możemy go mieć na uwadze w całym cyklu życia projektu, realizacja celu jest oceniana głównie na podstawie prognoz dokonanych w trakcie projektu. Nie powinniśmy jednak o ocenie zapominać w momencie zakończenia projektu. Ważne jest, aby na zakończeniu projektu sprawdzić realizację celów, ponieważ możemy zobaczyć, w jakim stopniu zostały osiągnięte cele ostateczne i potraktować to jako źródło wartościowej wiedzy dla kolejnych projektów. Czasami też cele są osiągane dopiero wtedy, gdy po zakończeniu projektu wykonujemy jakieś dodatkowe zadania. Te dodatkowe zadania wymagają również monitorowania. Monitorowanie po zakończeniu projektu jest niezbędnym krokiem, ściśle powiązane z ukierunkowaniem na cel. Jest to głównie obowiązkiem systemów zarządzania programami i portfelami, a ponieważ większość firm nie ma takich warstw zarządzania, ten krok jest zwykle zaniedbywany. Dlatego metody takie jak P3.express i DSDM^(®) dodają ten krok do metodyk zarządzania projektami. ### Przykład: Prostota Świat jest złożony i chaotyczny, a nasze modele są abstrakcyjnymi przybliżeniami, które odzwierciedlają wycinki rzeczywistości, mogą zatem być proste. Do tego jeszcze proste systemy zazwyczaj działają lepiej, ponieważ możemy skupić się na głównej idei. Wielu z nas próbuje uzyskać lepsze wyniki, podnosząc złożoność naszych systemów, mając nadzieję, że w ten sposób systemy dopasują się do złożoności świata. W praktyce jednak utrudnia to pracę z systemem i zwykle uniemożliwia nam spełnienie celu. ### Przykład: dostosowanie Oprogramowanie do strumieniowego przesyłania muzyki ma zupełnie inne uwarunkowania niż oprogramowanie używane w szpitalu lub w samolocie, od którego może zależeć życie ludzi, lub oprogramowanie, które będzie używane na satelicie, gdzie muszą pracować przez wiele lat bez awarii, a wszystkie różnią się od budowy letniej willi, straży pożarnej i zakładu przetwórczego. Mając na uwadze cele, lepiej zrozumiesz, jak dostosować systemy i artefakty do różnych projektów. ## NUP6 Używaj elementów powtarzalnych [image] Podejście ad hoc do projektu pochłania zbyt dużo energii i zasobów i zawsze wiąże się z ryzykiem pominięcia niektórych niezbędnych elementów. Najlepszym sposobem na uproszczenie tego, co należy zrobić, jest wykorzystanie powtarzalnych elementów, najlepiej w powtarzalnych cyklach. ### Przykład: listy kontrolne jakości Lista kontrolna jest prostym przykładem potencjalnie powtarzalnego elementu, z którego wiele osób korzysta w życiu osobistym i zawodowym. Weźmy pod uwagę kryteria jakości produktu. Przykładowo, wpierw można stworzyć listę kontrolną wszystkich kryteriów. Jest to forma planowania. To, co zaleca NUPP6, to próba uogólnienia. Czy w projekcie są inne podobne produkty? Jeśli tak, to w takim przypadku warto przygotować ogólną listę kontrolną jakości dla tej kategorii produktów i używać jej dla wszystkich z nich. Jeśli istnieją jakieś odmiany, zachowaj ogólną listę i dodaj kilka dodatkowych punktów do listy kontrolnej, dotyczących tych szczególnych produktów. Teraz masz powtarzalne listy kontrolne. Po przygotowaniu ogólnych list kontrolnych dla różnych typów produktów możesz znaleźć elementy, które się wśród nich powtarzają, co sugeruje wirtualną kategorię nadrzędną dla nich. W takim przypadku, zamiast powtarzać elementy dla wszystkich tych ogólnych list kontrolnych, możesz je wyodrębnić i umieścić w nadrzędnej liście kontrolnej. W końcu prawdopodobnie będziesz mieć jedną ogólną listę kontrolną dla całego projektu. „Definicja ukończenia” w podejściu SCRUM jest przykładem wykorzystania list kontrolnych na poziomie projektu dla jakości (między innymi). Dzięki temu każdy dostarczany produkt będzie należeć do pewnej kategorii w hierarchii i powinien spełniać wymagania, które pojawiają się na listach kontrolnych wszystkich kategorii w ich łańcuchu. W ten sposób element z nadrzędnej listy kontrolnej stanie się stosowalny do wszystkich produktów, jako że lista ta obejmie je wszystkie. To pozwoli zaoszczędzić czas i energię w planowaniu i realizacji. Co ważniejsze, gdy zrobisz to dla jednego projektu, możesz dostosować go i wykorzystać do wszystkich podobnych projektów w przyszłości, co jest powtarzalną formą planowania dla wielu projektów. ### Przykład: Procesy i przepływy pracy Niektóre rezultaty lub cele z nimi powiązane wymagają pewnych kroków, które mogą stać się ustandaryzowane i powtarzalne. Na przykład, jeśli produkty muszą być zaprojektowane i zatwierdzone indywidualnie, możesz przygotować prosty przepływ pracy, który obejmie wszystkie kroki, zaangażowane osoby i przybliżony czas trwania, dzięki czemu unikniesz wielu trudności. Należy jednak uważać, aby przepływy pracy i procesy nie były zbyt skomplikowane lub zbyt rozbudowane w dokumentacji, ponieważ będzie to miało negatywne konsekwencje. Wszystkie osoby zaangażowane w projekt powinny postrzegać przepływy pracy i procesy jako coś, co wspiera ich pracę i ułatwia im wszystko, a nie biurokratyczną dokumentację, która blokuje ich rzeczywistą pracę. Projekty zwinne mają powtarzalne elementy w swoim iteracyjnym podejściu do wytwarzania oprogramowania, w którym pewien rodzaj działań programistycznych jest powtarzany dla każdej funkcji; np. codzienna rutyna w XP (eXtreme Programming): dobierz się w parę, wybierz element, zaprojektuj go na tablicy, zbuduj skrypty testowe i kod, zintegruj kod itp. Oprócz powtarzalnych przepływów pracy, które można wykorzystać w działaniach technicznych, możesz mieć również powtarzalne elementy do działań związanych z zarządzaniem projektami. Procesy w przewodniku PMBOK^(®) Guide, PRINCE2^(®) i DSDM^(®), działania w P3.express i zdarzenia w Scrum są przykładami tej koncepcji. ### Przykład: Cykle Pomocne jest posiadanie powtarzalnych elementów do zarządzania projektem. Można to jeszcze ułatwić, umieszczając je w powtarzalnych cyklach. Cykle te znacznie upraszczają codzienne czynności osób zaangażowanych w zarządzanie i kierowanie projektem. Cykle grup procesów w przewodniku PMBOK^(®) Guide, gdy są używane w projekcie z wieloma fazami, etapami w PRINCE2^(®), cyklami dziennymi, tygodniowymi i miesięcznymi w P3.express, iteracjami i timeboxami w DSDM^(®) oraz sprintami w Scrum są tego dobrym przykładem. Krótsze cykle są łatwiejsze w zrozumieniu i wykorzystaniu niż dłuższe; np. Sprinty w Scrum w przeciwieństwie do faz według PMBOK^(®) Guide. Jednak cykle, które są zbyt krótkie, mogą być niewystarczające wystarczyć w niektórych projektach, a rozwiązaniem może być zastosowanie wielu cykli, takich jak użycie przez DSDM^(®) krótkich cykli timeboxu wraz z dłuższymi cyklami iteracji lub zastosowanie cykli dobowych, tygodniowych i miesięcznych w P3.express. ### Przykład: Metody Wykorzystanie metodyki lub ram do prowadzenia projektu to kolejne wykorzystanie elementów powtarzalnych. Może to być istniejący system, taki jak PRINCE2^(®), P3.express, DSDM^(®) lub Scrum, lub taki, który sam dostosowałeś lub zbudowałeś. Zwykle jednak lepszym pomysłem jest zacząć od jednej z istniejących metod i dostosować ją do potrzeb, niż budować od podstaw. Każdy powtarzalny element jest abstrakcyjny i wymaga dostosowania do rzeczywistego świata. Istnieje jednak spektrum abstrakcji i potrzeby dostosowywania: małe, stosunkowo konkretne listy kontrolne jakości znajdują się na jednym końcu spektrum (mają najmniejszy poziom abstrakcji i możliwość dostosowania), podczas gdy metodyki są na drugim końcu, z największą potrzebą dostosowania. W każdym razie, zawsze należy zwracać uwagę na konieczność dostosowania, w przeciwnym razie powtarzalny element nie będzie dopasowany do konkretnych, rzeczywistych potrzeb.