Співбесіда проджект-менеджера фокусується на оцінці, ризиках і незручних розмовах — з командою і з клієнтом. Нижче — найчастіші питання з еталонними відповідями. Middle: глибше розуміння, оптимізацію та реальні робочі ситуації.
Story points виражають відносний розмір і складність, а не години, що позбавляє хибної точності часових оцінок і враховує різну швидкість різних людей. У planning poker усі оцінюють одночасно, щоб ніхто не якорився на найгучнішій думці, і справжня цінність — в обговоренні після розходження. Прогнозувати за точками можна лише після кількох спринтів, коли встановилася velocity.
Піднімати питання одразу, щойно ви це зрозуміли, а не коли це стане незаперечним — ціна сюрпризу набагато вища за ціну поганої новини. Приходити треба з варіантами, а не лише з проблемою: урізаний скоуп, поетапна поставка, додавання людей з урахуванням часу на їх розгін або перенесення дати, і в кожного варіанта проговорені наслідки. А далі рішення ухвалює той, хто володіє цим компромісом.
Ризики виявляють разом з командою, заносять з імовірністю та впливом, призначають власника і прописують захід зниження й тригер, що каже, коли діяти. Конкретний приклад — залежність від стороннього API: захід це розробка проти моку за інтерфейсом, а тригер — відсутність доступу до пісочниці до визначеної дати. Реєстр ризиків, який ніхто не переглядає щотижня, це документація, а не управління.
Velocity — це кількість точок, яку команда закриває за спринт, і корисна вона як діапазон прогнозу по кількох спринтах, а не як одне число. Burndown показує залишок роботи в часі й здебільшого розкриває форму: пласка лінія на початку й обрив у кінці означають, що роботу не інтегрують до останнього дня. Обидва інструменти діагностичні, для команди — використання velocity як цілі за продуктивністю гарантовано псує оцінки.
Розбиратися рано і спершу віч-на-віч, відділяючи позицію кожного від потреби, що за нею стоїть. Більша частина технічних конфліктів насправді про непроговорені пріоритети — один оптимізує термін поставки, інший підтримуваність — і називання цього компромісу перетворює сварку на рішення. Якщо не розвʼязується, ескалювати тому, хто володіє компромісом, а не давати конфлікту тліти.
Не боротися зі змінами, а зробити їхню вартість видимою. Процес change control, де кожен запит отримує оцінку впливу на скоуп, терміни й бюджет, перетворює суперечку на усвідомлений вибір, і клієнти зазвичай самі себе обмежують, коли компроміси явні. Часті зміни ще й часто сигналять про недостатнє дискавері, тому коротші цикли зворотного звʼязку та демо можуть зняти причину, а не симптом.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Middle Project Manager →