# NUPP Майже універсальні принципи проєктів [image] Це завантажувана версія онлайн-посібника (https://omimo.org/uk/modules/nupp/), створена 2026‑07‑02. Новіші версії доступні на сайті. NUPP походить з OMIMO (https://omimo.org/uk/), сімейства відкритих мінімалістичних модулів. Цей посібник можна вільно використовувати та поширювати відповідно до ліцензії Creative Commons Attribution 4.0 International. OMIMO співфінансується Європейським Союзом. Висловлені погляди та думки належать виключно OMIMO і не обов’язково відображають погляди Європейського Союзу або EPOS VZW. Ані Європейський Союз, ані орган, що надав фінансування, не можуть нести за них відповідальність. Переклад Ганна Литвинченко ## Вступ 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 Водоспад Група сильно захоплених людей, які були достатньо сміливими, щоб спробувати адаптаційні підходи до розвитку ІТ в той час, коли нормою було використання прогнозних підходів, зібралися разом, і назвали свій підхід “Agile” (спритний). Це була чудова ініціатива не обмежувати вибір тим, що здавалося необхідним. У спільноті Agile є ще багато захоплених та орієнтованих на результат людей, але, на жаль, в цій спільноті також є деякі люди, які перетворюють Agile на культ і вважають усіх сторонніх людей ворогами. Це спричиняє проблеми різними способами, включаючи наступне: - Це не дозволяє їм вчитися у когось поза їхньою групою - Це перешкоджає стороннім людям навчатися у них - Це робить приналежність до групи важливішою за реальну мету, що, у свою чергу, заважає багатьом її членам пізнати справжнє значення Agility. Цю проблему можна значно зменшити, якщо не повністю усунути, використовуючи “Agile” лише як термін, що стосується підходу до розвитку, а не як спільноти з членами; і маючи людей, які вважають себе творцями, лідерами та вирішують проблеми, які сприймають Agile просто як один з інструментів, а не як свою ідентичність. Немає війни між Agile та Водоспадом для справжніх професіоналів. ### Приклад: PRINCE2^(®) vs PMBOK^(®) Guide У професійній спільноті є багато фахівців, які пов’язують себе з PRINCE2^(®) або PMBOK^(®) Guide (як правило, через своє географічне розташування) і не знайомі з іншими. Усі ми можемо мати переваги щодо певних джерел, але не слід ідентифікувати себе з ними, і що найважливіше, ми повинні ознайомитись із усіма ними, щоб розширити нашу перспективу та вибір. Справжній професіонал відкритий до всіх ідей, шукає їх, дізнається про них і використовує їх, коли потрібно, без прояву приналежності. ### Приклад: Безперервне навчання Приналежності задовольняють людину завдяки почуттю належності, яке вони породжують, але яка не підштовхує їх навчатись, а іноді навіть відштовхує їх від навчання, оскільки вони бояться втратити свою приналежність. Коли ви вільна людина, експерт без приналежностей, вам потрібно заповнити прогалину навчанням: безперервним навчанням. У що ми віримо сьогодні, це не є істиною. Це просто наше найкраще розуміння на даний момент, яке треба вдосконалювати в процесі роботи. Щось неправильно, якщо ваші погляди сущільно збігаютться з тими, що були кілька років тому. Це стосується навіть NUPP: якщо ви повертаєтесь через декілька років і побачите абсолютно те саме, то у вас має закрастися сумнів. ### Приклад: Відкритість Заперечуючи проти когось, переконайтеся, що ви націлили своє заперечення саме на ідею, а не на людину. Це допомагає запобігти великій напрузі. У подібному руслі, коли хтось заперечує вам чи проти вас, постарайтеся не тлумачити це як війну проти вас, а скоріше обговорення ваших ідей, і будьте відкриті до неї. Не слухайте, щоб відповісти; слухайте, щоб зрозуміти; співпрацюйте з іншою людиною, щоб вдосконалити ідею. Деякі люди можуть навмисно націлитися на вас замість ідеї; у такому випадку вам слід допомогти їм зосередитись на ідеї, а не на вас, перш ніж продовжувати, і спробувати зберегти зосередженість на йдеї протягом усієї розмови. ## NUP2 Зберігайте та оптимізуйте енергію та ресурси [image] Ресурси обмежені. Ресурси, доступні для проекту, обмежені, як і ментальна енергія, яку ви маєте витратити, щоб прийняти правильні рішення. Ви повинні зберегти та оптимізувати цей ресурс для себе та для проекту, та допомогти іншим членам команди зробити те саме. ### Приклад: Правило 80/20 Значну частину можливих переваг управління проектами можна отримати, витративши невелику частину зусиль. У більшості випадків орієнтація на 100% можливих вигод є дуже дорогою і невиправданою. Вам потрібно враховувати це правило у всьому, що ви робите, і заохочувати інших робити те саме. ### Приклад: Втома від прийняття рішення Ми використовуємо єдине джерело психічної енергії для прийняття всіх типів рішень, а також для вираження сили волі. Якщо ви використовуєте багато цього джерела для прийняття непотрібних чи неважливих рішень, у вас буде менше енергії для важливих рішень, що може призвести до поганих результатів. Це одна з причин, коли вам слід уникати мікроменеджменту (принцип “керувати за винятком” PRINCE2^(®)). Конфлікти, пов’язані з ідеями, можуть бути корисними, але ті, які стосуються людей, як правило, шкідливі для проекту, і одним із наслідків є те, що такий конфлікт виснажує психічну енергію членів команди. Якщо ви помітили такий конфлікт, вам слід зробити все можливе, щоб знайти першопричину та вирішити її. ### Приклад: Подбайте про себе! Рішення, які ви приймаєте, і сила волі, яку ви висловлюєте, використовують ваше джерело психічної енергії. З іншого боку, це джерело наповнюється енергією, коли ви спите і харчуєтесь правильно. Отже, слід добре дбати про себе: переконайтеся, що ви виспалися і відпочили, і харчуйтеся добре. Якщо у вас є шкідливі звички або проблеми зі сном, вам не доведеться з цим боротися поодинці; є багато фахівців, які можуть допомогти вам виправити подібні проблеми. Фізичні навантаження також можуть допомогти з цим джерелом енергії, хоча дослідження ще не є остаточними для цього питання. Спробуйте заохотити членів команди робити те саме, що і ви. По-перше, переконайтесь, що вони працюють стійкими темпами та без зайвих понаднормових робіт. Потім, якщо у вас є вибір, спробуйте запропонувати в робочий час енергійну, здорову їжу, закуски та напої. ### Приклад: Баланс роботи та життя Багато хто з нас любить те, що ми робимо, але це все ще не все, що нам потрібно мати в житті. Таким же чином, як ви оптимізуєте свою роботу, ви повинні планувати та впроваджувати ідеї в особистому житті таким чином, щоб зробити його радісним та щасливим. Коли ви більш щасливі, ви моєте бути більш успішними і у роботі. Якщо можете, спробуйте заохотити членів вашої команди зробити те саме. ### Приклад: Мотивація Мотивація - це складне поняття. Є цікаві та корисні джерела з цих тем, а також багато інших ненаукових. Проте, корисно дізнатися більше про мотивацію і намагатися постійно застосовувати в роботі, так як це збільшує розумову енергію команди і можливість досягнення кращих результатів для проекту. Мотивація може приймати такі прості форми як посмішка або “спасибі” в знак визнання роботи. Проте будьте обережні, так як деякі з поширених форм мотивації, наприклад, невеликі грошові винагороди, можуть мати негативний ефект. ### Приклад: Співпраця та командна робота Люди, які співпрацюють, іноді можуть мати можливість створювати кращі результати, але що ще важливіше, люди є соціальними і люблять бути частиною групи. Якщо ви зможете усунути негативні аспекти роботи в команді та створити приємне середовище, члени команди проекту будуть щасливіші. Але ви повинні бути обережнішими, тому що люди різні, а комусь потрібен більш спокійний, зосереджений та самотній час, ніж іншим; зазвичай необхідно дотримуватися балансу. ### Приклад: Культура єдиної команди Існує тенденція, щоб різні зацікавлені сторони створюють підгрупи, що стає джерелом напруги з іншими групами; наприклад, люди, орієнтовані на бізнес-аспекти проекту порівняно з людьми, які будують продукт. Ця напруга споживає багато енергії з обох сторін, що є однією з причин, щоб ми намагалися побудувати культуру єдиної команді, де всі працюють разом для досягнення однієї і тієї ж мети. ### Приклад: Мудрість натовпу Коли велика кількість різноманітних людей збирається і працює в сприятливому середовищі, є потенціал отримати дуже хороші результати, ідеї та рішення, які можуть бути навіть кращими, ніж ті, що надходять від окремих експертів. Якщо у вас є такий варіант, ви можете використовувати його регулярно, щоб звертатись до членів команди про допомогу вам у вирішенні складних проблем в проекті. Окрім можливості отримати хороші результати, це також дозволяє членам команди знати, що їх думка цінується і що вони відіграють важливу роль у проекті, що, в свою чергу, підвищує рівень їх енергії. Діяльність E02 P3.express - приклад використання мудрості натовпу у проектах. ### Приклад: Головний фасилітатор проекту Якщо ви керівник проекту, більшість речей, які ви робите, мають характер фасилітації (або, принаймні, повинні мати). З іншого боку, ви можете побачити, що в минулому члени команди мали поганий досвід роботи з менеджерами проектів, і що цей досвід впливає на їхні стосунки з вами: частина їх енергії витрачається на аналіз вашої поведінки на предмет можливих загроз, а не на довіру вам. У такому випадку ви можете змінити назву посади з керівника проекту на головного фасилітатора проекту. Зрештою, саме цим ви й займаєтесь у проекті. ## NUP3 Завжди будьте проактивним [image] В нас є природна тенденція бути реактивними. Це може допомогти нам зберегти свою енергетичну справу, що стосується неважливих питань, або може дати кращі результати, коли ми маємо справу з тим, у чому ми абсолютно некомпетентні. Ці ситуації відрізняються від наших проектів, і тут ми можемо отримати кращі результати, проявляючи активність. ### Приклад: Планування Якщо ви хочете їхати на нове місце, а ви запізнюєтесь, можете негайно почати рух, щоб “заощадити час”, і вирішити можливі проблеми, коли вони виникнуть. Проактивний підхід полягає в тому, щоб витратити деякий час на старті і встановити вашу навігаційну систему, щоб надати вам найшвидший маршрут на основі трафіку та можливих аварій і перекриттів, а потім їхати; це витрачає час перед виконанням задля уникнення проблем і таким чином заощаджує час. На відміну від того, що деякі люди думають про Agile проекти, планування завжди є необхідним, і мова лише про тип та рівень деталей у планах. Планування перед виконанням - це активний підхід. Запам’ятайте цитату: дайте мені шість годин, щоб зрубати дерево, і я проведу перші чотири для заточування сокири. Якщо проект прогнозований, ви можете витратити 4 години на заточування сокири, оскільки ви впевнені, що збираєтеся рубати дерево. У проекті Agile ви не впевнені, чи збираєтесь рубати дерево, збирати зламані гілки, збирати дернину, видобувати вугілля чи щось інше. Тим не менш, вам все-таки потрібно провести загальну підготовку до всіх цих робіт (знайти, де знаходиться найближчий магазин обладнання), і мати певну підготовку (заточування), коли ви збираєтеся зосередитися на певному рішенні; це і є планування. ### Приклад: Планування планування Планування того, як ми збираємось виконати проект, є проактивним підходом. Цю активність можна навіть розширити, запланувавши спосіб планування виконання; це концепція плану управління Керівництва PMBOK^(®), стратегій управління PRINCE2^(®) та підходів у DSDM^(®). ### Приклад: Безперервне планування Реальність рідко відповідає тому, що ми планували, і це нормально, але ми повинні постійно адаптувати наші плани, щоб переконатися, що вони залишаються реалістичними та практичними. Ми повинні робити це, як тільки потрібна адаптація, а не тоді, коли ми стикаємося з проблемами. Це проактивний підхід. ### Приклад: Управління ризиками Вся концепція управління ризиками базується на проактивності: коли ми стикаємося з невизначеними подіями, замість того, щоб чекати, що з’явиться, а потім реагувати, ми думаємо про можливості та наслідки, розглядаємо відповіді та, ймовірно, робимо щось щодо цього, перш ніж це станеться. Зауважте, що те, що ми робимо в проектах, є серйозним; іноді це стосується життя людей. ### Приклад: Визначте ролі та обов’язки Ви можете залишити членів проектної групи працювати без чітких ролей і обов’язків, і рано чи пізно з’явиться форма ролей і обов’язків, але це занадто дорого і може зрештою не працювати добре. Проактивний підхід полягає в тому, щоб визначити ролі та обов’язки рано та адаптувати за потребою. Це полегшує роботу всім, і допоможе зосередитись на створенні чогось, а не вирішувати, хто чим займається. Кількість та різноманітність ролей залежать від типу та розміру проекту; це може бути просте визначення, наприклад, одне у Scrum, щось помірне, як, наприклад, у P3.express, або щось всеосяжне на зразок DSDM^(®) та PRINCE2^(®). Однак не забувайте, що описи ролей у цих методах стосуються лише управлінської діяльності та що вам завжди потрібно додавати описи ролей і для технічних аспектів. ### Приклад: Доступні варіанти Чи слід достроково закривати проект чи продовжувати його? Рідко є лише два варіанти, навіть якщо питання передбачає це. Потрібно мати активний підхід і врахувати всі свої варіанти, перш ніж приймати рішення. Можливо, ви можете переробити зміст проекту; можливо, ви можете зробити паузу, поки щось інше не стане зрозумілим; або, можливо, ви можете змінити проектний підхід (наприклад, аутсорсинг) тощо. ### Приклад: Критичне мислення У всіх нас є багато упереджень, які допомагають нам, з одного боку, вижити і змушують нас приймати погані рішення, з іншого. Що стосується прийняття важливих рішень щодо проекту, то краще заздалегідь зробити паузу та розглянути всі упередження, які можуть вплинути на наше рішення, перш ніж вони спричинять проблеми. В якості довідки можна використовувати список когнітивних упереджень, наведений у Вікіпедії. Навіть існують структури (фреймворки) прийняття рішень, які можна використовувати для прийняття кращих рішень. Спочатку їх використання може відволікати і навіть дратувати, але незабаром ви звикаєте до них і отримуєте перевагу від них без особливих усвідомлених зусиль. ### Приклад: Прозорість Нам не подобаються затримки з проектом або якісь інші проблеми, але це не означає, що ми повинні їх приховувати. Ви повинні бути прозорими та повідомляти зацікавленим сторонам про проблеми, оскільки деякі з них можуть допомогти вам, і, крім того, вони рано чи пізно дізнаються про проблеми та їх наслідки, а деякі з них можуть вимагати завчасних дій зі свого боку (наприклад, прийняти негативний наслідок). ### Приклад: Спілкуйтеся ефективно Може бути багато випадків, коли ви надсилаєте звіти зацікавленим особам, і вони не дають вам жодних відгуків. Ви можете вважати, що все добре лише тому, що негативних відгуків немає, хоча це може бути і не так. Ви повинні проявляти активність і перевіряти, чи справді вони використовували звіт і чи він слугував цілі, і використовувати дані, щоб налаштувати ваш спосіб спілкування; в іншому випадку ця прихована проблема може спричинити серйозні проблеми пізніше, коли їх важко виправити. ### Приклад: Беріть на себе відповідальність Легко звинувачувати інших у поганих результатах. Наприклад, ви, можливо, хочете, щоб ваша організація наділила вас повною мірою повноваження змінювати все в проекті та робити це досконало, але вони цього не роблять, і в результаті проект провалюється. Це не проактивний підхід. Проактивний підхід полягає в тому, щоб брати на себе відповідальність і робити все можливе в рамках обмежень. Ви не можете сподіватися, що організація вам повністю довіриться і дасть вам все в надії отримати хороші результати, особливо коли вони побачили стільки невдалих проектів. Що вам потрібно зробити, це зробити одне невелике вдосконалення в рамках встановлених обмежень, використовувати це, щоб отримати трохи довіри, ще трохи ресурсів і трохи більше терпимості до обмежень, а потім використовувати це для трохи більшого вдосконалення, і виконуйте так, поки не досягнете оптимальної мети. ## NUP4 Пам’ятайте, що ланцюжок є настільки ж міцним, наскільки міцна його найслабша ланка [image] У проектах є різні складові, і всі вони потребують уваги; ми повинні мати цілісну перспективу проекту. Звернути увагу на, здавалося б, важливу складову (наприклад, час) недостатньо, тому що всі складові взаємодіють і вони не працюють належним чином, якщо всі вони не отримують належної уваги. ### Приклад: Це все про дедлайнІ! Скажімо, ви щось будуєте для Олімпійських ігор. Встановлено дуже жорсткий термін, що робить управління часом дуже важливим. Чи так це? Що робити, якщо якість настільки низька, що потребує повторної роботи через деякий час. Це вплине на час, так що час та якість будуть потребувати додаткової уваги. У вас може бути сад фантазий, зазначений в оригінальному визначенні проекту, але ви знаєте, що якщо часу не вистачає, ви можете пропустити його і просто прикрити травою, якщо ви вчасно розглядали таку можливість і підготувались до цього. Отже, важливим є також управління змістом. Тепер у центрі нашої уваги зміст, час та якість. Чи чули ви про той відомий приклад, коли президент Кеннеді зустрічається з двірником в НАСА і запитує його, що він робить, і двірник відповідає: “Я допомагаю посадити людину на Місяць”? Невже такий тип людей у проекті не допомагає дотриматись терміну? Продовжуючи, ви помічаєте, що кожна окрема складова у проекті сприяє управлінню часом, і ви не можете дотриматись терміну з прийнятним рівнем визначеності, якщо не звернете увагу на всі складові. ### Приклад: Вибіркові запозичення Коли люди стикаються з різноманітними методами, іноді вони починають вибіркові запозичення та створюють поєднання всього, що здається цікавим з різних систем. Зазвичай це не працює, оскільки елементи не працюють ізольовано і повинні бути сумісні один з одним. Будь-які доповнення або зміни у системі повинні здійснюватися з цілісного погляду. Ось чому ми іноді бачимо суперечливі елементи в різних методах; щось працює добре в одній системі, а його протилежність працює добре в іншій системі. Цей елемент не є правильним чи неправильним сам по собі. Найбезпечніший підхід - це вибрати методологію для проекту, адаптувати її, а потім обережно додати до нєї нові елементи, враховуючи узгодженість елементів всієї системи. ### Приклад: Антипроцесний підхід Одна з найкращих речей, яку зробили Agile методи - вони привернули увагу до людських аспектів. Agile Manifesto надає більшої цінності для особистостей та взаємодій порівняно з процесами та інструментами, хоча це може бути не справедливим порівнянням. Практично всі методи кажуть, що людські аспекти важливі, і реальна відмінність методів Agile полягає в тому, що аспекти людини є вбудованою частиною їхніх процесів, а не простою пропозицією. Отже, мова йде не про конкуренцію між людськими аспектами та процесами, а про те, як бачать людські аспекти в системі. Немає сумнівів, що деякі люди намагаються замінити людські аспекти більш складними процесами, але це лише неправильне використання. Навіть існує також зворотня ситуація: люди намагаються замінити процеси людськими аспектами, що теж не працює. ### Приклад: Це всі необхідні вам складові Розмірковуючи про складові, слід бути обережними, щоб не пропустити жодної з них. Хоча, які вони? Якщо ви перевірите фундаментальні джерела, ви отримаєте різні відповіді; і все ж, жоден з них не дасть повну відповідь. PRINCE2^(®) теми - це складові (домени), але це лише ті складові, які відіграють ключову роль у методології. Інші складові маються на увазі. Керівництво PMBOK^(®) не є методологією і може сформулювати відповідь набагато краще з десяти областей знань. Однак це інтерпретації всіх областей, що базуються на погляді Керівництва PMBOK^(®) на проект, а не нейтральному (не те, що обов’язково існує нейтральна перспектива). Наприклад, людським аспектам не приділено багато уваги в Керівництві PMBOK^(®). Хорошим джерелом інформації про складові є ICB (IPMA). Однак мова йде не про складові, а про компетенції, необхідні в проекті. ICB не має однозначних зіставлень з складовими, але ICB дуже допомагає їх ідентифікувати. У NUPP відсутній список складових, насамперед тому, що це метасистема, а не система, а також тому, що категоризація складових залежить від типу проекту та його середовища; наприклад, звичайний проект будівництва може потребувати іншого погляду, ніж творчий дослідницький проект. ## NUP5 Не робіть нічого без чіткої мети [image] Нічого не слід робити, якщо це не має чіткої мети. Уявіть два паралельні світи, де все те саме, за винятком того, що ви думаєте робити: Наскільки би різними були ці світи? Чи варта різниця зусиль, щоб зробити це? Якщо ви немаєте на увазі чіткої мети і ви робите лише щось, тому що всі інші це роблять, або всі кажуть, що це важливо робити, то - це може не мати реального зиску у вашому випадку, і тому ви можете нічого не отримати з цього; або - це може все-таки мати потенційні переваги у вашому випадку, але оскільки ви не маєте на увазі цілі, ваш спосіб її досягнення може не допомогти реалізувати переваги. ### Приклад: Портфелі та програми Якщо ви берете участь у виборі та ініціюванні проектів, вам слід переконатися, що ви бульше зосереджуєтесь на перевагах та проблемах, які потрібно вирішити, ніж на продукті, у якому будуть реалізовані рішення проблем та переваги. Класичний приклад - виробник ліфтів, який раніше отримував скарги на швидкість своїх ліфтів, і тому проводив безліч проектів для збільшення швидкості без повного успіху. Це тривало, поки вони не вирішили зосередитись на проблемі (нудьга чи дискомфорт людей) замість “природного” рішення (швидкі ліфти). У результаті було додано дзеркала до ліфтів, і це вирішило проблему просто і дешево. Пам’ятайте, що управління проектами полягає в тому, щоб робити все правильно, тоді як управління портфелем - це робити правильні речі. Не важливо, наскільки добре ви керуєте своїми проектами; це не буде добре, якщо ви робите неправильні проекти. Вся справа в тому, щоб мати мету. ### Приклад: Проект в цілому Гнучкість продукту залежить від проектів. У деяких проектах розвитку ІТ продукт є абсолютно гнучким, і його остаточна форма залежить від зворотного зв’язку, який буде формуватися інкрементами продукту під час проекту, що вимагає адаптивного (Agile) підходу. Це практично з точки зору поєднання портфеля, програми та шарів проекту, і йому потрібно максимально приділяти увагу кінцевій меті. Добре задокументувати мету та мати її досяжною; це одна з цілей “продуктового бачення”, яка використовується в деяких Scrum проектах. Увага до ділових цінностей у проектах Agile - це спосіб їх узгодження з метою. В інших типах проектів, де продукт відносно фіксований і існують інші механізми, які забезпечують, щоб ідентифікований продукт задовольнив мету, члени проектної групи можуть перенести значну частину своєї уваги з мети на продукт (отже, принцип “фокус на продуктах” PRINCE2^(®)), але принаймні мінімальна увага до мети все ж потрібна для того, щоб те, що будується, задовольнило мету, це можна зробити, порівнюючи прогнозовані переваги з очікуваними вигодами (отже, принцип “постійного бізнес-обґрунтування” та тема “економічне обґрунтування” у PRINCE2^(®)). Коли проект працює для зовнішнього клієнта, у клієнта буде власна ціль проекту, а у вашої компанії інша ціль. Ви повинні розуміти і використовувати обидві цілі, щоб дійсно досягти успіху. ### Приклад: Моніторинг проекту Зосередження уваги на кінцевій цілі необхідно, але це може бути занадто абстрактно для багатьох щоденних завдань. Ось чому потрібна ієрархія драйверів, щоб зробити кінцеву ціль більш практичною. Спочатку обґрунтування та переваги проекту визначаються виходячи з кінцевої цілі, а потім у вас будуть явні та неявні цілі для показників проектів (наприклад, часу, вартості та якості), щоб задовольнити обґрунтування, що, в свою чергу, задовольнить кінцеву мету. Це цілі нижчого рівня, які корисні для багатьох наших щоденних завдань. Що стосується моніторингу, моніторинг проекту на низькому рівні здійснюватиметься за допомогою показників найнижчого рівня, оскільки незавжди можливо відстежити кінцеву мету. У цьому випадку ви все ще повинні мати на увазі цілі: яка мета моніторингу? Нормальною і прийнятною відповіддю є перевірка того, чи йдемо ми визначеним шляхом, а якщо ні, то викликати певну реакцію, яка поверне нас на колію або скоригує цілі та дасть побачити, чи можемо ми все ще задовольнити кінцеву мету. Таким чином, наші вимірювання повинні бути в змозі допомогти в цій цілі низького рівня, а відповідні вимірювання - це прогнози показників після завершення; наприклад, коли нам вдасться закінчити проект? Скільки коштів нам знадобиться для завершення проекту? Усі інші вимірювання, такі як заплановані та фактичні значення на сьогодні, - це лише проміжні значення, які вам потрібні для обчислення прогнозів, а не кінцеві значення, які ви використовуєте для управлінських цілей. ### Приклад: Документи Незалежно від того, який підхід до розвитку ви використовуєте в проекті, планування завжди необхідно. Важливе питання - рівень деталізації у кожному типі плану. Якщо в плані недостатньо деталей, план не зможе зробити свій внесок, і виконання проекту буде базуватися на спеціальних рішеннях, а не на інтегрованих цілісних рішеннях. З іншого боку, багато людей намагаються бути обережними та додають занадто багато деталей до свого плану, що ускладнює підготовку та підтримку, і занадто жорстке для невизначеності проекту. В результаті план стає нереальним і марним. Найкращий спосіб визначитися з рівнем деталізації - мати на увазі мету для кожного елемента плану. Наприклад, якщо ви розглядаєте можливість додавання ресурсів до плану, у вас повинна бути мета: Як ви його будете використовувати? Як це допоможе проекту? Скільки зусиль буде потрібно? і чи варто того? Іноді справа в тому, щоб вирішити, чи хочете ви мати певний елемент у своїх планах, а іноді - про те, як ви хочете планувати чи підготувати щось. Будь то економічне обґрунтування, статут проекту чи звіт: ви все одно маєте запитати, чому ви готуєте цей документ і як він може допомогти проекту. Шукати «шаблон» - це протилежне тому, щоб робити щось на основі мети. ### Приклад: Звітність про хід віконання (статус) У багатьох проектах зазвичай є дуже довгі звіти про статус. Виходячи з цього NUP, ми повинні запитати себе, яка мета звіту, і як ми можемо досягти цієї мети незалежно від того, що може робити більшість інших людей. Це може, в багатьох випадках, змусити нас підготувати дуже прості звіти на одній сторінці, які зацікавлені сторони дійсно читають та розуміють замість довгих звітів. Це звертає увагу на мету. Якщо ви готуєте звіти на одних сторінках, деякі люди можуть заперечити проти вас і вважати, що у вас немає «належної» системи моніторингу. На практиці це створює для вас другу мету (окрім першої мети, яка допомагає зацікавленим сторонам зрозуміти статус проекту), і для того, щоб задовольнити це, ви можете просто створити другий тип звіту, який дуже об’ємним. Однак ви не змішаєте це з першим звітом, оскільки ці дві цілі неоднакові. ### Приклад: Бізнес-обґрунтування та статут проекту Підготовка документів, таких як бізнес-кейси та статут проекту, як правило, є нудною, безрезультатною, бюрократичною необхідністю для більшості людей, хоча всі ці документи мають дійсні цілі, що стосуються більшості проектів. Якщо ви спробуєте знайти «шаблон» і заповнити його, робота просто витрачається; тоді як ви можете замість цього перевірити реальне призначення цих документів, побачити, чи вони можуть бути корисними для вашого проекту, а потім підготувати документ будь-яким способом, який вам подобається, просто для задоволення цих цілей: це буде правильний документ. Хоча ви думаєте про те, як можна підготувати документи для задоволення їхніх цілей, ви можете не думати про кожен сценарій і може щось пропустити. Щоб уникнути цього, ви можете перевірити, що пропонують такі джерела, як PRINCE2^(®), PMBOK^(®) Guide, P3.express і DSDM^(®), а потім оцінити ці пропозиції, виходячи з цілей. ### Приклад: Постпроект Хоча проект має конкретну мету, і ми можемо враховувати цю мету протягом усього проекту, реалізація мети в основному оцінюється на основі прогнозів, зроблених під час проекту. Однак ми не повинні забувати про це, коли проект буде закінчений. Важливо перевірити реалізацію цілей після завершення проекту, адже ми можемо бачити, як досягаються кінцеві цілі та дізнаємось з них для майбутніх проектів, і іноді цілі досягаються лише тоді, коли ми виконуємо деякі додаткові завдання після завершення проекту, і розуміння необхідності цих додаткових завдань потребує моніторингу. Моніторинг після проекту - це необхідний крок у орієнтації на ціль. В основному це відповідальність систем управління програмами та портфелями, і оскільки більшість компаній не мають таких рівнів управління, цим кроком зазвичай нехтують. Ось чому такі методи, як P3.express та DSDM^(®), додають цей крок до своїх методологій управління проектами. ### Приклад: Простота Світ складний і хаотичний, але наші моделі - це абстрактні апроксімації, які відображають частини світу, а значить, вони можуть бути простими. З іншого боку, прості системи зазвичай працюють краще, оскільки ми можемо бути зосереджені на головній ідеї. Багато хто з нас намагаються досягти кращих результатів, додаючи складність нашим системам, сподіваючись, що це буде відповідати складності світу, хоча на практиці це ускладнює роботу з системою і, як правило, блокує нас у задоволенні мети. ### Приклад: Адаптація Програмне забезпечення для потокової музики відрізняється від того, яке буде використовуватися для обладнання в лікарні або в літаку, де від програмного забезпечення може залежати життя людей, або від програмного забезпечення, яке буде використовуватися в супутнику, де воно має працювати багато років без збоїв, і всі вони відрізняються від будівництва літньої вілли, пожежної станції та технологічного заводу. Коли ви маєте на увазі цілі, ви краще зрозумієте, як адаптувати системи та артефакти для різних проектів. ## NUP6 Використовуйте повторювані елементи [image] Ad hoc підхід до проекту забирає занадто багато енергії та ресурсів і ви завжди ризикуєте втратити деякі необхідні елементи. Найкращий спосіб спростити те, що потрібно зробити, - це використовувати повторювані елементи та, бажано, застосовувати їх у повторюваних циклах. ### Приклад: Контрольні списки якості Контрольний список (чек-лист) - простий приклад потенційно повторюваного елемента, який багато людей використовують у особистому та професійному житті. Візьміть критерії якості товару, наприклад: По-перше, ви можете створити контрольний список усіх критеріїв, що є формою планування. Що рекомендує NUP6 - спробувати узагальнити: чи є в проекті подібні результати? У цьому випадку підготуйте загальний контрольний список якості для цієї категорії результатів та використовуйте їх для всіх. Якщо є деякі варіанти, збережіть загальний список та додайте кілька додаткових елементів для окремих результатів. Тепер у вас є повторювані контрольні списки. Після того, як ви підготуєте загальні контрольні списки для різних видів результатів, ви можете знайти елементи, які повторюються серед них, що підказує для них віртуальну батьківську категорію. У такому випадку замість повторення елементів для всіх цих загальних контрольних списків ви можете їх витягнути і помістити в батьківський контрольний список. Зрештою, напевно, у вас буде єдиний загальний контрольний список для всього проекту. “Визначення зробленого” Scrum - приклад використання контрольних списків на рівні проекту для якості (можливо, серед іншого). Здійснюючи це, кожен результат буде належати до ієрархії категорій і повинен задовольняти позиції, що містяться в контрольних списках усіх категорій у їх ланцюжку. Таким чином, елемент у батьківському контрольному списку стане повторюваним для всіх результатів, що знаходяться під ним, що економить час та енергію при плануванні та виконанні. Що ще важливіше, коли ви зробите це для одного проекту, ви зможете адаптувати та використовувати його для всіх подібних проектів у майбутньому, що є повторюваною формою планування для декількох проектів. ### Приклад: Процеси та робочі процеси Деякі результати, або пов’язані з ними цілі, потребують певних кроків, які можуть стати стандартизованими та повторюваними. Наприклад, якщо результати повинні бути розроблені індивідуально та затверджені, ви можете підготувати простий робочий процес, який дозволяє зрозуміти всі кроки, залучених осіб та приблизну тривалість, щоб уникнути багатьох труднощів. Однак ви повинні бути обережними, щоб не зробити робочі процеси та процеси занадто складними або занадто інтенсивними в документації, оскільки це матиме негативний наслідок. Усі люди, які беруть участь у проекті, повинні сприймати робочі процеси та процеси як щось, що підтримує їхню роботу та полегшує для них все, а не як бюрократичну документацію, що блокує їх реальну роботу. Agile проекти мають повторювані елементи у своєму ітеративному підході до розвитку, де певний тип розроблювальної діяльності повторюється для кожної фічі; напр. звичайний розпорядок дня в XP (програмування eXtreme): складіть пари, виберіть елемент, спроектуйте його на дошці, побудуйте тестові сценарії та код, інтегруйте код тощо. Окрім повторюваних робочих процесів, які можна використовувати для технічної діяльності, ви можете мати повторювані елементи і для діяльності з управління проектами. Процеси в Керівництві PMBOK^(®), PRINCE2^(®) та DSDM^(®), діяльності в P3.express та події в Scrum - приклади цієї концепції. ### Приклад: Цикли Маючи корисні елементи для управління проектом. Це можна зробити ще простіше, поміщаючи їх у повторювані цикли. Ці цикли значно спрощують повсякденну діяльність людей, задіяних в управлінні та керівництві проектом. Цикли груп процесів у Керівництві PMBOK^(®) при використанні в проекті з декількома фазами, етапами PRINCE2^(®), щоденними, щотижневими та місячними циклами в P3.express, ітераціями та часовими рамками в DSDM^(®) та спринтами в Scrum - є прикладами цієї концепції. Коротші цикли легше зрозуміти та використовувати, ніж довші; наприклад, спринти в Scrum на відміну від фаз згідно з Керівництвом PMBOK^(®). Однак занадто коротких циклів може бути недостатньо для підтримки певних типів проекту, і рішенням може бути використання декількох циклів, таких як використання циклів коротких таймбоксів разом із тривалішими циклами ітерації DSDM^(®) або P3.express ‘використання щоденних, тижневих та місячних циклів. ### Приклад: Методи Використання методології чи основи для запуску проекту - це ще одне використання повторюваних елементів. Це може бути існуюча система, наприклад PRINCE2^(®), P3.express, DSDM^(®) або Scrum, або така, яку ви самостійно налаштували або побудували. Однак зазвичай краще почати з одного з існуючих методів і адаптувати його до ваших потреб, ніж будувати його з нуля. Будь-який повторюваний елемент є абстрактним і потребує налаштування, щоб адаптувати його до реального світу. Хоча існує спектр абстрагування та необхідність в кастомізації: хоча невеликі, відносно конкретні контрольні списки якості знаходяться на одному кінці спектра з найменшою кількістю абстракцій та потребують адаптації, в той час як методології - з іншого, з найвищою потребою у адаптації. Ви завжди повинні відзначати необхідність адаптації, інакше повторюваний елемент не буде відповідати вашим потребам.