Зміст

Проектний менеджмент

Стаття

12 січня, 2020

«Тут знову трішки треба все повністю переробити»

Head of IoT у Veon Group (Kyivstar) про найважливіше у розробці проєктів.

Багато хто болісно реагує на зміни. Але проєктний менеджер влаштований інакше: він обожнює розбиратися в незрозумілому і новому.

Його головне завдання — зробити так, аби проєкт дав бізнесу нове рішення. А головна радість — бачити, як це рішення допомагає і компанії, і клієнту.

Павло Харіков має понад 10 років досвіду управління проєктами у Kyivstar та Sense-Bank.

Він вів проєкти з бюджетом $150 млн і спільно з командою збільшив частку успішних проєктів у Kyivstar із 30% до 85%. Зараз у цьому телеком-гіганті він очолює новий бізнес-напрямок інтернету речей та «хмар».

Павло розповів про свої ключові кейси, пояснив, чому софт-скіли важливіші за хард-скіли, описав життєвий цикл проєкту та основні складнощі роботи з командою.

Хто такий проджект-менеджер

Проджект-менеджер (PM) — це, по суті, СЕО-початківець у компанії. Основна його функція — інтегрувати знання та людей. Тому для нього найважливішим є софт-скіли — тобто вміння слухати, спілкуватися, виходити з конфліктів.

Хард-скіли також потрібні, але важливо, як PM ними користується.

Якщо йому не дуже важливо бути «найрозумнішою людиною в кімнаті», тоді все добре. Він зможе виважено оцінювати думки інших. Якщо ж він вважає свою думку виключно важливою, а інших не чує — це біда. Тоді краще хард-скілів не мати.

Проджект-менеджер не зможе зробити проєкт сам. Він організовує команду та забезпечує умови, в яких вона його реалізовує.

Коли PM займається мікроменеджментом, на ньому й відповідальність. Але проконтролювати все неможливо.

Важливіше мати хард-скіли в управлінні проєктами. Досвід тисяч PM-ів зібраний у PMBoK та схожих інструкціях — і там пояснюють, як керувати проєктом, щоб підвищити його шанси на успіх.

Завдання проджект-менеджера — стояти на варті інтересів компанії. Якщо PM розуміє, що проєкт буде збитковим, він повинен першим сказати: «Час його зупинити».

Період адаптації PM з іншої сфери

2018 року я перейшов з телекому до «Альфа-банку» (тепер Sense-Bank) — директором з управління проєктами та процесами. Системи, бази даних, інтерфейси були по суті тими самими, але щоб розібратися в термінології та суті фінансових процесів, знадобилося близько півтора місяця.

Навіть коли PM з іншої сфери, його адаптація не буде тривалою та болісною — якщо він відкритий до нової інформації. Можна почитати про нову специфіку в документах компанії, пройти внутрішні навчальні курси.

Яким проєктам потрібен PM

Є операційна діяльність — чіткий процес, де дії виконують за інструкцією, щоб отримати гарантований результат. І є проєкти — вони створюють зміни, нові продукти та процеси.

Проджект-менеджери повинні пам'ятати, що гроші компанії дає операційна діяльність. Тому потрібно якомога раніше вивести своє нове рішення в «операційку». Тільки тоді воно почне приносити користь.

Проєкт — це завжди для результату, якого раніше не було.

Наприклад, ви будуєте типові 16-поверхівки. Візуально вони однакові. Але кожна багатоповерхівка — проєкт. Їй потрібне нове місце, нова команда будівельників та підрядників, нове підключення до міських комунікацій. Будинок типовий, але саме такий — перший.

Проєктне управління почало формуватися в середині XX століття у космічній та військовій галузях.

Раніше, якщо в операційному процесі не можливо було отримати потрібний результат, кожен керівник впроваджував зміну у себе і передавав її далі. Інші до неї щось додавали — і збирався результат.

Але складність завдань зростає. Вже не можна обійтися без того, хто займатиметься інтеграцією — збиранням результатів у єдине ціле. Будь-якому проєкту потрібен РМ.

Kyivstar з погляду проджект-менеджменту

Приклад проєктних організацій — сучасні IT-компанії. Там є чітко виділені команди, які реалізують проєкти замовника чи розвивають свої продукти.

Kyivstar — не проєктна організація у класичному вигляді.

Ми — відбудована мережа та бізнес, що добре працює, для якого найважливіше — підтримка операційних завдань на належному рівні. У нас багато налагоджених процесів, але проєкти, звісно, також є — без них не вдасться розвиватись.

За керування проєктами відповідає проєктний офіс. Очолювати його цікаво, але завжди чухаються руки зробити великий проєкт і отримати від нього результати.

По суті, мій проєкт зараз — створення нового бізнес-підрозділу інтернету речей та «хмар». Коли він ефективно запрацює і перейде в операційну систему, можливо, шукатиму щось нове.

Кейси, якими пишаєтесь

У 2016 році я очолив проєктний офіс у Kyivstar. Без стандартизації процесу проєктного управління лише третина проєктів була успішними. Моїм завданням було вибудувати процес, щоб нові рішення впроваджувалися швидше та ефективніше.

Ми змогли зробити так, щоб 85% проєктів завершувалися успішно: на ранніх стадіях відсікали все безперспективне та не витрачали ресурси.

Моя найбільша гордість — 4G в Україні. Цим проєктом я займався 2,5 року. Вирішувалося, як буде перерозподілено частоти, як брати участь у тендері на них, де і в яких обсягах будувати нову мережу.

Kyivstar, на мою думку, вийшов на цей тендер найбільш підготовленим. Ми пропрацювали та прорахували тисячі сценаріїв.

Витратили на ліцензії великі бюджети — але менше, ніж могли б. І постаралися, щоби для конкурента обійшлося не дешевше. Це було важливо, тому що можливості для інвестицій не безмежні: чим дорожчою обійдеться ліцензія, тим менше вкладеш у мережу.

Тендер був дуже серйозним. За папірці формату А4 з написом «Ліцензія» оператори загалом заплатили близько 9 млрд гривень. Потім були значні інвестиції в мережу.

На старті ми думали: «Чи буде у нас пів мільйона клієнтів за рік»? Зараз, через 1,5 року після старту, 4G Kyivstar користується понад 7 млн осіб.

Ще для мене цінний інший проєкт, який був майже провальним — сповіщення для користувачів домашнього інтернету Kyivstar.

Якщо з мобільними абонентами легше комунікувати — їм можна надіслати СМС або зателефонувати, то до абонентів домашнього інтернету достукатися складно. У кабель нічого не надішлеш. Було завдання придумати канал комунікації.

Ми знайшли технологічне рішення: показувати клієнтові повідомлення (наприклад, нагадати поповнити рахунок або поінформувати про планові роботи), коли той працював у браузері.

Підрядник запевнив, що все працюватиме. Але ми не зафіксували схему, за якою б рішення інтегрувалося в нашу мережу.

Провели тендер, купили рішення за кількасот тисяч доларів. Але підключити його так, як ми планували, було неможливо. Спосіб впровадити цю технологію ми знайшли. Але навіть після доопрацювання сервіс функціонував з обмеженнями.

Проте канал взаємодії з клієнтом з'явився, пропрацював близько п'яти років і окупився. Цей досвід для мене став цінним — навчив фіксувати всі домовленості на папері.

Загалом помилки — це непогано. Я більше довіряв би тому, хто запоров хоча б один проєкт, ніж тому, хто ще ні. Найімовірніше, ця друга людина буде помилятися та навчатися на вашому проєкті.

Життєвий цикл проєкту

Щоби зрозуміти, яким буде життєвий цикл проєкту, слід вирішити, як плануємо його реалізовувати.

Наприклад, у будівництві не вдасться зробити проєкт ітераційно — за agile. Там мінімально життєздатний продукт — будинок із усіма комунікаціями, не менше.

Така сама ситуація з телекомунікаційними сервісами: має працювати все, інакше це нікому не потрібне.

У цих і подібних сферах потрібен інший підхід, каскадний. Його етапи:

Ініціація. Фіксуємо головну мету проєкту, та з неї вже беремо верхньорівневі цілі (охоплення, бюджет і терміни).
Планування. Детально опрацьовуємо охоплення проєкту, під нього плануємо бюджет та ресурси, вибудовуємо графік робіт та визначаємо терміни.

На цьому етапі потрібно переглянути бізнес-кейс і прийти до спонсора з рішенням: «Ми згодні на ці витрати заради цього результату».

Реалізація. Вона може йти ітераційно чи каскадно. Дії можуть бути паралельними чи послідовними, взаємозалежними чи ні.

PM контролює прогрес, ризики, зміни в охопленні проєкту. Вирішує, чи вносити зміни до проєкту.

Оцінює, скільки ресурсів потрібно для реалізації нової «фічі» і скільки вона принесе у результаті. Ще PM важливо вчасно доносити реальну картину світу до людей, які ухвалюють рішення.

До етапу реалізації належать і тестування — технічні та користувацькі.
Закриття. Після запуску рішення в операційну діяльність слід закрити проєкт: зберегти всі його артефакти. Їх, найімовірніше, можна буде використовувати для схожих проєктів у майбутньому.

Важливо зафіксувати, що було добре у цьому проєкті, похвалити команду та усвідомити помилки (це найцінніше). Ще потрібно перевірити, чи все закрито за контрактами, чи з усіма постачальниками розрахувалися.

Як впроваджувати інновації у поточний процес

Найпростіше зробити щось нове, чого не було ніколи. Але якщо процес вже живе та обслуговує клієнтів — складність змін висока.

Потрібно продумувати все, що пов'язане з безперервністю сервісу. Будь-яка зміна при його впровадженні не повинна вдарити по користувачах.

Складність також у тому, що всі процеси і продукти мають стейкхолдерів, які не хочуть, щоб ви чіпали те, що працює. Тому треба пояснювати їм, які вигоди від змін.

PM повинен знати, хто його стейкхолдери, які у них їхні інтереси. Інформувати їх про статус, результати, проблеми. Якщо просто принести інновацію, їхня відповідь буде: «У нас обід, приходь завтра».

Поширені ризики

Основні ризики — не витримати термінів, не вкластися до бюджету. Потім уже брак ресурсів на реалізацію. Наприклад, не зможемо набрати потрібних фахівців на проєкт (вони виявляться дорожчими, ніж потрібно). Або люди підуть у процесі роботи. Або їх перекуплять.

Найважливіше визначити всі ризики і знати, як на них реагувати.

Зрозуміти, що частина команди може піти, наприклад, через невисоку зарплату і бути готовим шукати нових (знаючи, що це вплине на терміни). Або мотивувати їх нематеріально — хвалити, піднімати професійний рівень.

На проєкті 4G були великі ризики для бізнесу. Деякі реалізувалися. Наприклад, регулятор розставив лоти на аукціоні максимально незручно для нашої компанії. Але ми прорахували цей сценарій і були готові до нього.

Якщо проєкт ведеться правильно (охоплення, стейкхолдери та їхні очікування відомі), всі ризики можна виявити.

Їх вписують у реєстр ризиків з оцінкою ймовірності та вартості у разі настання. Там же вказують власника ризику — того, хто підключиться та почне діяти за планом, коли ризик проявиться.

Найскладніше у роботі з командою

Найскладніше — формування команди. Люди різні, у всіх свої погляди на хардові речі. Тут важливо поважати та модерувати всіх членів команди.

PM має бути довіреною особою, з якою можна поділитись побоюваннями. Вже на старті якийсь скромний працівник може розуміти, що все не спрацює. Але не скаже — це ж не його завдання. Важливо, щоб йому було комфортно висловити свої думки.

Ще важливо резервувати експертизу. У 2015 році ми планували партнерство з одним із найбільших брендів-виробників мобільних телефонів. Це була нова та складна бізнес-модель взаємодії.

У нас працювала дівчина з експертизою в девайсному бізнесі та контактом із партнером. Але вона пішла. Мені довелося розбиратися у тонкощах самому, тому реалізація затягнулася.

PM може бути додатковим резервом для багатьох ролей у команді. Це неправильно з погляду проєктного управління, але на практиці рятує та додає «плюсиків до карми» — з деяких питань я можу врятувати, якщо виникають навантаження.

Ваш стиль роботи у команді

Не люблю мікроменеджмент. Люди повинні мати можливість думати самостійно. Якщо ви будете вказувати, що робити — вони будуть робити тільки те, що ви говорите.

Контролювати треба. PM може заглиблюватись у кожне завдання, але його мають цікавити лише ці запитання:

чи все виконується вчасно
чи є проблеми
як можна допомогти

Команда повинна сама вирішувати, що, як і коли робити задля досягнення результату.

БЛІЦ

Фільм «Людина, яка змінила все» — про те, як правильно працювати з командою.
Книжка «Витончене мистецтво забивати на все. Нестандартний підхід до проблем» — про те, як розставляти пріоритети. Одна з небагатьох бізнес-книг, яку я прочитав на одному подиху.

Три основні страхи PM-а

#1. Не розуміти, чого від тебе хочуть. Тобі кажуть: «Займайся проєктом з розробки бузкових металоконструкцій із оптоволокна». Чому бузкових? Чому металоконструкцій? Кому це потрібно, до кого бігти?

#2. Порушити дедлайн.

#3. Не бути готовим прозвітувати перед спонсором.