Чому змішування Product та Project веде до організаційної ентропії

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Спостерігаючи за тим, як емісари кадрового ринку, яких у нашому напівсвітському дискурсі прийнято іменувати рекрутерами (фахівці з пошуку людського капіталу, що нерідко блукають у сутінках власних когнітивних дисонансів), демонструють прикру нездатність розрізнити архітектуру сенсів та логістику процесів, я відчув гостру екзистенційну потребу розпочати цей цикл публікацій. У зв’язку з цією тотальною інтелектуальною сліпотою, що панує серед тих, хто має бути провідником у світ професійних талантів, я вирішив провести демаркаційну лінію між двома фундаментально різними всесвітами управлінської думки.

У сучасному корпоративному пантеоні, де кожен другий намагається видати хаотичне пересування стікерів у Jira за стратегічне планування, виникає фундаментальна онтологічна помилка, що полягає у нездатності розрізнити фігуру Product Manager та Project Manager. Ця інтелектуальна сліпота призводить до того, що компанії намагаються схрестити чисту візію з брутальною логістикою, отримуючи на виході управлінського франкенштейна, який неспроможний ані осягнути ринкову безодню, ані вчасно завершити спринт.

1. Product Manager: Екзальтований деміург ринкових істин

Справжній Продакт-менеджер оперує в категоріях «Шо» та «Нахіба», де головним інструментом виступає Discovery, адже його місія полягає у валідації гіпотез, що мають принести бізнесу сакральний прибуток. Якщо звернутися до Принципу Парето, то Продакт — це той, хто безжально відсікає зайве, аби не збудувати ідеально сконструйовану споруду, яка виявиться абсолютно нікчемною для кінцевого споживача. Його фокус спрямований на ринкові катаклізми та ментальні пастки клієнтів, оскільки без чіткого розуміння Product-Market Fit будь-яка розробка перетворюється на марнославне спалення інвесторських грошей.

2. Project Manager: Приборкувач хаосу та дефіциту

На іншому боці барикад стоїть Проджект-менеджер, чиє буття просякнуте Delivery, де основними атрибутами є ресурси, ризики та невблаганна хода годинника. Він діє у межах Закону Паркінсона, намагаючись втримати команду в шорах бюджету та дедлайнів, поки Продакт літає в емпіреях стратегічного планування. Проджект відповідає за те, щоб будівництво нашого цифрового/залізного зиккурату не зупинилося через раптову нестачу інтелектуальних цеглин або через те, що розробники/інженери/дизайнери/аналітики знову занурилися в пучину прокрастинації.

Чому ця сепарація є критичною для виживання?

Коли ви намагаєтеся поєднати ці іпостасі в одній людині, виникає небезпечний когнітивний дисонанс, що неминуче призводить до одного з двох фіналів:

  • Або ви тонете в операційному багнюці, виправляючи баги та рухаючи таски, і при цьому остаточно втрачаєте здатність бачити стратегічний обрій, що робить ваш продукт неактуальним ще до моменту його релізу.
  • Або ви настільки захоплюєтеся малюванням повітряних замків та вивченням психологічних архетипів користувачів, що команда залишається без чітких вказівок, перетворюючи розробку на безкінечний сеанс групової психотерапії.

Продакт-менеджер створює цінність, виступаючи в ролі деміурга, тоді як Проджект-менеджер забезпечує передбачуваність, виконуючи функції суворого квартирмейстера. Один без одного вони — це або хаотичний геній без рук, або виконавчий механізм без голови, тому не намагайтеся економити на інтелекті, бо в результаті ви заплатите набагато більшу ціну за власну короткозорість.

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Стосовно статі: просто опис для однієї, скоріш за все, компанії чи проєкту. Бачив як це було навпаки і по-іншому в інших проєктах. Від того, що PM рухає таски в джирі і займається budgeting — це не робить ані його PMом, ані звільняє PdM від розуміння процессу.
Інокли PM — це просто плеййсхолдер на дзвінках з клієнтом, або вільні вуха для того ж. Інколи це людина відповідальна за прийняття рішень для highest business value, але досягається це пересуванням тасок чи effort type distribution — то неважливо.
За PdM — незгоден, я вже давно перестав дивитися на назву ролі, в неї запихнукть що завгодно. A/B tests та Discovery вже давно не є часткою лише PdM.

Власне:
інженерна дисципліна, як індустрія, давно має розділення на «конструктор» та «технолог». Перший каже що ми робимо, маючи, інколи, дуже поверхневі знання чи розумінн, як та чи інша деталь буде вироблена чи виготовлена. Друга роль саме відповідає за «щоб оте креслення стало фіз обʼєктом». І тому бійка між цима двома породжує в фіналі компроміс, котрий все-таки стає фізичним обʼєктом.
Поєднай ці 2 ролі в одну людину і буде внутрішній компроміс, схожий з тим зранку, коли ти знайдеш мільон причин щоб залишитися в ліжку.

додам: будь ласка, будьте обережні з «ентропією». Ніщо не веде до «організаційної ентропії», вона є завжди, коли нічого не робиш воно зростає, коли щось робиш вона змінюється тако ж. Це атрибут, а от саме його мінімізація і є ціллю.

У мене був невеликий досвід (всього рік), де я поєднував ці ролі (і деякі інші).

Жодної ентропії не виникне, якщо продакт чітко донесе завдання до проекту — наприклад, зробити лендинг для перевірки гіпотези та розіслати дискаунт по базі замість інтерв’ю.

І навпаки — я бачив як ментально гинуть проджекти через дурні цілі бізнесу, типу — знайти куди йдуть чотири косарі в рахунку за хмару, замість опрацювання багів/фіч на утримання користувача.

З іншого боку — є певні ліміти і всунути 10 созвонів по годині з лідами/хедами/стейкхолдерами в 8-й годинний день — важко. Якщо бізнес дає норм зворотний зв’язок — жодної ентропії немає. А якщо дає у вигляді — «немає можливості, зроби це якось сам» — то це і є те джерело, а ентропія — просто симптоматика.

недавно читак статтю про те як «скрам мастера» замінили «проектних менеджерів» — але тільки на папері

по факту, проектних менеджерів стало менше, їх робота переповзла на інші ролі АЛЕ неофіційно) і тепер всі через це страждають

Підписатись на коментарі