Олена Загоренко: про кар’єру в Австралії, Agile, сексизм та толерантність до ризиків

10 років тому Олена прийшла до нас на тренінг, через рік стала нашою колегою. А 7 років тому вона переїхала із України до Австралії і побудувала там успішну кар’єру з нуля.

В свої 34 роки Олена Загоренко керує департаментом управління портфелем проектів в BHP Minerals Australia,провідної гірничовидобувної компанії в світі. Вона допомагаю керувати портфелем проектів розміром 5,3 млдрд.$ на рік.

Ми давно хотіли зустрітися з Оленою і планували інтерв’ю про управління проектами. А вийшла дуже особиста бесіда про Австралію, культурні відмінності, про Agile, про те, як в BHP керують портфелем проектів і багато іншого. Раді поділитися з вами результатом.

Коротко про що ми говорили:

  • 00:18 Хто такий Project Manager?
  • 00:40 Шлях в професію: чарівний тренінг від Project Management Bureau та/або інтуїція
  • 1:22 Чому Австралія, а не Україна
  • 2:57 Як навчалась керувати проектами
  • 4:20 Soft Skills важливіше, ніж інструменти і методології
  • 5:22 Сексизм. Про пошук першої роботи РМ в Австралії
  • 7:34 Культурний бар’єр. “Вона з української мафії”. Ідеальний лідер по-австралійські
  • 9:57 Як в період реструктуризації отримати підвищення і отримати конкурентну перевагу
  • 10:52 Чи потрібно доводити, що ти крутий?
  • 12:50 Про найскладніший проект
  • 18:00 Роль РМ в Україні більша, ніж в Австралії. Чи так це добре?
  • 18:54 “Переможців не судять” – в Австралії так не працює
  • 20:38 Робота в пустелі або як ризикнути і перейти на новий рівень управління портфелем проектів
  • 24:52 Якісний портфель проектів, як команда Олени оцінює проекти
  • 29:23 Чому “вбивали” проекти?
  • 34:06 РМ повинен на 80% керувати зовнішнім контекстом і на 20% самим проектом
  • 36:32 Які ризики частіше за все спрацьовують
  • 39:50 Інтереси проекту vs інтереси замовника
  • 42:02 Чому agile – це лайливе слово
  • 44:45 Досвід використання Agile в BHP
  • 44:15 Що робити, коли в PM немає формальної влади
  • 48:09 Про командну відповідальність
  • 49:28 Несвідомі перекомання. Жінки-PM вбивають менше людей, але не підтримують інших жінок-PM
  • 56:10 Менше робіть? Головна порада
  ,
Поділитися з друзями

Радимо прочитати

Інтерв’ю з Оленою Загоренко, текстова версія
Інтерв’ю з Оленою Загоренко, текстова версія
Наш співрозмовник сьогодні - Олена Загоренко. Олена очолює департамент Portfolio Management в компанії BHP Minerals Australia. Вона допомагає формувати портфель розміром понад 5 мільярдів доларів. В Україні можливість реалізовувати проєкти, з використанням будь-яких прийнятних інструментів, часто обмежена вимогами замовника.   Поговоримо про професію керівник проектів. Якщо в 2-3 словах описати що це таке, що б ти сказала? Це людина, яка вміє представляти прогнозований результат у непрогнозованих умовах. При тому видає результат, який подобається замовнику, незалежно від того, чи зумів замовник якісно сформулювати свої вимоги на початку проекту чи ні. Загалом, людина, яка вміє танцювати на ходулях. Чому ти обрала професію керівник проектів? Це було, напевно, не зовсім усвідомлене рішення. Я випадково дізналася про тренінг, який відвідала одна з моїх тодішніх колег. Вона його дуже хвалила. Я вирішила сходити, тому що я дуже люблю вчитися новому. І я потрапила на тренінг Дмитра Лук'янова, в компанію РМВ і зрозуміла, що це те, чим я хочу займатися. Я вже говорила, що дуже сильно покладаюся на свою інтуїцію, і це був один з тих випадків, коли я зрозуміла, що це те, що мені потрібно. Так воно і вийшло. Цікаво! Давай продовжимо, можливо, тему інтуїції. Як ти прийняла рішення їхати до Австралії? Чому ти обрала саме цю країну? Це було пов'язано, по суті, з вибором професії. Я була залучена в декілька великих проектів, включаючи будівництво Radisson в Буковелі. Участь в цих проектах наштовхнула мене на думку, що в Україні можливість реалізовувати проекти, використовуючи будь-які адекватні інструменти дуже часто обмежена вимогами замовника. Ці вимоги пов'язані з небажанням витрачати більше коштів, небажанням дотримуватися розумних термінів, при яких дати нормальну якість результату проекту в кінці досить складно. Тобто ти хотіла продовжувати розвиватися як РМ, але розуміла, що в Україні це зробити важко? Абсолютно вірно. І з тих країн, в яких я могла розвиватися як РМ для мене було три опції: Канада, Австралія і США. У мене досить вільна англійська мова (закінчила інститут іноземних мов) і тому мені потрібна була країна, де говорять англійською, в якій можна дотримуватися правил, і при цьому отримувати результати. І країна, в яку я могла виїхати зі своїм чоловіком, тому що на той час я вже була одружена. Тобто, при дуже логічному розгляді всіх можливих варіантів, Австралія виявилася єдиною країною, яка могла мені це запропонувати. Soft skills важливіше, ніж будь-які інструменти та методології. Якщо ти розумієш людей, то зможеш зробити успішний проєкт.   Як ти вчилася управлінню проектами, що допомагало тобі? У мене немає системної освіти в управлінні проектами. Коли я починала, в цій сфері в Україні не було структурованої пропозиції з навчання. І як ти діяла? Після того першого чарівного тренінгу я прийшла додому і сказала своєму чоловікові: «Давай мені всі гроші, які в тебе є, хочу пройти всі тренінги на цю тему». І я це зробила. Здається, пройшла 10 тренінгів з PMB, і це дуже забавно зараз озирнутися назад. Напевно, я змогла засвоїти відсотків 30 матеріалу. Всі інструменти надавалися, але, я думаю, грамотний підхід до управління проектами в сенсі освіти – це зіставлення практики і навчання одночасно. Тобто, добре пройти перші 2, 3, 4 базових тренінгів і після цього робити паузи, спробувати керувати проектами і потім повторити ті ж тренінги або інші, більш складного рівня. І знову ж таки Plan-Do-Check-Act cycle ніхто не відміняв. Давай поговоримо про стилі. Завжди, коли ми говоримо про управління, є ті чи інші стилі. Який твій стиль в управлінні проектами? Це складне питання. Вже говорила, я точно не грунтуюся абсолютно на логіці, ні в якому поганому сенсі безумовно. Я керувала 5 років проектами в сфері високовольтної електрики, тому покладатися на інтуїцію в таких питаннях було б дуже самовпевнено. Можливо, хтось би міг померти (посміхається). Тому я все-таки вірю у важливість soft skills. Soft skills важливіші, ніж будь-які інструменти і методології. Якщо ти розумієш людей, то зможеш зробити успішний проект. Знову ж таки, добре було б мати обидві сторони: ти повинен знати інструменти, але як їх застосовувати і в які моменти їх грамотно застосовувати - саме це визначається твоїми soft skills, які повинні бути у тебе як у керівника проектів. Найбільша проблема, з якою я зіштовхнулась – сексизм. Після інтерв'ю мені прямо відповідали: «Якби ви були старші і не жінка, ми могли б запропонувати вам цю роботу».   Поговоримо про твій життєвий шлях в Австралії. Ти приїхала, країна нова, ти починаєш кар'єру PM з нуля. Як ти пройшла за 7 років ось цей великій шлях, який інший і за 20 років не пройде? Не простий шлях, насправді. Мені було легше, ніж багатьом іншим, тому що у мене не було мовного бар'єру. Мій чоловік взагалі не говорив по-англійськи, тобто для нього це було зовсім інакше. Найбільша проблема, з якою я зіткнулася - це сексизм. В Україні я навіть не могла собі уявити, того, що жінка PM до сих пір може викликати підняті брови у чоловіків з великим досвідом управління проектами. Я чомусь думала, що Австралія дуже просунута країна в цьому питанні. Після інтерв'ю мені в обличчя казали, що «якби ви були старші… і не жінка…, то ми могли б вам запропонувати ось цю роботу. Ви ж не поїдете там в пустелю…, ви ж не будете керувати чоловіками?». І на мої заяви «Так, я буду!» і «Так, я це робила раніше!» вони просто закатували очі. З рештою, в мене зайняло шість місяців знайти постійну роботу за фахом. Зазвичай перша робота в Австралії завжди набагато нижче за рівнем, ніж та, яка у вас була раніше в рідній країні. Так було і у мене. Моя перша робота не передбачала самостійного управління проектами, я займалася адмініструванням контрактів). І це мені насправді дуже допомогло, тому що одна річ, яку я недооцінила – це наявність величезного культурного бар'єру. Ми і австралійці – люди з абсолютно різних планет. Наш український підхід в Project Management (Управлінні проектами), в житті, у відносинах з друзями, з роботодавцями, з підрядниками зовсім інший. Я розповім досить особисту історію. У перший рік моєї роботи в Австралі, в мене було два неприємних HR-інциденти. На мене подали скаргу, це називається complaint (9.34). І звичайно в Австралії це закінчується тим, що ти втрачаєш роботу. Перший complaint був пов'язаний з тим, що я втомилася слухати ниття одного з колег і зробила різке зауваження про те, що я не очікувала від чоловіка почути таку кількість ниття. На мене відразу написали скаргу. Для мене це було великим шоком, коли чоловік на 20 років за мене старший написав скаргу. Другий випадок. У мене була асистентка, яка цілеспрямовано намагалася витіснити мене з робочого місця. Вона робила маленькі маніпуляції з бюджетом проекту, щоб він не сходився. Я її зловила один раз, другий. На третій раз я їй сказала: «Люба, от якщо ти ще раз так зробиш - уб'ю тебе». Але це було сказано абсолютно ... я не вбиваю людей зазвичай. Навіть в Україні ми не вбиваємо людей. (сміється) Тобто це був жарт? Це був жарт, який був дуже невдало сприйнятий. Вона взяла так званий stress leave, не виходила на роботу 3 тижні, і після цього подала заяву, що я з української мафії і вона більше не працюватиме, і їй повинні заплатити компенсацію. Через це я мало не втратила роботу. Мене врятували дві речі: по-перше - у мого роботодавця виявилося почуття гумору. По-друге, я не працювала на такій серйозній посаді, як зараз. На моїй теперішній посаді будь-яке необережне слово, будь то на адресу підрядників, підлеглих, будь-яке необережне слово в їдальні може виявитися причиною втрати роботи. Вимоги до лідера в Австралії і до лідера в Україні - абсолютно різні. І це стосується «лідерської поведінки», як називають це австралійці, яку від тебе очікують побачити. Тобто, ти не стільки даєш результати, як ти повинен надихати, ти повинен бути ідеальним лідером, який може за собою всіх повести, при цьому завжди посміхаючись, не показуючи ознак втоми. Це завжди було для мене складно. Опиши, що було після contract administrator. Так, через рік в компанії була реструктуризація. Я дуже багато працювала і дуже сильно старалася, і мене підвищили до PМ. За наступні 4 роки я зробила більше 83-х проектів. Це була абсолютно нова для мене сфера – високовольтна електрика. Компанія, в якій я працювала, була оператором всієї мережі ліній електропередачі високовольтної напруги (ЛЕП) Південної Австралії. Тобто, це 20 проектів на рік? Так. Я була єдиною жінкою керівником проектів в компанії. Всі мої колеги-чоловіки «бігали» за проектами хоча б по 30 млн., яких було набагато менше, ніж дрібних проектів, які ніхто не хотів робити. Користуючись цією нагодою, я почала робити всі дрібні проекти сама з великою швидкістю. І в кінці кінців, я зібрала їх всіх в один портфель. Я керувала OPEX refurbishment project (проекти з «косметичного ремонту», витрати по них відносятся до операційних витрат – прим. ред.), який робила моя компанія. Я сама для себе створила конкурентну перевагу, в якійсь мірі стала незамінною. Це мені допомогло дуже сильно підняти свій personal profile, як це називається в Австралії, Чим більше ти робиш чогось унікального, тим більший твій personal profile. Це усвідомлена стратегія або ж так склалися обставини і тобі хотілося працювати більше, довести щось? Нікому не рекомендую цей варіант, хоча для мене він спрацював добре. Я дуже багато працювала на те, щоб довести, що я можу і це було пов'язано більшою мірою з тим, що я іноземка і жінка. І мені про це нагадували регулярно. Жарти, якісь невеличкі коментарі, все дуже політично коректно, але досить образливо. Я поклала досить велику кількість часу на те, щоб довести щось світу і собі. Мене це в результаті призвело в гарне місце, але всім своїм підлеглим зараз я завжди говорю: «не треба нічого доводити: ні собі, ні мені, ні компанії. Ми всі тут робимо свою справу. Приходьте, робіть your personal best кожен день, і цього достаньо». Я не вважаю, що доводити що-небудь кому-небудь – це продуктивний шлях. Коли я взялася робити цей проєкт, виявилось, що на схожому проєкті раніше вже був нещасний випадок, в якому загинула людина.   Розкажи про найскладніший проект і який урок ти для себе взяла? Це, напевно, дуже, в якійсь мірі, болісно для мене. Я робила багато проектів, пов'язаних з мережею ЛЄП. Для того, щоб зробити їм технічне обслуговування, потрібно відключити половину штату. Безумовно, ніхто не хоче сидіти без світла. Тому ми використовували дуже складний метод: ми робили це з гелікоптерних платформ. Суть цього методу полягає в тому, що електрика не вимикається. Гелікоптер підлітає до лініі електропередачі, завісає в повітрі. Тобто він знаходиться абсолютно статично на рівні лініі електропередачі. А оператор, який сидить на платформі, знаходиться під гелікоптером і одягнений в спеціальний костюм, що стає однакової напруги з ЛЄП та за допомогою гачка може робити роботи на «живих» проводах. Я вже починаю турбуватися, що ж сталося далі? Коли я взяла цей проект, до цього вже був інцидент, в якому людина загинула на схожому проекті. Саме для того, щоб просто почати проект, мені довелося зібрати фахівців з усього світу, аби підтвердити, що той спосіб роботи, який ми будемо використовувати, абсолютно безпечний і ми нікого не вб'ємо. І причина для цього в законодавстві. Ми повинні були показати, що ми зробили все всебічну єкспертизу. Я не знаю, чи існує таке законодавство в Україні, але керівник проекту в Австралії є юридично зобов'язаною особою. Тобто, якщо я вб'ю людину на своєму проекті, особливо в такій небезпечній індустрії, то я потраплю під розслідування. Ціна питання – шість років у в'язниці, як Project Manager, і до 600 тисяч доларів штрафу. Загалом, то був досить ризикований проект. Я пам'ятаю, як прийшла додому така щаслива і чоловік сказав: «Ти абсолютно ненормальна» (сміється). Чому це сумна для мене тема? Коли ми вже виконали роботи майже в усьому штаті, мої колеги позичили в мене гелікоптер на вихідні – їм потрібно було зробити обслуговування на іншому об’єкті. Технічно це було не на моєму проекті, але включено в мій контракт. І на тих вихідних стався інцидент – гелікоптер впав. Було 4 людини в самому гелікоптері, вони всі постраждали. Був дуже серйозний юридичний розгляд обставин, мене він також стосувався. І я була визнана абсолютно не винною, в хорошому сенсі. Тобто, я дотрималася всіх правил, це була людська помилка – помилка пілота, але тим не менш, чесно кажучи – це дуже боляче. Могла ти щось зробити по-іншому? Ні. В цьому як раз і був зміст розгляду – я не могла нічого зробити по-іншому. Зараз я працюю в в гірничодобувній промисловості. Вони схожі тим, що людина може постраждати дуже легко. Напевно, це одна з тих причин, чому більше не хочу займатися безпосереньо управліннем проектами і віддаю перевагу управлінню портфелем. Вважається, що хороший Project Manager, хороший лідер відчуває постійне занепокоєння. Ти не можеш комусь там вручити документ з переліком робот і підрядник працює. Ти не можеш спокійно спати, тому що ти все-одно відповідальний, ти несеш особисту людську відповідальність. І тому зараз, коли я керую коштами більше, ніж керую самими проектами, чесно кажучи, спиться трохи спокійніше. Принцип «помри, але зроби» в Австралії непопулярний. Це признак короткострокового мислення.   Про портфелі проектів ми ще поговоримо. Давай порівняємо управління проектами в Україні та управління проектами в Австралії. У тебе був досвід і там, і там: чим відрізняється сприйняття управління проектами в Україні і в Австралії? Чим відрізняються критерії успіху в управлінні проектами? Мені, звичайно, страшно робити такі широкі заяви про Україну, тому що я вже не живу в Україні більше 7,5 років. Напевно, я трохи відстала від життя, і в Україні все змінилося. Але, на мій погляд, є дві великі відмінності. Перше: в Україні роль керівника проектів в успіху проекту набагато більше, ніж в Австралії. В Австралії опис бізнес-процесів це пройдений етап. Дуже складно знайти компанію, в якій бізнес-процеси не описані. Дуже складно знайти компанію, в якій немає методології управління проектами. Тобто, ти приходиш в компанію і в тебе вже все організовано? В тебе вже все є – працюй. В цьому і полягає складність для тебе, як керівника. У тебе, грубо кажучи, є методологія – тобі треба тільки слідувати крок за кроком. Зазвичай керівники проектів досить амбітні, вони хочуть всіх вразити чарівними стрибками. Це складно, тому що у тебе є фрейморк, в якому ти повинен існувати. Виклик в тому, що ти повинен вразити чимось, але чітко виконувати всі бізнес-процеси. Що ти можеш зробити, не порушуючи правил, і зробити це добре. І друге: закон «переможців не судять» в Австралії не працює. Тому важливо не те, що ти зробив, а важливо, що зробив плюс як ти це зробив. Добиватися результатів, заганяючи своїх співробітників, змушуючи їх працювати ночами – це погано, це засуджується. Погані стосунки з підрядниками, від яких ти «віджав» гарну ціну – це погано. В Австралії все направлено на стійкість в довгостроковій перспективі. Всі хочуть, щоб ти зробив хороший проект сьогодні, завтра і через 20 років. Нікому не цікаві хороші результати швидко, але тільки один раз. В Україні це було абсолютно інакше: «помри, але зроби». В Австралії це вважається ознакою короткострокового мислення. Тобі буде важко піднятися кар'єрними сходами, якщо будеш думати саме так. Я як би зайшла через задні двері і прорвалася в цей бізнес.   Чому ти вирішила змінити управління проектами на роботу з портфелем? Все-таки це зовсім інший масштаб, інше коло обов'язків, інша перспектива. І як ти зараз себе почуваєш, порівнюючи з позицією керівника проектів? Я працювала 5 років в компанії, в якій я займалася проектами в сфері високовольтної електрики. У якийсь момент я відчула, що мені стало нудно і більше я не можу кар'єрно просунутися. Я людина амбітна, мені хотілося більшого. Це було бажання трошки розширити свої межі і зробити щось більше. Мені подзвонив один знайомий і сказав: «Я розмовляв з однією компанією, вони шукають людину таку, як ти». Я кажу: «В якому сенсі?» «Людина, яка добре розуміє теорію Project Management, але також сама керувала проектами. На жаль, можуть запропонувати контракт тільки на 3 місяці». На що я взялася за голову, це пов'язано зі ступенем захищеності. Контракт, в порівнянні зі стабільною роботою, має дуже велику різницю і ступінь захищеності абсолютно інша. Але мене настільки зачепила ідея того, що я можу когось навчити і зробити щось добре для більшої кількості людей. Я прийшла додому, поговорила з чоловіком і кажу: «Ось такий ризик, я так хочу ризикнути, давай?». А він каже: «Ну добре, давай, з голоду не помремо». І я взяла цей контракт. Робота була FIFO (fly-in/fly-out, постійні переміщення по країні). Половина Австралії працює fly-in/fly-out. Це означає, що вранці в понеділок ти сідаєш в невеликий літак і летиш за 1000 кілометрів від дому. І потім в п'ятницю ввечері ти повертаєшся додому. Ти живеш в вагончиках, у тебе є свій санвузол, ти їси в загальній їдальні, і ти працюєш з 5:15 ранку, коли за тобою приходить автобус і до 7 вечора, коли тебе забирають до кампусу. Цю складову мені оцінити не вдалося, поки я не почала працювати. І робота виявилася дуже цікавою, але дуже важкою фізично, що пов'язано з цими перельотами. Коли ти знаходишся в пустелі, у тебе вранці, коли ти прокинувся, може бути -5 градусів, а до вечора вже +25. Величезний розкид по температурі, фізично це важко. Довгі робочі дні. Через три місяці мене взяли на постійну роботу, ще через місяць мене підвищили до рівня, який би в Україні, напевно, мав би назву менеджер (superintendent). Потім у мене збільшилася команда в 2 рази. За менше, ніж рік роботи на цій посаді я мала 43 підлеглих. Це якийсь збіг обставин чи ти збудувала цей шлях заздалегідь? Я розуміла, що я довго не затримаюсь на тій посаді, на яку я пішла, бо вона була для мене замала. Але я ніколи не змогла б потрапити в гірничодобувну індустрію, не маючи спеціальної освіти. Якби я була інженером мені, напевно, було б легше. Деякі роботи досі вимагають інженерної освіти. Тому я, як-би так сказати, зайшла через задні двері і прорвалася в цей бізнес. Я зробила той крок, який не змогла зробити в своїй попередній компанії. Нарешті я керувала людьми. Єдина відмінність – ці 43 підлеглих не робили проекти. Це називається project services (допоміжні послуги для проектних команд – прим. ред.). Ми займалися управлінням портфоліо, а також у мене були оцінка строків і витрат. У мене такж була команда, яка займалася operational readiness (експлуатаційна готовність). Це підготовка передачі проекту в експлуатацію. Таким чином, моя команда контролювала весь життевій цикл проектів, які робилися моїм департаментом. Я пропрацювала на цій посаді рік, коли мені подзвонив мій ментор і сказав: «Ти мусиш піти попрацювати ось на цю роботу». Новая посада ще більше віддаляла ще далі мене від того місця, де виконуються проекти. При тому вона пов’язана зы стратегічним вибором, які саме проекти будуть робитися в компанії наступного року. Хороший проєкт – це проєкт, що не відбувся.   По суті кажучи, це і є таке стратегічне управління, коли вибір проектів портфеля визначає наскільки компанія зможе рушити до своїх стратегічних цілей. Абсолютно. Поділися, на скільки це можливо, як організована процедура? Коротко, але щоб склалося загальне уявлення. Для компаній, таких як BHP, які грають на світовому біржовому ринку, дуже важливо мати грамотно визначений портфель проектів. Тому що, наші акції складають більшу частину пенсійних фондів в Австралії і по всьому світу. Ми несемо величезну відповідальність перед своїми акціонерами, одним з яких є я. І майже кожна людина, яка працює в Австралії має в своєму пенсійному фонді частину акцій BHP. Тобто, BHP дуже націлена на передбачуваність. Вони хочуть, щоб сказав-зробив, сказав-зробив і ніяких сюрпризів. Для того, щоб продовжувати приносити прибутки, коли ціни на ресурси змінюються щодня, таким компаніям, як BHP, потрібно структурувати свої портфелі проектів таким чином, щоб кожен проект був не випадковий. Кожен проект повинен відповідати певним критеріям. І одне з великих досягнень, моєї команди зокрема, це те, що зараз, в «Мінералах Австралії», є абсолютно структурована система того, як ми вибираємо проекти і як ми їх потім ранжируємо. Наші рекомендації ми представляємо президентам, вони можуть зробити невеликі поправки, дати нам завдання подивитися різні сценарії і потім приймається, так званий, п'ятирічний план. Який потім більш гранулюється в дворічний бюджет. Потім кожен квартал ми знову ж розглядаємо ці проекти, не під мікроскопом, а на більш високому рівні. Але ми їх тестуємо на предмет того, чи має бізнес-кейс досі сенс для компанії чи ні, чи може потрібно прибрати деякі проекти. Чи бувало таке, що ви відсікали? Дуже часто. І в цьому найбільша відмінність роботи керівника проектів і портфоліо менеджера. Я дуже добре розумію керівників проектів, які абсолютно ненавидять нас за те, що ми вбиваємо їх проекти. Це великий культурний шок для мене. Я пам'ятаю, як це любити свій проект і як це бачити, коли його відсікають. Одна з речей, яку ми визначили як стратегічно важливу –ми хочемо культурні зміни того, як Project Managers дивляться на свої проекти. Тобто, ми хочемо більше і більше пояснювати людям, чому їх проект, важливий для них, вже в якийсь момент стає не важливим для компанії. Хороший проект – це проект, що не відбувся. Вкласти це в голову Project Managers дуже складно, я їм співчуваю. Це те саме, як втратити свою дитину, коли «вбили» проект в середині шляху. В нас є методологія, за якою робляться всі проекти. В нас є фаза проекту, яка називається «відбір» - це остання фаза, в якій витрачаються операційні кошти. Після цього ми починаємо інвестувати капітал. Найважливіша точка прийняття рішень відбувається саме тоді, коли ми приймаємо останнє рішення, вже вклавши якусь кількість операційних коштів, про те чи будемо ми вкладати капітальні кошти. Керівник проєктів повинен на 80% керувати зовнішнім контекстом і тільки на 20% керувати самим проєктом.   З позиції і рівня портфеля проектів, давай поговоримо про деякі підказки, які ти могла б дати керівникам проектів в їх поточній діяльності. Чи є якісь знаки, які вказують на те, що даний проект розвивається в неправильному напрямку, що він буде неуспішним і його краще дійсно призупинити? Я пам'ятаю себе початківцем Project Manager. Ти отримав тех. завдання від замовника, ти його схопив, пішов і робиш. Ніколи, ніколи, ніколи не можна втрачати зв'язок із замовником. Це велика спокуса - не спілкуватися з замовниками, тому що вони дають весь час якісь нові завдання, або хочуть щось змінити. Світ навколо нас змінюється швидше, ніж будь коли раніше. Те, що було релевантно рік тому, через два роки вже може бути нікому не потрібним, особливо в Україні, де, наскільки я знаю, цикл планування трохи коротший, ніж в інших країнах. Тому потрібно добре розуміти контекст. Завдання керівника проектів не тільки в тому, щоб дивитися всередину проекту, а в основному керувати зацікавленіми сторонами. І я б сказала, керівник проектів повинен на 80% управляти зовшнім контекстом і тільки на 20% управляти самим проектом. Якщо є хороші бізнес-процеси і, якщо є хороша команда, є сенс розподілити роботу всередині команди і все-таки займатися більше моніторингом того, що відбувається навколо. Ще б я, напевно, сказала, що це помилки багатьох початківців керівників проектів - не потрібен мікроменеджмент, дайте своїй команді більше свободи. Немає такої зміни об'єму проєкту, яка б не впливала на проєкт.   Ще одне питання з приводу ризиків. Ризики часто недооцінюються в управлінні проектами. З твого досвіду, які ризики найчастіше спрацьовують в проектах, на що б ти звернула увагу? Залежить, звичайно, від індустрії. Останнім часом я працюю більше з фізичними проектами, там, де щось фізично відбувається. Тут, я б сказала, що безпека - це найважливіший ризик. Все що може статися поганого, на жаль, відбудеться. Не дивлячись на те, які б у вас не були хороші процеси, людина засуне палець в рухомий механізм, людина прийде на роботу втомлена після вчорашнього робочого дня і оступитися, людина перевернеться на 25-ти тонном траку, тому що він посварився вчора з дружиною був у стресі. Я б сказала, що найголовніше в управлінні ризиками - це покладатися і більше звертати увагу на так звані слабкі сигнали. Це означає, якщо ви бачите, що щось не так і ви навіть не знаєте, що це, значить точно щось не так. Тобто, це не пов'язано з інтуїцією, це знаходиться в абсолютно логічному середовищі. Якщо є хоч якесь припущення, що щось може піти не так, швидше за все так і відбувається. На другому місці ризики, пов'язані зі зміною думки замовника або зі зміною контексту проекту. Думаю, це відбувається скрізь і кожен день. Я вже навіть не знаю, чи можливо це вважати ризиком, думаю, що це просто данність в управлінні проектами, це нормальне життя. Стандартна проблема для проектів полягає в області scope creep, коли зміст проекту починає розростатися. Як ти працювала з цим в ролі керівника проекту і що ти можеш порекомендувати, спостерігаючи вже за більшою кількістю проектів на рівні портфелю? Напевно, це по-різному працювало тоді і зараз. Раніше, мені здавалося, коли в нас з'являються якісь зміни, ми оцінюємо: «це вплине на ціну, а це не вплине на ціну, це вплине на рядки, а це не вплине, добре, давайте будемо добрими до нашого замовника і погодимося». Зараз, коли я почала застосовувати фінансові методи оцінки життездатності проектів, наскільки ці проекти вигідні для компанії, немає такої зміни обсягу проекту, яка б не впливала на проект. Моя найголовніша порада - документуйте, документуйте, документуйте. Будь-яка зміна має бути задокументована. Це звучить, напевно, як заїзджена платівка, про це багато говориться і це мало хто добре робить. Друге – не потрібно нікого жаліти, не шкодуйте свого замовника сьогодні, погоджуючись на те, що йому не потрібно. Тому що потім він вас не пошкодує, коли ви будете здавати проект. Тобто, ви повинні ставити інтереси проекту, якщо це можливо (в Україні, я знаю, це все працює трохи по-іншому) вище інтересів замовника. Якщо у проекту є якісь результати, які потрібно досягти, завжди можна зателефонувати замовнику і запитати: «ви хочете це, або щоб я робив що-небудь?». Ця розмова, я знаю, досить болюча завжди і, напевно, це одна з причин чому я більше не працюю в Україні. Про Agile. «Якщо щось не вийде, ми прийдемо і відремонтуємо» - це не управління проєктами, а те, як люди зазвичай і живуть.   Питання, яке, напевно, цікавить багатьох - це agile. Зараз багато протиставленнь agile класичній моделі управління проектами. Що ти можеш сказати на цю тему? Поділися своїм досвідом. Ми жартуємо в моїй команді, що agile - це лайливе слово. Величезна кількість людей у всьому світі, не тількі в Україні, абсолютно сплутали agile як підхід до життя і до планування з методологією управління проектами. Треба усвідомлювати те, що agile - це не методологія, це скоріше спосіб мислення, тобто, те, як ти підходиш до проекту, те, як ти підходишь до життя, а не структурований підхід до того, як досягти результату. Ми завжди говоримо, що agile - це принцип «ти повинен робити більше за менше». Але якщо подивитися на це в раціональній площині - це неможливо. Неможливо зробити більше за менше, якщо ти не внесеш будь-які зміни. Я абсолютно підтримую agile в сенсі того, як ти думаєш. Грубо кажучи, давайте відмовимося від роботи, яка не приносить ніякої реальної вигоди проекту. Це підхід, коли ти відмовляєшся від непотрібного для того, щоб приділити увагу важливому. Якщо ти просто прийшов і сказав: «Ми не будему слідувати жодній методології, ми зараз нічого не будемо планувати, давайте щось намалюємо на великому білому аркуші паперу і приклеїмо на стіну, підемо це все швидко впроваджувати. А якщо чогось не вийде, ми прийдемо і підправимо» - це не управління проектами, а те, як люди зазвичай і живуть. Ми мали один дуже сумний досвід в цьому році в BHP. Один з наших металургійний активів вирішив застосувати підхід agile до 5-річного планування, яке ми робимо. Це було боляче, всі працювали ночами в кінці, тому що ми ж звичайно не стали планувати і потім в кінці нам всім довелося це підтягувати. Я це не поважаю, я все-таки за класичне планування. Коли люди працюють в команді і знають, що їхній невиконаний шматок роботи вплине на 10 колег, які з ними працюють, вони рідше зривають строки.   Поговоримо трохи про вплив керівника проекту. Дуже часто виявляється, особливо в функціональних організаціях, коли ресурси зосереджені у функціональних керівників, у керівника проекту недостатньо влади. Що ти думаєш з цього приводу? Чи можливе управління проектами, коли у тебе немає формальної влади, коли вона розосереджена по функціональним підрозділам. Я хочу сказати, що я працюю в матричній структурі і це не набагато краще. Я думаю, що дуже мало проектів, навіть у всьому світі, які можуть похвалитися тим, що у них є певна команда, яка належить тільки їм. В Австралії, зазвичай, такі проекти починаються від 50 мільйонів доларів і вище. Всі, хто живуть до 50 мільйонів - не мають своєї команди. І що робити? Який секрет тут для керівника проектів? Побудувати добрі відносини з керівниками функціональних підрозділів, зрозуміти, що рухає ними, коли вони не дають тобі ресурси, і знайти спільну мову, щоб зрозуміти, як можна зробити win-win ситуацію. Ти їм пропонуєш щось - вони дають тобі щось, і так ви працюєте. Найбільший нюанс тут - це не дозволяти співробітникам, які працюють в проекті користуватися тим, що у них два керівника. Тому що, напевно, найбільший виклик, коли одночасно говорять: «Ой, та я повинен попрацювати для свого «звичайного» начальника, а «звичайному» начальнику – не можу, я зараз зайнятий в проекті». В результаті вони ніде не працюють. Австралійці прямо гуру в цьому підході. Що робити? По-перше, потрібно добре планувати. В Австралії зараз дуже популярна «гнучка робота» - це означає, що багато людей працюють з дому. Я сама працюю з дому один день в тиждень. Багато людей працюють віддалено. Один з моїх співробітників працює один день на місяць з Японії, один – з Мельбурна. Це означає, що контролювати людей фізично на предмет того, що вони роблять, стає неможливо. Я думаю, що це тренд сьогодення. Тому що ми повинні працювати більше на обсязі робіт, ніж намагатися керувати людьми. Тобто, людина, яка працює у тебе на проекті, повинна на початку проекту чітко знати обов’язки та ділянку робіт, за яку вона відповідає, вона повинна тобі зобов'язатися виконати ці роботи в певний чітко встановлений строк. Ти повинен безумовно з ним бути на з’вязку. В залежності від свідомості кожної людини. Поділити роботу на конкретні результати. Дуже добре на людей працює емоційний тиск. Коли люди працюють в команді, і вони знають, що їх якийсь невиконаний шматок роботи вплине на 10 їх колег і друзів, які з ними працюють, вони рідше зривають строки. Тому я великий адепт особистих відносин і це ніколи не підводить. Тобто, командна відповідальність. Абсолютно. Тому що люди не працюють на компанію, люди працюють на людей. Якщо ти хочеш, щоб людина зробила те, що вона пообіцяла, було б бажано, щоб вона пообіцяла це тій людині, яка для неї важлива. Твоє завдання зробити так, щоб хтось став для неї важливим. Є, звичайно, такі люди, на яких нічого не діє. Тоді їх треба, по можливості, знімати з проекту, або шукати як замінити їх, або як поставити їх в ситуацію, коли вони не можуть відмовитися. В Україні, думаю, з цим легше. У нас не можна звільняти людей так легко. Але я звільнила за останні півроку двох людей. Це хороший результат. Це не просто хороший результат - до мене тепер ходять на курси, як звільнити співробітника за два місяці. Жінки керівники проєктів статистично вбивають набагато менше людей, ніж чоловіки керівники проектів.   Питання, яке ти частково згадувала - це жінка PM. Все-таки є певні забобони, що керівник проектів - це більше чоловіча робота, особливо, в тій галузі, де ти зараз працюєш. Як ти долаєш це, що тобі допомагає, що тобі заважає? Ці забобони мають під собою дуже давній, історичний контекст, чому люди так вважають. Я борюся за рівноправність, але вважаю, що кожна людина абсолютно індивідуальна. Я бачила чоловіків, які абсолютно жахливі управлінці і погані лідери, а також я бачила жінок, які хочуть працювати на великих посадах і потім хочуть так само йти рано з роботи і брати довгі вихідні. Кожна професія передбачає певний набір компетенцій, які ти повинен мати і висуває певні вимоги до способу життя, який ти будеш вести. Абсолютно сухі цифри говорять, що жінки керівники проектів статистично вбивають набагато менше людей, ніж чоловіки керівники проектів. Це пов'язано з толерантністю до ризика, яка у жінок і чоловіків абсолютно різна. Жінки набагато менше схильні брати ризики в деяких сферах, там, де чоловіки покладаються на «як буде». Одна з речей, з якою я зараз дуже щільно працюю у своїй власній голові - це неусвідомлені упередження, які живуть в кожному з нас. Дуже часто, знову ж статистично, жінки не підтримують інших жінок. Жінки PМ погано підтримують інших жінок PМ. І самі не хочуть, щоб з’являлося більше жінок PМ в індустрії, тому що, напевно, ті, які домоглися успіху, дуже сильно насолоджуються таким своїм становищем «я одна з небагатьох» і це те, що потрібно обов'язково міняти. Я взагалі вірю в менторство. По-справжньому зрозуміла в Австралії, як важливо допомагати тим, хто йде позаду тебе. Тобто, не класно бути однією жінкою PМ, такою кльовою, однією з небагатьох, ось я зробила, домоглася, а класно навчити ще 20 жінок, як стати успішною. Останнє запитання: що б ти побажала всім, хто цікавиться темою управління проектами? Дивна порада, напевно. Більше думайте - менше робіть. Я думаю, що Україна, оскільки у нас так багато всього відбувається, не зовсім спокійна країна останнім часом, є велика тенденція переходити до дій. Ми дуже багато діємо і недостатньо даємо собі часу щось усвідомити. Я пам'ятаю, проживаючи в Україні, мене постійно переслідувало відчуття, що я зробила недостатньо, можна ж було ще. Коли ви перестанете бути настільки сфокусованими на дії і витратите час на усвідомлення, ви зрозумієте, що ті ж самі результати вимагають у вас набагато менше зусиль. В цьому і є секрет всіх великих лідерів і людей, які отримують мільйони доларів на рік. Вони більше думають, менше роблять, але все те, що вони роблять, воно точно в ціль. Менше рухів – більше результату. Ось така у мене порада. Читати далi 
Гібридні практики (hybrid) – (не)новий підхід до управління проектами
Гібридні практики (hybrid) – (не)новий підхід до управління ...
Вибір неправильної методології управління проектом може стати однією з причин того, що проект зазнав невдачі. З іншого боку, не існує єдиної методології, яка підходить для всіх проектів. Більш того, навіть в одному проекті використання однієї методології на різних етапах його життєвого циклу буде знижувати ефективність досягнення результату і взаєморозуміння між проектною командою і замовником. Так виникла ідея використовувати різні підходи в рамках одного проекту. Така методологія отримала назву гібридної (hybrid). Гібридна методологія передбачає, що в компанії використовують інструменти, які найбільше підходять на різних етапах життєвого циклу і рівнях управління проектом. Наприклад, етап планування і збору вимог виконується з використанням рекомендацій PMBOK, а на етапах проєктування, розробки і впровадження використовується Scrum або Kanban. Такий підхід дозволяє зібрати достатньо інформації на старті проєкту для оцінки бюджету і термінів, а потім вже в міру реалізації проекту враховувати коригування вимог і вносити уточнення в оцінку термінів і вартості. В результаті прогнози бюджету і терміни для замовника будуть більш точними. Поставка результатів проєкту здійснюється поетапно. Це дає можливість звірятися з очікуваннями замовника, отримувати від нього зворотній зв'язок і більш гнучко реагувати на зміни ринку. Недавній звіт PMI показує зростання обсягу ІТ-проектів, які виконуються з використанням гібридних підходів. Обмеження виявляється в тому, що команди і окремо взяті співробітники часто не готові міняти звичні методи роботи. У цій ситуації важлива підтримка з боку топ-менеджменту і HR-фахівців - повести співробітників за собою і стати лідерами змін. Читати далi 
Agile: революція чи… еволюція?
Agile: революція чи… еволюція?
На тренінгах з управління проектами та управління бізнес-процесами ми часто отримуємо запитання про agile-практики і їх безальтернативність в сучасному швидкоплинному світі. Ми детально розповідаємо про переваги та обмеження agile.І навіть йдемо далі: демонструємо, як проекти і процеси доповнюють один одного і чому agile-практики можна чудово застосовувати для оптимізації бізнес-процесів. Давайте спробуємо історично простежити, чому agile-практики близькі до процесного управління і які концепції передували їх появі. Поява Agile У 2001 році група розробників програмного забезпечення (ПО) зібралася в м.Юта (США), щоб запропонувати нову методологію управління проектами з розробки ПЗ на противагу класичним «бюрократичним і важким» підходам. Прийти до консенсусу по методології не вдалося, зате з'явився «Agile-маніфест», який позиціонувався як радикально новий підхід до управління проектами. З легкої руки Кена Швабера (Ken Schwaber) Agile починають називати революцією в управлінні проектами. Ідеї, які лягли в основу Agile-маніфесту, з'явилися задовго до 2001 року. Звернімося до історії (див. мал.1). Мал.1  PM/BPM Timeline Фредерік зустрів Генрі Коріння Agile йдуть в 1878 рік, коли Фредерік Тейлор (Frederick Taylor) представив теорію «Наукового менеджменту». Тейлора асоціюють зі стандартизацією праці на виробництві та підвищенням продуктивності бізнес-процесів. Однак його внесок в розвиток інструментів управління проектами та процесами цим не обмежується. Справа в тому, що в 1887р. Фредерік Тейлор найняв помічником Генрі Гантта (Henry Gantt), який на початку 20 століття запропонував знайомий багатьом спосіб візуалізації план-графіка проекту (див. мал.2). Через 100 років діаграма Гантта все ще залишається популярним інструментом серед керівників проектів. Мал.2 Діаграма Гантта Народження Lean та ітеративних практик Праці Тейлора дали поштовх подальшому вивченню бізнес-процесів. Френк і Ліліан Гилбрет (Frank and Lilian Gilbreth) в 1921р. запропонували використовувати діаграми процесу (process charts) для його візуалізації, аналізу та удосконалення. В основі їх рекомендацій по оптимізації лежали: стандартизація процесу, усунення втрат (waste) і спрощення роботи співробітників. У 1930р. Ліліан Гилбрет презентувала спосіб візуалізації потоку робіт за допомогою інструменту, відомого сьогодні як Kanban-дошка: «We had three rows of hooks, one marked "Jobs to be done", one marked "Jobs being done" and a third marked "Jobs completed" with tags which were moved from hook to hook to indicate the progress of the task. (Джерело: 1930 Speech by Lillian Gilbreth to National Federation of Business and Professional Women's Clubs in New York)». Мал.3 Kanban-дошка Через деякий час, після завершення другої світової війни, в 1950 році на зустрічі з японською спільнотою вчених й інженерів, доктор Едвардс Демінг (Edwards W. Deming) представив ідеї статистичного контролю процесу (Statistical Process Control) і циклу PDCA (Plan-Do-Check- Act). Цикл PDCA має на увазі ітеративну роботу над поліпшенням бізнес-процесу: починається все з планування, потім слідує реалізація ініціатив щодо поліпшення, перевірка отриманих результатів і рішення про подальші дії на наступній ітерації. Найбільш популярний agile-фреймворк Scrum пропонує фактично аналогічний підхід до організації роботи проектної команди (мал. 4). Використання agile-практик в проектах по оптимізації бізнес-процесів виходить настільки органічним саме тому, що agile є еволюцією циклу PDCA. Мал.4 Two-week sprint Кіічиро Тойода (Kiichiro Toyoda) познайомився з роботами Гілбретів в 1929 році під час поїздки в США і Європу. У 50-х роках компанія Тойота стала піонером в адаптації ідей Гілбретів і Демінга. Виробнича система Тойота (Toyota Production System) увібрала в себе ідеї стандартизації роботи, усунення втрат, безперервного вдосконалення за ітеративним принципом, канбан та ін. На хвилі зростання інтересу до японських автовиробників в 80-х роках в США з'явився термін Lean Production (бережливе виробництво). Lean - маркетингова назва принципів виробничої системи Тойота. Підхід швидко набрав популярність, і незабаром з'явилися адаптації Lean для інших галузей. Концепція Lean software development стала однією з перших agile-методологій по розробці програмного забезпечення. В цей же час в Японії розвивалися фабрики розробки ПО (Software factories). По мірі слабшання бар'єрів в торгівлі та глобалізації бізнесу доводилося адаптувати практики паралельної розробки для географічно розподілених команд. Ідеї усунення втрат (elimination of waste), стандартизації ролей і спрощення процесу дісталися до самої прогресивної, на сьогоднішній день, галузі через 60 років після виникнення. «Залізний» трикутник, інкрементальні і ітеративні практики Повернемося до «класичного» управління проектами і згадаймо діаграми процесів Гілбретів. Саме їх компанія DuPont адаптувала і поклала в основу свого Critical Path Method (CPM). Діаграма Гантта, критичний шлях і «залізний» трикутник стали популярними інструментами керівників проектів в 60-х роках минулого століття. Через 40 років ідею трикутника стали використовувати послідовники agile для пояснення відмінностей класичного управління проектами та agile-практик (див. мал. 5).   Мал.5 Agile-підхід У 60-х роках виникли перші згадки про інкрементальні і ітеративні практики управління проектами. Вперше це сталося в проекті Меркурій, який реалізувала NASA в 1958-1963 рр. Трохи пізніше, з 1968 року, почалася адаптація ітеративних практик під проекти розробки ПЗ. Через деякий час ітеративні практики включили в фреймворк PROMPT (праобраз сучасного PRINCE2) і керівництво PMBOK (згадується як спіральний життєвий цикл проекту, spiral project lifecycle). З нашої точки зору, концепція Agile стала закономірним продовженням еволюції підходів, які використовувалися раніше, наприклад, в проектах по розробці ПЗ та оптимізації бізнес-процесів. Історія показує, що більшого успіху досягають ті компанії, які комбінують різні інструменти і методології, в залежності від специфіки проекту і контексту, в якому він реалізується. Судячи з усього, в недалекому майбутньому agile-практики також будуть еволюціонувати і в управлінні проектами з'являться нові «революційні» ідеї.   При підготовці статті використовувалися матеріали: McKenna T, Whitty SJ. (2013) Agile is Not the End-Game of Project Management Methodologies. In: Proceedings of the Annual Project Management Australia Conference Incorporating the PMI Australia National Conference (PMOz), Melbourne, 17-18 September 2013. Читати далi