Проєкт ніколи не йде за планом. Ви можете продумати все до дрібниць, але прийде замовник, скаже «міняти концепцію» — і все полетить коту під хвіст.
Що ж робити, щоби реалізувати проєкт вчасно, в рамках бюджету і залишитися психічно здоровою людиною, — розповідає Марина Мельник, ex-Program Director у Luxoft.
Марина має понад 13 років досвіду в управлінні проєктами та програмами. Вона багато консультує у сфері проєктного управління, зокрема ПриватБанк, VARUS, АНЦ.
Разом ми підготували гайд, який допоможе здати проєкт, не зриваючи дедлайну.
#1. Сформулюйте чіткий product vision
Для цього на старті визначте, чого ви хочете, з якою метою, чому саме в такі терміни та скільки готові витратити на проєкт.
Я згодна з бізнес-спікером Саймоном Сінеком, який каже: «Start with why». Почніть із визначення, для чого потрібен проєкт, а потім беріться за втілення. Сформулюйте, яку цінність він принесе користувачеві, бізнесу та замовнику. Це те, що дає мотивацію команді.
Постійно синхронізуйте бачення проєкту в процесі його реалізації: що ми продовжуємо робити і які завдання для нас досі актуальні. Умовно, можна домовитися на березі, що ми прямуємо до конкретного острова, але потім погода зміниться і ми зрозуміємо, що краще пливти до іншого або взагалі стати на якір.
Це важливий момент — постійно відчувати бачення проєкту: що ми робимо і для чого.
Наприклад, замовник хоче систему керування клієнтською базою. На запитання «Для чого?», він відповідає: «Плануємо розширювати бізнес та очікуємо отримати більше клієнтів». Коли йдеться про те, що дасть нова система і яку цінність вона принесе, клієнт каже: «Ми розуміємо, що всі на ринку так роблять» або «Ми дізналися, що наш конкурент так веде бізнес». Це очевидний сигнал, що щось не так.
Порівнювати себе із суперниками та аналогічними організаціями — неправильна мотивація. Правильна — в тому, що компанії некомфортно. Наприклад, вона витрачає багато часу на роботу з поточною базою або на зведення клієнтів в Excel, тому важливо автоматизувати процеси, щоб ефективно вибудувати роботу. Тобто нова система потрібна для підвищення продуктивності.
#2. Визначтеся з конкретною датою
Тут можна виділити два типи проєктів:
- Scope-driving — проєкт, який залежить від функціоналу. Якщо його немає, випускати проєкт немає сенсу. Тут є обсяг роботи, який обов'язково має бути виконаний перед релізом.
- Date-driving — проєкт із критичною датою виходу та, можливо, урізаним скоупом. Ймовірно, ми зробимо не всі завдання до конкретного терміну, але якусь частину роботи виконаємо точно, і це дозволить нам вистрілити на ринку.
Умовно, якщо у нас проєкт, у якому діти пишуть листа Святому Миколаю, він не має сенсу після 6 грудня. Тут критична дата і ми орієнтуємося на неї. Можливо, ми цього листа надсилатимемо не з усіма чудовими фішками, які спочатку запланували, але точно відправимо до дедлайну. А якщо наш проєкт стосується лазера для корекції зору, то без функціонала, що ідеально працює, ніяких термінів немає.
Тому потрібно визначитися, що важливіше: дата чи функціонал. Я часто стикаюся з клієнтами, які наполягають, що найголовніше — дата. А коли ми максимально підганяємо завдання під дедлайн, замовник каже, що поки не будемо релізитися — хотіли б ще додати новий функціонал.
Коли клієнту важлива дата і вона справді «горить», він каже: «Зробіть продукт хоч би з елементарним функціоналом». І може сформулювати бачення мінімально життєздатного продукту.
Грамотна робота аналітика та проджект-менеджера тут — поставити клієнту правильні запитання. Якщо ми зрозуміємо одне одного на самому початку, тоді буде успіх.
#3. Контролюйте якість на старті
Якщо ми говоритимемо «нічого, поки так зробимо, а потім полагодимо», потім можемо зіткнутися з ефектом «тріснутого скла». Дозволимо одну поблажку в якості — і як снігова куля почнемо їх допускати далі. А потім це вдарить по нас технічним боргом і не дозволить зарелізити проєкт вчасно. Ми не маємо права вийти на ринок із поганим продуктом — це як стріляти собі в ногу. Так можна розгубити клієнтів та обрости проблемами.
Іноді замовник починає «тиснути», щоб випустити не повністю готовий продукт. І тут важливо вміти керувати ним: якщо ви не робитимете цього, клієнт через незнання і недосвідченість почне сам собі шкодити. Тому відстежувати якість на старті вкрай важливо — потрібно вибудувати контроль та постійно його вести.
#4. Навчіться керувати змінами
Клієнтське «побачив щось нове, давайте змінювати концепцію» точно позначиться на датах. Щоб зробити все вчасно, потрібно спочатку проговорити: якщо візьмемо зміну в роботу, хоч би якою правильною вона не була, це вплине на терміни.
Можна сказати, що ми приймаємо коригування в скоуп, але оскільки ми маємо дедлайн, спочатку випускаємо проєкт без нового функціоналу в потрібну дату, а далі вже доопрацюємо його. Якщо ж нововведення кардинально перебудує проєкт і ми не можемо його відкласти, говоримо, що інші завдання посунемо на більш пізні терміни.
Коли ми йдемо на поводу у клієнта і беремо всі корективи до роботи — 100% не встигнемо до дедлайну. Тому кожну зміну від замовника оцініть із двох позицій:
- чи можна ним зайнятися вже після випуску першої версії продукту
- якщо важливо реалізувати його зараз:
1) який обсяг роботи потрібно на нього витратити;
2) які аналогічні таски з таким самим обсягом роботи ми можемо прибрати з поточного списку завдань.
Крім того, можна сказати клієнту, що ми впишемося з нововведеннями у дату, але тоді постраждає бюджет. Трикутник проєктного менеджменту ніхто не скасовував: у нас є обсяг роботи, бюджет та час. Коли ми починаємо одну із цих сторін тягнути — розтягуються й інші.
Усі ці моменти потрібно проговорювати, а рішення вже буде за клієнтом. Наприклад, якщо замовник готовий продовжити дедлайн та збільшити бюджет, тоді беремо в роботу всі зміни. Якщо ні, що трапляється найчастіше, робимо, як спочатку домовилися, а потім дивимося, що додавати до продукту.
#5. Не забувайте про управління ризиками
Це постійний контроль себе як проєктного менеджера: сідаємо та думаємо, що може піти не так. Досвідчений проджект завжди пам'ятає джерела ризику. Він повинен розуміти, звідки може прийти проблема, щоб вона не стала для нього несподіванкою.
Так ми можемо скласти ризик-матрицю: неприємність може статися з такої причини → якщо це станеться, нам доведеться витратити Х часу на усунення проблеми → що я можу зробити зараз, щоб подібна неприємність не сталася.
Тому проджект-менеджеру потрібно продумати кілька стратегій:
- превентивну — як не допустити проблеми
- стратегію пом'якшення ризику — як зробити так, щоб він мав мінімальний вплив на проєкт
- план Б — якщо ризик реалізується, як я діятиму
Бонус: як розставляти завдання за пріоритетами
Є класична матриця пріоритетів Ейзенхауера, яку я застосовую як у роботі, так і в особистому житті. Вона поділяє всі завдання на 4 групи:
- важливе та термінове
- важливе, але не термінове
- не важливе, але термінове
- не важливе та не термінове
Термінові та важливі завдання — ті, які потрібно виконати негайно. Якщо у вас таких більше 20%, то це вже проблема — отже, колись ви не зробили їх вчасно.
Не термінові, але важливі завдання — ті, які рано чи пізно все одно потрібно буде виконати. Інакше вони перемістяться до першого квадрата — тоді доведеться займатися ними в режимі авралу та із зіпсованим настроєм. Це може бути підготовка до нових проєктів, налагодження відносин, вивчення іноземних мов.
Термінові, але не важливі завдання — ті, які (на чиюсь думку) ви повинні виконати негайно, проте вони не приносять користі особисто вам. Погоджуватися на них — означає саботувати свої інтереси, але бути добрим для всіх.
Не термінові і не важливі завдання — ті, які не приносять значущого результату, але можуть бути цікавими. Наприклад, дивитися серіали або грати в ігри.
Кожне нове завдання я одразу ж вношу до календаря. І коли приходить час виконувати, ще раз аналізую: якщо я просто зараз його не зроблю, щось грандіозне станеться і хтось постраждає? Чи можу я зайнятися чимось іншим? Якщо можу, вношу новий таск у календар, а відкладений — відсуваю.
Внутрішня пріоритизація завдань напрацьовується шляхом спроб і помилок. І важливо, щоб робочі таски не виходили за межі робочого часу. Work-life balance ніхто не скасовував: якщо проджект-менеджер енергетично не наповнений, успіху у проєкту не буде.
Бажаєте отримувати дайджест статей?
