Узгодження між відділами

Мета

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

Узгодження — не каскадування зверху вниз. Каскадування означає "керівник визначив ваші цілі". Узгодження означає "команда визначила свої цілі, які свідомо підтримують стратегію організації". Різниця — в ownership.

---

Покроковий процес

Крок 1. Побудувати вертикальну архітектуру OKR

Вертикальне узгодження — зв'язок між рівнями: стратегічні OKR організації → OKR відділів → OKR команд. Кожен рівень підтримує рівень вище, але не копіює його.

Три рівні OKR:

Рівень	Хто ставить	Горизонт	Кількість	Приклад
Стратегічний (організація)	CEO + C-suite	Річний (переглядається щоквартально)	3-5 Objectives	"Стати лідером у сегменті SMB на ринку України"
Тактичний (відділ)	VP/Director + тімліди	Квартальний	1-3 Objectives	"Побудувати канал залучення через партнерів"
Операційний (команда)	Тімлід + команда	Квартальний	1-2 Objectives	"Запустити партнерську програму з self-serve онбордингом"

Правила вертикального узгодження:

1. Кожен OKR команди повинен підтримувати хоча б один OKR відділу. Але не кожен OKR відділу має бути покритий OKR кожної команди.
2. Команда не копіює KR відділу. Вона визначає свої KR, які впливають на KR відділу. Приклад: KR відділу — "З 100 до 300 нових клієнтів через партнерський канал". KR команди — "З 0 до 20 підписаних партнерських угод" (які потім генерують клієнтів).
3. Не більше 2 рівнів каскадування. Стратегічний → Тактичний → Операційний. Якщо організація намагається додати четвертий рівень (підкоманди) — це занадто глибоко. Підкоманди можуть мати KR, але не окремі Objectives.
4. Не всі OKR команди повинні бути узгоджені вгору. 70-80% — узгоджені. 20-30% — ініціативи команди, які не пов'язані з OKR відділу напряму, але підтримують стратегію неявно (наприклад, технічний борг, внутрішні процеси).

Процес узгодження (bottom-up з guard rails):

1. Лідерство визначає стратегічні OKR та комунікує їх усім відділам (тиждень 1 кварталу).
2. Відділи визначають свої OKR, орієнтуючись на стратегічні (тиждень 1-2).
3. Команди визначають свої OKR, орієнтуючись на OKR відділу (тиждень 1-2).
4. Alignment session: відділ переглядає OKR команд і перевіряє зв'язність (тиждень 2).
5. Cross-team session: команди з різних відділів перевіряють залежності (тиждень 2-3).
6. Фіналізація (тиждень 3).

Крок 2. Побудувати горизонтальне узгодження

Горизонтальне узгодження — координація між командами різних відділів, які залежать одна від одної для досягнення OKR.

Типові cross-functional залежності:

Команда А	Залежить від	Команда Б	Тип залежності
Продукт	Дані	Аналітика	KR продукту потребує дашборд від аналітики
Маркетинг	Контент	Продукт	Маркетинг просуває фічу, яку продукт ще не випустив
Продажі	Матеріали	Маркетинг	Продажі потребують case studies від маркетингу
Інженерія	Вимоги	Продукт	Інженерія будує, що продукт визначив
HR	Дані	Фінанси	HR потребує бюджетне погодження від фінансів

Техніка маппінгу залежностей — для кожного KR кожної команди визначте: чи є зовнішня залежність (так/ні), від якої команди, що саме потрібно (конкретний deliverable), коли потрібно (дата або тиждень кварталу), чи є цей deliverable в OKR залежної команди (так/ні).

Якщо відповідь на останнє запитання — "ні", це ризик. Команда Б може не пріоритизувати те, що потрібно команді А. Варіанти: команда Б додає відповідний KR або ініціативу; команда А знаходить альтернативний шлях без залежності; менеджери обох команд узгоджують пріоритет та дедлайн.

Крок 3. Провести alignment session (вертикальне узгодження)

Alignment session — зустріч усіх тімлідів одного відділу з менеджером відділу для перевірки вертикальної зв'язності OKR.

Коли: тиждень 2 кварталу, після того як команди підготували драфти OKR. Учасники: менеджер відділу, усі тімліди, OKR-фасилітатор відділу. Тривалість: 60-90 хвилин.

Підготовка: менеджер відділу публікує OKR відділу за 3 дні до зустрічі; кожен тімлід готує драфт OKR команди та визначає зв'язок з OKR відділу; OKR-фасилітатор готує alignment matrix (див. шаблон нижче).

Формат зустрічі:

Частина 1 — Огляд OKR відділу (10 хвилин). Менеджер відділу нагадує OKR відділу та контекст: "Ось наші цілі на квартал. Ось чому саме ці."

Частина 2 — Презентація OKR команд (30-40 хвилин). Кожен тімлід презентує OKR команди за 5 хвилин: Objective та KR, зв'язок з OKR відділу (який KR відділу підтримує), ключові ризики та залежності.

Частина 3 — Перевірка зв'язності (15-20 хвилин). OKR-фасилітатор показує alignment matrix: чи покриті всі KR відділу OKR команд? Чи є дублювання (дві команди працюють над одним)? Чи є "сироти" — OKR команди, які не підтримують жоден OKR відділу?

Частина 4 — Рішення (10-15 хвилин). Визначити: які OKR команд потребують корекції (не узгоджені або дублюються), які KR відділу не покриті жодною командою (хто візьме?), дедлайн фіналізації корекцій.

Крок 4. Провести cross-team session (горизонтальне узгодження)

Cross-team session — зустріч тімлідів з різних відділів для виявлення та узгодження залежностей.

Коли: тиждень 2-3 кварталу, після alignment sessions в кожному відділі. Учасники: тімліди команд, які мають cross-functional залежності, OKR-фасилітатори відділів. Не потрібні всі тімліди — лише ті, хто має залежності. Тривалість: 60 хвилин.

Підготовка: кожен тімлід заповнив маппінг залежностей (Крок 2); OKR-фасилітатор збирає всі залежності в єдину таблицю; визначає "неузгоджені" залежності (команда А потребує щось від команди Б, але в OKR команди Б цього немає).

Формат зустрічі:

Частина 1 — Огляд залежностей (15 хвилин). Фасилітатор представляє таблицю залежностей та виділяє неузгоджені.

Скрипт:

"Ось карта залежностей між командами. Зеленим — узгоджені: обидві команди бачать залежність і вона в їхніх OKR. Червоним — неузгоджені: команда А потребує щось від команди Б, але команда Б не включила це у свої OKR."

Частина 2 — Обговорення неузгоджених залежностей (30-35 хвилин). Для кожної неузгодженої залежності: тімлід команди-залежної пояснює, що потрібно та коли; тімлід команди-постачальника відповідає, чи реалістично, які ресурси потрібні, який пріоритет; рішення: (а) команда-постачальник додає це в OKR, (б) команда-залежна знаходить альтернативу, (в) ескалація на рівень менеджерів відділів.

Частина 3 — Фіксація домовленостей (10 хвилин). Кожна узгоджена залежність фіксується: хто → кому, що (конкретний deliverable), коли (тиждень кварталу), де відстежувати (спільний дашборд або check-in).

Крок 5. Підтримувати узгодження протягом кварталу

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

Механізми підтримки узгодження:

Cross-team check-in (раз на 2 тижні): 15-хвилинна зустріч тімлідів залежних команд. Фокус — статус спільних deliverables, нові блокери.

Alignment dashboard: одна сторінка, де видно OKR усіх рівнів (стратегічний → відділ → команди) та статус залежностей. OKR-фасилітатор оновлює після check-ins.

Mid-cycle alignment review (тиждень 6-7): 30-хвилинна зустріч менеджерів відділів для перевірки — чи все ще узгоджені OKR, чи з'явились нові залежності.

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

---

Шаблони та порядок денний

Шаблон: Alignment matrix

ALIGNMENT MATRIX — [Відділ] — [Квартал]

OKR ВІДДІЛУ:
  O1: ___________
    KR1.1: ___________
    KR1.2: ___________
    KR1.3: ___________
  O2: ___________
    KR2.1: ___________
    KR2.2: ___________

МАППІНГ КОМАНД → OKR ВІДДІЛУ:

|              | KR1.1 | KR1.2 | KR1.3 | KR2.1 | KR2.2 | Не узгоджені |
|---|---|---|---|---|---|---|
| Команда A    | OA-KR1 |       | OA-KR2 |       |       |              |
| Команда B    |       | OB-KR1 |       | OB-KR2 |       |              |
| Команда C    |       |       | OC-KR1 |       | OC-KR2 | OC-KR3       |
| Не покрито   |       |       |       |       |       |              |

АНАЛІЗ:
- KR відділу, не покриті жодною командою: ___
- Дублювання (2+ команд на одному KR): ___
- OKR команд, не узгоджені з відділом: ___

Шаблон: Карта залежностей

КАРТА ЗАЛЕЖНОСТЕЙ — CROSS-TEAM — [Квартал]

| # | Команда-залежна | Що потрібно | Від кого | Коли | В OKR постачальника? | Статус |
|---|---|---|---|---|---|---|
| 1 | ___ | ___ | ___ | Тиждень ___ | [ ]Так [ ]Ні | [ ]Узгоджено [ ]Ні |
| 2 | ___ | ___ | ___ | Тиждень ___ | [ ]Так [ ]Ні | [ ]Узгоджено [ ]Ні |
| 3 | ___ | ___ | ___ | Тиждень ___ | [ ]Так [ ]Ні | [ ]Узгоджено [ ]Ні |
| 4 | ___ | ___ | ___ | Тиждень ___ | [ ]Так [ ]Ні | [ ]Узгоджено [ ]Ні |
| 5 | ___ | ___ | ___ | Тиждень ___ | [ ]Так [ ]Ні | [ ]Узгоджено [ ]Ні |

НЕУЗГОДЖЕНІ ЗАЛЕЖНОСТІ (потребують обговорення):
1. ___
2. ___
3. ___

Порядок денний: Alignment session (60 хв)

ALIGNMENT SESSION — [Відділ]
Мета: перевірити вертикальне узгодження OKR команд з OKR відділу

Учасники: менеджер відділу, тімліди, OKR-фасилітатор
Підготовка: OKR відділу опубліковані, тімліди підготували драфти OKR

[0:00-0:10] OKR ВІДДІЛУ
Менеджер відділу представляє OKR та контекст.
"Ось наші цілі на квартал. O1 фокусується на ___. O2 — на ___."

[0:10-0:35] OKR КОМАНД (5 хвилин на команду)
Кожен тімлід:
- Objective + KR (2 хв)
- Зв'язок з OKR відділу: "Мій KR1 підтримує KR1.2 відділу" (1 хв)
- Ключові ризики та залежності (2 хв)

[0:35-0:50] ПЕРЕВІРКА ЗВ'ЯЗНОСТІ
Фасилітатор показує alignment matrix:
- Які KR відділу покриті?
- Чи є дублювання?
- Чи є "сироти"?
Обговорення: "KR1.3 відділу не покритий жодною командою. Хто може взяти?"

[0:50-1:00] РІШЕННЯ
- Корекції OKR команд (якщо потрібні)
- Дедлайн фіналізації
- Дата cross-team session для горизонтального узгодження

Порядок денний: Cross-team session (60 хв)

CROSS-TEAM SESSION — ГОРИЗОНТАЛЬНЕ УЗГОДЖЕННЯ

Учасники: тімліди команд з cross-functional залежностями
Фасилітатор: OKR-фасилітатор

[0:00-0:15] ОГЛЯД ЗАЛЕЖНОСТЕЙ
Фасилітатор представляє карту залежностей.
"Зеленим — узгоджені. Червоним — потребують обговорення.
У нас [N] неузгоджених залежностей."

[0:15-0:50] ОБГОВОРЕННЯ НЕУЗГОДЖЕНИХ (7-10 хв на кожну)
Для кожної:
- Тімлід-залежний: "Мені потрібно ___ від команди ___ до тижня ___"
- Тімлід-постачальник: "Це реалістично / нереалістично, тому що ___"
- Рішення: [ ] Включити в OKR  [ ] Альтернативний шлях  [ ] Ескалація

[0:50-1:00] ФІКСАЦІЯ
- Оновити карту залежностей
- Визначити формат cross-team check-in (хто, коли, як часто)
- Наступний mid-cycle alignment review: дата ___

---

Метрики

Метрика	Як вимірювати	Ціль
% OKR команд, узгоджених з OKR відділу	Узгоджені / загальна кількість OKR команд	> 70%
% KR відділу, покритих OKR команд	Покриті / загальна кількість KR відділу	> 90%
Кількість неузгоджених залежностей на початку кварталу	Лічильник	< 3 на організацію
Кількість неузгоджених залежностей на mid-cycle	Лічильник	0 (усі мають бути вирішені)
% залежностей, виконаних вчасно	Виконані до дедлайну / загальна кількість	> 80%
Кількість ескалацій через невиконані залежності	Лічильник	< 2 на квартал
Час на alignment process	Дні від початку постановки до фіналізації	< 15 робочих днів

Індикатор зрілості узгодження: відсоток залежностей, які виявляються на cross-team session (на початку кварталу), а не під час кварталу (коли вже стало блокером). Ціль: > 80% залежностей виявлені на етапі планування.

---

Типовий опір та контрзаходи

Опір 1: "Узгодження — це каскадування зверху. Ми хочемо автономію"

Чому виникає: Команди, які цінують self-organization (особливо інженерні та продуктові), сприймають узгодження як обмеження їхньої свободи визначати власні цілі.

Контрзахід: Узгодження і каскадування — різні речі. Каскадування: CEO визначає KR → VP розбиває на під-KR → тімлід отримує конкретні цілі. Узгодження: CEO визначає стратегічний Objective → команда сама визначає свій Objective та KR, які підтримують стратегію. Різниця в процесі: узгодження bottom-up (команда пропонує), каскадування top-down (керівник призначає). 20-30% OKR команди можуть бути повністю автономними — не пов'язаними зі стратегічними OKR напряму.

Опір 2: "Alignment sessions — це ще одна зустріч, яка забирає час"

Чому виникає: Команди перевантажені зустрічами. Ще одна зустріч на початку кварталу сприймається як overhead.

Контрзахід: Alignment session проводиться 1 раз на квартал (60 хвилин) та замінює десятки годин, витрачених на з'ясування залежностей під час кварталу. Порахуйте: скільки часу минулого кварталу витрачено на ситуації "ми чекаємо на команду X", "ми не знали, що команда Y працює над тим самим"? Alignment session запобігає цим ситуаціям.

Опір 3: "Ми залежимо від команди X, але вони не хочуть включати наш deliverable в свої OKR"

Чому виникає: Конфлікт пріоритетів між командами. Команда-постачальник має свої пріоритети і не бачить цінності у deliverable для команди-залежної.

Контрзахід: Ескалація на рівень менеджерів обох відділів. Формат: "Команда А потребує X від команди Б до тижня Y. Команда Б не може це пріоритизувати. Які варіанти?" Варіанти: (1) команда Б включає це в OKR як додатковий KR (з відповідним зменшенням іншого scope); (2) команда А знаходить альтернативний шлях; (3) менеджери відділів погоджують пріоритет на рівні організації. Якщо конфлікт не вирішується — ескалація до виконавчого спонсора OKR.

Опір 4: "Стратегічні OKR організації невизначені або надто абстрактні"

Чому виникає: Лідерство не визначило чітких стратегічних OKR, або сформулювало їх занадто загально ("стати кращими", "зрости"). Команди не можуть узгодитись з тим, що незрозуміле.

Контрзахід: OKR-фасилітатор ескалює цю проблему спонсору. Стратегічні OKR — передумова для узгодження. Без них узгодження неможливе. Якщо лідерство не готове визначити стратегічні OKR — команди працюють автономно (кожна визначає свої OKR без вертикального зв'язку), а узгодження обмежується горизонтальним (залежності між командами). Це не ідеально, але краще, ніж узгодження з абстрактними цілями.

Опір 5: "У нас матрична структура, люди працюють у кількох командах одночасно"

Чому виникає: В матричних організаціях одна людина може бути в продуктовій команді та в функціональному відділі одночасно. OKR якої команди має пріоритет?

Контрзахід: Правило — людина має OKR лише в одній команді, тій, де вона проводить більше 60% часу. Для решти команд вона — ресурс, а не учасник OKR. Якщо розподіл часу 50/50 — це проблема організаційного дизайну, а не OKR. Менеджери обох команд мають узгодити пріоритет. OKR допомагає виявити цю проблему, але не вирішує її — вирішує менеджмент.