# NUPP Амаль універсальныя прынцыпы праектаў [image] Гэта версія анлайн-дапаможніка для спампоўвання (https://omimo.org/be/modules/nupp/), згенераваная 2026‑07‑02. Праверце вэб-сайт на наяўнасць новых версій. NUPP паходзіць ад OMIMO (https://omimo.org/be/), сямейства адкрытых мінімалістычных модуляў. Гэты дапаможнік можна свабодна выкарыстоўваць і распаўсюджваць у адпаведнасці з ліцэнзіяй Creative Commons Attribution 4.0 International. OMIMO сумесна фінансуецца Еўрапейскім Саюзам. Аднак выказаныя погляды і меркаванні належаць выключна OMIMO і не абавязкова адлюстроўваюць пазіцыю Еўрапейскага Саюза або EPOS VZW. Ні Еўрапейскі Саюз, ні орган, які прадастаўляе грант, не могуць несці адказнасць за іх. Пераведзена: Kristina Mozhei, Dmytro Lukianov. ## Introduction NUPP - гэта набор амаль універсальных праектных прынцыпаў, якім лепш прытрымлівацца ва ўсіх праектах, незалежна ад выкарыстоўваных метадалогій і падыходаў, калі мы хочам дамагчыся поспеху. Кожны з вядомых падыходаў і метадаў для кіравання праектам абапіраецца на некаторыя з гэтых NUP (амаль універсальныя прынцыпы). Аднак, неабходна ўлічваць наступныя моманты: - Звычайна, выкарыстоўваюцца не ўсе прынцыпы, а для практыкаў было б карысна разгледзець усе NUP, а не паасобку. - Асноватворныя прынцыпы звычайна недастаткова растлумачаны ў падыходах і метадах, і большасць практыкаў настолькі захопленыя практычнымі дэталямі, што забываюць аб прынцыпах і робяць рэчы, якія несумяшчальныя з імі. NUPP сумяшчальны з усімі асноўнымі метадамі, сістэмамі, рэсурсамі і асяроддзямі, такімі як PRINCE2^(®), PMBOK^(®) Guide, P3.express, PM², DSDM^(®), XP і Scrum. Аднак, гэта можа быць несумяшчальна з пэўнымі інтэрпрэтацыямі гэтых сістэм, і менавіта тут NUPP спрабуе заахвоціць практыкаў перагледзець свае інтэрпрэтацыі. NUPP - гэта калекцыя наступных NUP: - NUP1 — выбірай вынікі і праўду, а не прыхільнасці - NUP2 — беражы і аптымізуй энергію і рэсурсы - NUP3 — заўсёды будзь проактыўным - NUP4 — памятай, што трываласць ланцугі вызначаецца па самаму слабаму звяну - NUP5 — не рабі нічога без выразнай мэты - NUP6 — выкарыстоўвай прайграваныя элементы ## NUP1 выбірай вынікі і праўду, а не прыхільнасці [image] Ва ўсіх нас ёсць натуральнае імкненне належаць да груп, імкненне, якое часцяком выходзіць за рамкі першапачатковай формы, стварае трывалыя сувязі і выклікае праблемы. З-за прыхільнасцяў, мы губляем нашмат больш, чым знаходзім. Не абмяжоўваючы сваю ідэнтычнасць і погляды прыхільнасцямі, мы можам дамагчыся больш, як прафесіяналы. ### Прыклад: Agile vs Waterfall Група энтузіястаў, дастаткова смелых, каб паспрабаваць адаптыўны падыход у ІТ у той час, калі нормай было выкарыстоўваць прэдыктыўны, сабраліся разам і назвалі свой падыход «Agile». Гэта была выдатная ініцыятыва: не абмяжоўваць свой выбар тым, што здавалася абавязковым. У Аgile супольнасці, па-ранейшаму, шмат энтузіястаў і людзей, арыентаваных на вынік, але, на жаль, ёсць людзі, якія ператвараюць Agile ў культ, і якія лічаць усіх навокал ворагамі. Гэта выклікае праблемы, напрыклад: - Гэта не дазваляе ім вучыцца ў каго-небудзь за межамі іх групы. - Гэта перашкаджае староннім вучыцца ў іх. - Гэта робіць прыналежнасць да групы больш важнай, чым рэальная мэта, што, у сваю чаргу, перашкаджае многім яе членам даведацца аб праўдзівам значэннi Agility. Гэтую праблему можна зняць, калі выкарыстоўваць тэрмін «Agile» у дачыненні да падыходу да распрацоўкі, а не супольнасці; і калі людзі, якія лічаць сябе стваральнікамі, решацелямі праблем і лідэрамі, будуць разглядаць Agile як адзін з інструментаў, а не як сваю ідэнтычнасць. Для сапраўдных прафесіяналаў не існуе вайны паміж Agile і вадаспадам. ### Прыклад: PRINCE2^(®) vs PMBOK^(®) Guide У супольнасці ёсць шмат прафесіяналаў, якія звязваюць сябе з PRINCE2^(®) або PMBOK^(®) Guide (звычайна з-за свайго геаграфічнага становішча) і не знаёмыя з іншымі падыходамі. Ва ўсіх нас могуць быць перавагі ў дачыненні да пэўных інструментаў, але не варта сябе з імі ідэнтыфікаваць - важней азнаёміцца з усімі, каб пашырыць нашыя гарызонты. Сапраўдны прафесіянал адкрыты для ўсіх ідэй, шукае іх, пазнае пра іх і выкарыстоўвае, калі патрабуецца, па-за залежнасці ад прыхільнасцяў. ### Прыклад: бесперапыннае навучанне Прыхільнасці задавальняюць чалавека пачуццём прыналежнасці, якое яны спараджаюць, але не прымушаюць, а часам нават замінаюць яму вучыцца з-за страху страціць гэта пачуццё. Калі вы вольны чалавек, эксперт без прыхільнасцяў, вам неабходна запоўніць прабел навучаннем - няспынным навучаннем. Тое, што мы ведаем сёння, не з’яўляецца ісцінай у апошняй інстанцыі. Гэта толькі наша разуменне праўды ў моманце, якое трэба паляпшаць, рухаючыся наперад. Калі вашыя погляды за некалькі гадоў наогул не памяняліся, што-то пайшло не так. Гэта дакладна і ў выпадку з NUPP: калі вы звернецеся праз некалькі гадоў і ўбачыце ўсё тое ж самае, у вас павінна закрасціся сумненне. ### Прыклад: адкрытасць Запярэчу камусьці, пераканайцеся, што вашы пярэчанні накіраваны на ідэю, а не на чалавека. Гэта дапаможа знізіць напружанасць. Аналагічна, калі хто-небудзь пярэчыць вам, паспрабуйце не прымаць гэта на свой рахунак, сфакусуйцеся на абмеркаванні ідэй. Не трэба слухаць, каб адказаць, трэба слухаць, каб зразумець. Працуйце з іншымі людзьмі, каб развіваць вашыя ідэі. ## NUP2 беражы і аптымізуй энергію і рэсурсы [image] Рэсурсы абмежаваныя. Рэсурсы, даступныя для праекта, абмежаваныя гэтак жа, як і разумовая энергія, неабходная для прыняцця правільных рашэнняў. Вы павінны берагчы і аптымізаваць гэты рэсурс для сябе і для праекта, і дапамагаць іншым чальцам каманды рабіць тое ж самае. ### Прыклад: правіла 80/20 Большую частку магчымых выгод ад кіравання праектамі можна атрымаць, выдаткаваўшы невялікую частку намаганняў. У большасці выпадкаў імкненне да атрымання 100% магчымых выгод занадта дорага і неапраўдана. Улічвайце гэта правіла ва ўсім, што робіце і падахвочвайце да гэтага іншых. ### Прыклад: стомленасць ад прыняцця рашэнняў Мы выкарыстоўваем адзінаю крыніцу разумовай энергіі для прыняцця ўсіх тыпаў рашэнняў, а таксама для праявы сілы волі. Калі выкарыстоўваць яго для прыняцця непатрэбных або няважных рашэнняў, у вас будзе менш энергіі для важных рашэнняў, што прывядзе да дрэнных вынікаў. Гэта адна з прычын, па якой лепш пазбягаць мікрамэнэджмента (прынцып PRINCE2^(®) «упраўленне па выключэнняў»). Канфлікты, звязаныя з ідэямі, могуць быць карысныя, але канфлікты, звязаныя з людзьмі, звычайна шкодныя для праекта, і адно з наступстваў гэтага заключаецца ў тым, што ён высільвае разумовую энергію членаў каманды. Калі вы заўважылі такі канфлікт, зрабіце ўсё магчымае, каб знайсці прычыну і ліквідаваць яе. ### Прыклад: беражы сябе! Рашэнні, якія вы прымаеце, і сіла волі, якую вы выказвае, расходуюць вашу разумовую энергію. З іншага боку, энергія папаўняецца, калі вы спіце і правільна харчуецеся. Значыць, вы павінны добра клапаціцца пра сябе: пераканайцеся, што ў вас дастаткова сну і адпачынку, і добра сілкуйцеся. Калі ў вас ёсць шкодныя звычкі або праблемы са сном, не варта змагацца з імі ў адзіночку. Ёсць шмат спецыялістаў, гатовых дапамагчы вырашыць такія праблемы. Фізічная актыўнасць таксама можа дапамагчы з папаўненне энергіі, хоць даследаванні на тэму не даюць адназначных высноў. Падахвочвайце членаў каманды рабіць тое ж, што і вы. Па-першае, пераканайцеся, што яны працуюць ва ўстойлівым тэмпе і без лішніх перапрацовак. Калі ў вас ёсць магчымасць, прапануйце пажыўную здаровую ежу і напоі ў працоўны час. ### Прыклад: баланс паміж працай і асабістым жыццём Шмат хто з нас любяць сваю працу, але гэта яшчэ не ўсё, што нам трэба ў жыцці. Сапраўды гэтак жа, як вы аптымізуеце сваю працу, вы павінны планаваць і рэалізоўваць ідэі ў сваім асабістым жыцці такім чынам, каб яно былы радасным і шчаслівым. Калі вы шчаслівыя ў жыцці, вы больш паспяховыя і на працы. Калі можаце, паспрабуйце заклікаць членаў вашай каманды зрабіць тое ж самае. ### Прыклад: матывацыя Матывацыя - складаная канцэпцыя. Ёсць некалькі цікавых і карысных рэсурсаў па гэтай тэме, у тым ліку і ненавуковыя. Тым не менш, карысна даведацца больш аб матывацыі і імкнуцца пастаянна ўжываць яе у працы, так як гэта павялічвае разумовую энергію каманды і магчымасць дасягнення лепшых вынікаў для праекта. Матывацыя можа прымаць такія простыя формы як ўсмешка і «дзякуй» у знак прызнання працы. Дадаткова звярніце ўвагу, што некаторыя з распаўсюджаных формаў матывацыі, напрыклад, невялікія грашовыя ўзнагароды, могуць даць адмоўны эфект. ### Прыклад: супрацоўніцтва і камандная праца Супрацоўнічаючы, людзі могуць дамагацца лепшых вынікаў, але што яшчэ больш важна, мы па сваёй прыродзе таварыскія і любім быць часткай групы. Калі вы зможаце ліквідаваць негатыўныя аспекты каманднай працы і стварыць спрыяльную абстаноўку, ваша каманда стане больш шчаслівей. Вы павінны быць асцярожныя, таму што людзі розныя, і некаторым трэба праводзіць час у цішыні і адзіноце - неабходна выконваць баланс. ### Прыклад: культура адной каманды Розныя зацікаўленыя стораны маюць тэндэнцыю групавацца, што выклікае напружанасць у адносінах з іншымі групамі; напрыклад, людзі, якія сканцэнтраваны на бізнес-аспектах праекта vs людзі, якія ствараюць прадукт. Гэта напружанне спажывае шмат энергіі з абодвух старон, і гэта адна з прычын, па якой мы павінны паспрабаваць стварыць культуру адной каманды, дзе ўсе працуюць разам для дасягнення адной мэты. ### Прыклад: мудрасць натоўпу Калі вялікая колькасць людзей з розным вопытам і поглядамі збіраюцца разам і працуюць у спрыяльнай асяроддзі, ёсць патэнцыял для атрымання вельмі добрых вынікаў, ідэй і рашэнняў, якія могуць быць нават лепш, чым тыя, што прыходзяць ад асобных экспертаў. Калі ў вас ёсць такая магчымасць, рэгулярна прыцягвайце каманду да вырашэння складаных пытанняў. Акрамя магчымасці атрымання добрых вынікаў, гэта таксама дае ведаць членам каманды, што іх меркаванне цэніцца і што яны атрымліваюць важную ролю ў праекце, што, у сваю чаргу, павышае іх узровень энергіі. Тэхніка на кроку E02 з P3.express з’яўляецца прыкладам выкарыстання мудрасці натоўпу ў праектах. ### Прыклад: галоўны фасілітатара праекта Калі вы менеджэр праекта, вялікая частка вашай працы мае характар фасілітацыі (ці, па меншай меры, павінна мець). З іншага боку, вы можаце бачыць, што члены каманды ў мінулым мелі негатыўны вопыт работы з мэнэджэрамі праектаў, і што гэты вопыт ўплывае на іх адносіны з вамі: замест даверу частка іх энергіі выдаткоўваецца на аналіз вашых паводзін на прадмет патэнцыйных пагроз. У такім выпадку вы можаце змяніць сваю пасаду з кіраўніка праекта на галоўнага фасілітатара праекта. У канечным ітозе, гэта тое, што вы сапраўды робіце ў праекце. ## NUP3 заўсёды будзь проактыўным [image] Мы схільныя быць рэактыўнымі, а не проактыўнымі. Гэта можа дапамагчы нам захаваць нашу энергію пры вырашэнні другарадных задач, або можа даць нам лепшыя вынікі, калі мы маем справу з чымсьці, у чым мы зусім некампетэнтныя. Гэтыя сітуацыі адрозніваюцца ад нашых праектаў, і тут мы можам дамагчыся лепшых вынікаў, праявіўшы ініцыятыву. ### Прыклад: планаванне Калі вы вырашылі кудысьці паехаць і ўжо спазняецеся, можна выехаць адразу, каб «сэканоміць час», а магчымыя праблемы вырашаць па меры з’яўлення. Проактыўны падыход складаецца ў тым, каб выдаткаваць некаторы час і спачатку пабудаваць самы хуткі маршрут, які ўлічвае пробкі, аварыі і перакрыцці, а затым ехаць; гэта зойме час, але ў выніку вы яго сэканоміце, пазбегнуўшы праблем. Нягледзячы на тое, што некаторыя людзі думаюць пра Agile праектах, планаванне неабходна заўсёды, і яно залежыць толькі ад тыпу і ўзроўню дэталізацыі. Планаванне перад выкананнем з’яўляецца проактыўны падыходам. Памятаеце выраз: дайце мне шэсць гадзін, каб ссекчы дрэва, і я правяду першыя чатыры завострывання сякеры. Калі гэта прэдыктыўны праект, вы можаце выдаткаваць 4 гадзіны на завострыванне сваей сякеры, таму што вы ўпэўненыя, што збіраецеся ссекчы дрэва. У Agile праекце вы не ўпэўненыя, ці збіраецеся вы секчы дрэва, збіраць зламаныя галіны, стрыгчы газон, здабываць вугаль ці нешта яшчэ. Тым не менш, вам усё роўна трэба падрыхтавацца да гэтых работ у цэлым (даведацца, дзе бліжэйшая крама інструментаў) і падрыхтавацца да канкрэтных работ (завастрыць сякера), калі вы выберыце канкрэтнае рашэнне - гэта таксама планаванне. ### Прыклад: падрыхтоўка к планаванню Планаванне таго, як мы збіраемся выканаць праект, з’яўляецца проактыўным падыходам. Такая проактыўнасць можа быць нават пашырана шляхам планавання таго, як мы будзем планаваць выкананне. Гэта план кіравання праектам з Кіраўніцтва PMBOK^(®), стратэгіі кіравання PRINCE2^(®) і падыходаў DSDM^(®). ### Прыклад: бесперапыннае планаванне Рэальнасць рэдка адпавядае таму, што мы запланавалі, і гэта нармальна, але мы павінны пастаянна адаптаваць нашы планы, каб яны заставаліся рэалістычнымі і практычны. Мы павінны рабіць гэта адразу, як толькі патрабуецца карэкціроўка, а не калі мы ўжо сутыкнуліся з праблемамі. Гэта проактыўны падыход. ### Прыклад: кіраванне рызыкамі Уся канцэпцыя кіравання рызыкамі заснавана на проактыўнасці: сутыкаючыся з нявызначанасцю, мы не чакаем, што адбудзецца, каб потым адрэагаваць, а загадзя думаем пра магчымасці і наступствах, разглядаем меры рэагавання і, верагодна, нешта робім да таго, як рызыка рэалізуецца. Памятаеце, што тое, што мы робім у праектах, сур’ёзна, часам гэта закранае чыесьці жыцце. ### Прыклад: вызначэнне роляў і абавязкаў Вы можаце пакінуць членаў праектнай каманды працаваць без дакладных роляў і абавязкаў, і рана ці позна з’явіцца форма роляў і абавязкаў, але гэта занадта дорага і можа не спрацаваць. Проактыўны падыход складаецца ў тым, каб вызначыць ролі і абавязкі на ранняй стадыі і адаптаваць іх па меры неабходнасці. Гэта палягчае працу для ўсіх, і яны могуць засяродзіцца на стварэнні прадукту, замест таго, каб вырашаць, хто чым займаецца. Колькасць і разнастайнасць роляў залежаць ад тыпу і памеру праекта; іх набор можа быць строга вызначаны, як, напрыклад, у Scrum, умерана, напрыклад, у P3.express, або усёабдымна, як у DSDM^(®) і PRINCE2^(®). Аднак не забывайце, што апісання роляў у гэтых метадах тычацца толькі кіраўніцкіх аспектаў, - вам заўсёды трэба дадаваць апісання роляў і для тэхнічных аспектаў. ### Прыклад: даступныя варыянты Ці варта заўчасна зачыніць праект або працягнуць? Вельмі рэдка ў нас сапраўды ёсць толькі два варыянты, нават калі пытанне мае на ўвазе гэта. Вам трэба праяўляць проактыўны падыход і абдумаць усе варыянты, перш чым прымаць рашэнне. Можа быць, вы можаце змяніць праект; магчыма, вы можаце прыпыніць яго, пакуль нешта яшчэ не стане ясным; ці, можа быць, вы можаце змяніць падыход да праекту (напрыклад, аўтсорсінг) і г. д. ### Прыклад: крытычнае мысленне Ва ўсіх нас шмат прадузятасцяў, якія, з аднаго боку, дапамагаюць нам выжываць, а з другога - прыводзяць да няякасным рашэнням. Прымаючы важныя рашэнні па праекце, лепш за ўсё ўзяць паўзу і разгледзець ўсе прадузятасці, якія могуць паўплываць на наша рашэнне, перш чым яны выклічуць праблемы. У якасці спасылкі вы можаце выкарыстоўваць спіс кагнітыўных скажэнняў, прыведзены ў Вікіпедыі. Ёсць нават спецыяльныя фреймворкі, якія вы можаце выкарыстоўваць для атрымання якасных рашэнняў. Спачатку іх выкарыстанне можа адцягваць і нават раздражняць, але неўзабаве вы прывыкае да іх і атрымліваеце ад іх перавага без асаблівых свядомых высілкаў. ### Прыклад: празрыстасць Нам не падабаецца зрываць тэрміны або сутыкацца з іншымі праблемамі, але гэта не значыць, што іх трэба хаваць. Вы павінны захоўваць празрыстасць і адкрыта паведамляць аб праблемах стэйкхолдэрам, таму што некаторыя з іх могуць вам дапамагчы, і, акрамя таго, рана ці позна яны ў любым выпадку даведаюцца аб праблемах і іх наступствах, а некаторыя з іх могуць запатрабаваць хутчэйшых дзеянняў з іх боку (напрыклад, прыняць негатыўныя наступствы). ### Прыклад: мець эфектыўныя зносіны Бывае, што вы адпраўляеце справаздачу стэйкхолдэрам і не атрымліваеце зваротнай сувязі. Вы можаце падумаць, што ўсё ў парадку толькі таму, што адмоўных водгукаў няма, хоць гэта можа быць і не так. Вы павінны быць проактыўнымі і правяраць, азнаёміліся ці яны са справаздачай і паслужыў ён дасягнення сваёй мэты, і выкарыстоўваць гэтую інфармацыю для ўдасканалення камунікацый; у адваротным выпадку, гэтая прыхаваная праблема можа выклікаць сур’ёзныя праблемы пазней, калі яе будзе занадта цяжка выправіць. ### Прыклад: бярыце на сябе адказнасць Лёгка вінаваціць іншых у дрэнных выніках. Напрыклад, вы хочаце, каб ваша арганізацыя прадставіла вам карт-бланш, і вы зробіце праект ідэальна, але яны гэтага не робяць, і ў выніку праект трымае няўдачу. Гэта не проактыўны падыход. Проактыўны падыход заключаецца ў тым, каб узяць на сябе адказнасць і рабіць усё магчымае ў рамках існуючых абмежаванняў. Не варта чакаць, што арганізацыя цалкам вам давярае і дасць зялёнае святло ў надзеі на лепшыя вынікі, асабліва калі яны ўжо бачылі няўдалыя праекты. Зрабіце адно невялікае паляпшэнне ў рамках існуючых абмежаванняў і выкарыстоўвайце яго, каб заваяваць давер, трохі больш рэсурсаў і цярпення, а затым выкарыстоўвайце гэта для крыху большага паляпшэння і так да таго часу, пакуль не дасягне сваёй мэты. ## NUP4 памятай, што трываласць ланцугі вызначаецца па самаму слабаму звяну [image] У праектах ёсць розныя дамены, і ўсе яны патрабуюць увагі; у нас павінна быць цэласная карціна праекта. Недастаткова звярнуць увагу на, здавалася б, самы важны дамен (напрыклад, тэрміны), таму што ўсе дамены ўзаемазвязаны. ### Прыклад: гэта ўсё аб дэдлайне! Дапусцім, вы будуеце што-то для Алімпійскіх гульняў. У праекта вельмі строгі дэдлайн, што робіць кіраванне тэрмінамі вельмі важным. Ці так гэта? Што калі якасць настолькі нізкая, што праз некаторы час патрабуецца паўторная праца. Гэта паўплывае на час, значыць, трэба надаваць увагу якасці ў тэрмінах. У вас можа быць мудрагелісты сад, названы ў першапачатковым вызначэнні праекта, але вы ведаеце, што калі не хапае часу, вы можаце прапусціць яго і проста замяніць траўнікам, калі вы своечасова разгледзелі гэтую магчымасць і падрыхтаваліся да яе. Такім чынам, кіраванне зместам таксама важна. Цяпер змест, час і якасць у цэнтры нашай увагі. Вы чулі пра знакаміты выпадак, калі прэзідэнт Кэнэдзі сустрэў прыбіральніка ў NASA і спытаўся ў яго, што ён робіць? Прыбіральнік адказаў: «Я дапамагаю пасадзіць чалавека на Луну». Хіба такія людзі ў праекце не дапамагаюць выканаць яго ў тэрмін? Працягваючы, вы заўважаеце, што кожны асобны дамен у праекце спрыяе кіраванні тэрмінамі, і вы не можаце ўкласціся ў тэрмін з прымальным узроўнем верагоднасці, калі не зважаеце на ўсе дамены. ### Прыклад: выбарачныя запазычанні Калі людзі сутыкаюцца з рознымі метадамі, часам яны пачынаюць рабіць выбарачныя запазычанні і ствараюць сумесь за ўсё, што здаецца ім цікавым з розных сістэм. Гэта звычайна не працуе, таму што элементы не працуюць ізалявана і павінны быць сумяшчальныя адзін з адным. Любыя дапаўненні або змяненні ў сістэме павінны быць зроблены з комплекснай пункту гледжання. Таму мы часам бачым супярэчлівыя элементы ў розных падыходах; нешта добра працуе ў адным, а яго супрацьлегласць добра працуе ў іншым. Самі па сабе гэтыя элементы не з’яўляюцца ні правільнымі, ні няправільнымі. Самы бяспечны падыход - гэта выбраць метадалогію для праекта, адаптаваць яе, а затым асцярожна дадаць да яе новыя элементы, улічваючы цэласнасць ўсёй сістэмы. ### Прыклад: антыпрацесный падыход Адна з лепшых рэчаў, якую зрабілі Agile-метады, - прыцягненне ўвагі да чалавечых аспектах. Agile Manifesto дае вялікую каштоўнасць асобным асобам і узаемадзеянням у параўнанні з працэсамі і прыладамі, хоць гэта можа і не быць справядлівым параўнаннем. Амаль усе падыходы прызнаюць важнасць чалавечага аспекту, але менавіта ў Agile чалавечыя аспекты ўбудаваны ў працэсы, а не з’яўляюцца іх дадаткам. Такім чынам, гаворка ідзе не аб канкурэнцыі паміж чалавечымі аспектамі і працэсамі, а хутчэй пра тое, як чалавечыя аспекты разглядаюцца ў сістэме. Няма сумненняў у тым, што некаторыя людзі спрабуюць замяніць чалавечыя аспекты больш складанымі працэсамі, але гэта толькі злоўжыванне. Існуе і зваротная праблема: людзі спрабуюць замяніць працэсы чалавечымі аспектамі, што таксама не вельмі добра працуе. ### Прыклад: гэта ўсе дамены, якія вам патрэбныя Калі вы думаеце аб даменах, будзьце асцярожныя, каб не прапусціць ні адзін з іх. Дарэчы, што гэта за дамены? Калі вы праверыце асноўныя рэсурсы, вы атрымаеце розныя адказы; і ўсё ж, ні адзін з іх не з’яўляецца поўнай праўдай. Тэмы PRINCE2^(®) - гэта дамены, але гэта толькі тыя дамены, якія гуляюць ключавую ролю ў метадалогіі. Іншыя дамены толькі маюцца на ўвазе. Кіраўніцтва PMBOK^(®) не з’яўляецца метадалогіяй і можа сфармуляваць адказ значна лепш з дапамогай дзесяці абласцей ведаў. Аднак гэта інтэрпрэтацыі ўсіх даменаў, заснаваныя на пункце гледжання кіраўніцтва PMBOK^(®) на праект, а не на нейтральнай (нейтральная кропка гледжання існуе не заўсёды). Напрыклад, чалавечыя аспекты не атрымліваюць вялікай увагі ў Кіраўніцтве PMBOK^(®). Добрым крыніцай інфармацыі аб даменах з’яўляецца ICB. Аднак тут гаворка ідзе не аб даменах, а аб кампетэнцыі, якія патрабуюцца ў праекце. У іх няма адназначных супастаўленняў з даменамі, але гэта вельмі дапамагае ў іх ідэнтыфікацыі. У NUPP няма спісу даменаў, у першую чаргу таму, што гэта хутчэй метасістема, чым сістэма, а таксама таму, што катэгарызацыі даменаў залежыць ад тыпу праекта і яго асяроддзя; напрыклад, руцінны будаўнічы праект можа мець патрэбу ў іншым падыходзе, чым творчы даследчы праект. ## NUP5 не рабі нічога без выразнай мэты [image] Вы не павінны нічога рабіць, калі гэта не мае выразнай мэты. Уявіце сабе два паралельных свету, у якіх усе аднолькава, за выключэннем таго, што вы плануеце рабіць: наколькі рознымі будуць гэтыя міры? Хіба розніца каштуе намаганняў, каб зрабіць гэта? Калі ў вас няма яснай мэты і вы робіце нешта толькі таму, што гэта робяць усе астатнія, ці ўсё кажуць, што гэта важна, то: - гэта можа не прынесці вам рэальнай карысці, і, такім чынам, вы можаце нічога не атрымаць ад гэтага. - ці ж у вашым выпадку ён усё яшчэ можа мець патэнцыйныя выгады, але паколькі ў вас няма гэтай мэты, ваш спосаб зрабіць гэта можа не дапамагчы рэалізаваць перавагі. ### Прыклад: партфоліо і праграмы Калі вы ўдзельнічаеце ў адборы і запуску праектаў, пераканайцеся, што вы сканцэнтраваны на развязальных праблемах і ствараемых перавагах, а не на тэхнічных рашэннях. Класічным прыкладам з’яўляецца вытворца ліфтаў, які атрымліваючы скаргі на хуткасць сваіх ліфтаў, запусціў некалькі праектаў па павелічэнні хуткасці без асаблівага поспеху. Гэта працягвалася да таго часу, пакуль яны не вырашылі засяродзіцца на праблеме (нуда або дыскамфорт людзей) замест «натуральнага» рашэння (больш хуткія ліфты). У выніку яны дадалі люстэрка ў ліфты, і гэта вырашыла праблему проста і танна. Памятаеце, што кіраванне праектамі - гэта ў асноўным правільныя дзеянні, а кіраванне партфелямі - правільныя рэчы. Усё роўна, наколькі добра вы кіруеце сваімі праектамі; гэта не спрацуе, калі вы робіце няправільныя праекты. Усё гэта пра наяўнасць мэты. ### Прыклад: праект у цэлым Гнуткасць прадукту вар’іруецца паміж праектамі. У некаторых праектах па развіццю ІТ прадукт з’яўляецца цалкам гнуткім, і яго канчатковая форма залежыць ад зваротнай сувязі, якая будзе генеравацца па инкрементам прадукту ў ходзе праекта, што патрабуе прымянення адаптыўнага (гнуткага) падыходу. На практыцы гэта камбінацыя узроўняў партфеля, праграмы і праекта і патрабуе максімальнай увагі да канчатковай мэты. Рэкамендуецца задакументаваць мэта і зрабіць яе даступнай; гэта адна з мэтаў «бачання прадукта», якое выкарыстоўваецца ў некаторых праектах Scrum. Увага да кошту бізнесу ў Agile праектах - гэта іх спосаб забяспечыць адпаведнасць мэты. У іншых тыпах праектаў, дзе прадукт з’яўляецца адносна фіксаваным і існуюць іншыя механізмы, якія гарантуюць, што канчатковы прадукт будзе задавальняць мэты, члены праектнай каманды могуць перанесці большую частку сваёй увагі з мэты на прадукт (такім чынам, прынцып «засяродзіць увагу на прадуктах» (PRINCE2^(®))), але ўсё ж патрабуецца па меншай меры мінімальнае увагу мэты, каб гарантаваць, што тое, што будуецца, будзе адпавядаць мэты, што можна зрабіць шляхам параўнання прагназуемых выгад з чаканымі (прынцып «пастаянная ацэнка мэтазгоднасці» і тэма «эканамічнае абгрунтаванне» у PRINCE2^(®)). Калі праект запускаецца для внешняга кліента, у кліента будзе свая мэта праекта, а ў вас свая. Каб атрымаць поспех, вам трэба разумець абедзве. ### Прыклад: маніторынг праекта Неабходна засяродзіцца на канчатковай мэте, але яна можа быць занадта абстрактнай для многіх паўсядзённых задач. Вось чаму для эфектыўнай працы неабходная іерархія мэтаў. Спачатку абгрунтаванне і выгады праекта вызначаюцца на аснове канчатковай мэты, а затым у вас з’яўляюцца відавочныя і няяўныя мэты для зменных праекта (напрыклад, тэрміны, кошт і якасць), дасягаючы якія вы, у сваю чаргу, задавальняеце канчатковую мэту. Гэта мэты больш нізкага ўзроўню, якія карысныя для многіх нашых паўсядзённых задач. Калі справа даходзіць да маніторынгу, нізкаўзроўневы маніторынг праекта будзе ажыццяўляцца з выкарыстаннем самага нізкага ўзроўню зменных, паколькі адсачыць канчатковую мэту не заўсёды магчыма. У гэтым выпадку трымаеце ў розуме: якая мэта маніторынгу? Нармальны і прымальны адказ - паглядзець, знаходзімся мы на правільным шляху, і калі няма, здзейсніць пэўныя дзеянні, каб вярнуцца ў ранейшае рэчышча, або скарэктаваць мэты і паглядзець, ці зможам мы па-ранейшаму дасягнуць канчатковую мэту. Таму нашы вымярэнні павінны быць у стане дапамагчы справіцца з гэтай нізкаўзроўневай задачай, а таксама сфармаваць прагноз па завяршэнні для зменных праекта; напрыклад, калі мы зможам завяршыць праект? Колькі грошай нам спатрэбіцца, каб скончыць праект? Усе астатнія вымярэння, такія як планавыя і фактычныя значэнні на сённяшні дзень, з’яўляюцца толькі прамежкавымі значэннямі, якія вам патрэбныя для разліку прагнозаў, а не канчатковымі значэннямі, якімі вы карыстаецеся для кіраўніцкіх мэтаў. ### Прыклад: дакументы Незалежна ад таго, які падыход да распрацоўкі вы выкарыстоўваеце ў праекце, планаванне заўсёды неабходна. Важным пытаннем з’яўляецца ўзровень дэталізацыі кожнага тыпу плана. Калі ў плане недастаткова падрабязнасьцяў, план не зможа ўнесці дастатковы ўклад, і выкананне праекта будзе заснавана на спантанных рашэннях, а не на комплексных, цэласных рашэннях. З іншага боку, многія людзі імкнуцца быць асцярожнымі і дадаюць занадта шмат дэталяў да свайго плану, што робіць яго занадта складаным для падрыхтоўкі і суправаджэння і занадта жорсткім для нявызначанасці праекта. У выніку план становіцца нерэальным і бессэнсоўным. Лепшы спосаб вызначыць узровень дэталізацыі - гэта мець мэта для кожнага элемента ў плане. Напрыклад, калі вы разглядаеце магчымасць дадання рэсурсаў у план, у вас павінна быць для гэтага мэта: як вы збіраецеся яго выкарыстоўваць? Як гэта дапаможа праекту? Колькі высілкаў гэта зойме? і ці варта гэта таго? Часам трэба вырашыць, ці вы хочаце мець пэўны элемент у сваіх планах, а часам - то, як вы хочаце спланаваць або падрыхтаваць нешта. Няхай гэта будзе эканамічнае абгрунтаванне, статут праекта або справаздачу: вы ўсё роўна павінны спытаць сябе, чаму вы рыхтуеце гэты дакумент і як ён можа дапамагчы праекту. Пошук «шаблону» - гэта супрацьлегласць таму, каб рабіць нешта на аснове мэты. ### Прыклад: статус-справаздачы Па праектах часта фарміруюць сапраўды доўгія статус-справаздачы. Грунтуючыся на гэтым NUP, мы павінны спытаць сябе, якая мэта справаздачы і як мы можам дасягнуць гэтай мэты незалежна ад таго, як паступае большасць іншых людзей. Гэта можа прывесці да таго, што мы пачнем фарміраваць вельмі простыя одностраничные справаздачы, якія зацікаўленыя бакі сапраўды прачытаюць і зразумеюць, у супрацьлегласць доўгім. Гэта азначае ўвагу да мэты. Аднак, калі вы рыхтуеце аднастаронкія справаздачы, некаторыя людзі могуць пярэчыць і думаць, што ў вас няма «належнай» сістэмы маніторынгу. На практыцы гэта стварае для вас другую мэту (акрамя першай мэты - дапамагчы зацікаўленым бакам зразумець статус праекта), і каб задаволіць яе, вы можаце проста стварыць другі тып справаздачы, які будзе вельмі доўгім. Пры гэтым вы не будзеце змешваць яго з першым справаздачай, таму што гэтыя дзве мэты не супадаюць. ### Прыклад: бізнес-кейс і статут праекта Падрыхтоўка дакументаў, такіх як бізнес-кейс і статут праекта, звычайна з’яўляецца сумнай, бясплоднай, бюракратычнай неабходнасцю, у той час як усе гэтыя дакументы маюць абгрунтаванне і дастасавальныя да большасці праектаў. Калі вы паспрабуеце знайсці «шаблон» і запоўніць яго, праца будзе проста зроблена марна; тым часам як вы можаце замест гэтага праверыць рэальнае прызначэнне гэтых дакументаў, паглядзець, ці могуць яны дапамагчы ў вашым праекце і якім чынам яны могуць дапамагчы, а затым падрыхтаваць дакумент так, як вам падабаецца, проста для дасягнення гэтых мэтаў: гэта будзе правільны дакумент. Пакуль вы думаеце пра тое, як падрыхтаваць дакументы для дасягнення іх мэтаў, вы забыцца разгледзець усе варыянты. Каб пазбегнуць гэтага, вы можаце праверыць, што прапануюць PRINCE2^(®), PMBOK^(®) Guide, P3.express і DSDM^(®), а затым ацаніць гэтыя варыянты ў залежнасці ад мэтаў. ### Прыклад: пост-праект Хоць праект мае пэўную мэту, і мы можам ўлічваць гэтую мэту на працягу ўсяго праекта, рэалізацыя мэты ў асноўным ацэньваецца на аснове прагнозаў, зробленых у ходзе праекта. Аднак, не варта забываць пра гэта, калі праект завершаны. Важна праверыць рэалізацыю мэтаў пасля завяршэння праекта, таму што: - мы можам убачыць, як дасягаюцца канчатковыя мэты і атрымаць з гэтага ўрокі для будучых праектаў, і - часам мэты дасягаюцца толькі тады, калі мы робім некаторыя дадатковыя дзеянні пасля завяршэння праекта, і разуменне неабходнасці гэтых дадатковых задач патрабуе кантролю. Постпраектны маніторынг з’яўляецца неабходным крокам для дасягнення мэты. У асноўным гэта зона адказнасці кіравання праграмамі і партфелямі, і паколькі большасць кампаній не маюць такіх узроўняў кіравання, гэтым крокам звычайна трэбуюць. Вось чаму такія метады, як P3.express і DSDM^(®), дадаюць гэты крок у метадалогіі кіравання праектамі. ### Прыклад: прастата Свет складзены і хаатычны, але нашы мадэлі ўяўляюць сабой абстрактныя набліжэння, якія адлюстроўваюць часткі свету, і, такім чынам, яны могуць быць простымі. З іншага боку, простыя сістэмы звычайна працуюць лепш, таму што мы можам засяродзіцца на асноўнай ідэі. Шмат хто з нас спрабуюць дамагчыся лепшых вынікаў, дадаючы складанасць да нашых сістэмах, спадзеючыся, што яна будзе адпавядаць складанасці усяго свету, хоць на практыцы гэта абцяжарвае працу з сістэмай і, як правіла, перашкаджае нам дасягнуць мэты. ### Прыклад: адаптацыя Праграмнае забеспячэнне для струменевай музыкі вельмі адрозніваецца ад праграмнага абяспячэння, якое будзе выкарыстоўвацца для абсталявання ў бальніцы або самалёце, дзе ад яго можа залежаць жыццё людзей, ці ад праграмнага обяспячэння, якое будзе выкарыстоўвацца на спадарожніку, дзе яно, як мяркуецца, будзе працаваць шмат гадоў без збояў, усё гэта адрозніваецца ад будаўніцтва летняй дачы, пажарнай станцыі або завода. Факусуючыся на мэтах, вы лепш зразумееце, як адаптаваць сістэмы і артэфакты для розных праектаў. ## NUP6 выкарыстоўвай прайграваныя элементы [image] Спантанны падыход да праекту патрабуе занадта шмат энергіі і рэсурсаў, і вы заўсёды маеце рызыку прапусціць некаторыя з неабходных элементаў. Лепшы спосаб спрасціць працу - выкарыстоўваць прайграваным элементы, пажадана ў паўтаральных цыклах. ### Прыклад: чэк-лісты якасці Чэк-ліст - гэта просты прыклад патэнцыйна паўтараюцца элементы, які многія людзі выкарыстоўваюць і ў асабістай і прафесійнай жыцці. Вазьміце, напрыклад, крытэрыі якасці прадукту: - па-першае, вы можаце стварыць спіс усіх крытэрыяў, што ўжо з’яўляецца формай планавання. - NUP6 рэкамендуе паспрабаваць абагульніць іх: ці ёсць іншыя падобныя прадукты ў праекце? У такім выпадку зрабіце агульны чэк-ліст якасці для гэтай катэгорыі прадуктаў. Калі магчымыя варыяцыі, захавайце агульны спіс і дадайце некалькі дадатковых элементаў для асобных прадуктаў. Зараз у вас ёсць прайграваным чэк-лісты. - пасля таго, як вы падрыхтуеце агульныя чэк-лісты для розных тыпаў прадуктаў, вы можаце знайсці паўтараюцца пункты і зрабіць для іх віртуальную бацькоўскую катэгорыю. У гэтым выпадку замест паўтарэння элементаў для ўсіх гэтых агульных кантрольных спісаў вы можаце атрымаць іх і змясціць у бацькоўскі чэк-ліст. У канцы ў вас, верагодна, будзе адзіны агульны кантрольны спіс для ўсяго праекта. «Definition of Done» у Scrum з’яўляецца прыкладам выкарыстання чэк-лістоў на ўзроўні праекта для праверкі якасці (магчыма, сярод іншага). Такім чынам, кожны вынік будзе належаць іерархіі катэгорый і павінен задавальняць элементам, якія з’яўляюцца ў кантрольных спісах ўсіх катэгорый у іх ланцужку. Такім чынам, элемент у бацькоўскай чэк-лісце стане паўтараным для ўсіх вынікаў, якія знаходзяцца пад ім, што эканоміць час і энергію пры планаванні і выкананні. Што яшчэ больш важна, як толькі вы зробіце гэта для аднаго праекта, вы можаце адаптаваць і выкарыстоўваць яго для ўсіх аналагічных праектаў у будучыні, што з’яўляецца паўтараемай формай планавання для некалькіх праектаў. ### Прыклад: працэсы і працоўныя працэсы Некаторыя прадукты ці звязаныя з імі мэты патрабуюць стандартызацыі і узнаўляльнасці пэўных крокаў. Напрыклад, калі прадукты павінны быць распрацаваны індывідуальна і зацверджаны, вы можаце распрацаваць просты працоўны працэс, у якім будуць зразумелыя ўсе этапы, задзейнічаныя асобы і прыблізная працягласць, што дазволіць пазбегнуць многіх цяжкасцяў. Аднак варта выконваць асцярожнасць, каб не ўскладняць працэсы, паколькі гэта будзе мець негатыўныя наступствы. Усе ўдзельнікі праекту павінны разглядаць бізнес-працэсы як падтрымку і спрашчэнне, а не як бюракратыю, якая замінае працы. Гнуткія праекты маюць прайграваным элементы ў сваім ітэратыўным падыходзе да распрацоўкі, дзе пэўны тып дзеянняў паўтараецца для кожнай фічы; напрыклад, звычайная штодзённая руціна ў XP (экстрэмальным праграмаванні): аб’яднанне ў пару, выбар элемента, праектаванне на дошцы, стварэнне сцэнарыяў тэсту і кода, інтэграцыя кода і г. д. Акрамя прайграваных працэсаў, якія можна выкарыстоўваць для тэхнічных дзеянняў, у вас могуць быць паўтараныя элементы для дзеянняў па кіраванні праектамі. Працэсы ў Кіраўніцтве PMBOK^(®), PRINCE2^(®) і DSDM^(®), крокі ў P3.express і падзеі ў Scrum з’яўляюцца прыкладамі гэтай канцэпцыі. ### Прыклад: цыклы Карысна выкарыстоўваць прайграваным элементы для кіравання праектам. Гэта можа быць зрабіць яшчэ прасцей, калі размяшчалі іх у паўтараюцца цыклы. Гэтыя цыклы значна спрашчаюць паўсядзённае працу людзей, уцягнутых у кіраванне і кіраўніцтва праектам. Цыклы груп працэсаў у Кіраўніцтве PMBOK^(®) пры выкарыстанні ў праекце з некалькімі фазамі, этапамі ў PRINCE2^(®), штодзённымі, штотыднёвымі і штомесячнымі цыкламі ў P3.express, ітэрацыі і часовымі рамкамі ў DSDM^(®) і спрынце ў Scrum з’яўляюцца прыкладамі гэтай канцэпцыі. Больш за кароткія цыклы лягчэй зразумець і выкарыстоўваць, чым больш доўгія; напрыклад, спрынты ў Scrum ў параўнанні з фазамі з кіраўніцтва PMBOK^(®). Аднак занадта кароткія цыклы падыходзяць не для ўсіх тыпаў праектаў, рашэннем можа быць выкарыстанне спалучэння некалькіх тыпаў цыклаў, напрыклад кароткія таймбоксы ў спалучэнні з больш доўгімі ітэрацыі ў DSDM^(®), або выкарыстанне штодзённых, штотыднёвых і штомесячных цыклаў ў P3.express. ### Прыклад: метады Выкарыстанне метадалогіі або фреймворка для запуску праекта - яшчэ адзін прыклад выкарыстання прайграваных элементаў. Гэта можа быць ўжо існуючая сістэма, такая як PRINCE2^(®), P3.express, DSDM^(®) або Scrum, або сістэма, якую вы наладзілі або стварылі самастойна. Аднак, як правіла, лепш пачаць з аднаго з існуючых метадаў і адаптаваць яго да сваіх патрэбам, чым ствараць свой з нуля. Любы паўтораны элемент з’яўляецца абстрактным і мае патрэбу ў наладзе, каб адаптаваць яго да рэальнага свету. Тым не менш, існуюць розныя ступені і абстракцыі і патрэбнасці ў адаптацыі: невялікія, адносна канкрэтныя чэк-лісты якасці знаходзяцца на адным канцы спектру з найменшай узроўнем абстракцыі і патрэбай у адаптацыі, у той час як метадалогіі знаходзяцца на іншым канцы, з самай высокай патрэбай у адаптацыі. Вы павінны заўсёды ўлічваць неабходнасць адаптацыі, у адваротным выпадку прайграваны элемент не будзе адпавядаць вашым патрэбам.