Один проект і два PM: можливе ефективне керування

Мене звуть Влад Самойлов. Остання компанія в якій я займав позицію IT portfolio manager, — «Київстар». У проектному і продуктовому менеджменті на ринках СНД, Європи, США та Азії я вже більше 6 років. Останні два роки активно викладаю IT project management в кількох школах і центрах IT-освіти, а також є тренером з командоутворення.

Трапилося якось мені працювати з проектом, в якому було два прожект-менеджера при рівноправній управлінської моделі. Проект був досить великим, слабка матриця в організаційній структурі мала плюси і мінуси зі своїм шерінг-пулом ресурсів. І напевно, одним з найцікавіших проектів у моїй кар'єрі. Наявність двох проджект-менеджерів в ньому, звичайно, могло б принести більше користі, ніж шкоди, якби все те, про що я пишу в цій статті, ми змогли реалізувати в повному обсязі і, головне, вчасно. Є ще ряд assumptions, але вони вже другорядні.

Однак про все по порядку.

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

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

Мета будь-якої сучасної IT-конференції сьогодні — нетворкінг. За останні 6-7 років я відвідав значну кількість конференцій, щоб сьогодні чітко формулювати завдання. Виконання цих завдань допоможе мені винести максимум, будучи спікером чи учасником. Цілі, поставлені на цей рік у ролі спікера PM Day, можна вважати досягнутими.

Принципи побудови команд

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

Питання «Що найголовніше у побудові команд?» досить складний. Гроші? Мотивація? Висококваліфіковані фахівці? Можливо. Але я для себе виніс інші цінності.

Продукт

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

Не буває стовідсотково успішно реалізованих проектів. І один з таких моїх кейсів нагадує мені вже кілька років про важливість максимального рівня залученості кожного учасника команди в продукт.

Був я в той момент ще зовсім молодим проджект-менеджером, і попався мені в команді людина зі слабкою зацікавленістю в продукті. Забігаючи наперед, скажу, що проект був провалений, правда, частково, так як вдалося вийти в ресурсний нуль. При цьому витративши 7 місяців. Для замовника це повна невдача. Безумовно, відповідальність лежала на прожект-менеджера. Тоді мене підвів слабкий інтерес до фріланс-проектів цього розробника, одним з яких виявився замовлення від конкурента на суміжний з нашим продукт (тут, звичайно, очікую від вас безліч коментарів, що правильно було б робити і як себе вести). А адже він навіть погоджував зі мною свій гнучкий графік для можливості ведення свого проекту. Ех, молодість... Ну да ладно, продовжимо.

Для кого і навіщо

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

Остання компанія в якій я черговий раз на практиці переконався у важливості не просто створювати продукти, а створювати цінність цих продуктів, це «Київстар». Ринок телеком-послуг, звичайно, не сильно великий в Україні, але вибрати є з чого. Тому нам у кожної, навіть найдрібнішої, ініціативи доводилося ретельно вивчати потреби, болі і бажання кінцевих користувачів, щоб саме у тебе не виникало бажання «спробувати більш зручний додаток оператора АВС» або «поставити другу сімку тільки для інету».

Для більш наочного розуміння важливості створення цінності можна навести приклад можливого розподілу бюджету проекту по розробці найпростішого API (що дозволить користувачеві уникнути необхідності проходження додаткового кроку при оплаті пакету послуг), яка може становити 90/10. А саме: 90% витрат бюджету — на маркетингові дослідження, customer success experience, пілотний запуск, А/Б тести і т. д. і лише 10% — на фактичне виконання проекту (повний SDLC).

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

Розуміння, ким ви керуєте

Команда — це що таке? Який тип команди формується у вас? Керувати або направляти? Важливо зрозуміти одне: кожен випадок унікальний. І ваш теж. Тому кожен повинен відповісти на ці питання для себе і тільки потім обговорювати їх вголос.

Три найважливіших аспекти, розуміння яких допоможе вам з першого разу успішно побудувати ефективні процеси менеджменту:

Що хочемо створити.
Для кого хочемо створити.
Навіщо хочемо створити.

Після одержання відповіді на ці питання ми визначаємо/коригуємо/змінюємо майже все:

структуру команди;
рольову модель;
методологію управління;
план адаптації до змін;
набір інструментів та підходів управління;
цілі і road maps розвитку;
метрики, KPIs, OKR.

Список може бути настільки тривалим, скільки потрібно в конкретному кейсі.

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

Двоє біля керма

Як показало спілкування і спільна робота з проджект-менеджерів на конференціях, питання, яким задавався фактично кожен практик, наступний: можливо управління проектом удвох?

Сьогодні можна придумувати різні методології/фреймворки (Waterfall, Agile, Scrum, Kanban, Lean...), інструменти (RACI, WBS, Gantt chart diagram, матриця вимог/ризиків/стейкхолдерів...), посилаючись на професійні джерела (PMI , ScrumAlliance , DOU та ін). Але іноді зустрічаються кейси, які суперечать не тільки класичним підходам у проектному менеджменті, але і здоровому глузду. Один з них — керування одним проектом при рівноправній рольової моделі двох проджект-менеджерів. І навіть у цьому випадку у вас є всі шанси на успіх. Не опускаємо руки, для початку необхідно розібратися, чи законно це.

Це досить нетипова модель, але вона часто зустрічається в сучасній практиці, коли йде етап реструктуризації проекту або його передача від одного до іншого PM (адже етап передачі highload-проекту може досягати 2-3 місяців, і протягом усього цього часу проектом керують дві людини). Дуже важливо вчасно ідентифікувати, що проект почав якусь трансформацію, наприклад з проекту в програму або портфель, адже ці структурні зміни вимагають перегляду рольової і поведінкової моделі в команді, в тому числі — кількості проджект-менеджерів (можливо, функціональних).

Також наявність двох проджект-менеджерів можливо в мультистримовых проектах, де, крім напрямки розробки ПЗ, є стріми маркетингу, продажів/логістики та інше. І в кожному напрямку може бути свій менеджер.

Мій улюблений кейс, з яким я сам одного разу зіткнувся на практиці, коли на проекті з'являються два прожект-менеджера, це питання-хочу замовника «А давай посилимо твій проект?»; хоча фактично це ніколи не є питанням, а радше: «Я розумніший, тому вирішив, що тепер вас двоє». І навіть якщо ви використовували всі свої хард-, софт - і мегасупер-скіли для відходу від цього «рішення», з цим можна ефективно працювати. Поговоримо детальніше як.

Що потрібно врахувати в першу чергу

Кожному на новому етапі життя проекту важливо знати, які перші кроки потрібно зробити. Я підкажу які.

Отже, на черговій зустрічі з керівником/клієнтом вам озвучують: «Ти молодець. Але ми вирішили посилити твій проект, і завтра до тебе приєднується ще один PM. Ви, звичайно, спробували змінити умови гри, витерти холодний піт. Але що ж робити, враховуючи, що цього кейса не уникнути? Поїхали.

Причина. Визначите, який з перерахованих вище кейсів у вас склався і з якоїсь причини у вас в проекті додався другий PM. Адже трансформація проекту або організаційної структури компанії — далеко не єдина причина. Ще однією причиною я б хотів назвати ваше власне рішення як менеджера проекту. Додавання другого людини не завжди погане, притягнута за вуха рішення». І якщо ви як менеджер вирішили вирости (до Program/Portfolio manager), щоб тим самим принести користь проекту, то маєте всі інструменти для цього; головне, не забудьте підготувати під такі зміни бюджету.

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

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

Зрозуміти це дуже просто. У більшості випадків новий PM може допомогти з вирішенням завдань з області ресурсного перерозподілу (простіше кажучи, візьме на себе частину функцій у проекті), впровадженням зовнішньої експертизи в реалізацію проекту або рішення точкових проблематичних кейсів. Формулювання «Ми постійно провалюємо дати нових релізів, тому нам потрібен другий PM, щоб все більш якісно заменеджерить» може стати згубною, якщо, розбираючи кожний окремий випадок, з'ясуйте, що не в нестачі ресурсу прожект-менеджера проблема, а банально не прописаних Definition of Ready і Definition of Done. Цей приклад — не плід неординарною фантазії, а приклади з одного мого проекту. У момент першого знайомства з одним з головних стейкхолдерів проекту я і почув таке формулювання. Добре, що через кілька тривалих зустрічей і безліч ночей, проведених у процесі аудиту проекту, мені вдалося переконати його в тому, що тут не вирішити проблему навіть 10 проджект-менеджерами, якщо не прописати вищеназвані критерії.

Кваліфікація другого прожект-менеджера. Ми ж повинні розуміти, наскільки потужний ресурс потрапляє до нас в команду. Є ймовірність, що нас просто змушують поменторить якогось джуна під таким приводом.

Проджект-менеджер проджект-менеджеру один. Просто поговоріть з новим PM в неофіційному форматі, спробуйте зрозуміти його очікування, поділитися своїми, дізнатися про те, яку користь він може і хоче принести, і просто банально попытайтеь домовитися, як же вам тепер жити разом.

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

Інструментарій

Я за всю свою практику виніс два найбільш важливих і ефективних інструменту, які необхідні для ефективного управління проектом удвох:

карта комунікацій;
багаторівнева RACI-матриця.

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

На перший погляд цей інструмент може здатися забюрократизованим. Вік agile, а ми тут папірці з правилами спілкування всередині команди формуємо! Але це абсолютно не так. І той, хто стикався з хаосом у проектах, розуміє, що без чітких правил взаємодії і управління комунікаціями ефективне управління неможливе, тим більше удвох.

Ви тільки уявіть (або згадайте свої відчуття, коли приходите на проект, в якому 10-50 (неважливо скільки) людина, і вам необхідно всім цим керувати. І що ще важливіше, управляти, досягаючи певної мети.

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

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

Я для себе вивів два типи багаторівневої RACI-матриці:

Крос-функціональна, або «RACI на RACI». Вище говорили, що кілька проджект-менеджерів можливо на мультистримовых проектах. Так ось ми на кожен стрім/функціональний напрям створюємо окрему RACI, де відповідальним за бюджет, до прикладу кожного з стримов, буде свій проджект-менеджер, але при цьому нам ще необхідно створити глобальну матрицю, в якій визначити одного відповідального за глобальний бюджет.
Багаторівнева RACI. Це класична візуалізація RACI-матриці, тільки вона включає не просто одного відповідального за бюджет наприклад, а 3 рівня (ну або скільки у вас там проджект-менеджерів на проекті утворилося), правила, які ми ставимо. І вони нам можуть говорити про те, що:
- R (Responsible) 3 — відповідальний за бюджет бізнесу;
- R2 — відповідальний за бюджет ІТ;
- R1 — відповідальний за бюджет всього проекту/продукту.

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

Приклад класичної карти комунікацій, яка застосовується для численних команд; тому структуруємо мапу по функціям, а не людям і проставляємо зв'язку проектного та функціонального взаємодії:

? лаконічність, доступність широкого кола стейкхолдерів, легко вносити динамічні зміни, ідеально підходить для команд з більш, ніж 20 учасників.

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

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

? візуально доступна для сприйняття, правила зрозумілі без додаткової презентації/пояснень/коментарів, формат застосовується в командах до 12-15 чоловік.

? може містити до 3-4 правил, не враховує виняткових кейсів, незастосовна в структурних матричних організаціях.

Альтернативно-креативним варіантом карти комунікацій може бути і такий формат. Дана карта візуалізує не рольова взаємодія, а маршрути комунікації в команді/організації/групи:

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

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

Як ви вже зрозуміли, немає правильного або неправильного формату для візуалізації карт комунікацій, найголовніше, щоб вона відповідала своєму призначенню і команда готова була нею користуватися. А для цього спробуйте не фантазувати на самоті, а створити її разом з командою. У моїй практиці дуже добре зарекомендував себе ітеративний підхід створення подібних карт через командні мозкові штурми. Тобто ми не прагнемо створити за допомогою одного підходу відразу комплектний інструмент, а доповнюємо, коригуємо і модернізуємо його протягом певного періоду, наприклад до закінчення фази ініціації/планування. У виняткових випадках, коли ви на проекті не з самого початку, є сенс ставити дедлайн самому собі, підв'язавши його до impact milestone на критичному шляху.

Є й інші можливі варіанти поведінково-рольових моделей в залежності від структурного типу компаній, що є основоположним чинником формування карти комунікацій і багаторівневою RACI. У Києві на Project Management Day 2019 ми встигли не тільки поговорити про це, але і сформувати кілька детальних моделей.

P. S.

Відвідуючи різні конференції, для себе почерпнув важливість того, що кожна компанія, як і кожна команда, є унікальною і несе унікальні культурні цінності. При спілкуванні з представниками різних продуктових, аутсорсингових, діджитал-компаній ця їх особливість дуже помітна. І це круто! Частково в цьому і є принадність нетворкінгу на подібного роду заходах. Після них ти завжди маєш щось на «подумати», якщо, звичайно, не проводиш весь час за столиком з безкоштовними снеками та кави. Дуже корисно зазирнути за борт своєї організації і задатися питанням: невже там може бути по-іншому?

Також корисно говорити з колегами і формулювати свої погляди і гіпотези. Так народжується істина. Сподіваюся, я зміг принести користь менеджерам, з якими поділився цими знаннями. Все вищесказане я успішно застосовую в процесі створення нашого нового продукту Connectable (проект в розробці).

Спілкування, спілкування і ще раз спілкування. І навіть керуючи командою удвох, ви почнете перформить на максимум.

А тепер спробуйте зазирнути за борт...

Опубліковано: 27/12/19 @ 11:00
Розділ Різне

SEO Блог