Щотижневий дашборд для керівника
Шаблон дашборду для відстеження прогресу OKR на рівні керівництва
Призначення
Дашборд для керівника — це зведений звіт про стан OKR в організації, який оновлюється щотижня. Він дає керівнику повну картину за 3-5 хвилин читання: скільки OKR в нормі, де проблеми, хто потребує уваги.
Коли використовувати:
- Щотижнево — як основний інструмент керівника для моніторингу OKR.
- На нарадах керівництва — як стартова точка для обговорення пріоритетів.
- При підготовці до квартальної ретроспективи — як історичні дані для аналізу.
- При ескалації проблем — як об'єктивна основа для рішень про перерозподіл ресурсів.
- Для комунікації стану OKR виконавчому спонсору або раді директорів.
Дашборд не замінює check-in зустрічі з командами. Дашборд показує "де проблема", check-in з'ясовує "чому проблема і що робити". Без дашборду керівник реагує на найгучніше, а не на найважливіше. Без check-in — бачить числа, але не розуміє контекст.
Оновлення дашборду відбувається після завершення всіх командних check-in на тижні. Чемпіон збирає дані з команд та заповнює шаблон. Керівник переглядає дашборд та приймає рішення.
Шаблон
Блок 1. Зведена інформація
| Показник | Значення |
|---|---|
| Звітний період | Тиждень __ з 12 (Q__ 20__) |
| Дата оновлення | ..20__ |
| Підготував | ___________________ |
| Загальна кількість OKR (objectives) | ___ |
| Загальна кількість KR | ___ |
| On track (впевненість >= 0.5) | ___% |
| At risk (впевненість 0.3-0.4) | ___% |
| Off track (впевненість <= 0.2) | ___% |
| Completed (впевненість 1.0) | ___% |
Блок 2. Прогрес по командах
| Команда | Objective | Кількість KR | Середня впевненість | Тренд vs минулий тиждень | Кількість блокерів |
|---|---|---|---|---|---|
| _______________ | _______________ | ___ | . | ↑/↓/→ | ___ |
| _______________ | _______________ | ___ | . | ↑/↓/→ | ___ |
| _______________ | _______________ | ___ | . | ↑/↓/→ | ___ |
| _______________ | _______________ | ___ | . | ↑/↓/→ | ___ |
| _______________ | _______________ | ___ | . | ↑/↓/→ | ___ |
| _______________ | _______________ | ___ | . | ↑/↓/→ | ___ |
Блок 3. OKR, що потребують уваги
Перелік усіх KR з впевненістю 0.3 або нижче.
| Команда | KR | Впевненість | Тижнів у зоні ризику | Причина | Запропоноване рішення |
|---|---|---|---|---|---|
| _______________ | _______________ | . | ___ | _______________ | _______________ |
| _______________ | _______________ | . | ___ | _______________ | _______________ |
| _______________ | _______________ | . | ___ | _______________ | _______________ |
Блок 4. Завершені OKR та досягнення
| Команда | KR | Досягнуто | Коментар |
|---|---|---|---|
| _______________ | _______________ | Тиждень ___ | _______________ |
Блок 5. Рішення та action items керівництва
| Рішення/Дія | Відповідальний | Дедлайн | Статус |
|---|---|---|---|
| ___________________ | _______________ | ..__ | Новий / В роботі / Завершений |
| ___________________ | _______________ | ..__ | Новий / В роботі / Завершений |
| ___________________ | _______________ | ..__ | Новий / В роботі / Завершений |
Блок 6. Action items з минулого тижня
| Рішення/Дія | Відповідальний | Дедлайн | Статус | Результат |
|---|---|---|---|---|
| ___________________ | _______________ | ..__ | _______________ | _______________ |
| ___________________ | _______________ | ..__ | _______________ | _______________ |
Процес збору даних
| Крок | Хто | Коли | Що робить |
|---|---|---|---|
| 1 | Команди | Понеділок-вівторок | Проводять check-in, оновлюють впевненість по KR |
| 2 | OKR Чемпіон | Середа ранок | Збирає дані з усіх команд, заповнює дашборд |
| 3 | OKR Чемпіон | Середа до обіду | Надсилає дашборд керівнику |
| 4 | Керівник | Середа | Переглядає дашборд, фіксує питання |
| 5 | Керівник + Чемпіон | Четвер (за потреби) | Обговорюють OKR із зони ризику, приймають рішення |
| 6 | Чемпіон | П'ятниця | Комунікує рішення командам |
Заповнений приклад
Блок 1. Зведена інформація
| Показник | Значення |
|---|---|
| Звітний період | Тиждень 7 з 12 (Q2 2026) |
| Дата оновлення | 14.05.2026 |
| Підготував | OKR Чемпіон |
| Загальна кількість OKR (objectives) | 5 |
| Загальна кількість KR | 16 |
| On track (впевненість >= 0.5) | 62% (10 KR) |
| At risk (впевненість 0.3-0.4) | 25% (4 KR) |
| Off track (впевненість <= 0.2) | 6% (1 KR) |
| Completed (впевненість 1.0) | 6% (1 KR) |
Блок 2. Прогрес по командах
| Команда | Objective | Кількість KR | Середня впевненість | Тренд | Кількість блокерів |
|---|---|---|---|---|---|
| Product | Створити досвід першого використання для нових учнів | 3 | 0.5 | → | 1 |
| Marketing | Побудувати впізнаваність бренду серед української аудиторії | 4 | 0.6 | ↑ | 0 |
| Engineering | Забезпечити стабільну та швидку платформу | 3 | 0.4 | ↓ | 2 |
| Sales | Збільшити дохід від B2B-сегменту | 3 | 0.5 | ↑ | 0 |
| Customer Success | Підвищити задоволеність та утримання клієнтів | 3 | 0.3 | ↓ | 1 |
Блок 3. OKR, що потребують уваги
| Команда | KR | Впевненість | Тижнів у зоні ризику | Причина | Запропоноване рішення |
|---|---|---|---|---|---|
| Engineering | З 2.1с до 0.8с час завантаження головної сторінки | 0.2 | 3 | Міграція на нову CDN зайняла вдвічі більше часу. Технічний борг блокує оптимізацію. | Виділити 2 розробників на повний тиждень. Розглянути зменшення scope: спочатку 1.2с, потім 0.8с у Q3. |
| Engineering | З 45 до 15 критичних багів у продакшені | 0.4 | 1 | Новий реліз додав 8 нових багів. Зараз 38 замість очікуваних 25. | Провести bug bash наступного тижня. Зменшити обсяг нових фіч до стабілізації. |
| Customer Success | З 62 до 80 NPS серед платних клієнтів | 0.3 | 2 | NPS знизився до 58 через проблеми зі стабільністю платформи (залежність від Engineering). | Каскадна проблема. Вирішується разом з Engineering. Паралельно — збільшити проактивні контакти з топ-20 клієнтів. |
| Customer Success | З 8% до 3% monthly churn | 0.4 | 1 | Churn зріс до 9.2% після підвищення цін. Три великих клієнти повідомили про розгляд альтернатив. | Підготувати retention-пропозиції для клієнтів at risk. Провести exit-інтерв'ю з тими, хто пішов. |
| Product | З 18% до 40% retention Day 7 | 0.3 | 2 | Push-нотифікації дали недостатній ефект. Потрібна персоналізація, але відсутній backend-ресурс. | Виділити backend-розробника з Engineering на 1 спринт. |
Блок 4. Завершені OKR та досягнення
| Команда | KR | Досягнуто | Коментар |
|---|---|---|---|
| Marketing | З 2 000 до 10 000 підписників email-розсилки | Тиждень 6 | Вірусний контент в LinkedIn перевищив очікування. Фактичний результат: 12 400. |
Блок 5. Рішення та action items керівництва
| Рішення/Дія | Відповідальний | Дедлайн | Статус |
|---|---|---|---|
| Виділити 2 розробників на оптимізацію швидкості на повний тиждень 8 | CTO | 19.05 | Новий |
| Провести bug bash у тиждень 8 | Engineering Lead | 23.05 | Новий |
| Підготувати retention-пропозиції для 3 клієнтів at risk | Head of CS | 16.05 | Новий |
| Переглянути target KR "час завантаження" — чи реалістичний 0.8с до кінця Q2 | CTO + Чемпіон | 16.05 | Новий |
Блок 6. Action items з минулого тижня
| Рішення/Дія | Відповідальний | Дедлайн | Статус | Результат |
|---|---|---|---|---|
| Узгодити бюджет на нову CDN | CTO | 09.05 | Завершений | Бюджет затверджено, міграція розпочата |
| Провести аналіз причин зростання churn | Head of CS | 12.05 | Завершений | Основна причина — підвищення цін. Звіт надіслано. |
| Організувати зустріч Product + Engineering щодо backend-ресурсу | OKR Чемпіон | 12.05 | В роботі | Зустріч перенесена на 15.05 через хворобу EM |
Типові помилки
1. Дашборд без дій
Керівник переглядає дашборд, каже "зрозуміло" і не приймає рішень. Дашборд без Блоку 5 (рішення та action items) — це декорація. Кожна "червона" зона має призводити до конкретного рішення: перерозподіл ресурсів, зміна пріоритетів, ескалація, або свідоме прийняття ризику.
2. Збір даних як тиждень роботи
Чемпіон витрачає 2-3 дні на збір даних з команд: писати в Slack, нагадувати, чекати відповідей. Рішення: визначити фіксований дедлайн для оновлення впевненості (вівторок 18:00), після якого Чемпіон збирає дані автоматично з системи. Команди, які не оновили — отримують впевненість "N/A" у дашборді, що видно керівнику.
3. Середня впевненість як єдина метрика
Команда має 3 KR: 0.8, 0.8, 0.1. Середня — 0.57, виглядає як "on track". Але один KR повністю провалений. Завжди додавайте Блок 3 з деталізацією проблемних KR. Середнє значення маскує проблеми. Правило: якщо хоча б один KR нижче 0.3 — команда потребує уваги, незалежно від середнього.
4. Тренд без контексту
Стрілка ↓ без пояснення. Впевненість знизилася з 0.6 до 0.4 — але чому? Без колонки "Причина" та "Запропоноване рішення" в Блоку 3 дашборд генерує тривогу без можливості діяти. Чемпіон має заповнювати причину на основі check-in з командою.
5. Ігнорування action items з минулого тижня
Нові action items додаються, але статус попередніх не перевіряється. Це руйнує довіру до процесу. Блок 6 існує саме для цього: кожен тиждень переглядаємо статус рішень минулого тижня. Якщо рішення не виконане — або перенести з новим дедлайном, або ескалювати.
6. Дашборд як інструмент контролю замість підтримки
Керівник використовує дашборд для "виклику на килим" команд з низькою впевненістю. Це миттєво знищує культуру прозорості — команди почнуть завищувати впевненість. Дашборд — це інструмент підтримки. Питання керівника має бути "що вам потрібно?", а не "чому ви відстаєте?".
7. Оновлення рідше ніж щотижня
Дашборд оновлюється раз на місяць або "коли є час". При квартальному циклі (12 тижнів) оновлення раз на місяць означає лише 3 точки даних. Цього недостатньо для виявлення тренду. Щотижневе оновлення — мінімальна частота. Якщо немає ресурсу — спростіть формат, але збережіть каденцію.