Скільки проєктів проджект-менеджер може вести одночасно без овертаймів? Як сказати клієнту, що проєкт вийшов за межі бюджету? Що робити, якщо керівник не розуміє, що команді потрібен PM?
Це формат, де лектор Laba відповідає на найболючіші запитання наших студентів, а відповіді ми публікуємо для всіх. Цього разу спікер — Павло Харіков, який керує проєктами та командами 15+ років і випустив 20+ потоків курсу «Project Manager».
#1. Скільки проєктів одночасно може вести проєктний менеджер?
Відповідь впирається у фізіологічну здатність переключатися між задачами. Людині потрібно приблизно пів години, щоби повернутися до якісної осмисленої творчої роботи після того, як її відволікли.
Далі — проста математика. Якщо у ПМа більше трьох проєктів, то займатися ними усвідомлено і глибоко він не зможе. Можна епізодично підключатися, пропонувати ідеї, але повноцінно вести — ні. З мого досвіду, навіть дуже досвідчені ПМи можуть тягнути максимум три проєкти одночасно: один великий і два значно менші. Усе, що понад — самообман.
У мене був період, коли на мене навалили сім проєктів, і це просто не працювало. Тоді ми всі ще працювали в офісі, і мій день складався з постійного переміщення з однієї переговорки в іншу. Я намагався вникати, фіксувати питання, але фактично це трималося тільки на овертаймах. І це пряма дорога до вигорання.
Є ще закон Літтла: час перебування будь-якої задачі в системі прямо пропорційний кількості задач та обернено пропорційний пропускній здатності. Тобто, чим більше задач закидаємо, тим ближче час очікування виконання кожної з них до нескінченності. При цьому всі будуть зайняті, втомлені, роздратовані й запрацьовані «в нуль».
Як керівник команд ПМів, я можу сказати: наша задача — максимально ефективно використовувати ресурс, але без перевантаження людей. Бо заміна спеціаліста завжди буде довшою та дорожчою, ніж збереження здорової, стабільної роботи. Тому моя відповідь на питання «скільки проєктів?» — стільки, скільки реально потрібно, щоб зробити їх добре й не вигоріти у процесі.
#2. Як зрозуміти, що роль ПМ тобі не підходить?
Робота проєктного менеджера за визначенням стресова. Якщо подивитися на саме визначення проєкту — це реалізація унікального продукту з обмеженими ресурсами, бюджетом і часом.
Ключове тут — «унікальний». Це означає, що ми не можемо жити з постійним відчуттям впевненості у завтрашньому дні. Пригадайте правило 10 тисяч годин: коли ти робиш щось стільки часу, то стаєш суперекспертом. Але в проєктного менеджера все інакше: сьогодні ти ведеш проєкт у одній галузі, завтра — у іншій, навіть у межах однієї компанії. Змінюється все. Це створює стан, коли ти постійно робиш щось нове, а це викликає природну реакцію — прокрастинацію. Незрозуміле, складне, нове хочеться відкласти «на потім».
Тому, на мій погляд, є кілька якостей, без яких у проєктному менеджменті буде важко:
- Цікавість
Потрібно, щоби було внутрішнє «мені цікаво, чим це закінчиться». Я, наприклад, інтроверт, і мені не хочеться спілкуватися з незнайомими людьми. Але цікавість до результату (чи вийде проєкт, як житиме продукт далі) переважає моє небажання комунікувати. Тому я треную себе, розвиваю ці навички. - Внутрішній спокій
Вам цікаво, але іншим учасникам команди — ні, бо вони в стресі. Для них провал — це трагедія, а для нас — природна частина роботи з унікальними продуктами.
Треба вміти розбивати незрозумілий майбутній результат на конкретні, зрозумілі, звичні задачі. І робити це спокійно: якщо в нас немає експертизи — шукаємо консультантів чи підрядників. Головне — не панікувати, бачити велику картину й системно розкладати складне на просте. - Проактивність
Процеси самі по собі не працюють. Якщо ПМ просто розіслав кілька листів і поставив задачі, то або не отримає нічого, або отримає щось зовсім не те. Не можна відпускати роботу «на самоплин». Не можна розраховувати, що всі самі себе організують. Це означає не пасивно спостерігати, а постійно взаємодіяти, уточнювати, підштовхувати.
Як зрозуміти, що ця робота не для вас?
— якщо вам болісно займатися тим, у чому ви не експерт
— якщо неприємно постійно комунікувати й шукати способи впливу
— якщо все це тисне більше, ніж захоплює перспектива створити щось унікальне
… тоді, можливо, не варто цим займатися. Бо проєктний менеджмент — це історія для тих, кого драйвить новий виклик. Якщо драйву немає, ви швидко вигорите.
#3. Чи обов’язково ПМу розвивати доменну експертизу?
Мій досвід каже: галузі можна змінювати. Я працював у телекомі, у банківській сфері — і там, і там після певних зусиль перехід не був проблемою. Але є сфери, де доменна експертиза критично важлива. На мій погляд, це дуже зарегульовані галузі — наприклад, медицина.
#4. Чи може PM виконувати інші задачі, не пов’язані з управлінням процесами?
Обставини бувають різні, інколи в компанії просто не вистачає людей. Але, на мій погляд, у проєктного менеджера й без того багато завдань.
Навіть коли проєкт уже на етапі реалізації, і здається, що планування завершене, кожен має свої задачі, а ПМ «нібито нічого не робить» — починається найважча частина роботи.
По-перше, доводиться гасити пожежі: щось завжди йде не так, і це треба виправляти.
По-друге, ПМ постійно робить прогнози: аналізує терміни/витрати й переплановує кроки так, щоб не зупиняючи роботу, усе ж вийти на успішний результат.
І це набагато важливіше, ніж, скажімо, зекономити на бізнес-аналітику, переклавши його роботу на ПМа. Бо швидше за все, бізнес-аналіз вийде слабким, і коли через це щось посиплеться, буде вже пізно рятувати. Тому якщо є можливість не вантажити ПМа додатковими задачами, краще цього не робити.
#5. Як довести керівнику чи власнику, що проєкту треба PM?
Я не прихильник когось переконувати. Якщо без проєктного менеджера все працює — чудово. Не треба наймати людину тільки тому, що так прийнято.
Потреба в ПМ стає очевидною, коли все починає валитися: проєкти не запускаються, дедлайни зриваються, обіцянки клієнтам не виконуються, компанія втрачає гроші й репутацію. І це розуміння приходить лише через негативний досвід — словами його не нав’яжеш.
Якщо зараз у вас усе працює, мабуть, хтось уже виконує роль ПМа. Бо саме собою нічого не відбувається.
Якщо ж справді немає нікого, хто цим займається, можливо, варто подивитися в дзеркало. Бо, швидше за все, це робите ви — керівник, який каже, що ПМ не потрібен. Але тут інше питання: чи ви маєте займатися організацією роботи людей замість того, щоб фокусуватися на стратегії і розвитку бізнесу?
#6. Як визначити, який фреймворк найкраще підійде проєкту?
Якщо дуже просто, то класичний Waterfall — це зовсім не застарілий підхід. Навпаки — найбільш ефективний там, де вимоги можна зафіксувати. Наприклад, у вас проєкт, пов’язаний зі змінами в законодавстві, де ви точно знаєте, що і як треба зробити. У такому випадку нічого кращого за перевірений десятиліттями «ватерфольчик» не придумали.
Agile потрібен тоді, коли ми чесно визнаємо: ми не знаємо, що саме потрібно кінцевому споживачеві. Наше завдання — «нащупати» це, роблячи маленькі кроки. Ми щось робимо, показуємо результат, отримуємо фідбек — потрібно це чи ні, і якщо потрібно, то що змінити. Так рухаємося далі. Це дорого, але якщо хочемо створити дійсно затребуваний продукт, іншого виходу немає.
Отже, ключове правило таке: гнучкі методології потрібні там, де кінцевий обсяг робіт і потреби користувача незрозумілі. Класичні підходи — там, де можемо чітко визначити скоуп із самого початку.
#7. Що робити ПМу, якщо проєкт вийшов за межі бюджету?
Чи може щось піти не так? Може. І, чесно кажучи, обов’язково піде. Коли ми плануємо, ми створюємо проєкт у голові та на папері. Фізично продукту ще не існує, це набір наших гіпотез.
Ми, звісно, намагаємося дотримуватися початкового плану й бюджету, але життя вносить корективи. Найгірший сценарій — коли ви приходите до спонсора вже з фактом: «Ми витратили вдвічі більше». Це означає, що ви не відстежували витрати й не виконували свою роботу. За таке справді має бути соромно.
Інша річ — коли ви завчасно бачите, що запланований обсяг робіт коштує більше, ніж передбачалося. Наприклад, під час тендеру з’ясовується, що ціна не X, а X×3. Це вже не ваша провина, просто реальність змінилася.
Правильна робота ПМа тут — прийти до спонсора з варіантами. Для цього треба розуміти, що саме є пріоритетом: строки, бюджет чи обсяг робіт.
Наприклад, якщо для замовника критичний дедлайн — як у випадку, коли Нацбанк зобов’язує банки змінити процеси до конкретної дати, інакше заберуть ліцензію, — то строки будуть важливішими за бюджет. Але навіть тоді можна прийти з опціями: «Ми бачимо перевищення, пропонуємо прибрати ось ці додаткові задачі, які ми додали для зручності, але яких немає в обов’язкових вимогах».
В ідеалі, ви завжди маєте приходити з кількома рішеннями, балансуючи між трьома обмеженнями: строки, бюджет, скоуп. Якщо треба зберегти бюджет, є два варіанти: або робити менше, або робити довше (наприклад, силами внутрішньої команди без підрядників).
Варіант «знизити якість» я навіть не розглядаю. Просто бо поганий результат навіть за ті ж гроші нікому не потрібен.
От і вся формула: якщо вилізли за бюджет — або збільшуємо строки, або зменшуємо обсяг.
#8. Як відстежувати динаміку, щоби попереджати зрив дедлайну?
Мій рецепт без токсичності чи оверконтролю — вирішувати через допомогу, а не тиск. Є виконавець, у нього є дедлайн. Він каже: «Все гаразд». Але проходить половина часу, і нічого не відбувається — що робити? Подивитися, що далі має відбуватися з результатом його роботи. Зазвичай він передається іншій людині чи підрозділу.
Я тоді приходжу до цього виконавця і кажу: «Наступний виконавець хвилюється, що задача нечітка. Давай я організую зустріч, і ти розкажеш, у якому форматі буде результат, що саме ти зробиш». Відмовлятися тут немає причин: усі зацікавлені, щоби проєкт відбувся.
Часто проблема зірваного дедлайну в тому, що час на виконання минає, а людина ще навіть не почала. Наприклад, мала 10 днів, думала: «Зроблю за два», а потім виявилося, що треба всі десять. Наше завдання — змусити почати. Бо коли людина вже у задачі, їй легше завершити її, ніж кинути.
Організація такої зустрічі змушує виконавця розібратися, сформувати бачення кінцевого результату, і тоді він захоче довести роботу до кінця, щоб не починати заново.
#9. Як говорити зі стейкхолдером, який неактивно залучений у проєкт?
Будь-яку комунікацію треба будувати з повагою до співрозмовника. А повага — це коли нам не байдужі його інтереси. Якщо ми розуміємо, що важливо цьому стейкхолдеру, то можемо дати корисну інформацію або зробити пропозицію, яка його залучить.
Робота зі стейкхолдерами — це не «софт-скіли для галочки». У 7-му виданні PMBOK є окремий принцип, який підкреслює важливість ефективної комунікації в проєкті, включаючи своєчасний обмін інформацією, адаптацію до потреб аудиторії та використання відповідних методів. ПМ має вміти це робити.
Якщо нам від людини щось потрібно, треба почати з її інтересів: показати, як наш проєкт і його результати закриють її потреби. І лише потім переходити до того, яка від неї потрібна допомога чи інформація.
Бажаєте отримувати дайджест статей?
