Це третя стаття циклу «Як пройти співбесіду на роль Senior PM». В попередньому матеріалі обговорили, які запитання ставлять про досвід кандидата й чому. Сьогодні поговоримо про базові навички позиції РМ-а: планування, трекінг прогресу й управління змінами. Цей базис дає можливість роботодавцю зрозуміти, чи підходить кандидат на роль РМ-а.
Запитання про планування
Відкрите запитання: «Як ви плануєте проєкт?» ставлять, щоб дати людині вибрати зручний напрямок відповіді, зрозуміти сильні та слабкі сторони кандидата. Далі можуть запропонувати для розгляду ситуаційний кейс. Давайте подивимося на приклад у наступному пункті.
Строки здачі проєкту
Уявіть, що ви плануєте проєкт із зовнішнім дедлайном (його не можна перенести) та скоупом, який обов’язково потрібно виконати. Як вирішите ситуацію?
В аутсорсингу часто обмежений бюджет і строки, й часто ці рамки дуже жорсткі. Навіть якщо у вас не Fixed Price контракт, все одно невиконання очікувань викличе невдоволення клієнта й зіпсує репутацію менеджера.
Наймаючи РМ-а, роботодавець хоче зрозуміти, чи зможе фахівець планувати проєкти, дотримуючись жорстких бюджетних і часових обмежень. Відповідь: «Спланую на пару спринтів вперед, почну розробку, зрозумію свою швидкість і тоді повідомлю про приблизні терміни» — не підходить. Такий прийом хороший, коли є готовий план, і ви почали відслідковувати його реалістичність. Клієнт не підпише з вами контракт, якщо не побачить хоча б попередньої оцінки бюджету й термінів здачі. А в деяких випадках йому потрібна не просто оцінка, а контрактний комітмент.
Процес оцінки беклогу
Оцінку можна побудувати по-різному: попросити команду заповнити таблицю з трудомісткістю, провести спільну зустріч, застосувати фасилітаційну техніку Planning Poker. Цінність таких технік у тому, що вони стимулюють обговорення задач між інженерами, а це сприяє загальному розумінню задач командою.
Покажіть, що розумієте механіку процесу: що саме включаєте в оцінку, в яких одиницях звикли працювати (години або відносні одиниці, наприклад Story Points) і які техніки застосовуєте: PERT, 2-point і т.д.
Конвертація оцінки робіт у план і розрахунок дедлайну
Цей блок питань відповідає наступному важливому етапу планування – розрахунку прогнозу дати релізу.
Кандидат повинен показати, як оцінка беклогу, зроблена командою, буде сконвертована в роадмап проєкту й ресурсний план. Зокрема, як кандидат враховуватиме залежності, продуктивність команди, час на комунікацію, багфікс. Наприклад, побудує діаграму Ганта чи замінить її простими математичними розрахунками (варто розповісти, якими саме). Тут варто уникати відповідей у стилі «Просто візьму оцінку від команди й поділю на кількість людей» — досвідчені PM-и знають, що такий розрахунок призводить до нереалістичного плану і зриву термінів.
Підготовка до релізу
Інтерв’юеру потрібно впевнитись, що кандидат зможе спланувати весь життєвий цикл проєкту — від початку до кінця. Роботи з реалізації проєкту складаються не лише з розробки й тестування.
Направити думки в потрібне русло допоможе запитання, як РМ готуватиметься до релізу. Плануючи проєкт, менеджер завжди повинен розуміти, як він його завершуватиме. Правильно спланований реліз передбачає такі фази:
- регресійне тестування і стабілізація;
- прийомка — замовник оцінює результати з погляду відповідності бізнес-вимогам і приймає проєкт;
- розгортання системи у продакшн-середовищі.
Всі ці блоки запитань допомагають зрозуміти, чи є у вас досвід планування проєкту повного циклу: від збору вимог до релізу з передбачуваними термінами й бюджетом. Кандидату важливо відповідати предметно та вміти показати механіку процесу.
Запитання про трекінг прогресу
Наступна група запитань орієнтована на оцінку трекінгу прогресу. Жоден проєкт не йде чітко за планом, тому потрібно постійно відслідковувати його стан: наскільки випереджаємо чи відстаємо від графіка, чи встигаємо до дедлайну.
Як зрозуміти, що ви встигаєте/не встигаєте до релізу
У клієнта завжди є очікування по строкам, і РМ-у потрібно ними керувати. Кандидат має розповісти, які метрики збирається використати і як прогнозуватиме нову дату релізу, якщо стара вже не актуальна.
Наприклад, у вас пройшла половина проєкту, виконали 40% робіт. Як дізнатися, чи встигнете ви до дедлайну? Як це прорахувати? Деякі менеджери кажуть, що визначають прогрес проєкту з контрольних точок. Це хороший спосіб, але якщо контрольні точки не гранулярно розташовані на таймлайні, відставання по строках можна побачити занадто пізно. Вам потрібно показати, як ви збудуєте процес регулярного виміру прогресу.
Як виміряти прогрес, якщо не весь беклог декомпозовано
Зазвичай розробка починається з високорівневого негранулярного беклогу (рівня епіків і фіч), який команда поступово декомпозує у процесі роботи. В більшості випадків, планування відбувається «на хвилі, що набігає»: деталізуємо беклог на один-три спринти вперед.
На співбесіді наймач може попросити розповісти механіку виміру прогресу у випадку, якщо є розписані на три тижні User Story, але на наступні півроку їх немає, а є лише епіки.
Які показники включати до звіту
Це запитання не тільки про те, як вимірювати прогрес, але й про те, чи ви розумієте, що цікаво клієнту. Це особливо важливо в аутсорсингу, де робота PM-а завжди орієнтована на зовнішнього клієнта.
Менеджер повинен знати, яку інформацію потрібно надати клієнту, щоб той розумів, чи дотримуються дедлайни, при цьому не заглиблюючись у непотрібні деталі. Наприклад, клієнту на великому проєкті може бути не важливо, в якому статусі є та чи інша задача. Набагато важливіше розуміти загальний прогрес щодо проєкту та прогноз щодо термінів, бюджету, скоупу.
Кандидата можуть запитати, що він включить до звіту на різних фазах. Наприклад, на фазі приймання логічно використовувати метрику, яка покаже скільки функцій продукту клієнт вже прийняв, а на фазі стабілізації – кількість знайдених й усунених дефектів і загальний тренд щодо них.
Плюсом буде, якщо відповідаючи на цей блок питань, ви скажете, що хочете узгодити структуру і формат звіту з клієнтом. Це особливо важливо в роботі Senior-фахівця — ваша задача не просто дотримуватись стандартів компанії, а й адаптувати їх під потреби конкретного замовника.
Scope Change Management
Не буває так, що спочатку затвердили скоуп — і проєкт «живе» півроку без жодних коректив. Робота зі змінами знайома всім менеджерам: іноді змін настільки багато, що команда витрачає більше часу на їхню обробку, ніж на виконання проєкту. Запитання щодо Change-management дозволяють наймачеві зрозуміти, чи зуміє РМ впоратися з потоком змін замовника.
Що робити, якщо клієнт постійно уточнює скоуп проєкту
Запитання ставлять, щоб зрозуміти, чи знайомий кандидат із change-менеджментом, які інструменти застосовує. Припустимо, PM розповів про реєстр змін і даних, які туди потрібно вносити, показав, як використав це на поточній роботі. Тепер можна переходити до уточнюючих запитань.
Як відрізнити новий скоуп від простої деталізації вимог
З подібними ситуаціями РМ стикаються постійно, але при цьому на багатьох проєктах change-менеджмент побудований погано. Наймачеві потрібно розуміти, як ви вирішуватимете спірні питання щодо скоупу.
Уявіть, що є недекомпозованний елемент беклогу — менеджмент користувачів. Ви починаєте уточнювати, що саме стосується цієї фічі, й раптово з’являється імпорт акаунтів з active directory. Щоб зрозуміти, новий це скоуп чи ні, менеджеру потрібно оперувати поняттями scope baseline, вміти застосовувати як формальні критерії порівняння, так і переконувати клієнта, зсилаючись на здоровий глузд. Адже не всі аспекти можуть бути задокументовані навіть у дуже детальному бейзлайні.
Що робити, якщо змін надто багато
Буває так, що клієнт безперервно генерує зміни й команда витрачає час на їхню обробку замість розробки. Пропонуючи таку ситуацію, наймач хоче почути, з якими аргументами ви підете до клієнта, що йому запропонуєте або які дані зберете.
Якщо підсумувати, то блоки з запитаннями щодо трекінгу прогресу й управління змінами показують інтерв’юеру, чи вміє менеджер брати відповідальність за проєкт цілком, не обмежуючись виключно постачанням окремих спринтів.
Senior PM — це фахівець, який може спланувати проєкт із «нуля», знає, як діяти в жорстких обмеженнях за термінами, бюджетом, скоупом. Проходячи співбесіду на цю позицію, покажіть, що у вас є план, як вирішувати складні ситуації. Зважайте на те, що роботодавець хоче почути не теорію, а те, з чим кандидат реально стикався на практиці.
У наступній, четвертій статті, поговоримо про фінанси, контракти та кризи на проєкті. Побачимося!