Проєктні результати vs продуктові результати: відмінності
Кожен проєкт створює два види результатів: те, що йому доручили побудувати, і те, що потрібне йому для керування самим собою. Перші це продуктові результати, другі проєктні результати, і обидва є результатами в повному сенсі: перевірними, з відповідальним і переданими на приймання. Різниця полягає в їхній функції та їхньому адресаті, а плутання цих двох призводить до реальних проблем: клієнтів просять затвердити внутрішні документи, або продукти приймають люди, які ніколи ними не користуватимуться. Ця стаття визначає обидва типи, зіставляє їх поряд, показує, де різниця важлива на практиці, і пояснює, як відстежувати обидва в одній системі.
Ключові висновки:
- Визначення — проєктні результати створюються, щоб планувати, скеровувати й документувати сам проєкт; продуктові результати це результати, задля яких проєкт було доручено.
- Приклади — до проєктних результатів належать план проєкту, базовий план графіка, звіти про статус і реєстр ризиків; до продуктових результатів система, будівля, кампанія або результати приймальних випробувань.
- Ключові відмінності — проєктні результати служать внутрішнім адресатам, як-от спонсору та PMO; продуктові результати йдуть до клієнта або кінцевих користувачів і приймаються за узгодженими критеріями.
- Поширені помилки — відстеження лише продуктових результатів залишає проєкт без сліду рішень; надвиробництво проєктних результатів перетворює управління на звітування заради звітування.
- Керування обома типами — продуктові результати потребують відповідальних, критеріїв приймання та статусу, видимого поруч із графіком; проєктні результати потребують процесів затвердження та звітів, згенерованих з актуальних даних.
Що таке проєктні результати?
Проєктні результати це результати, які створюються, щоб планувати, скеровувати й документувати сам проєкт: план проєкту, базовий план графіка, звіти про статус, реєстр ризиків, протоколи нарад, бюджетна документація. Іноді їх називають процесними результатами, бо їх створює процес управління, а не виробнича робота, або внутрішніми результатами, бо їхні адресати перебувають усередині організації. Тут потрібна термінологічна примітка: у повсякденному вжитку проєктні результати також слугують як загальний термін для всіх результатів проєкту будь-якого роду, і цей ширший сенс розглянуто в нашому посібнику з проєктних результатів. У порівнянні, про яке йдеться в цій статті, термін стосується саме управлінського боку.
Те, що робить ці результати повноцінними результатами, а не паперами, це те, що вони проходять той самий тест, що й усе інше, що передає проєкт: кожен є перевірним, має відповідального й має адресата, який його приймає. Базовий план графіка затверджує спонсор; звіт про статус отримує керівний комітет. Ці результати існують, щоб рішення можна було ухвалювати на основі фактів, і проєкт, який не створює жодного з них, усе одно може побудувати продукт, але ніхто не зможе сказати, на якій основі ним керували.
Отримай повний доступ до FlexiProject на 30 днів, без витрат і без плати
Що таке продуктові результати?
Продуктові результати це результати, задля яких проєкт було доручено: програмна система, нова функція, будівля, маркетингова кампанія, навчальна програма, результати приймальних випробувань, які підтверджують, що продукт працює. Іноді їх називають кінцевими результатами, бо вони представляють остаточні підсумки роботи, або зовнішніми результатами, бо вони залишають проєкт і йдуть до клієнта або кінцевих користувачів.
Продуктові результати це причина, чому існує бюджет. Їх приймають за критеріями приймання, узгодженими до початку роботи, зазвичай клієнтом, власник продукту або кінцевими користувачами, і їхня передача закриває головну обіцянку проєкту. Проєкт може бути зразковим у своїх планах і звітах, але якщо продуктові результати не пройдуть приймання, жодна управлінська дисципліна його не врятує. Тому статус приймання заслуговує на власне відстеження: у FlexiProject завдання в графіку має піктограму зі статусом пов’язаного продукту, тож різниця між завершеним завданням і прийнятим результатом видно з першого погляду.
Проєктні результати vs продуктові результати: порівняння
| Проєктні результати | Продуктові результати | |
| Мета | Планувати, скеровувати й документувати проєкт | Постачити результати, задля яких проєкт було доручено |
| Типові адресати | Спонсор, керівний комітет, PMO | Клієнт, власник продукту, кінцеві користувачі |
| Приклади | План проєкту, базовий план графіка, звіти про статус, реєстр ризиків | Система, функція, будівля, кампанія, результати приймальних випробувань |
| Приймання | Внутрішнє затвердження, часто через формальний процес | Приймання за критеріями, узгодженими з клієнтом |
| Коли створюються | Упродовж усього проєкту, від ініціації до закриття | Здебільшого у виконанні, передаються наприкінці етапів і при закритті |
З таблиці випливають дві речі. По-перше, обидва типи проходять той самий тест результату: перевірний, з відповідальним, прийнятий. Різниця полягає у функції та адресаті, а не в ранзі, і ставлення до проєктних результатів як до другосортних паперів це те, як організації втрачають слід своїх рішень. По-друге, здорова пропорція між двома типами не є фіксованою. Регульований фармацевтичний проєкт закономірно створює більше управлінських результатів, ніж маркетинговий проєкт із двох осіб, і пропорція має відповідати профілю ризику проєкту, а не універсальному шаблону.
Чому різниця має значення
Різні адресати та шляхи приймання
Кожен тип долає різний шлях до приймання. Проєктні результати затверджують внутрішньо: спонсор затверджує базовий план, керівний комітет отримує звіти, PMO перевіряє відповідність стандартам. Цей внутрішній шлях може бути формальним: у FlexiProject базовий план і ключові документи затверджують через шлях приймання, тож затвердження спонсора це подія, зафіксована в системі, а не домовленість у коридорі. Продуктові результати приймає клієнт або користувачі за критеріями, записаними до початку роботи. Проблеми починаються, коли шляхи змішуються: клієнт, якого просять затвердити внутрішній реєстр ризиків, марнує час усіх, а продукт, оголошений прийнятим командою, яка його побудувала, без затвердження клієнта, це спір, що чекає на рахунок.
Поширені помилки у відстеженні обох типів
Перша помилка це відстежувати лише продуктові результати. Продукт створюється, але немає затвердженого плану, немає базового плану, немає запису рішень, тож коли надходить аудит, передача чи спір, проєкту нема чим показати, як ним керували. Друга помилка протилежна: надвиробництво проєктних результатів, доки управління не стає звітуванням заради звітування, а команда витрачає більше часу на документування роботи, ніж на її виконання. Обидві помилки мають той самий корінь: копіювання переліку результатів із шаблону замість виведення його з реального ризику проєкту та потреб зацікавлених сторін.
Як PRINCE2 називає ці два типи
Різниця, описана в цій статті, має формальні назви в PRINCE2: управлінські продукти для проєктного боку та спеціалізовані продукти для продуктового боку, кожен визначений власним описом і критеріями якості. Якщо ваша організація працює з PRINCE2 або ви хочете погляд методологій на той самий поділ, перегляньте наше порівняння проєктних результатів (PMBOK) і проєктних продуктів (PRINCE2).
Розблокуй усі функції та прискор свої проєкти: 30 днів FlexiProject безкоштовно!
Як керувати обома типами в одній системі
Два типи потребують різної механіки, але мають жити в одному місці. У FlexiProject продуктові результати визначають у модулі Продукти: кожен зі своїм описом, критеріями приймання, терміном і відповідальним, пов’язаний із завданнями та етапами, що його створюють. Проєктні результати виграють з іншого боку. Повторювані звіти про статус генеруються з актуальних даних проєкту, що прибирає найбільш витратний за часом управлінський результат зі списку ручних справ, а реєстр ризиків, який ведеться в системі замість таблиці, завжди актуальний для перегляду, без збирання даних електронною поштою. У підсумку обидва типи мають названих відповідальних і видимий статус, без паралельної таблиці для жодного з них.
Проєктні результати vs продуктові результати: поширені запитання
Звіт про статус це проєктний чи продуктовий результат?
Проєктний результат. Він документує стан роботи для внутрішніх адресатів і підтримує рішення щодо скерування. Частиною продуктового результату він став би лише в рідкісному випадку, коли саме звітування є замовленою послугою.
Чи проєктні результати це те саме, що процесні результати?
На практиці терміни майже повністю збігаються. Строго кажучи, процесні результати названо за тим, коли вони створюються, управлінським процесом, а внутрішні результати за тим, хто їх отримує. Більшість результатів підпадає під обидві назви, тому позначки вживають взаємозамінно.
Хто приймає кожен тип результату?
Проєктні результати приймають внутрішньо, спонсор, керівний комітет або PMO. Продуктові результати приймає клієнт, власник продукту або кінцеві користувачі за заздалегідь узгодженими критеріями. Розмежування двох шляхів приймання запобігає більшості спорів під час передачі.
Чи може один елемент бути водночас проєктним і продуктовим результатом?
Так. Класичний випадок це документація користувача: вона створюється під час проєкту, як будь-який управлінський результат, але постачається з продуктом і служить кінцевим користувачам. Вирішальний чинник це кінцевий адресат. Якщо її отримує клієнт або користувачі, розглядай її як продуктовий результат із критеріями приймання.
Проєктні результати та продуктові результати ділять результати проєкту за функцією та адресатом: один набір існує, щоб вести проєкт, інший це те, задля чого проєкт було доручено. Обидва заслуговують повного ставлення як до результату, з відповідальними, перевірністю та визначеним шляхом приймання, бо проєкт, який нехтує будь-яким боком, платить за це: без проєктних результатів немає сліду рішень, а без прийнятих продуктових результатів немає результату.
Різниця до того ж практична, а не академічна, оскільки кожен тип долає різний шлях до приймання та служить різним адресатам. Система PPM, яка опрацьовує обидві механіки в одному місці, як це робить FlexiProject із модулем Продукти для продуктових результатів і процесами затвердження з автоматичними звітами про статус для проєктних результатів, тримає обидва боки видимими, не подвоюючи адміністративну роботу.
