П’ять пасток, у які потрапляють навіть досвідчені проджект-менеджери. Колонка FAVBET Tech

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

У цій партнерській статті з FAVBET Tech розбираємо п’ять управлінських помилок, які запускають такий сценарій, і ділимося способами вчасно його зупинити.

Помилка №1. Менеджмент без контексту

Уявіть ситуацію: замовник приходить і просить розширити блок рекомендацій, щоб було «як у конкурентів». Зробити треба швидко, тож PM одразу ставить завдання на технічну команду. Чи виконає вона його? Цілком може бути, що так. Але ось що може відбутися далі: аналітика покаже, що на блок майже не клікають, рекомендації не релевантні, а місце розташування невдале.

Як можна було б запобігти цій ситуації? Одразу дізнатися контекст. Поставити запитання, чи йдеться про зростання середнього чека, CTR або утримання користувачів. Тоді це був би не просто готовий модуль, а бізнесово вмотивований результат.

За даними PMI Pulse of the Profession, 37% проєктів провалюються через нечіткі або неправильно визначені вимоги. Завдання PM – не лише передати вимоги розробникам, але й зрозуміти, яку саме проблему розв’язує клієнт, які показники мають змінитися та як виглядає успіх.

Помилка №2. Гасити пожежі, а не будувати систему

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

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

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

Із чого почати? Із простих, але регулярних практик стратегічного контролю:

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

Але найголовніше – залишати в календарі час не лише на завдання, а й на аналіз процесів.

Помилка №3. Мікроменеджмент

Деяким PM, особливо новачкам, здається, що чим більше мітингів, статус-апдейтів і таблиць, тим стабільніше рухається проєкт. Але насправді саме автономія, а не мікроменеджмент підвищує продуктивність команд. Дослідження Harvard Business Review 2023 року показало, що команди з високим рівнем автономії генерують на 40% більше інноваційних рішень, ніж ті, що перебувають під жорстким контролем.

Автономія не означає анархію – потрібні чітко задані межі. Ось як можна впровадити це на практиці:

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

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

Помилка №4. Не прокачувати навички комунікації

За даними Project Management Institute, найчастіше провали проєктів пов’язані з неефективною комунікацією. Ось які конкретні помилки можуть бути:

• Не домовитись про правила спілкування. Один клієнт пише у Telegram, інший – на пошту, а частина команди відповідає лише в Jira. У результаті важливі оновлення розсипаються по різних каналах і кожен учасник має свою версію реальності.

Проста communication matrix – хто, з ким і де обговорює завдання – знімає половину непорозумінь, але часто про неї згадують лише після кризи.

• Обговорювати, але не вирішувати. Мітинги, де всі активно дискутують, створюють ілюзію прогресу. Але якщо після таких розмов немає жодного рішення або відповідального, наступного тижня команда знову збереться, щоб обговорити те саме питання іншими словами.
• Не проговорювати очевидне. Досвідчені менеджери часто пропускають речі, які їм здаються базовими: хто затверджує фінальний дизайн, коли настає момент done, які очікування щодо тестів. Але саме очевидне найчастіше стає причиною затримок.

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

Помилка №5. Естімейтити навмання

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

Естімейти – не просто цифри. Це спільна домовленість між тими, хто виконує роботу, і тими, хто її координує. Коли менеджер бере повну відповідальність на себе, він вирізає найважливішу частину процесу – діалог.

Але чому це взагалі відбувається? Хіба правило «не оцінюй самостійно» не просте як двічі два? Часто в його невиконанні винний страх виглядати некомпетентним: ніби фраза «потрібно перевірити з розробниками» зменшує авторитет. Що іронічно, бо насправді саме вона відрізняє зрілого PM від новачка.

Ба більше, досвідчені проджекти ніколи не називають одну цифру. Вони працюють з діапазоном – оптимістичним, реалістичним і песимістичним сценарієм – і завжди закладають у план близько 30% буфера на непередбачені ризики. А після старту не вважають соромом переглянути оцінки, коли стає більше даних.

Як зрозуміти, що ви не повторюєте ті самі помилки

Після завершення проєкту можна одразу перейти до наступного. А можна виділити час на ретро. Щоб зробити його правильно, варто почати з короткого самоаналізу і спитати себе:

• Чи були завдання, для яких я дав / дала оцінку без консультації з командою і як це закінчилося?
• Де ми втратили найбільше часу: у плануванні, комунікації чи погодженнях?
• Які ризики ми недооцінили і як їх можна було помітити раніше?
• Чи були моменти, коли я підмінив / підмінила рішення діалогом або навпаки – замовчав / замовчала проблему?
• Які сигнали про проблеми я проігнорував / проігнорувала, бо не було часу?

Можливо, відповіді будуть не завжди приємними, але вони приведуть вас до професійного зростання. Як зазначають у дослідженні Exploring Retrospective Meeting Practices and the Use of Data in Agile Teams, найефективніші команди – не ті, що помиляються рідше, а ті, що системно аналізують власні збої та коригують процеси вже на наступному циклі.

Більше про FAVBET Tech