Мабуть, перша відповідь, що крутиться у всіх в голові: дуже погано, тільки одним словом. Як тільки думаю про нетехнічних ПМ-ів в ІТ згадую анекдот:
ПМ: Чому ми досі не зробили реліз?
Дев: AWS не працює
ПМ: то полагодьте його швидше
Дев: Але ж AWS це…
ПМ: деталі не важливі, скажи естімейт і полагодь!
Але, насправді, нетехнічному ПМ-у можна вижити і доволі непогано керувати проектом. Тільки за однієї умови: є повна підтримка фахівців проекту у вашій команді. Тобто завжди буде “підстраховка” у вигляді відкритих пояснень причин затримок в розробці фічі, чи пояснення можливих ризиків і взаємозалежностей. В свою чергу ПМ теж має поважливо ставитись до експертної думки своїх спеціалістів, щоб не перетворюватись у вищезгаданий анекдот. Це працює лише при повній взаємній довірі, визнанні помилок і роботі над ними, як команда, а не нападки одне на одного.
Інакше, або я б сказала у більшості випадків, ПМ-у який не розбирається у якихось базових поняттях таких як AWS, чи не має розуміння взаємозалежностей компонентів у арітектурі продукту та про сам продукт, ніколи не вдастся зробити проект легко та вчасно. Якщо такий ПМ буде дивитись на проект лише зі сторони “дайде естімейти і все зробіть” він втратить будь-яку повагу до себе і буде просто набридливим членом команди, у якого чомусь нічого не виходить. Також, важливо зрозуміти, що ПМ - це не енциклопедія, яка має знати всі “кишки” девелопменту. Наприклад, не треба лізти у гіт і дивитись як таи і що девелопери кодять, чи просити показати як виглядає кубер чи як, з яких гілочок і куди девелопери що мержать, щоб вийшов реліз Х. Це як людське тіло. ПМ має знати що є кістки, кров, мозок і т.д., що за що відповідає. Але який гормон де виробляється та як той шлунок перетравлює їжу - його мало це хвилює. Але він знає, що як болить живіт - це до шлунку, а як з’явився поріз то треба сходити по пластир.
Також, треба знати хоча б поверхнево продукт, основні функції та “куди тикать”, хоча б хепі-пас. Один мій знайомий був переконаний, що ПМ-у не важливо знати свій продукт. Він відповідає тільки за процес. У кожного в команді є своя роль, і якщо ПМ налагодив процес - то весь механізм під назвою проект має працювати чітко і вчасно поставити повноцінно працюючий продукт. І, можливо, таке б і працювало. В ідеальному світі, коли всі все знають, у всіх все виходить і всі дуже самоорганізовані. В моїй практиці у випадку не розуміння і незнання свого продукту будь-яке уточнююче питання поставить вас у незручне становище. Як би ви майстерно його не редіректили до інших чи не “повертались до цього пізніше”, рано чи пізно всі зрозуміють що ви просто “прокладка” між знаючими людьми і замовниками. Чи є сенс в такому ПМ-і? Лишу питання відкритим.
В альма-матер усіх ПМ-ів - PMBoK - в розділі про технічні навички проджект менеджера вказано, що ПМ має мати знання, навички що відповідають специфиці домену проекту. Тобто розуміти технології, тренди, стандарти та економіку в домені і якому вирішено розпочати поект. Але більше детально розписано, що під цим мається на увазі наявність відповідних артефактів для управління проекту: критичні фактори для успіху проекту, графіки, список проблем, фінансові звіти, тощо.
Хоч я і не великий фанат ведення проектів за PMBoK (про це окремо напишу), але тут важко сперечатись. Не дурні люди ж ділились своїми знаннями і сформували збірку. В будь-якому випадку, я дуже заохочую всіх ПМ-ів, як початківців так і досвічених, вивчайне базові речі, вивчайте продукт і домен проекту, задавайте питання, які б дурнуваті вони не були. Ці питання дають вам безцінний досвід, і краще задати питання раз, отримати відповідь і запам’ятати, ніж бути героєм анекдоту.
