Проєктний менеджер, який розуміється на технічних нюансах з першого робочого дня — міф. Єдиний виняток — це PM-и з бекграундом у розробці. Отже, ви проєктний менеджер, який прийшов на свою першу роботу і нічого не тямить у тонкощах проєкту. Спочатку це нормально. Розробники косо поглядають? Нічого страшного, всі ми там були.
Освоївшись на проєкті, ви задумуєтеся, а чи потрібно взагалі розбиратися в деталях, чи це не має значення? Класична дилема, після якої кожен обирає свій шлях у проєктному менеджменті. Перш ніж обрати, радимо ознайомитися з перевагами розуміння деталей, які обговорюють розробники на мітингах і перекурах.
Насамперед, давайте домовимося, що проєктний менеджер у невеликому стартапі за обов’язком служби виконує зовсім не ті завдання, з якими стикається проєктний менеджер у великій корпорації.
У стартапі вам, швидше за все, не доведеться масштабувати SCRUM, зате від вас очікуватимуть економії коштів, уміння домовлятися з не завжди адекватними замовниками й щоразу стрибати вище голови.
Проєктні менеджери, які виконують лише свої обов’язки, приймайте наші сердечні привітання з потраплянням до 15% співробітників великих компаній із налагодженими процесами. Інші ж 85%, ласкаво просимо до реального світу.
У реальному світі проєктному менеджеру було б непогано розуміти, про що говорять розробники. Це не обов’язкова умова, але дуже бажана. Зараз пояснимо чому.
Робота з командою
Для роботи над репутацією компанії в медіапросторі важливо отримувати максимально можливий відсоток задоволених замовників. Таке можливе лише якщо команда працює злагоджено й на результат. Для результату зазвичай вистачає виконання однієї з двох умов:
- Процеси максимально налагоджені;
- Проєктний менеджер своєю могутньою спиною закриває всілякі проблеми і за будь-яку ціну залишається другом і лідером команди.
І якщо на перший пункт ви можете впливати лише частково, то реалізація другого — ваша відповідальність. Як це зробити розповіли нижче.
Вникати в суть, а не просто посміхатися й кивати
Якщо вам здається, що розробники ведуть себе занадто гордо, поставте себе на їхнє місце. Найімовірніше, на початку своєї кар’єри хлопці щиро намагалися доносити технічні нюанси до менеджменту, але стикалися із хвилею нерозуміння.
А тепер чесно дайте відповідь собі на питання, чим ви відрізняєтеся від попереднього менеджера? Тож не дивуйтеся, якщо їхні відповіді будуть односкладовими й ніяк не розкриватимуть суть. «Це або можна реалізувати, або не можна тому, що не можна», — скаже вам розробник і буде абсолютно правий, тому що яка різниця, говорити просто «не можна» або замінювати «просто» купою незнайомих слів?
«Не можна» — воно і простіше, і зрозуміліше. Якщо вам комфортно, коли з вами розмовляють, як з нерозумною дитиною, значить, час щось змінювати.
Лідити команду незважаючи ні на що
Командувати розробниками й бути менеджером проєкту — не те саме. Бути менеджером проєкту означає гарувати більше за всіх й овертаймити разом із командою. Якщо ви нічим не можете допомогти розробникам навіть на елементарному рівні — яка користь з вас як менеджера?
Тут можна було б сказати про те, що менеджер своє завдання виконав, можна йти додому, але з таким підходом не дивуйтеся, коли команда так само наплювацьки ставитиметься до вас, як і ви до них.
Найкраще, що ви можете зробити на проєктах, що горять, — постаратися допомогти. Якщо у вас немає бекграунду в розробці, можете прискорити роботу якимось рішенням, колом, листом, паралельно виконуючи свій нескінченний список завдань за іншими проєктами.
Найважливіше тут — залишатися на місці і максимально оперативно допомагати, коли ви потрібні. Але без розуміння суті процесів ви швидше затягуватимете реліз, ніж допомагатиме команді.
Адекватно оцінювати рівень розробників
Навіть у невеликих компаніях за вами має залишатися право підбирати команду під проєкт. В іншому випадку ви можете взагалі не зрозуміти, як розбити завдання і на чому команді сфокусуватися насамперед.
Судити про розробника за послужним списком проєктів складно. Наприклад, абсолютно геніальний пітонщик Аркадій, який не спрацювався з попередніми командами через свій перфекціонізм, на вашому проєкті може виявитися суперзіркою, якщо знайти йому вірних падаванів і правильно розставити пріоритети.
Приємний бонус: якщо команда зрозуміє, що ви на їхньому боці й намагаєтеся зробити все можливе, щоб не ускладнювати їм життя, крім того знаєте, чому тут прийнято те чи інше рішення, вони намагатимуться працювати з вами якомога довше. Ще й розумних друзів приведуть, бо побачать процеси заради результатів, а не заради самих процесів.
Робота з замовником
Відповідати на запитання одразу по мірі їх надходження
Замовники — не наївні діти, і щоби переконатися в адекватності запропонованих вами рішень, намагаються максимально підстрахуватися, залучаючи інших технічних фахівців та консультантів.
Таким людям платять за максимально можливу кількість уточнюючих і незручних питань, і якщо на кожне з них ви не зможете відповісти без команди розробки, то в очах замовника виглядатимете зайвою ланкою в ланцюзі. Навіщо зустрічатися з людиною, яка не готова вести конструктивний діалог, якщо можна відразу запитувати розробників?
Крім того, не варто недооцінювати конкуренцію. Якщо вже замовник шукає людину, готову моментально відповідати на його запитання і знається на технічній частині, рано чи пізно він її знайде. Цією людиною може стати один із найсильніших розробників, який давно цікавився менеджментом.
Намагайтеся не випадати з технічного контексту. Ваш обов’язок — міняти проєкт, а не просто працювати з документацією і нагадувати всім про дедлайн.
Продавати додаткові послуги
Під час обговорення функціоналу, замовник може озвучити якесь побажання, і якщо ви зумієте вчасно згенерувати відповідне рішення та озвучити хоча б приблизні терміни й вартість – компанія отримає додатковий прибуток.
Прибуток — це добре, але щоб розробники не погрожували вам після цієї пропозиції розправою, треба розуміти, що саме ви пропонуєте, і наскільки ця пропозиція виглядає реалістично та здорово.
Приємні бонуси
Бюджет
Ви можете сказати, що для реалізації всіх озвучених вище завдань достатньо залучити спеціально навчених фахівців (читай бізнес-аналітиків, техлідів і тімлідів), але ці хлопці цілком заслужено коштують своїх грошей, яких компанія на етапі масштабування може не бути готовою виділити.
Ось і виходить, що чим глибше у вас експертиза в суміжних областях, тим вище ви цінуєтеся як проєктний менеджер. А ще такі знання чудово відбиваються на вашій зарплаті.
Обсяг робіт
Коли проєктний менеджер знає матчастину і всі процеси, що відбуваються, можна бути впевненим, що, з одного боку, без його апрува в проєкт не «всунеться» те, що виходить за рамки бюджету, а з іншого, що сам менеджер з незнання не пообіцяє розробку адронного колайдера.
Кар’єрне зростання
Багатофункціональний проєктний менеджер — мрія будь-якого CEO, оскільки замість того, щоб постійно його контролювати, можна отримувати відгуки задоволених замовників, розробників та гроші. Кого під час масштабування підвищать насамперед — розповідати не треба.
Висновки
Керувати тим, чого не розумієш, можна, але потрібно бути готовим сумувати й часто випадати з контексту. Щоб отримувати більше свободи (й відповідальності), проєктному менеджеру було б непогано розумітися на технічній матчастині.
Ми не закликаємо PM-ів ставати програмістами, проте поглиблене розуміння процесів на проєкті — чудова підмога професійного зростання. Доведено прикладом наших спікерів і менторів курсів Dao PM, PM Hard Skills: Planning, PM Hard Skills: Release та Techmind.