Модель ескалації проблем

Навіщо потрібен протокол ескалації

OKR-процес генерує проблеми. Команда не може домовитися про Key Results. Два департаменти ставлять суперечливі OKR. Тімлід відмовляється проводити check-in. Спонсор змінює пріоритети в середині кварталу без пояснення.

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

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

Три рівні ескалації

Рівень 1. Командний рівень

Хто вирішує: Тімлід за підтримки OKR-фасилітатора.

Типи проблем:

• Команда не може сформулювати Key Results — нечіткі метрики, немає даних для вимірювання.
• Один або кілька контриб'юторів не оновлюють прогрес під час check-in.
• Команда не розуміє зв'язок своїх OKR з OKR департаменту.
• Прогрес по Key Result зупинився через технічну або організаційну перешкоду.
• Конфлікт всередині команди щодо пріоритетів.
• Тімлід не впевнений у правильності scoring.

Дії:

1. Тімлід виявляє проблему під час check-in або у щоденній роботі.
2. Тімлід намагається вирішити самостійно: проводить 1-на-1, фасилітує обговорення, пропонує альтернативи.
3. Якщо самостійно вирішити не вдається протягом 3 робочих днів — тімлід звертається до фасилітатора.
4. Фасилітатор проводить коучинг-сесію: допомагає тімліду знайти рішення, а не вирішує замість нього.
5. Рішення фіксується в інструменті (коментар у Google Sheet, нотатка в Google Sheets, повідомлення в Slack-каналі).

SLA (час на вирішення): 5 робочих днів з моменту виявлення.

Критерій ескалації на Рівень 2: Проблема не вирішена протягом 5 робочих днів. Або: проблема виходить за межі однієї команди (потрібні ресурси іншої команди, конфлікт з іншою командою).

Рівень 2. Рівень департаменту

Хто вирішує: Керівник департаменту + OKR-фасилітатор.

Типи проблем:

• Конфлікт між командами одного департаменту щодо пріоритетів або ресурсів.
• OKR двох команд суперечать одне одному.
• Тімлід систематично не виконує свою роль в OKR-процесі (не проводить check-in, не фасилітує постановку).
• Необхідність перерозподілу ресурсів між командами для досягнення OKR департаменту.
• OKR департаменту потребують рекалібрації через зміни в контексті.
• Систематичне невиконання OKR однією з команд (прогрес менше 20% на середину кварталу).

Дії:

1. Тімлід або фасилітатор формулює проблему та передає керівнику департаменту за встановленим шаблоном (див. нижче).
2. Керівник департаменту проводить зустріч з залученими сторонами протягом 3 робочих днів.
3. На зустрічі: аналіз ситуації, варіанти рішення, прийняття рішення.
4. Рішення комунікується всім зацікавленим сторонам письмово.
5. Фасилітатор фіксує рішення та відстежує його виконання.

SLA: 7 робочих днів з моменту ескалації.

Критерій ескалації на Рівень 3: Проблема потребує рішення на рівні кількох департаментів. Або: керівник департаменту не може прийняти рішення без санкції вищого керівництва. Або: рішення вимагає зміни стратегічних OKR.

Рівень 3. Рівень керівництва

Хто вирішує: Виконавчий спонсор за підтримки OKR-фасилітатора.

Типи проблем:

• Конфлікт між департаментами щодо стратегічних пріоритетів.
• Необхідність зміни стратегічних OKR організації.
• Системна проблема з OKR-процесом, яка вимагає перегляду підходу (наприклад, масова відмова команд від OKR).
• Спонсор або інший топ-менеджер блокує процес своїми діями (або бездіяльністю).
• Потреба у додатковому бюджеті або ресурсах для OKR-ініціативи.
• Рішення про припинення OKR в одному або кількох департаментах.

Дії:

1. Керівник департаменту або фасилітатор формулює проблему та передає спонсору за шаблоном.
2. Спонсор призначає зустріч з залученими сторонами протягом 5 робочих днів.
3. Фасилітатор готує аналіз ситуації: факти, вплив, варіанти рішення з оцінкою наслідків.
4. Спонсор приймає рішення.
5. Рішення комунікується через формальний канал (all-hands, email від спонсора, оновлення в OKR-інструменті).

SLA: 10 робочих днів з моменту ескалації.

Зведена таблиця рівнів ескалації

Параметр	Рівень 1 (Команда)	Рівень 2 (Департамент)	Рівень 3 (Керівництво)
Хто вирішує	Тімлід + Фасилітатор	Керівник департаменту + Фасилітатор	Спонсор + Фасилітатор
Масштаб	Одна команда	Один департамент	Організація
SLA	5 робочих днів	7 робочих днів	10 робочих днів
Формат комунікації	Slack / усно	Письмово + зустріч	Формальний канал
Приклади	Нечіткі KR, відсутній check-in	Конфлікт команд, рекалібрація	Зміна стратегічних OKR

Дерево прийняття рішення про ескалацію

Коли виникає проблема, пройдіть по цьому алгоритму:

Крок 1. Чи стосується проблема тільки однієї команди?

• Так → Рівень 1. Тімлід вирішує за підтримки фасилітатора.
• Ні → перейти до Кроку 2.

Крок 2. Чи можна вирішити проблему на рівні одного департаменту?

• Так → Рівень 2. Керівник департаменту вирішує.
• Ні → перейти до Кроку 3.

Крок 3. Чи потрібне рішення на рівні організації або зміна стратегічних OKR?

• Так → Рівень 3. Спонсор вирішує.
• Ні → поверніться до Кроку 1 і переформулюйте проблему.

Додатковий тригер: Якщо SLA поточного рівня вичерпано і рішення не прийнято — автоматична ескалація на наступний рівень.

Шаблони повідомлень для ескалації

Шаблон для Рівня 1 → Рівень 2

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

Тема: [OKR Ескалація] {Назва команди} — {Короткий опис проблеми}

Команда: {Назва команди}
Дата виявлення: {Дата}
OKR, якого стосується: {Objective / Key Result}

Суть проблеми:
{2-3 речення, що конкретно не працює}

Що вже спробували:
1. {Дія 1 — результат}
2. {Дія 2 — результат}
3. {Дія 3 — результат}

Чому потрібна допомога:
{Чому проблема виходить за межі повноважень тімліда}

Пропоноване рішення (якщо є):
{Що, на вашу думку, треба зробити}

Необхідне рішення від керівника департаменту:
{Конкретне рішення або дія, яку очікуєте}

Приклад заповнення:

Тема: [OKR Ескалація] Команда "Платформа" — конфлікт ресурсів з командою "Мобайл"

Команда: Платформа
Дата виявлення: 2026-02-10
OKR: KR "З 200 до 500 мс середній час відповіді API"

Суть проблеми:
Для досягнення KR потрібен DevOps-інженер на 2 тижні для
оптимізації інфраструктури. Єдиний доступний DevOps зайнятий
задачами команди "Мобайл", яка також має критичний KR.

Що вже спробували:
1. Обговорили з тімлідом "Мобайл" — не можуть звільнити ресурс.
2. Консультація з фасилітатором — підтвердив, що потрібне рішення
   керівника.
3. Оцінили альтернативи — без DevOps KR недосяжний.

Чому потрібна допомога:
Рішення про розподіл спільного ресурсу між командами виходить
за повноваження тімлідів.

Пропоноване рішення:
Виділити DevOps на 1 тиждень кожній команді (тижні 8 і 9).

Необхідне рішення:
Пріоритизація: яка команда отримує DevOps першою.

Шаблон для Рівня 2 → Рівень 3

Цей шаблон використовує керівник департаменту або фасилітатор для ескалації на рівень спонсора.

Тема: [OKR Ескалація — Рівень 3] {Короткий опис проблеми}

Ініціатор: {Ім'я, роль}
Департамент(и): {Задіяні департаменти}
Дата першого виявлення: {Дата}
Дата ескалації на Рівень 2: {Дата}
Дата ескалації на Рівень 3: {Дата}

OKR, яких стосується:
- {Стратегічний OKR 1}
- {OKR департаменту 1}

Суть проблеми:
{3-5 речень з фактами}

Хронологія:
- {Дата}: {Що сталося}
- {Дата}: {Яке рішення прийнято на Рівні 2}
- {Дата}: {Чому рішення Рівня 2 недостатнє}

Вплив:
- На OKR: {Які OKR під загрозою, прогнозований scoring}
- На команди: {Кількість людей, мотивація, ризики}
- На строки: {Які дедлайни порушуються}

Варіанти рішення:
А) {Варіант 1}
   Плюси: {…}
   Мінуси: {…}

Б) {Варіант 2}
   Плюси: {…}
   Мінуси: {…}

Рекомендація: {Варіант A або Б, з обґрунтуванням}

Необхідне рішення від спонсора:
{Конкретне рішення або набір рішень}

Дедлайн для рішення: {Дата, після якої ситуація стане критичною}

Спеціальні ситуації

Ситуація: Тімлід відмовляється від OKR

Тімлід відкрито або пасивно відмовляється вести OKR-процес у команді: не проводить check-in, не фасилітує постановку, саботує scoring.

Протокол:

1. Фасилітатор проводить 1-на-1 з тімлідом. Мета — зрозуміти причину: перевантаження, непорозуміння методології, незгода з підходом.
2. Якщо причина — перевантаження, фасилітатор допомагає оптимізувати процес або тимчасово бере на себе частину функцій.
3. Якщо причина — незгода, фасилітатор ескалює на керівника департаменту (Рівень 2).
4. Керівник департаменту проводить розмову з тімлідом: пояснює очікування, слухає заперечення, домовляється про план дій.
5. Якщо тімлід продовжує відмовлятися — рішення про заміну відповідального за OKR у цій команді.

SLA: 10 робочих днів від першої розмови фасилітатора до фінального рішення.

Ситуація: Спонсор змінює пріоритети в середині кварталу

Спонсор оголошує нові пріоритети або проєкти, які конфліктують з поточними OKR.

Протокол:

1. Фасилітатор ініціює зустріч зі спонсором протягом 2 робочих днів.
2. На зустрічі фасилітатор представляє вплив зміни на поточні OKR: які OKR потрібно змінити, які команди це зачепить.
3. Якщо спонсор підтверджує зміну — формальний процес рекалібрації: оновлення стратегічних OKR, каскадування змін на рівень департаментів та команд.
4. Комунікація змін через формальний канал з поясненням причин.

SLA: 5 робочих днів від оголошення змін до завершення рекалібрації.

Ситуація: Систематично низький scoring по всій організації

Три або більше команди мають середній scoring нижче 0.3 протягом кварталу.

Протокол:

1. Фасилітатор аналізує причини: занадто амбіційні OKR, зміна контексту, проблеми з виконанням, невірний scoring.
2. Фасилітатор готує звіт для спонсора з аналізом та рекомендаціями.
3. Спонсор скликає зустріч з керівниками департаментів.
4. Рішення: коригування калібрації амбіційності, перегляд процесу постановки, додаткове навчання.

SLA: 10 робочих днів після завершення scoring.

Ситуація: Міждепартаментний конфлікт

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

Протокол:

1. Керівники департаментів намагаються домовитися на двосторонній зустрічі (Рівень 2).
2. Фасилітатор фасилітує зустріч, якщо потрібно.
3. Якщо домовитися не вдалося протягом 5 робочих днів — ескалація на спонсора (Рівень 3).
4. Спонсор приймає рішення, яке стає обов'язковим для обох сторін.

SLA: 5 робочих днів на Рівні 2 + 5 робочих днів на Рівні 3 (максимум).

Впровадження протоколу ескалації

Крок 1. Адаптуйте шаблони

Візьміть шаблони з цієї статті та адаптуйте під свою організацію: додайте назви реальних інструментів, каналів комунікації, контактних осіб.

Крок 2. Погодьте SLA

Обговоріть запропоновані SLA зі спонсором та керівниками департаментів. SLA мають бути реалістичними для вашої організації. Якщо 5 робочих днів на Рівні 1 — занадто мало, збільште до 7. Головне — зафіксувати конкретні числа.

Крок 3. Опублікуйте

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

Крок 4. Навчіть тімлідів

Тімліди — перша лінія ескалації. Вони мають знати: коли ескалювати, як заповнити шаблон, кому адресувати.

Крок 5. Відстежуйте використання

Щоквартально перевіряйте: скільки ескалацій було, на якому рівні, за який час вирішені. Якщо ескалацій нуль — або все ідеально (малоймовірно), або люди не знають про протокол. Якщо всі ескалації йдуть одразу на Рівень 3 — Рівні 1 і 2 не працюють.

Антипатерни

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

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

"SLA ніхто не дотримується." Проблеми ескалюються, але рішення не приймаються вчасно. Фасилітатор нагадує про дедлайни і публічно відстежує статус ескалацій.

"Рішення без комунікації." Проблема вирішена, але ніхто не знає як і чому. Кожна ескалація має зафіксований результат, який комунікується всім зацікавленим сторонам.