📌Info
Репост із телеграм-каналу Є управа
Проект — задумка (бізнес-авантюра), що має початок, більш-менш фіксований об’єм і кінець.
Продукт — це проект, котрий зміг: він сподобався клієнтам, він приносить дохід і розвивається.\
Ці аспекти визначають різницю в управлінні проектом і продуктом.
Управління проектом (традиційний PM) — то бізнес-задача. Дуже спрощено то виглядає якось так:
1️⃣ Авантюра: було би класно керувати телевізором з телефона.
2️⃣ Нахера: Чи буде з цього профіт? (порівняння потенційної вартості та потенційного доходу)
3️⃣ Проект: Робимо аплікацію для телефона, з ось таким функціоналом. Робитиме ось ця команда, від завтра і до першого вересня.
Проект
👥 Проект для команди — то тимчасова штука до першого вересня. Як студенти: здали й забули (ну ок, виділили 4 годино-джуна на тиждень для підтримки). Проект має (більш-менш) фіксований розмір (скоуп). Звісно, in real life, скоуп зі скрипом міняється і терміни сунуться (також зі скрипом, або з лубрикантом — залежно від стосунків PM з інвесторами).
🗣️ Роль PM — управління бізнес-авантюрою зі всіма допусками та ризиками. Команда може не справитися зі скоупом до першого вересня (ніколи такого не було, і ось знову!) Зрештою, ринок може не оцінити геній нашої авантюри і не купити проект взагалі ☹️ Або фортуна посміхнеться і проект виявиться новим disrupt-ом і завіруситься ТікТоками в Метаверсех.
Тоді Проект промоутиться до Продукту.
Продукт
Продукт, в свою чергу, живе довго. А з ним живе Product Backlog. Ми радісно приносимо нові захцянки в наш улюблений продукт і реалізовуємо їх: декотрі тепер, інші восени. Ми любимо продукт за його передбачуваність: Sprint must go on і мітинг-рум по п’ятницях зарезервований без кінцевої дати.
Продукт в цілому менш авантюрний, проте запропонований новий функціонал таки треба пропускати через сито “нахера”. В момент оцінки потенційної користі та потенційної вартості імплементації народжується пріорітизація. Це є цілком бізнес-задача, в якій ролі PM та PO досить подібні.
Проте інтенція постійності продукту вимагає від PO постійного уточнення (рефайнменти), постійного внесення нового функціоналу (як бізнесового, так і технічного) та постійної роботи з беклогом. В цьому роль PO та PM відрізняються.
З життя: я працював у компанії, котра розробила доволі функціональний двигун для роботи з гео-даними. Компанія дуже хотіла, щоби той двигун став Продуктом: з’явився новий клієнт — ось форма для реєстрації, ось рахунок для оплати. Як в Нетфліксу 🙂
Проте, кожен новий клієнт стає Проектом, не зважаючи на те, що використовує той же двигун. Чому? — бо в клієнтів дуже специфічний і складний бізнес; кастомізація двигуна під нового клієнта займає декілька місяців роботи потужної скрам-команди.
Більшість таких Проектів стали Продуктами для свого єдиного клієнта: новий функціонал додається, сервери крутяться і фідбек-форми ліниво заповнюються.
Але деякі Проекти “не злетіли”. Щож, то є ризики бізнесу.
Так і живуть 🙂