×

Відтінки проектних менеджерів у Кремнієвій долині ― PgM, TPM, EPM, але не PM

Привіт, мене звуть Андрій. Я пройшов шлях від інженера до проектного менеджера, а згодом став СЕО компанії Stanfy. За цей час зроблено десятки різноманітних проектів ― від невеликих у мобільній розробці до монстрів у телекомі. Для Stanfy, сервісної компанії, важливою ланкою в роботі були проектні менеджери. У певний момент, через бажання бути ефективнішими, ми майже залишилися без них.

Прагнучи кращого ― дивишся на найкращих. Для мене такими завжди були компанії Кремнієвої долини, де народжувалися інноваційні технології та підходи до розробки програмних продуктів.

Ця стаття ― ретроспективний погляд на моделі роботи компаній Долини, з якими ми стикнулися й аналізували, а також значення проектного менеджера в цих процесах. Чимало інформації тут узято з десятків розмов з колегами на ринку США, а також під час інтерв’ю проектних менеджерів, де мені довелося побувати з обох сторін. І, чесно кажучи, найцікавішими виявилися кейси, де я був кандидат. Для початку погляньмо на одну з найпопулярніших моделей організації роботи в інженерній команді серед компаній Долини.

Менеджмент продукту й менеджмент інженерів

«Here we call PM a Product Manager not Project Manager», ― такою була відповідь одного з моїх клієнтів, коли ми лише починали працювати з компаніями Кремнієвої долини. Це був невеликий стартап тоді, а тепер це вже кілька сотень людей та успішний бізнес.

Абсолютне розуміння того, чому деякі компанії Долини мало знайомі з роллю проектного менеджера до мене прийшло значно пізніше. Розгляньмо структуру організації роботи в сучасних компаніях, зокрема Facebook, Amazon, Netflix, Google (FANG). Адже їхній підхід до роботи копіюють чимало компаній навколо, особливо стартапи, що наймають колишніх працівників цих гігантів.

У центрі таких технологічних компаній завжди був і є продукт. Але найчастіше це не монолітна структура, а набір багатьох елементів ― за аналогією до мікросервісів. Цим напрямом займаються Product Managers (PM) ― люди, що відповідають за бізнесову частину цифрового продукту: як його виводити на ринок, як розвивати і що нині в пріоритеті. У таких людей є велика автономія в ухваленні рішень без погодження з керівництвом, якщо запропоноване в межах загальної стратегії компанії. Менеджери продуктів, їхні директори й віце-президенти (VP) ― це майже окрема структура в межах компанії.

Комплементарно до цього існують інженерні команди, які й займаються технічною реалізацією та підтримкою продуктів. Саме в тісній співпраці PM та інженерів народжуються нові ідеї і запускаються експерименти в продуктах. З мого останнього спілкування з командами компанії Amazon: команди з 5―8 людей самі не лише генерують нові ідеї, а й ставлять собі цілі на майбутнє. Часто ніхто не приходить зверху й не каже, що робити ― команда повинна бути максимально автономна й відповідати за свою частину продукту. Звичайно, для масштабніших ініціатив може знадобитися кілька таких команд.

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

Слід зазначити, що постановка цілей, планування і контроль ― це одне із завдань саме менеджера інженерів. У менших командах і стартапах це може бути досвідченіший інженер. Відповідно, уміння зробити декомпозицію завдань і спланувати власну роботу — важливий чинник під час наймання інженера.

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

Така формула надзвичайно поширена в більшості стартапів Кремнієвої долини й серед гігантів індустрії.

Наприклад, ось історія активного стартапу. Компанія Samsara натепер налічує понад 150 інженерів і близько 1000 працівників загалом. За 4 роки її оцінка зросла до 6 мільярдів доларів, і компанію вже не перший рік додають до списку перспективних у Долині. У продуктній лінійці в неї близько десятка різних продуктів, об’єднаних платформою керування флоту автотранспорту. Перший проектний менеджер з’явився близько року тому. До цього ж десятки продуктних команд працювали в конфігурації: команда ― інженерний менеджер ― продуктний менеджер.

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

Кремнієвій долині не потрібні проектні менеджери?

Це логічне запитання, яке могло б виникнути у вас... Але все зовсім навпаки. Історія менеджменту в нових технологічних компаніях досить цікава й далеко не обмежена моделлю, описаною вище. Чого тільки варта історія Google про те, як вони вирішили відмовитися від менеджерів узагалі, а потім повернули (не лише проектних). Або ж компанії, що працюють у пласкій ієрархії (Valve).

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

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

Якщо для досягнення певної цілі потрібно декілька проектів, їх об’єднують у програму. Назва позиції при цьому може дуже сильно варіюватися: хтось і далі називається Project Manager, а хтось уже Program Manager. Щоправда, в розмовах із софтверними командами Google, Facebook, Amazon зазвичай фігурують Program Managers.

Проте в межах однієї назви є певний розподіл. Найперше такі ролі можна умовно розділити на дві категорії: узагальнена Program Manager (PgM) і Technical Program Manager (TPM). До того ж кількість різноманітних додатків перед словосполученням Program Manager просто гігантська і зазвичай визначає сферу роботи людини: Engineering (Hardware), Operations, Marketing, Software, Supply Chain тощо. До цього додається варіативність у назвах у межах різних компаній ― суть одна, а назви різні. Так в Apple частіше можна зустріти Software Engineering Program Manager, ніж Technical Program Manager.

У чому ж різниця між PgM і TPM? Банально, але це глибина технічних знань. Від TPM вимагають глибшого розуміння технологій і вміння з ними працювати. Усе задля того, щоб така людина могла ефективніше комунікувати між різними сторонами проекту й не бути лише проміжною ланкою. Наприклад, коли потрібно планувати розвиток потужностей дата-центру на наступні 5 років, то менеджер з власного досвіду повинен розуміти складнощі такого процесу й мати змогу оцінити інформацію.

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

Ось деякі з видів діяльності, якими займаються PgM у відомих компаніях і з якими я знайомий:

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

У такій ролі PgM стає більше схожим на Agile-коуча або просто коуча для команди й допомагає структурувати підхід у роботі, дотримуватися планів і фокусуватися на головному. Це не вичерпний перелік типів діяльності, і вам можуть трапитися досить цікаві й можливо екзотичні завдання.

Наскільки технічним повинен бути TPM

Чудовим критерієм, щоб зрозуміти вимоги до таких людей є питання, що ставлять під час інтерв’ю, коли наймають на роботу. Отож, ключовим технічним питання тут є «System design» (проектування софтверної системи). Зазвичай у межах такого питання ставлять бізнес-завдання, а кандидат повинен у результаті спроектувати технічну систему, яка б дала змогу її розв’язати. Особливість таких питань ― їхня невизначеність і велика кількість можливих рішень, тобто тут немає однієї правильної відповіді.

Наприклад, проблема: як організувати облік продукції на складі невеликого магазину будівельних матеріалів. При цьому очікують, що кандидат зможе поставити потрібні запитання й уточнення, запропонувати план, який дав би змогу розпочати максимально швидко й з мінімальними витратами. Та на цьому відповідь не завершено. Майже завжди я чув продовження запитання з проханням запропонувати стратегію зростання системи, тобто як її масштабувати: які системи й рішення використати залежно від запланованої швидкості зростання? які стратегії у разі перевищення показників? які потенційні проблеми можуть виникнути?

Одне таке запитання дає змогу оцінити, як кандидат у TPM розуміє функціювання складних технічних систем і чи вже робив він щось подібне. До слова, майже такі самі запитання ставлять під час інженерних інтерв’ю програмістам або менеджерам інженерів.

У ширину чи в глибину

Якщо опис вище звучить «занадто технічно», то можу заспокоїти ― вимоги досить різняться від компанії до компанії. З власного досвіду: у розмовах та інтерв’ю дехто заглиблювався і доводилося вести дискусії про функціювання різноманітних частин операційних систем і розказувати деталі під час тренування нейронних мереж, а хтось обмежувався запитаннями щодо мого розуміння, як функціювали проекти, над якими я працював. Щоправда, більшість розмов усе-таки можна зарахувати до другої групи ― важливіше, щоб людина мала загальне уявлення про функціювання і взаємодію компонентів системи, аніж володіла знаннями на рівні інженера.

На моє запитання: «У чому ти бачиш основну цінність програмного менеджера для команди?» інженери з Долини найчастіше згадували такі чинники:

  • бачить загальну картину і транслює це бачення команді;
  • допомагає сфокусуватися на головному;
  • стежить за прогресом і дедлайнами;
  • відповідає за координацію з іншими командами.

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

Що обрати для себе

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

1. Спочатку визначтеся, чого саме ви чекаєте від роботи або що хочете отримати. Це універсальний крок за будь-якого пошуку роботи, і тут він теж буде не зайвим.

2. Якщо ви думаєте про шлях проектного менеджменту або ж уже на ньому, то, найімовірніше, вам подобається:

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

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

3. Якщо у вас серйозний технічний бекграунд і ви не дуже хочете його втрачати або ж маєте цікаву спеціалізацію (наприклад, data science), то посада TPM вам може гарно пасувати. Там можна й технічно зануритися за потреби й відповідати за широку картину проекту або програми. Для деяких компаній вона дуже близька до менеджера інженерів ― принаймні за рівнем вимог.

Якщо ж глибина захоплює менше, ніж масштаб подій, то погляньте на ролі PgM ― там теж є з чого вибрати.

Щодо технічних навичок зауважу: усі технологічні компанії розраховують, що кандидат на посаду PgM не буде абсолютним новачком у технологіях і вже працював з такими проектами й завданнями. Вас наймають передусім за те, що ви вже робили й досягли, а потім уже за ваш потенціал.

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

Відповідно, якщо ви захочете опанувати роль PgM або TPM десь у Facebook або Google, то вам безпосередньо не будуть підпорядковані люди ― у них свої менеджери.

Висновки

З проектними менеджерами чи без них ― кожна компанія вирішує для себе, зважаючи на потреби продукту та внутрішні реалії. У певних ситуаціях компанії шукають проектних менеджерів з глибокими технічними навичками, а комусь потрібні вміння широкої координації.

Зі свого досвіду знаю, що чимало українських компаній успішно копіюють підхід до роботи західних колег як у продуктах, так і сервісі. Десь користі від проектних менеджерів бачать більше, а деяким командам це не потрібно. Тож чи потрібні вашій компанії проектні менеджери, вирішувати вам самим, так само, як менеджерові вирішувати, чи йти в команду, де можна ефективно організувати роботу й без нього.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному4
LinkedIn

Схожі статті




3 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
3. Якщо у вас серйозний технічний бекграунд і ви не дуже хочете його втрачати або ж маєте цікаву спеціалізацію (наприклад, data science), то посада TPM вам може гарно пасувати. Там можна й технічно зануритися за потреби й відповідати за широку картину проекту або програми. Для деяких компаній вона дуже близька до менеджера інженерів ― принаймні за рівнем вимог.

За всю SV казати не можу, але щодо технічних ролей в Гуглі є тільки одна нормальна технічна роль — SWE. Якщо ти SWE, і береш на себе функції TPM — молодець, це ріст, нові скіли — вищій рейтинг, промо. Береш на себе функції PM — клас, опікуєшся продуктом, супер. Пишеш код — молодець, пишеш design docs — теж. Виконуєш функції EM, ростиш команду — круто. Тому в Гуглі є люди рівня директорів і VP з тайтлом SWE — власне це дуже поширена ситуація.

Якщо ж ти TPM, це означає, що там вже SWE не справилися (а значить, там вже є легасі процесси, і тобі придеться нелегко), і ти можеш працювати плюс-мінус в рамках свого job ladder. Щось інше не зараховується. Не дай боже написати якийсь код, а ще не дай боже написати код, який хтось інший хотів написати — ти ж наступаєш на п’ятки інженерам (деякі з яких мають в рази меншу експертизу)! Щодо рівня вимог, то це правда — вимоги як до менеджера інженерів і інженера одночасно, але можливості менші, ніж у будь-якого SWE такого ж рівня.

Андрей, спасибо за отличный материал! В Украине роль TPM-a в понимании SV — это редкость, но, возможно, больше наших продуктовых компаний возьмут на заметку такую орг структуру.

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

Коментар порушує правила спільноти і видалений модераторами.

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