Проєктний менеджер може витягнути складний проєкт, а може й усе зіпсувати. Від зусиль і знань PM-а залежить злагодженість команди, виконані терміни, обсяг робіт і навіть ступінь задоволеності замовника.
І хоча менеджер в IT не пише код, натомість координує процес розробки, балансуючи між інтересами замовника, команди й керівництва компанії.
Які знання потрібні такому спеціалісту, щоб успішно завершувати розпочате?
Перший крок — розібратися, із чого складається IT-проєкт, адже не можна добре керувати процесами, яких не розумієш.
Що таке IT-проєкт
Якщо дати коротке визначення, то проєкт — це спільна робота групи людей для досягнення запланованого результату за обмеженого часу й бюджету.
У будь-якому IT-проєкті є три складові:
- Замовник — ставить бізнес-цілі.
- Менеджер — доносить вимоги бізнесу до розробників.
- Команда — реалізує задумане.
Менеджер служить сполучною ланкою, його роль — налагодити комунікацію між людиною з бізнес-цілями, бізнес-вимогами, розумінням кінцевого результату й виконавцями, які займаються підтвердженням, розробкою і тестуванням.
На IT-ринку присутні дві великі категорії проєктів: продуктова й аутсорс-розробка. В аутсорсі команда працює над замовленнями клієнтів, а в продуктовій компанії над власним продуктом.
Outsource проєкти
Замовник приходить у outsource з якоюсь ідеєю та мінімальною кількістю інформації. Клієнт наймає команду для реалізації його проєкту: створення функціоналу або програми, яка допоможе досягти бізнес-цілей.
В аутсорсі між командою та замовником є дві сполучні ланки: Project Manager і Business Analyst. PM вибудовує процес так, щоб замовник отримав потрібний результат, а працівники – оплату своєї роботи.
За що відповідає Project Manager:
- Терміни: за який час команда зробить окрему ітерацію чи весь проєкт, якими будуть проміжні точки.
- Вартість: кількість людей у проєкті, які ставки в цих фахівців, скільки коштуватиме конкретна задача.
- Скоуп роботи: що й в якому обсязі потрібно зробити.
Business Analyst займається уточненням і підтвердженням вимог клієнта, працює з формулюваннями. Мета бізнес-аналітика — правильно зрозуміти замовника, й опрацювати від початку до кінця задачі, поставлені в скоуп.
Досвідчений BA вміє виявляти реальні бізнес-потреби у спілкуванні з замовником і знає, як перетворити «побажання» клієнта на задачі для розробників.
Схема, коли бізнес-аналітик і РМ працюють на одному проєкті — золотий стандарт аутсорсу, проте на практиці Project Manager часто буває єдиною сполучною ланкою між замовником і командою. Якщо ВА в компанії немає, то РМ виконує роль бізнес-аналітика та працює з вимогами.
Приклади аутсорс компаній: Luxoft, Redmadrobot, DataArt, Epam.
Продуктова розробка
У продуктовому менеджменті схема відрізняється від аутсорсу. Тут у ролі замовника виступає користувач: це може бути корпоративний клієнт чи окремі люди. Наприклад, якщо створюємо рішення для конкретного банку, цей банк і буде нашим клієнтом і користувачем створеного продукту.
Залежно від того, це будуть тисячі окремих людей — користувачів продукту або кілька компаній — корпоративних користувачів, продуктову розробку ділять на В2С і В2В:
- В2С — business to consumer — продукт створюють для приватних користувачів. Приклади: програми для замовлення таксі, месенджери, стрімінгові сервіси.
- В2В — business to business — рішення для бізнесу. До цієї категорії можна віднести хмарну платформу Zoom. З одного боку, платформою користуються окремі люди, з іншого — компанія пропонує облікові записи з додатковими фічами для корпоративного сегменту.
Менеджментом у продуктовій розробці займаються два спеціалісти: Product і Delivery Manager.
Product Manager працює над покращенням проєкту в довгостроковій перспективі: прибутковість, кількість часу, який людина проводить у продукті, задоволеність користувачів.
Продуктовий менеджер орієнтований на бізнес, його завдання пріоритезувати функціональність. Є велика кількість різних фіч, які можна вкласти в продукт, але менеджеру потрібно сфокусувати роботу на тих речах, які принесуть найбільшу цінність.
Delivery Manager відповідає за доставку результату користувачеві в рамках обумовлених термінів, якості й бюджету. Delivery Manager бере готові завдання, які розробляє команда, ділить процес на фази, вирішує, чи ми встигаємо чи ні й т.д.
У невеликих компаніях Product Manager об’єднує обидві ролі:
- розвиває бізнес-складову: проводить дослідження, тести, збирає метрики;
- працює з командою: погоджує час, розподіляє людей, планує дату релізу.
По суті, продакт виконує всі обов’язки РМ-а в аутсорсі, тільки при цьому відповідає ще й за бізнесову частину.
Гіганти серед продуктових команд — це Google, Amazon, Apple, а локальні гравці — Readle, Grammarly, Monobank.
В окремих компаніях одні й ті самі ролі можуть називати по-різному. Роль Delivery Manager у продуктовій компанії схожа на роль РМ в аутсорсі — це людина, яка відповідає за доставку результату замовнику.
Сьогоднішнє IT-середовище дуже розмите: можна потрапити до команди, де РМ виконує продуктову роботу в аутсорсі. А можна прийти в продукт, де взагалі немає РМ-а, зате є Scrum Master, бізнес-аналітик і Product Owner.
Добре, ми запам’ятали, що в аутсорсі є РМ і ВА, а в продукті — Product і Delivery менеджери, але хто решта людей, наприклад, той же Scrum Master або Product Owner?
Менеджерські ролі в ІТ
Деякі менеджерські ролі з’явилися в IT-проєктах із двох основних фреймворків: Scrum і Kanban. Зі Scrum прийшла позиція Product Owner — людина, яка займається пріоритезацією, постачанням нових завдань, бізнес-цілей і Scrum Master, що вибудовує процес, аби всі працювали оптимально. З Kanban перейшла роль Service Delivery Manager.
Однак якщо узагальнити, можна виділити три базові менеджерські позиції, інші ролі виходять із цих трьох:
- Product Manager — займається дослідженням конкурентів, розумінням ринку й бізнесової складової, розбирається, яку фічу ми запускаємо й чому.
- Project Manager — веде проєкт. Відповідає за те, щоб поставка сталася вчасно й була потрібної якості, керує командою.
- Business Analyst – вміє виявляти бізнес-вимоги й доносити їх до розробників. Позиція ВА зазвичай буває в аутсорс-компаніях.
Іноді виникає плутанина між обов’язками Project і Product Manager. Якщо спростити класифікацію, то продакт вирішує, що робити розробникам, щоб бізнес заробив гроші, а Project Manager будує процес так, щоб це сталося.
Звідки приходять у РМ-и
У менеджери часто переходять розробники, тестувальники або спеціалісти з support з хорошими управлінськими скилами. PM з технічним бекграундом правильно розставляє терміни, знає, кому адресувати завдання в команді, може самостійно обговорювати деталі з клієнтом і не наобіцяє зайвого.
Звичайно, менеджерська роль — це про управління людьми та процесами, але в IT роботодавці віддають перевагу кандидатам із технічними навичками.
Якщо у вас зовсім немає досвіду, можна піти кількома шляхами:
- Влаштуватися стажером. Заробіток буде на початку невеликим, натомість набудете релевантного досвіду й в майбутньому зможете претендувати на бажану посаду.
- Використовувати силу рекомендацій: знайти людину, яка порадить вас компанії як фахівця без досвіду, але з великим бажанням працювати й якимось важливим скілом. Наприклад, у вас може бути англійська рівня native й високий рівень організованості.
- Бути активним у соцмережах: підпишіться на сторінки вибраних компаній, приєднайтесь до менеджерських спільнот, стежте за обліковими записами людей, які вже працюють в IT-проєктах. Нерідко вакансії щодо пошуку кандидатів розміщують саме на таких ресурсах.
Одне з найчастіших питань на співбесіді – «Чому ви хочете працювати в нашій компанії?» Тому заздалегідь подумайте, що відповідатиме, пошукайте інформацію про компанію — і приходьте на співбесіду підготовленим.
Які менеджерські якості цінують роботодавці
Основний стереотип, який є у Junior РМ-ів при влаштуванні на роботу, звучить так: «Щоб працювати в IT, потрібна технічна освіта».
Хід міркувань приблизно такий: «Ось прийдуть до мене люди і спитають, що робити з сокетами або помилка 401 виходить», — а я нічого не зрозумію, просто злякаюся і все.
Тому більшість новачків намагаються вивчати програмування до того, як прийти в проєктний менеджмент. І це не зовсім правильна стратегія. Щоб керувати командою, потрібні загальні технічні навички, які стосуються скоріш взаємодії між системами, ніж їхньої детальної організації.
Давайте поговоримо про безпосередньо менеджерські скіли. Що потрібно, крім стресостійкості й мультизадачності, щоб отримати шанс на роботу в компанії.
Вміння пріоритезувати задачі, організувати свою активність і роботу команди. Менеджеру доведеться розібратися, які речі основні й що потрібно робити протягом дня. Навичка пріоритезації з’являється з досвідом. Логіка на кшталт: «Зараз краще дороблю якесь не дуже важливе завдання, тому що не хочу переходити до наступного», — дуже швидко зникає в перший же рік роботи РМ-ом.
Спосіб працювати із задачами простий: пишіть у Trello або в нотатки всі свої завдання, а потім витягуйте звідти найпріоритетніші й робіть їх протягом дня. Якщо завдань на день занадто багато, виділіть 3-4 найважливіші й робіть їх насамперед.
Менеджмент очікувань — максимальна прозорість у спілкуванні з усіма учасниками проєкту. Якщо бачите, що є ризики або якісь проблеми, якомога раніше повідомляйте вашого замовника, партнера, керівництво про те, що може піти не так й які є варіанти вирішення.
Ситуативне мислення. Вміння будь-якої миті знайти якусь зачіпку, недоговореність, ризик, або побачити можливість.
Невід’ємна частина роботи в IT — це постійні зміни. Будьте готові, що початковий план ніколи не буде виконано на 100% у задуманому вигляді.
В умовах, коли все часто йде не за планом, ситуативне мислення допомагає РМ-у швидко побачити можливості й рішення:
- Звільнився фахівець — його можна швидко перемістити на інше завдання і встигнути вчасно.
- Виникла велика кількість багів — зараз перегрупуємо команду.
- З’явився новий сервіс — давайте його швидко інтегруємо, щоби встигнути більше зробити.
Ситуативне мислення розвивається з досвідом, як і всі скіли.
Робота із ризиками. Розуміння, де на кожному етапі проєкту можуть виникнути ризики й які: відмова системи, не встигнемо закінчити якусь функціональність, буде більше багів, ніж розраховували. Важливо вміти наперед прогнозувати різні загрози, відстежувати та зводити до мінімуму їхній вплив на проєкт.
Планування навантаження. Здатність знайти баланс сил у команді, передбачати «вузькі місця» та мінімізувати їх. Наприклад, зрозуміти, що у аналітиків зараз перевантаження по задачам, а розробники, навпаки, недовантажені, бо аналітики десь застрягли.
Вміння підтримати команду. Розуміти настрій людей, не транслювати стрес, «тримати руку на пульсі» кожного: регулярно бачитися, проводити зустрічі віч-на-віч, систематично розмовляти з усіма.
Менеджер повинен транслювати команді важливий посил: Що б не сталося на проєкті, РМ — та людина, яка завжди витягне, захистить, допоможе.
Емпатія та компетенція. Якщо у РМ-а добре розвинена емпатія, люди не дратуватимуться, коли ви чогось не розумієте. РМ може сказати розробникам: “Хлопці, я тут не до кінця розумію, поясніть, будь ласка, щоб я знав, як це захищати перед замовником”, — і ніяких проблем
Розробники пояснять і не вважатимуть вас некомпетентним.
Акуратність — дуже важлива риса РМ-а. Якщо РМ неакуратний, неуважний до деталей, це призведе до проблем. Одна незграбна фраза, моменти, коли ви забули відправити follow-up або комусь надто різко відповіли, накопичується в скарбничці ставлення до менеджера. Project Manager, звичайно, не повинен бути роботом, але при цьому потрібно завжди максимально акуратно й дипломатично взаємодіяти з людьми.
Чи підходить мені ця робота
Не кожен буде почуватися успішно в ролі РМ-а. Практично завжди робота продуктового і проєктного менеджера пов’язана зі стресом: конфлікти з командою і замовником, гарячі терміни, бракує бюджету, несподівані загрози. Тому Project Manager має бути максимально стресостійким.
Якщо вам важко справлятися зі стресом і хочеться спокійнішу роботу, подивіться у бік ролей Data або Business Analyst.
Якщо ви спокійно реагуєте на стрес, тоді є кілька можливих варіантів:
- Вам найбільше подобаються процеси: фасилітувати роботу команди, налагоджувати хід проєкту, знаходити слабкі місця, робити розрахунки — можна йти до РМ-ів або Scrum Master. Хоча зазвичай, Scrum Master — це не вакансія, а роль на проєкті, яку виконує хтось із команди, найчастіше якраз проєктний менеджер.
- Якщо цікавий продукт: подобається розбиратися в потребах користувача, аналізувати ринок, вибудовувати лійки — вам потрібно в продуктовий менеджмент. Або можна стати Product Owner в аутсорсі — це одна з ролей у команді по Scrum-у.
- Вам не подобається концентруватися на чомусь одному, а хочеться прокачатися у всьому одразу – йдіть у стартап. Продакту чи РМ-у в стартапі доведеться і дизайн малювати, і з замовником щось узгоджувати, і презентації проводити. Така роль дасть величезний досвід.
Якщо все ще сумніваєтеся, чи підходить вам професія Project Manager, поспілкуйтеся з кимось, хто вже працює PM-ом, розпитайте про переваги й недоліки посади.
А якщо вже зважилися, приходьте за теоретичною базою та практичними скілами на DAO PM, щоб здобути навичку управління IT-командою.