PMO у венчур-білдері: як перестати гасити пожежі й почати масштабуватися

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт! Я — Олександр Цуркан, PMO у венчур-білдері Spalah. Моя робота — переводити компанії з режиму «вічного пожежогасіння» у режим системної роботи та профілактики: правила гри, метрики, чек-листи й рішення, що не залежать від однієї людини. За останні роки в AdTech (а до цього FinTech, аутсорс та аутстаф) я достатньо бачив, як відсутність системи б’є по грошах, людям і стратегії, і достатньо робив, щоб такого не відбувалося.

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

Хто такий PMO і навіщо він бізнесу

PMO — не ще один менеджер, а офіс-практик. Він задає спільну методологію та інструменти, алайнить проєкти зі стратегією, дає видимість портфеля (ресурси, ризики, пріоритети), накопичує знання та lessons learned.

Що кажуть дослідження PMI: організації з PMO мають вищі показники успіху проєктів і кращу узгодженість зі стратегією (менше провалів, більше проєктів у бюджеті та строках).

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

Реактивність vs профілактика

Реактивний підхід дорого коштує: ви відволікаєте людей, дедлайни горять, якість страждає. Harvard Business Review описує, як пожежогасіння (в оригіналі firefighting) засмоктує компанії в цикл авралів, дуже раджу прочитати цю статтю.

Економіка якості каже те саме: правило 1—10—100, де $1 на профілактику економить $10 на виправлення і $100 на наслідки провалу (ASQ / Cost of Quality, пояснення 1—10—100).

Що робить PMO:

• бачить ризики заздалегідь і закладає контрольні точки;
• після інциденту проводить blameless постмортем (причини → рішення → оновлення процесу → метрика ефекту) — гайд і шаблони від Atlassian;
• фіксує зміни у Jira/Confluence, вчить команду, впевнюється, що проблема не повернулась (що робить постмортем корисним).

Мінімально достатня система, як зробити це без бюрократії

Принцип 1. Процес працює без імен. PMO-тест на людинозалежність: для цього запитайте себе, чи зламається процес, якщо завтра конкретної людини не буде? Якщо так — це єдина точка відмови (SPOF-(Single Point of Failure)). Дії: чек-лист/SOP у Confluence, бекап-виконавець, перехресне навчання, SLA і метрика.

Принцип 2. Один зрозумілий воркфлоу в Jira. Уявімо Jira канбан-борд. Там є назви стовпців, а також статусів. На початку все зʼявляється в беклозі, потім рухається в ToDo і так далі. Обов’язкові поля перед переходами: бізнес-цінність, DoD, посилання на Confluence. І в ідеальному варіанті цей флоу має виглядати так:

Backlog → Ready (To Do) → In Progress → Code Review → QA → Ready for Release → Done

Принцип 3. RACI на епіки й ініціативи. Хто відповідає ^®, хто затверджує (A), кого консультуємо ©, кого інформуємо (I). Це знімає розмазану відповідальність і конфлікти (RACI-гайд Atlassian).

Кейс 1

Контекст: пішов ключовий інженер. Реліз заблоковано, тому що тільки він знає кроки деплою (частину процессу ci\cd), як деплоїти на прод і при цьому не паузити його.

Що зробили:

• Blameless постмортем (1 година): таймлайн, корінна причина (5 Whys), ризики.
• Чек-лист релізу + DoD у Confluence; обов’язкові поля в Jira.
• Succession-note на критичні ролі (доступи, кроки, fallback).
• Bus factor ≥ 2 на реліз: перехресне навчання; RACI — Responsible: TL, Accountable: PMO.

Результат: реліз відновили того ж тижня; наступні два пройшли без участі героїв-власників.
Шаблони постмортемів.

Кейс 2

Контекст: розмазування ролей між функціями зривало нову ініціативу.

Що зробили:

• На епік ввели RACI; погодили «вузькі» рішення через A, а не колективно.
• Побудували capacity-план на 2 спринти, зафіксували WIP-ліміти.
• Запустили щотижневу 15-хв сінку по метриках (Lead/Cycle time, блокери, ризики).

Результат: прибрали конфлікти, підняли передбачуваність. RACI.

90-денний план запуску PMO (без болю, як зробив би я)

Дні 0–30 — навести видимість

• Інвентар проєктів/епіків, карта залежностей, топ-5 ризиків.
• Мінімальний Jira-воркфлоу (див. вище).
• Єдині артефакти: шаблон задачі, DoD/DoR, посилання на Confluence.

Дні 31–60 — прибрати SPOF’и

• PMO-тест на людинозалежність; succession-notes на ключові ролі.
• Постмортеми за інцидентами → зміни у процесах.
• RACI + capacity на стратегічні епіки.

Дні 61–90 — закріпити системність

• Щотижневі метрики здоров’я: Lead/Cycle time, Defects escaped, On-call noise.
• Комунікаційні SLA між функціями (підтримка, легал, фінанси, HR).
• Огляд портфеля: все, що не тягне OKR — паркуємо/пивотимо (PMI про роль PMO у стратегії).

Типові помилки впровадження PMO (і як їх уникнути)

• Забагато процесу одразу → спротив. Почніть з мінімально достатнього.
• Немає метрик → не видно ефекту. Візьміть 3–5 простих і тримайте ритм.
• Проєктна поліція замість сервісу. PMO — це допомога, а не кара.
• Без підтримки C-level все буксує. Попросіть один пілот і покажіть цифри.

Швидкі фішки

1. Шаблон постмортему: факт → вплив → root cause → рішення → відповідальний → дедлайн → метрика. (Atlassian)
   
   • Факт — що саме сталося.
   • Вплив — на що саме вплинуло (що зачепило).
   • Root cause — йдемо до істинної причини через метод «5 чому».
   • Рішення — що робимо, щоб уникати повторення проблеми в майбутньому?
   • Відповідальний — хто буде впроваджувати рішення.
   • Дедлайн — коли буде впроваджено і коли потрібно речекнути, що все ок.
   • Метрика — як відслідкувати, що проблему вирішено.
2. RACI на епік + capacity-плани на 2–3 спринти. (Atlassian)
3. One-pager ризиків: матриця, Top-5, тригери, відповідальні; перегляд раз на 2 тижні.
4. SLA між функціями: хто/де/за скільки відповідає — менше пінг-понгу, більше фокусу.
5. Definition of Ready/Done у Confluence + обов’язкові поля в Jira.

Висновок і запрошення подискутувати в коментах :)

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

• які SPOF’и болять у вас зараз?
• які метрики здоров’я працюють/не працюють?
• куди б ви додали RACI вже цього тижня?

Я з радістю подискутую й додам конкретики по ваших кейсах.

Джерела

• Harvard Business Review — Stop Fighting Fires
• PMI — The Value of Project Management (whitepaper, PDF)
• PMI — Project Management Office & Strategic Goals
• PMI — Pulse of the Profession (огляди)
• ASQ — Cost of Quality (CoQ)
• EASE — 1—10—100 правило (пояснення)
• Atlassian — Blameless postmortem
• Atlassian — Postmortem templates
• Atlassian — RACI guide
• Atlassian — What makes a good postmortem report