Значна частина літератури з управління проєктами зосереджена на плануванні, формуванні графіків, розподілі ресурсів і оцінці термінів. Дані інструменти є необхідними, проте в умовах технологічних проектів вони рідко залишаються незмінними протягом усього циклу роботи.
Проте у реальності тимчасова втрата ключового спеціаліста, поява критичної помилки в продукті або зміна вимог клієнта напередодні релізу змінюють початкові припущення. У таких ситуаціях питання полягає в здатності команди зберегти керованість і приймати обґрунтовані рішення в умовах невизначеності.
Для Марини Гаврилишиної така динаміка є базовим станом роботи з великими інженерними продуктами, адже в такому середовищі формувався її професійний досвід під час роботи з технологічними командами в американських компаніях.
Марина працювала з інженерними та продуктовими командами, розподіленими між різними країнами, часовими поясами та культурними контекстами. У таких умовах відсутність єдиних правил взаємодії швидко призводить до втрати синхронізації між сторонами. Практики, які вона застосовувала, були придатними для масштабування в міжнародних організаціях, де прозорість рішень і чітке узгодження очікувань між сторонами мають критичне значення незалежно від юрисдикції чи країни розробки.
Ілюзія стабільності в інженерних середовищах
Коли Марина приєдналася до Janus Technologies, компанія переживала фазу швидкого розширення: інженерні команди зростали, продукт ускладнювався, а процеси залишалися фрагментованими. Основні проблеми полягали в тому, що чіткої документації вимог не існувало, релізи відбувалися хаотично, а координація між розробниками та тестувальниками була мінімальною. На жаль, у такій ситуації будь-який план втрачає актуальність за кілька днів.
Замість спроб нав'язати жорстку структуру зверху, Марина почала з діагностики того, чому система не працює і виявилося, що проблема у відсутності механізмів комунікації. Розробники не знали, які саме функції критичні для клієнтів, тестувальники отримували завдання в останній момент і не встигали провести повноцінну перевірку, а продуктові менеджери, в свою чергу, не розуміли технічних обмежень і обіцяли клієнтам нереалістичні терміни.
Марина побудувала процеси, які дозволяли виявляти такі розриви на ранніх етапах. Фактично вона створила критерії входу та виходу для кожної фази розробки, встановила чіткі точки комунікації між командами, впровадила механізми контролю якості ще до початку тестування, що не усунуло невизначеність у технічних залежностях і термінах повністю, проте робило її керованою. Таким чином протягом кількох місяців скоротилася кількість блокуючих дефектів, виявлених на фінальних етапах розробки, а також зросла прогнозованість релізів.
Один з колег Марини згадує:
"Вона поєднує системне мислення з надзвичайно швидкою здатністю виконувати завдання і розуміє як технічну архітектуру, так і операційні реалії інженерної доставки".
Саме це дозволяє Марині орієнтуватися в ситуаціях, де немає готових рішень, і коли виникає конфлікт між швидкістю випуску та якістю продукту, вона аналізує, які ризики критичні для клієнтів, які можна прийняти, а які слід усунути негайно. Коли одна з команд затримується, вона перебудовує залежності так, щоб інші підрозділи могли продовжувати роботу без блокувань.
Відновлення керованості в моменті розламу
Найскладніші ситуації виникають, коли руйнуються базові припущення, на яких будувався план. Наприклад, з'являється нова регуляторна вимога, яка вимагає переробити частину архітектури, або клієнт змінює пріоритети, і функція, над якою команда працювала місяць, втрачає актуальність.
Марина описує свій хід роботи наступним чином:
"Коли ситуація стає непередбачуваною, перше, що потрібно зробити — відновити прозорість. Команди мають розуміти, що саме змінилося, чому це важливо і як це вплине на їхню роботу. Без цього люди починають діяти хаотично, кожен робить власні припущення, і координація остаточно руйнується".
На своєму наступному робочому місці протягом першого місяця Марина впровадила структуру, на створення якої зазвичай потрібно кілька кварталів. Це стало можливим саме тому, що вона зосередилася на найкритичніших точках: де найбільше непорозумінь між командами, де найчастіше виникають затримки та де ризики найвищі. Решта елементів додавалися поступово, в міру того, як з'ясовувалися реальні потреби.
Прийняття рішень за браком повної інформації
Одна з найважчих компетенцій проєктного менеджера — вміння діяти, коли даних недостатньо, адже у складних технологічних проєктах ніколи немає повної картини.
Завжди існують питання без відповідей.
Чи спрацює нова архітектура під навантаженням? Чи встигне команда завершити інтеграцію вчасно? Чи виявляться критичні помилки на фінальному етапі тестування?
Марина підходить до таких ситуацій через оцінку наслідків.
"Я питаю себе: якщо ми приймемо це рішення і воно виявиться помилковим, що станеться? Чи зможемо ми відкотитися назад? Чи втратимо довіру клієнтів? Чи заблокуємо роботу інших команд?" — пояснює вона.
Так спеціалістка відрізняє ризики, які можна прийняти, від тих, які необхідно усунути. Наприклад, якщо затримка релізу на тиждень не критична для клієнта, але дозволяє провести повноцінне тестування безпеки, рішення очевидне. Якщо ж продукт вже обіцяний на конкретну дату, а проблема стосується лише візуального інтерфейсу, можна випустити базову версію і додати поліпшення пізніше.
Важливо, що такі рішення Марина приймає не в ізоляції і залучає технічних лідерів, продуктових менеджерів та представників клієнтів. Кожен бачить ситуацію під своїм кутом, і саме на перетині цих перспектив з'являється розуміння, яке рішення найменш ризиковане.
Принципи роботи в нестабільних умовах
За роки роботи в різних компаніях Марина виробила кілька принципів, які допомагають їй орієнтуватися в хаосі.
“По-перше, я ніколи не покладаюсь на припущення, що все піде за планом. Кожен проєкт передбачає буфери на непередбачувані затримки, критичні компоненти мають резервні варіанти, а залежності між командами регулярно переглядаються. По-друге, я завжди будую комунікацію таким чином, щоб проблеми виявлялися якомога раніше. Регулярні синхронізації між підрозділами, чіткі критерії готовності на кожному етапі, відкриті канали для повідомлення про ризики — все це створює середовище, де люди обговорюють всі труднощі відразу. По-третє, я чітко відокремлюю важливе від термінового. Коли виникає криза, легко потрапити в пастку реагування на найгучніші проблеми замість найкритичніших, тому я систематично перевіряю, чи дійсно та чи інша проблема блокує прогрес, чи можна відкласти її вирішення, щоб зосередитися на чомусь важливішому”.
