# NUPP Почти универсални принципи на проектите [image] Това е версия за изтегляне на онлайн ръководството (https://omimo.org/bg/modules/nupp/) Проверете уебсайта за по-нови версии. NUPP произлиза от OMIMO (https://omimo.org/bg/), който е част от отворени, минималистични модули. Това ръководство може да се използва и разпространява свободно под международния лиценз Creative Commons Attribution 4.0. OMIMO е съфинансиран от Европейския съюз. Изразените възгледи и мнения обаче принадлежат единствено на OMIMO и не отразяват непременно тези на Европейския съюз или на EPOS VZW. Нито Европейският съюз, нито предоставящият финансирането орган могат да бъдат държани отговорни за тях. Преведено от Alexander Petkov, Aneliya Chervenova ## Въведение NUPP е колекция от почти универсални проектни принципи, които може да приложите във всеки проект за да има максимален успех, независимо от използваната методология или подход. Всеки ресурс и метод по проектен мениджмънт обръща внимание на NUP / ПУП (почти универсални принципи), обаче: - Използващите тези принципи, трябва да ги разглеждат като едно цяло вместо като отделни принципи, и - Тези принципи не са достатъчно ясни като ресурси и повечето прилагащи ги са толкова ангажирани в практичните детайли за изпълнението им, че забравят за самите принципи и постъпват по начин, който не е съвместим с тях . NUPP (ПУПП) са съвместими с основните методологии, ресурси и принципи като PRINCE2^(®), PMBOK^(®) Guide, P3.express, PM², DSDM^(®), XP и Scrum. Въпреки, че NUPP (ПУПП) може да има разминаване с някои методологии, ПУПП насърчава използващите го да преусмислят техните тълкувания. - NUP1 — Бъдете ориентиране към постигане на резултати и истината за съпричастност - NUP2 — Запазвайте и оптимизирайте ресурсите и енегията си - NUP3 — Винаги бъдете инициативни - NUP4 — Не забравяйте, че една верига е толкова силна, колкото най-слабото й звено - NUP5 — Не правете нищо без ясна цел - NUP6 — Използвайте повторяеми елементи ## NUP1 Бъдете ориентиране към постигане на резултати и истината за съпричастност [image] Хората имат вродена склонност да бъдат част от група, което, в повечето случаи, преминава отвъд основната идея да бъдеш част от нея, създава силно чувство за съпричастност и води до проблеми. Ние губим повече отколкото печелим в съпричастността си. Ние може да станем по-големи професионалисти и ефективни експерти, ако не органичаваме нашата индентичност и съпричастност с дадени групи. ### Пример: Agile срещу Waterfall Група от силно мотивирани хора, които били достатъчно смели да опитат да адаптивни подходи при в ИТ разработки, във времената, когато догмата била да се използват стандартните предсказуеми методи, се събрали и кръстили този метод Agile. Това би било страхотна инициатива, да не се ограничава избора в рамките на необходимото. Въпреки, че има много ентусиазирани и ориентирани към постигането на резултати хора в Agile общността, то все още има членове, които издигат Agile в култ и считат останалите за врагове. Това води до различни проблеми: - Не им позволява да научат нищо ново извън тяхната организация - Обезкуражава външни хора да научат нещо за тях - Превръща съпричастността към групата в нешо по-важно от реалната цел, което пречи да се разбере и осъзнае същносттна на Agile Този проблем може да бъде значително намален, и дори разрешен, ако Agile не бъде използван единствено като етикет означаващ определен подход за разработка, а, по-скоро, като общност от хора, които считат себе си за създатели и лидери използващи Agile като средство за постигане на целите си, а не идентифицайраки се с него. За истинския професионалист, войната Agile срещу Waterfall не същестува. ### Пример: PRINCE2^(®) vs. PMBOK^(®) Има много професионалисти в oбщността, които се асоциират или с Prince 2 или с PMBOK^(®) методологията (обикновено, заради тяхното географско разположение) и съответно не са запознати с другия метод. Всеки от нас може да има предпочетания, но да не се индефицира с тях. По-важно е да се запознаем с другите методологии, за да разширим кръгозора и избора си от ресурси. Истинският професионалист е отворен към всички идеи, търси ги, изучава ги, и ги използва, когато е необходимо без предрасъдъци и чувство за съпричастност. ### Пример: Непрекъснато обучение Съпричастността задоволява усещането на човека за принаджленост към дадена група и не го подтиква да учи, а понякога и го обезкуражава от страх да не бъде вече част от групата. Когато си свободен човек, експерт без принадлежност към дадена група, ти имаш нужда да запълваш недостатъците на дадената група със знания: с непрекъснато обучение. Това, в което вярваме днес, не е истината. Това е само най-доброто ни възприятие и разбиране на нещата към момента, което трябва да развием за напред. Има нещо объркано, ако нечий идеи са съвсем същите, както са били преди няколко години. Дори с ПУПП: ако се върнем след няколко години назад и забележем, че принципите съвсем същите, трябва да бъдем мнителни. ### Пример: Отвореност Когато възразявате, постарайте се възражението ви да е насочено към идеята на човека, а не към самия него. Това спомага за избягването на напрежение. От друга страна, когато някой ви възразява, не го възприемайте като война, а като дискуия на идеята ви и отстането отворен (позитивен). Недейте да слушате, за да отговорите, а слушайте, за да разберете и работете с другия човек да доразвиете идеята. Въпреки, че някои хора могат съзнателно да ви нападнат лично, вместо да обсъдят идеята ви. В такъв случай, преди да продължите, помогнете им да се концентрират върху идеята вместо върху вас и поддържайте фокуса по време на целия разговор. ## NUP2 Запазвайте и оптимизирайте ресурсите и енегията си [image] Ресурсите са органичени. Ресурсите за даден проект са ограничени, както е ограничена и менталната енергия необходима ви, за да взимате правилни решения. Трябва да запазите и оптимизирате този ресурс за себе си и за проекта, и да помогнете на другите членове на екипа ви да направят същото. ### Пример: Правилото 80/20 Голяма част от възможните ползи от проектния мениджмънт могат да бъдат постигнати с малко усилия. В повечето случаи, стремежът да се реализират на 100% от възможните ползи е много скъпо и неоправдано. Трябва да се възползвате от това правило във всичко което правите и да насърчавате останалите да правят същото. ### Пример: Умора от вземането на решения Ние имаме един източник на ментална енергия за вземането на решения, както и за запазване на самообладание. Ако използваме прекалено много от енергията си за вземане на ненужни или несъществени решения, ще имаме по-малко сили при вземането на важни решения, което може да доведе до слаби резултати. Това е една от причините да се избягва микро-мениджмънта (принципът на „управление на изключенията“ според Prince2 the “manage by exception” principle of PRINCE2^(®)). Подлагането на дадена идея под съмнение може да бъде полезно, но конфронтирането с хора, обикновено, е погабно за проекта. Едно от последствията е, че може да изцеди менталната енергия на хората от екипа. Ако забележете такова конфронтиране между хора от екипа, трябва да направите всичко възможно да откриете и да я отсраните. ### Пример: Грижете се за себе си Менталната ви енергия се изчерпва, когато взимате решения и запазвате самообладание. От друга страна, енергията се възстановява при правилно хранен и здрав сън. Следователно, трябва да се грижите са себе си: спете достатъчно, за да бъдете отпочинали и се хранете правилно. Ако имате вредни навици или проблеми със съня, може да се обърнете за съвет към специалисти в тези сфери. Физическата активност също може да ви помогне с набавянето на ментални сили, въпреки че проучванията не са катергорични в тази насока. Опитвайте се да мотивирате членовете на екипа да правят същото. Първо, погрижете се да работят с постояннно темпо и без много допълнителни часове. След това, ако имате избор, опитайте да предложите здравословна храна и напитки по време на работния процес. ### Пример: Баланс между работа и личен живот Повечето от нас обичат това, с което се занимават, но това не е всичко, от което се нуждаем в живота. За да направим личният си живот щастлив и забавен, можем да използваме идеи и опита си при планиране и оптимизиране на служебния такъв. Когато сте по-щастливи, може да сте и по-успешни в работата си. Ако имате възможност насърчавайте екипа си да прави същото. ### Пример: Мотивация Мотивацията е сложна сфера. Има много интересни и полезни източници по темата, дори и много ненаучни трудове. Въпреки това, трябва да сте запознати с мотивационната теория и да я използвате непрекъснато, защото тя може да повиши менталните сили на хората от екипа и да помогне за постигането на по-добри резултати за проекта. Мотивирането може да се изрази като просто покажем, че оценяваме труда на колегите си за добре свършената работа с приятелска усмивка или едно „Благодаря“. Трябва, обаче, да бъдем предпазливи, защото понякога някои мотивационни стимули като финансовия, могат да имат отрицателен ефект. ### Пример: Сътрудничество и работа в екип Хората, които си сътрудничат често могат да постигнат по-добри резултати, но по-важното, е че по този начин те са социални и са доволни да бъдат част от група. Ако успеете да премахнете отрицателните аспекти от работата в екип и да създадете благоприятни условия на труд, ще има много по-доволни хора в екипа ви. Трябва да сте внимателни, защото хората са различни и някои имат нужда от повече почивка, по-голяма концентрация, повече социализиране от други, поради тази причина трябва да намерите баланса. ### Пример: Култура на единен екип Има тенденция да се формират по-малки работни (под)групи от заинтересованите лица създава напрежение между тях: например, финансово ориентираните служители срещу служителите, които произвеждат/разработват продукта. Това напрежение отнема много енергия и на двете страни, което е една от причините, поради която ние трябва да изградим култура на единен екип, където всички работят заедно за постигането на обща цел. ### Пример: Мъдростта на тълпата Когато различни хора работят като екип в подходяща среда, потенциално могат да се постигнат много добри резултати, идеи и решения, които даже да са по-добри тези идващи от даден експерт. Ако имате тази възможност, събирайте екипа си регулярно, за да ви помагат при вземато на трудни решения за проекта. Освен възможността да постигнете по-добри резултати, това показва, че оценявате мнението на хората от екипа и те играят важна роля в проекта, което покачва тяхната мотивация и дух. Дейност E02 от P3.express е добър пример за използване на мъдростта на тълпата. ### Пример: Главен проектен посредник Ако сте ръководител проект, повечето от нещата, които правите имат посреднически характер (или поне би трябвало). От друга страна, може да забележите, че хората са имали предишен опит с други мениджъри, който влияе върху сегашните ви взаимоотношения: част от енергията им отива в това да анализират поведението ви за потенциални опасности вместо да ви имат доверие. В този случай, може да си смените титлата на Главен проектов посредник. В крайна сметка, това е ролята, която изпълнявате в рамките на проекта. ## NUP3 Винаги бъдете инициативни [image] По природа имаме склонност да реагираме на дадени неща и ситуации. Това може да ни помогне да запазим енергия занимавайки се с незначителни неща или да постигнем по-добри резултати в област, в която сме напълно некомпетентни. Тези ситуации са различни от нашите проекти и точно в тях, може да постигнем по-добри резултати бъдейки инициативни. ### Пример: Планиране Ако искате да стигнете до непозната локация с кола и закъснявате, то може просто да се качите в колата и да започнете да карате, за да „спестите време“, а да се справяте с евентуалните проблеми по време на пътя (в движение). Проактивният подход е да отделите време в началото, за да настроите навигацията си и тя да ви даде най-бързия път базирайки се на трафика и потенциалните инциденти и задръствания и чак след това да тръгнете на път. Така отделяме време в началото, за да избегнем потенциални проблеми повреме на изпълнението, което накрая води до спестено време. В противовес на това, което някои хора мислят за Agile проектите, планирането е винаги необходимо, но е въпрос на вид и степен на детайлност в плана. Да планираме преди да пристъпим към изпълнение е проактивен подход. Припомнете си цитата: Дайдете ми 6 часа да отрежа дърво и аз ще отделя първите четири часа да наточа брадвата. Ако целта на проекта е ясна и сте сигурни, че трябва да се нареже дърво, то наистина може да отделите 4 часа, за да наточите брадвата. В Agile проектите, не е сигурно, че ще трябва да се нареже дърво или да се съберат отсечените клони или да се окоси тревата или нещо друго. Въпреки това, ще ви е необходима обща подготовка за всички дейности (да знаете къде е най-близкият магазин за резервни части) и малко специфична подготовка (заточване), преди да се фокусирате върху конкретни решения; това е планиране. ### Пример: Планиране на планирането Планиране на начина, по който ще се осъществи проектът е проактивен подход. Тази проактивност може дори да бъде разширена като се планира начина, по който планираме изпълнението на проекта: Според PMBOK^(®) тове е проектния план, според PRINCE2^(®) това са мениджърските стратегии, а според DSDM^(®) това са подходите. ### Пример: Непрекъснато планиране В действителност нещата рядко се получават така, както сме ги планирали, и това е нормално, но ние непрекъснато трябва да адаптираме плановете, за да са реалистични, практични и реализируеми в действителност. Ние трябва да направим промяната в момента, в който е необходима, а не когато вече имаме проблем. Това е проактивен подход. ### Пример: Управление на риска Идеята за управление на риска е базирана на проактивност: при материализирането на несигурни събитие, предварително обмислете възможните последствия и възможните реакции и, съответно, какви действия да предприемете преди да се е случило събитието, вместо да чакате да видите какви ще са последствията, за да предприемете коригиращи действия. Не забравяйте, че това което правим в проектите е сериозно и дори понякога е крие риск за живота на хора. ### Пример: Определете ролите и отговорностите Може да оставите екипа си да работи без да има ясни роли и отговорности (длъжностни характеристики), и рано или късно дадени роли и отговорности ще се обединят, но това може да струва прекалено скъпо за проекта и, в крайна сметка, да няма положителен ефект. Проактивният подход е да определите ролите и отговорностите в ранен етап на проекта и да ги адаптирате спрямо ситуацията. Това ще подобри работния процес на всеки от екипа, и ще му помогне да се фокусира върху изпелнението на поставените задачи вместо да се разпределя коя задача трябва са се свърши и от кого. Броят на ролите и тяхното разнообразие зависи от проекта; може да е опростен вариант както при SCRUM, не сложен вариант като при P3.Express или нещо сложно както при DSDM^(®) и Prince2. Не забравяйте, че тези подходи са за определяне на управленските дейности, в допълнение, трябва да се дефинират и техническите характеристики на ролята. ### Пример: Избор Трябва ли да прекратите проекта преждевременно или да продължите? Рядко има само две възможности, дори и въпросът да загатва за това. Трябва да имате проактивен подход и да обмислите всички възможности преди да вземете решение. Може да преразгледаде обхвата на проекта, може да го преустановите докато не се изясни нещо, или може би да промените подхода за изпълнение (например: аутсорсване) или друго. ### Пример: Критично мислене Всички имаме някакви предрасъдъци, които, от една страна, ни помагат да оцеляваме, но от друга могат да ни подведат да вземем лошо решение. Когато става въпрос за вземане на важни решения за проекта, най-добре е да направим малка пауза за известно време и да обмислим всички предпоставки, които биха повлияли нашето решение преди да предизвикат проблеми. За справка може да използвате списъка за когнитивни предрасъдъци в Wikipedia. Има и методология за вземане на решение, която може да ви помогне. Отначало, може да е разсейващо и дори дразнещо, когато ги употребявате, но след известно време ще свикнете и в последствие ще се научите да извличате ползите от тях без да ви представлява усилие. ### Пример: Прозрачност Не ни е приятно когато задачите по проекта се изпълняват със закъснение или имаме проблеми при изпълнението, но това не означава, че трябва да ги скрием. Трябва да бъдем прозрачни и да информираме заинтересованите страни, защото някои от тях може да са в състояние да ни помогнат и освен това, рано или късно те ще узнаят за проблемите и техните последствия, а за някои от тях ще са необходими по-ранни противодействия (например: за да се приемат негативните последствия). ### Пример: Ефективна комуникация Вероятно е имало случаи, когато сте изпращали отчети до заинтересованите страни и не сте получавали обратна връзка. Може би сте вярвали, че всичко е наред само, защото не е имало негативна реакция макар, в действителност, да не е било така. Трябва да бъдете проактивен и да проверите дали отчетът е бил видян и дали е постигнал целта, да използвате обратна връзка за да подобрите комуникацията. В противен случай, този потенциално скрит проблем може да причини сериозни проблеми на по-късен етап, когато е по-трудно да бъде разрешен. ### Пример: Поемете отговорност Лесно е да се обвиняват другите за слабатие резултати. Например, може да искате фирмата да ви даде цялата власт да промените всичко по проекта и да го направите идеално, но не я получавате и като резултат проектът се проваля. Това не е проактивен подход. Проактивният подход е да поемете цялата отговорност и да направите всичко по силите ви, въпреки ограниченията. Не очаквайте фирмата да ви гласува пълно доверие с надеждата да подобрите резултатите, след като вече са имали толкова провалени проекти. Това, което трябва да направите е да внесете подобрения въпреки ограниченията, да спечелите доверие и така стъпка по стъпка да достигнете до желаната в началото цел. ## NUP4 Не забравяйте, че една верига е толкова силна, колкото най-слабото й звено [image] Има различни области при управлението на проекти и всички те се нуждаят от внимание, т.е необходимо е да имаме цялостен поглед върху проекта. Фокусирането върху една привидно важна област (напр. Време) не е достатъчно, тъй като всички области си взаимодействат и не работят правилно, освен ако не получат адекватно внимание. ### Пример: Всичко опира до крайния срок! Да предположим, че изграждате нещо за Олимпийските игри. Спазването на крайния срок е от изключително значение, което прави управлението на времето много важно. Но дали е така? Какво ще стане, ако качеството на работа е толкова ниско, че изисква тя (или части от нея) да се повторят след време. Това ще се отрази на времето, така че нещата вече опират до време и качество. Може да имате фантастична градина включена в първоначалната дефиниция на проекта, но знаете, че ако няма достатъчно време, можете да я пропуснете и просто да я покриете с трева, стига да сте обмислили тази възможност навреме и да сте се подготвили за нея. Така че, управлението на обхвата също е важно. Сега вече имаме областите на обхвата, времето и качеството в центъра на нашето внимание. Чували ли сте за този известен пример, когато президентът Кенеди се среща с чистач в НАСА и го пита какво прави, а той отговаря: „Аз помагам да се изпрати човек на Луната“. Дали и този тип хора в проекта не спомагат за спазването на крайния срок? Докато напредвате забелязвате, че всяка отделна област в проекта допринася за управлението на времето и не бихте могли да спазите крайния срок с приемливо ниво на сигурност, освен ако не обърнете внимание на всички области. ### Пример: Подбиране на най-доброто (черешката на тортата) Когато хората се сблъскат с различни методи, понякога започват да подбират най-доброто (черешката на тортата) от всеки и създават комбинация от виско което исглежда интересно от различните системи. Това, обикновено, не работи, защото елементите не работят изолирано и трябва да са съвместими един с друг. Всякакви допълнения или промени в системата трябва да се правят от гледна точка на цялото. Ето защо понякога виждаме противоречиви елементи в различни методи, т.е. нещо работи добре в една система, а противоположното му работи добре в друга система. Този елемент сам по себе си не е правилен или грешен. Най-сигурният подход е да се избере методология за проекта, да се приспособи за него, и след това предпазливо да се добавят нови елементи, като се вземе предвид съвместимостта на цялата система. ### Пример: Подходът на антипроцеса Едно от най-добрите неща, които Agile методологиите са направили, е да привлекат вниманието към човешките аспекти. Манифеста за Agile разработка отдава по-голямо значение на индивидите и взаимодействията между тях в сравнение с процесите и инструментите, въпреки че това може да не е справедливо сравнение. Почти всички методологии казват, че човешките аспекти са важни, а истинската разлика в Agile методологията е, че човешките аспекти са част от процесите, а не просто предположение. Така че не става въпрос за конкуренция между човешките аспекти и процеси, а по-скоро за начина, по който човешките аспекти се разглеждат в системата. Няма съмнение, че някои хора се опитват да заменят човешките аспекти, като прилагат по-сложни процеси, но това е само злоупотреба. Дори обратното: хората се опитват да заменят процесите с човешки аспекти, което също не работи добре. ### Пример: Това са всички необходими области Когато мислите за областите, трябва да внимавате да не пропуснете нито една от тях. А какви са те? Ако проверите основните източници, ще получите различни отговори и, все пак, никой от тях не дава цялата истина. Темите на PRINCE2^(®) са области, но това са само областите, които играят ключова роля в методологията. Другите области са само подразбиращи се. PMBOK^(®) ръководството не е методология, но много добре описва десет области на познание. Според него, обаче, това са интерпретации на всички области, което не е непременно неутрална гледна точка. Например, човешките аспекти не получават много внимание в PMBOK^(®) ръководството. Добър източник на информация за областите е ICB (IPMA Competence Baseline), въпреки че не става въпрос за области, а за компетенциите, които се изискват в проекта. Тези компетенции нямат еднозначна връзка с областите, но много помагат при идентифицирането им. Няма списък с области и в ПУПП, главно, защото е мета-система, а не система, а също така и защото категоризацията на областите зависи от вида на проекта и неговата среда. Например, един рутинен строителен проект може да се нуждае от различен подход и гледна точка в сравнение с един творчески изследователски проект. ## NUP5 Не правете нищо без ясна цел [image] Не бива да правите нищо, освен ако нямате ясна цел. Представете си два паралелни свята, където всичко е същото, с изключение на това, което смятате да правите. Колко различни биха били тези светове? Дали разликата си струва усилието да се направи това което смятате да правите? Ако нямате ясна цел и само правите нещо, защото всички останали го правят или всички казват, че е важно да го направите, то: - може да няма реална полза от него във вашия случай и следователно да не получите нищо от това или - все пак, може да има потенциални ползи във вашия случай, но тъй като не сте целенасочени, това което правите и начина по който го правите може да не доведе до реализиране на ползите. ### Пример: Портфолио и програми Ако участвате в подбора и инициирането на проекти, трябва да се уверите, че се фокусирате върху ползите и проблемите, които трябва да бъдат решени, а не върху продукта, който ще реализира тези неща. Класическият пример е производителят на асансьори, който тъй като получавал оплаквания за скоростта на своите асансьори инициирал и ръководил множество проекти за увеличаване на скоростта, без пълен успех. Това продължило докато не решили да се съсредоточи върху проблема (скуката или дискомфорта на хората) вместо с „естественото“ решение (по-бързи асансьори). Резултатът е, че те добавят огледала в асансьорите и решават проблема просто и евтино. Не забравяйте, че в управлението на проекти става въпрос основно да правите нещата правилно, докато управление на портфолио е за правене на правилните неща. Няма значение колко добре управлявате проектите си, тъй като това няма да работи добре, ако правите грешни проекти. Всичко опира до това да имате цел. ### Пример: Проектът като цяло Гъвкавостта на продукта варира между проектите. В някои ИТ проекти продуктът е напълно гъвкав и неговата окончателна версия зависи от обратната връзка, която ще бъде генерирана на всеки етап от разработката му по време на проекта, което изисква адаптивен (Agile) подход. На практика това е комбинация от наслояване на портфолио, програма и проект и се нуждае от максимално внимание към крайната цел. Добра идея е да се документира целта и тя да бъде достъпна. Това е една от целите на „продуктовата визия“, използвана в някои Scrum проекти. Вниманието към стойността на бизнеса в Agile проектите е техният начин да осигурят съответствие с целта. В други видове проекти, където продуктът е относително фиксиран и съществуват други механизми, които да гарантират, че идентифицираният продукт ще задоволи целта, членовете на екипа на проекта могат да прехвърлят голяма част от фокуса си от целта към продукта (следователно, принципът „фокус върху продуктите“ на PRINCE2^(®)). Минималното внимание към целта, обаче, все още е необхоидмо, за да се гарантира, че това, което се разработва, ще задоволи целта, което може да бъде направено чрез сравняване на прогнозираните ползи с очакваните ползи (оттук и принципът на „продължаващата бизнес обосновка“ и темата „бизнес казус“ в PRINCE2^(®)). Когато даден проект се изпълнява за външен клиент, то той ще има своя собствена цел за проекта, а вашата компания ще има различна цел. Трябва да разберете и да следвате и двете, за да успеете наистина. ### Пример: Мониторинг на проекта Необходимо е да се фокусираме върху крайната цел, но, в повечето случай, в ежедневието тя може да бъде твърде абстрактна. Ето защо, за повече практичност, е необходима йерархия на целите. Първо, обосновката и ползите от проекта се дефинират въз основа на крайната цел, което ще ви даде ясни и подразбиращи се цели за променливите на проекта (напр. време, разходи и качество), които да удовлетворят обосновката, която от своя страна ще удовлетвори крайната цел. Това са цели от по-ниско ниво, които са полезни за много от ежедневните ни задачи. Когато става въпрос за мониторинг, мониторингът на проекта на ниско ниво ще се извърши, като се използва най-ниското ниво на променливите, тъй като може да не е възможно да се проследи крайната цел. В този случай все още трябва да имате предвид целите: каква е целта на мониторинга? Нормален и приемлив отговор е да видим дали се движим по план и, ако не, да предизвикаме определена реакция, която ще ни върне обратно в норма. В противен случай ще коригираме целите и ще видим дали все още можем да задоволим крайната цел. Следователно нашите измервания трябва да могат да помогнат с целта на ниско ниво, а подходящите измервания, от друга страна, дават прогнози за променливите накрая. Например, кога ще можем да завършим проекта? Колко пари ще ни трябва, за да приключим проекта? Всички други измервания, като планираните и действителните стойности до момента, са само междинни стойности, които са ви необходими, за да изчислите прогнозите, а не крайните стойности, които използвате за управленски цели. ### Пример: Документи Без значение какъв подход за управление използвате в проекта, планирането винаги е необходимо. Важният въпрос е нивото на детайлност във всеки вид план. Ако няма достатъчно подробности в него, то той няма да бъде достатъчно полезен, а изпълнението на проекта ще се основава на временни решения, а не на интегрирани и цялостни такива. От друга страна, много хора се опитват да бъдат предпазливи и да добавят прекалено много подробности към своя план, което го прави твърде труден да се подготви и поддържа и твърде строг за несигурността на проекта. В резултат на това планът става нереалистичен и безполезен. Най-добрият начин да се определи нивото на детайлност е да определите по една цел за всеки елемент в плана. Например, ако обмисляте добавянето на ресурси към плана, то трябва да имате цел за това: Как ще ги използвате? Как ще помогнат на проекта? Колко усилия ще им отнеме? Струва ли си? Понякога трябва да решите дали искате да имате определен елемент в плана си, а понякога и за начина, по който искате да планирате или подготвите нещо. Независимо дали става дума за бизнес случай, за харта на проекта или за доклад, винаги трябва да се запитате защо подготвяте този документ и как той може да помогне на проекта. Търсенето на „шаблон“ е обратното на правенето на нещо, което се основава на цел. ### Пример: Отчитане на състоянието Често се случва да създадем наистина дълги отчети за състоянието на проекта. Въз основа на този ПУП трябва да се запитаме каква е целта на отчета и как можем да постигнем тази цел, независимо от това, което повечето други хора биха направили. В много случаи това може да ни накара да подготвим прости отчети от една страница, които заинтересованите страни наистина да прочетат и разберат, вместо дълги такива. Това обръща внимание на целта. Ако подготвите отчет на една страница, обаче, някои хора могат да възразят срещу вас и да помислят, че нямате подходяща система за наблюдение. На практика това създава за вас втора цел (освен първата цел, която помага на заинтересованите страни да разберат статуса на проекта) и, за да я задоволите, може просто да създадете втори тип доклад, който е дълъг. Въпреки това няма да го смесвате с първия, защото тези две цели не са еднакви. ### Пример: Бизнес казус и харта на проекта Подготовката на документи като бизнес казус и проектна харта обикновено е скучна, безплодна, бюрократична необходимост за повечето хора, докато тези документи имат валидни цели, които се прилагат за повечето проекти. Ако се опитате да намерите „шаблон” и да го попълните, усилието е просто пропиляно. Като се има предвид, че вместо това можете да проверите истинската цел на този документ, да видите дали и как той може да бъдат полезен за вашия проект, и след това да го подготвите по какъвто желаете начин, само за да удовлетворите тези цели, то това ще бъде правилният документ. Докато мислите за начина, по който можете да подготвите документите, за да задоволите техните цели, може да не мислите за всеки сценарий и да пропуснете нещо. За да избегнете това, можете да проверите какви ресурси предлагат PRINCE2^(®) , PMBOK^(®) ръководстворо, P3.express и DSDM^(®) и след това да оцените тези предложения въз основа на целите. ### Пример: Пост-проект Въпреки че проектът има конкретна цел и ние можем да я разгледаме по време на проекта, реализирането й се оценява основно въз основа на прогнозите, направени по време на проекта. Не трябва обаче да забравяме за това, когато той приключи. Важно е да се провери реализацията на целите след приключване на проекта, защото - можем да видим как са постигнати крайните цели и да използваме наученото при бъдещи проекти и - понякога целите се постигат само когато изпълним някои допълнителни задачи след приключването на проекта, а разбирането на необходимостта от тези допълнителни задачи се нуждае от мониторинг. Мониторингът след приключване на проекта е необходима стъпка за постигане на целта. Това е основна отговорност на системите за управление на програми и портфолио и, тъй като повечето компании нямат такива нива на управление, тази стъпка обикновено се пренебрегва. Ето защо методи като P3.express и DSDM^(®) добавят тази стъпка към техните методологии за управление на проекти. ### Пример: Простота Светът е сложен и хаотичен, но нашите модели са абстрактни приближения, които отразяват части от света и следователно могат да бъдат прости. От друга страна, простите системи обикновено работят по-добре, защото можем да се фокусираме върху основната идея. Много от нас се опитват да постигнат по-добри резултати, като добавят сложност към нашите системи, надявайки се, че това ще съответства на сложността на света, въпреки че на практика това прави системата трудна за работа и, обикновено, ни пречи да изпълним целта. ### Пример: Приспособяване Част от софтуер за стрийминг на музика, например, има много различни условия за разработка и управление на проекта от тези, които ще се разглеждат при оборудване в болница или на самолет, където животът на хората може да зависи от продукта, или пък от софтуер, който ще се използва в сателит, който се предполага, че ще работи много години, без да се срине. И всички те са различни от изграждането на лятна вила, противопожарна станция и технологичен завод. Когато имате предвид целите, ще разберете по-добре как да приспособите системите и артефактите при управлението на различни проекти. ## NUP6 Използвайте повторяеми елементи [image] Моментният (ad hoc) подход към проекта отнема твърде много енергия и ресурси, при което рискувате да пропуснете някой от необходимите елементи. Най-добрият начин за опростяване на това, което трябва да се направи, е да се използват повтаряеми елементи и, за предпочитане, в повтарящи се цикли. ### Пример: Контролни списъци за качеството Използването на пълен списък за бърза справка е прост пример за потенциално повтаряем елемент, който много хора използват в личния и професионалния си живот. Вземете критериите за качество на даден краен продукт или услуга, например: - Първо, можете да създадете пълен списък с всички критерии, което е форма на планиране. - Това, което ПУП6 препоръчва, е да се опитате да обобщите ситуацията: има ли сходни продукти или услуги, върху които да работите повреме на проекта? В такъв случай подгответе общ контролен списък за тази категория продукти или услуги и го използвайте за всички. Ако има някои вариации, то запазете общия списък и добавете няколко допълнителни елемента за отделните случаи. Сега имате повторяеми контролни списъци. - След като подготвите общите контролни списъци за различни видове продукти/услуги, можете да намерите елементи, които се повтарят сред тях, което предполага мета категория. В този случай, вместо да повтаряте елементите за всички тях, можете да ги обобщите и да ги поставите в главен контролен списък. В крайна сметка, вероятно ще имате един общ контролен списък за целия проект. „Дефиницията на завършено“ от Scrum е пример за използване на контролни списъци за качество на ниво проект (възможно е и използването му за други неща). Правейки това, всеки продукт или услуга ще принадлежи към йерархия от категории и трябва да удовлетворява елементите от контролните списъци на всички категории в тяхната верига. По този начин един елемент от главения контролен списък ще стане повторяем за всички продукти или услуги под него, което спестява време и енергия при планирането и изпълнението. По-важното е, че след като направите това за един проект, можете да го приспособите и да го използвате за всички подобни проекти в бъдеще, което е повторяема форма на планиране за множество проекти. ### Пример: Процеси и работни потоци Някои продукти или услуги или цели свързани с тях се нуждаят от определени стъпки, които могат да станат стандартизирани и повтаряеми. Например, ако продуктите или услугите трябва да бъдат проектирани индивидуално и одобрени, то можете да разработите прост работен поток, който изяснява всички стъпки, заинтересовани лица и приблизително времетраене, така че да се избегнат много трудности. Трябва, обаче, да внимавате да не правите работните потоци и процеси твърде сложни или твърде бюрократични, тъй като това би имало негативни последици. Всички хора, участващи в проекта трябва да приемат работните потоци и процеси като нещо, което подпомага тяхната работа и прави всичко по-лесно за тях, а не като бюрократична документация, която блокира дейността им. Гъвкавите проекти имат повторяеми елементи в техния итеративен подход на разработване, където някои видове дейности при разработката се повтарят за всяко изискване. Например, обичайната рутинна работа в XP (eXtreme Programming): свържете, изберете елемент, проектирайте го на бяла дъска, изградете тестови скриптове и код, интегрирайте кода и т.н. Освен повтарящите се работни потоци, които могат да се използват за оперативни дейности, може да имате и повторяеми елементи за дейностите по управление на проекти. Примери за тази концепция са процесите в PMBOK^(®) ръководството, PRINCE2^(®) и DSDM^(®), дейностите в P3.express и събитията в Scrum. ### Пример: Цикли Изготвянето на повтарящи се елементи за управление на проекта е полезно. Това може да се направи още по-лесно, като тези елементи се поставят в повторяеми цикли. Тези цикли значително опростяват ежедневните дейности на хората участващи в управлението и ръководенето на проекта. Всички примери за това понятие са: циклите на групите от процеси в PMBOK^(®) ръководството, когато се използват в проект с множество фази; етапите в PRINCE2^(®) ; дневните, седмичните и месечните цикли в P3.express; итерациите и времевите кутии в DSDM^(®) и спринтовете в Scrum. По-кратките цикли са по-лесни за разбиране и използване от по-дългите. Например, спринтовете в Scrum за разлика от фазите, съгласно PMBOK^(®) ръководството. Въпреки това, цикли, които са твърде кратки, може да не са достатъчни при определени видове проекти. Решение на това може да бъде използването на няколко цикъла, като употребата на кратки времеви цикли при DSDM^(®) заедно с по-дълги поетапни цикли или използване на ежедневни, седмични и месечни цикли при P3.express. ### Пример: Методи Друг пример за употреба на повторяеми елементи е използването на методология или рамка за изпълнение на проекта. Това може да бъде съществуваща система като PRINCE2^(®) , P3.express, DSDM^(®) , или Scrum, или такава, която да приспособите или изградите сами. Обикновено е по-добра идея да започнете с един от съществуващите методи и да го адаптирате към нуждите си, отколкото да го изградите от нулата. Всеки повтарящ се елемент е абстрактен и се нуждае от приспособяване, за да се адаптира към реалния свят. Можем да говорим за спектър от абстракция и необходимост от приспособяване, където в единия край на спектъра с най-малко абстракция и необходимост от приспособяване са малки, относително конкретни контролни списъци за качество, а методологиите са на другия край, с най-голяма нужда от приспособяване. Винаги трябва да обърнете внимание на необходимостта от приспособяване, в противен случай повторяемият елемент няма да отговаря на вашите нужди по подходящ начин.