Менеджмент проєктів заведено описувати товстими книжками, сертифікатами й абревіатурами з трьох-чотирьох літер. Усе це має право на життя, але я помітив дивну річ: багато людей, які прочитали ці книжки, однаково провалюють проєкти, а дехто, не прочитавши жодної, веде їх блискуче. Отже, суть не в термінології. Суть у кількох простих основах, які треба не знати, а відчувати шкірою.
За роки в розробці я бачив сотні проєктів: маленьких і величезних, вдалих і катастрофічних. І якщо звести весь цей досвід до фундаменту, вийде не так уже й багато принципів. Їх я і спробую описати без академічного пилу.
Проєкт і продукт це не одне й те саме
Перше, що варто зрозуміти: проєкт це тимчасове підприємство з початком і кінцем. У нього є мета, обмежені ресурси й дата, коли він має закінчитися. Продукт же може жити роками. Проєкт створює продукт або його частину, а потім закінчується.
Ця різниця здається формальною, але на практиці вона величезна. Коли люди плутають проєкт і продукт, проєкт ніколи не закінчується. Він перетворюється на нескінченне доопрацювання, де щотижня додається щось нове, бюджет тече, а слово «готово» не звучить ніколи. Добрий менеджер завжди знає, що саме вважатиметься закінченням проєкту, і захищає цю межу.
Трикутник, який не можна обдурити
В основі будь-якого проєкту лежать три параметри: обсяг робіт, бюджет і час. Я називаю це трикутником проєкту, і він підкоряється майже фізичним законам. Не можна змінити одну сторону, не зачепивши інших. Хочете більше функцій? Знадобиться більше грошей або більше часу. Хочете швидше? Доведеться урізати обсяг або найняти більше людей, а це знову гроші.
Уявіть канатохідця, у якого жердина тримається на трьох канатах. Натягнете один сильніше, і два інші провиснуть або луснуть. Більшість конфліктів у проєктах виникає саме звідси: клієнт хоче, щоб усі три канати були натягнуті до межі водночас. Більше функцій, менше грошей, швидше. Так не буває, і завдання менеджера не обіцяти неможливе, а чесно показувати, чим доведеться пожертвувати.
Є й четвертий, прихований параметр: якість. Коли трикутник перетягнутий, якість просідає першою й найнепомітніше. Терміни дотримані, бюджет укладено, функції на місці, а за місяць починається потік помилок. Це не економія, це відкладений рахунок.
Фази проєкту
Кожен проєкт проходить через схожі фази, хоч би як їх називали в різних методологіях.
- Ініціація. Навіщо ми це робимо, яку проблему розвʼязуємо, як зрозуміємо, що успіху досягнуто.
- Планування. Що саме робимо, у якому порядку, хто, за які гроші й терміни, які ризики.
- Виконання. Власне робота, найдовша фаза.
- Контроль. Іде паралельно з виконанням: порівнюємо план із фактом, реагуємо на відхилення.
- Завершення. Здача результату, приймання, розбір того, що вийшло, а що ні.
Найбільш недооцінена фаза перша. Люди хочуть швидше почати щось робити, а питання «навіщо» здається очевидним. Але я бачив проєкти, які блискуче виконали все заплановане, а потім зʼясувалося, що це нікому не потрібно. Година, витрачена на питання «навіщо», заощаджує місяці роботи над непотрібним.
Друга за недооціненістю остання. Проєкт здали, усі видихнули й розійшлися. А розбір польотів, де команда чесно каже, що пішло не так, і є тим, що робить наступний проєкт кращим. Без нього компанія роками наступає на ті самі граблі й щоразу дивується.
Ризики: парасолька, яку беруть до дощу
Управління ризиками звучить нудно, але це одна з найпрактичніших речей у менеджменті. Ризик це те, що може піти не так. Не обовʼязково піде, але може. Ключовий постачальник затримає постачання. Програміст захворіє в найвідповідальніший момент. Сторонній сервіс змінить умови. Клієнт змінить вимоги посеред проєкту.
Добрий менеджер складає перелік таких ризиків на початку проєкту й для кожного серйозного продумує, що робитиме, якщо він станеться. Це як брати парасольку, коли небо хмурніє. Можливо, вона не знадобиться. Але якщо піде дощ, Ви будете єдиною сухою людиною на зупинці.
І обовʼязково закладайте резерв часу й бюджету. Не тому, що команда лінива, а тому, що в будь-якому складному проєкті будуть сюрпризи. Проєкт без резерву це проєкт, який точно запізниться, просто Ви ще не знаєте, наскільки.
Комунікація це половина менеджменту
Якщо спитати мене, на що менеджер проєкту витрачає найбільше часу, відповідь буде несподіваною для новачків: на спілкування. З клієнтом, із командою, з підрядниками, з керівництвом. Проєкти рідко провалюються через технічні проблеми. Значно частіше вони провалюються через те, що люди зрозуміли одне одного неправильно й довго цього не помічали.
Тому базові правила комунікації важливіші за будь-яку методологію. Домовленості фіксуються письмово. Усі учасники знають, де шукати актуальну інформацію про проєкт. Погані новини повідомляються одразу, а не тоді, коли їх уже неможливо приховати. Клієнт отримує регулярний зрозумілий статус, а не тишу, яку перериває паніка.
З чого почати
Якщо Ви тільки починаєте керувати проєктами, не намагайтеся одразу опанувати всі методології. Почніть із трьох речей. Запишіть мету проєкту одним реченням і критерій, за яким зрозумієте, що його завершено. Намалюйте трикутник: обсяг, бюджет, терміни, і чесно визначте, який із канатів можна послабити, якщо доведеться. Складіть перелік пʼяти головних ризиків і для кожного вигадайте план Б.
Ми в Ingello Systems починаємо кожен клієнтський проєкт саме з цього, ще до того, як написано перший рядок коду. А далі багато рутини знімає формалізація: коли систему описано схемами у Fractal, обсяг робіт стає видимим і вимірюваним, і трикутник перестає бути предметом суперечок. Але фундамент завжди один: розуміти, навіщо, скільки й до якого терміну. Решта надбудова.
