Уявімо цілком реальну ситуацію.
Проєкт триває кілька місяців. Погоджені структура, дизайн, технічне завдання. Частина функціоналу вже готова.
І тут з боку замовника змінюється PM.
Нова людина відкриває макети й каже: «Я б побудував це інакше».
І, дійсно, іноді свіжий погляд справді висвітлює рішення, які команда не помітила або не врахувала певних нюансів.
«І я ж те ж кажу, і воно усе так, та тільки трішки, будучи, не так», — як казав один із персонажів відомої комедії «Шельменко-денщик».
Проблема починається з іншого: коли «я б зробив інакше» автоматично перетворюється на «давайте переробимо».
У нашій практиці був проєкт, у якому з боку клієнта змінилися три керівники: виконавчий директор, маркетолог і комерційний директор.
І кожен цілком логічно дивився на систему зі свого боку.
Маркетолог хотів більше промоінструментів.
Комерційний директор — сильніше підпорядкувати сайт продажам.
Виконавчий — вибудувати процеси.
Усі три погляди можуть бути правильними. Але якщо після кожної зміни керівника перебудовувати проєкт, бізнес починає оплачувати не розвиток системи, а зміну управлінських поглядів.
Тому після приходу нового PM ми радимо робити стоп-кадр.
Спочатку потрібно зафіксувати:
- що було погоджено;
- чому саме таке рішення ухвалили;
- що вже реалізовано й оплачено;
- що зараз у роботі;
- які залежності має запропонована зміна.
І тільки після цього обговорювати нове бачення.
Наприклад, бажання «трохи змінити оформлення каталогу» може бути локальним завданням. А може потягнути за собою каталог, картку товару, фільтри, мобільну версію й уже готову логіку оформлення замовлення.
На екрані обидва варіанти починаються зі слів: «А давайте тут переробимо».
У кошторисі — виглядають зовсім по-різному.
Новий PM має повне право ставити під сумнів попередні рішення. Але право переглядати рішення — це ще не причина обнуляти вже виконану роботу.
Спочатку контекст. Потім оцінка наслідків. І тільки потім — зміни.
Коли хороший PM веде проєкт не туди
Є менш очевидна проблема, ніж просто зміна вимог.
Новий PM може бути сильним фахівцем: добре аргументувати свої рішення, швидко відповідати, бути активним і не «випадати» з проєкту. І водночас поступово вести проєкт убік від того, заради чого власник бізнесу взагалі вклав у нього гроші.
Виконавчий директор дивиться на операційні процеси.
Маркетолог — на залучення та контент.
Комерційний директор — на продажі.
Нічого дивного.
Проблема виникає, коли посада людини фактично починає визначати стратегію всієї системи.
Наприклад, маркетолог пропонує більше посадкових сторінок, промоблоків і механік для кампаній. З його точки зору — усе логічно.
А власник очікував, що новий сайт насамперед зменшить навантаження на відділ продажів: клієнти самі отримуватимуть документи, бачитимуть свої ціни, статус замовлення й історію операцій.
І ось через кілька місяців можна отримати дуже пристойний сайт.
Просто не той, за який бізнес планував платити.
Саме тому в довгих проєктах недостатньо зв’язки:
PM замовника ↔ PM виконавця.
Потрібна ще одна контрольна точка — людина з боку бізнесу, яка відповідає не за окремий департамент, а за кінцеву бізнес-мету проєкту. Часто це Owner або проєктний спонсор.
І це не означає, що власник повинен обговорювати кожну кнопку.
Навпаки.
Йому важливо погоджувати інший рівень питань:
- яку проблему бізнесу вирішуємо;
- які процеси точно мають змінитися після запуску;
- які принципові зміни допустимі;
- де закінчуються повноваження PM і починається рішення власника щодо бюджету та пріоритетів.
Особливо важлива така звірка, коли нова пропозиція змінює не деталь інтерфейсу, а логіку проєкту.
Бо додаткова кнопка — це робоче питання PM.
А рішення перетворити корпоративний сайт на B2B-систему або, навпаки, відмовитися від частини запланованої автоматизації — уже бізнес-рішення.
Хороший PM не повинен бути просто «передавачем побажань» власника. Йому потрібна свобода для роботи. Але стратегічний напрям проєкту не має непомітно змінюватися разом із прізвищем людини в Zoom.
Передати доступи — ще не означає передати проєкт
Найгірший сценарій під час зміни PM — надіслати новій людині посилання на ТЗ, відкрити доступи й сказати: «Тут усе є, розберетеся».
Бо в документах зазвичай є що погодили.
А от чому відмовилися від іншого варіанта, де вже пішли на компроміс, хто наполягав на певному рішенні, що власник назвав критичним, — часто залишається в листуванні, дзвінках і голові попереднього PM.
Тому передача проєкту має бути контрольованою.
1. Зафіксуйте поточну точку
Не «сайт готовий на 70%», а конкретно:
- що завершено та вже прийнято;
- що зараз розробляється;
- що ще не починали.
2. Зберіть базові рішення в одному місці
Наприклад, у Jira, Confluence або іншій системі, якою користується команда.
Там мають бути:
- актуальне ТЗ;
- дизайн і прототипи;
- кошторис;
- погоджені зміни;
- протоколи або записи важливих зустрічей.
Особливо важливо зберегти рішення, після яких команда вже виконувала роботу.
3. Передайте не тільки рішення, а й контекст
«Каталог зробили так» — мало.
Краще: «Розглядали три варіанти. Цей обрали через такі обмеження й такі бізнес-вимоги».
Це суттєво знижує ризик вдруге винайти велосипед, який команда вже колись розглядала й відкинула.
4. Нові побажання складіть окремим списком
Не змішуйте їх із помилками та недоробками.
Якщо щось не відповідає затвердженому ТЗ — це одне питання.
Якщо новий PM просто хоче зробити інакше — це зміна обсягу робіт, яку потрібно окремо оцінити за бюджетом, строками та впливом на вже готові частини системи.
Це важливе розмежування. Бо інакше побажання нового керівника дуже швидко перетворюються на «недоробки виконавця», хоча насправді команда реалізувала саме те, що було погоджено раніше.
5. Проведіть спільну зустріч
Ідеальний склад: попередній PM + новий PM + представник виконавця + людина, яка відповідає за бізнес-результат.
Зафіксуйте підсумок письмово.
Зовсім не для бюрократії.
Через два місяці фрази «мені здається, ми домовлялися інакше» коштують значно дорожче за один нормальний протокол.
Чи потрібно після зміни PM зупиняти весь проєкт?
Ні. Зміна PM сама по собі не означає, що команда повинна поставити все на паузу.
Якщо розробники виконують незалежний, давно погоджений блок, на який нове бачення не впливає, — немає сенсу створювати простій.
Зупиняти варто саме те, що потенційно може бути переглянуте.
У цьому й різниця між контрольованою передачею проєкту та панічним рестартом.
Зміни — нормальна частина довгих IT-проєктів. Особливо якщо розробка триває кілька місяців, змінюються ринок, процеси компанії, команда та пріоритети бізнесу.
Завдання не в тому, щоб заборонити новому PM пропонувати свої рішення.
Завдання — зробити так, щоб бізнес у кожній такій точці чітко розумів:
- що саме ми змінюємо;
- чому це потрібно;
- скільки це коштуватиме;
- як зміняться строки;
- і що вже створене доведеться переглянути разом із новим рішенням.
У Molfar ми вважаємо саме такий підхід здоровою моделлю роботи з довгими вебпроєктами.
Не «попередній PM сказав так, отже нічого не чіпаємо».
І не «прийшов новий PM — починаємо все спочатку».
А нормальна керована зміна: з контекстом, оцінкою наслідків і розумінням, за що саме бізнес платить.