применение методологии Objectives & Key Results в команде, которая работает с инцидентами, ведёт CI/CD и хочет строить платформу
OKR — система постановки и отслеживания целей, созданная Энди Гроувом (Intel) и популяризованная Джоном Дорром (Google, книга «Measure What Matters», 2018). Не теория — рабочий инструмент: Google использует с 1999 года, LinkedIn, Twitter, Uber, и тысячи других компаний.
Амбициозное, вдохновляющее направление. Качественное. Даёт ответ на вопрос «Куда?». Должно вызывать лёгкий дискомфорт — если комфортно, недостаточно амбициозно.
Измеримый milestone. Только числа: не «улучшить», а «снизить с X до Y». 3–5 KR на один O. По каждому — прогресс 0%→100%.
KR команды верхнего уровня становятся Objective команды ниже. Цепочка от CEO → Department → Team → Individual.
Квартальный цикл — стандарт. Ежегодные OKR задают горизонт. Еженедельные check-in — пульс. Без ритма OKR превращаются в документ, который никто не читает.
По данным Google и наблюдениям Дорра: организации нужно 4–5 квартальных циклов чтобы полноценно освоить систему. Первый квартал — почти всегда неудача по процессу. Это нормально. Главное — провести ретроспективу и улучшить следующий цикл.
IT-команда, которая одновременно ведёт поддержку 24/7, CI/CD, инфраструктуру и хочет трансформироваться в Platform/AI Engineering — это три разных режима работы с принципиально разными горизонтами планирования и типами работы.
Инциденты, алерты, тикеты. Горизонт — часы. Нельзя планировать. Прерывает всё остальное. Легко поглощает 60–80% времени команды.
Деплои, релизы, мониторинг, on-call ротации. Горизонт — недели. Предсказуем, но не создаёт ценность сам по себе.
IDP, AI-агенты, платформенные продукты. Горизонт — кварталы/годы. Требует protected time. Без него трансформация не случится никогда.
Если команда поддержки с дежурствами ставит себе aspirational OKR «как стартап» — они не выполнятся никогда: инциденты съедят время. Но если ставить только операционные OKR — трансформации не будет.
// Блок 1: Распределение времени (измерить факт за последний квартал) □ Сколько % времени команды уходит на инциденты и тикеты? □ Сколько % — на плановые операции (деплои, on-call, maint)? □ Сколько % — на проектную/трансформационную работу? □ Цель: 50% reactive / 30% operational / 20% transformational □ (Реальность большинства команд: 70% / 25% / 5%) // Блок 2: Текущие метрики надёжности □ MTTR (Mean Time To Recovery) последние 3 месяца □ Количество инцидентов P1/P2 в месяц □ Deployment frequency (как часто деплоим) □ Change failure rate (% деплоев вызвавших инцидент) □ SLA выполнение по каждому сервису // Блок 3: Зрелость процессов □ Есть ли IaC (Terraform/Pulumi) покрытие > 80%? □ CI pipeline покрытие > 90% проектов? □ Есть ли Internal Developer Portal? □ Есть ли платформенный roadmap? // Блок 4: Вектор трансформации □ Что значит "платформенная команда" для вашего контекста? □ Какие AI-инструменты уже используются? □ Кто внутренние "клиенты" платформы? □ Каков бизнес-результат, который должна дать трансформация?
OKR — не интуиция. Есть конкретные правила написания хороших Objectives и Key Results. Нарушение любого из них даёт «мёртвые OKR» — документы, которые создаются и забываются.
| Критерий | Плохо ❌ | Хорошо ✓ |
|---|---|---|
| Качественный | «Улучшить производительность CI/CD» | «Стать командой, которой разработчики доверяют деплоить без страха» |
| Вдохновляющий | «Поддерживать 99.9% uptime» | «Сделать платформу, которую хотят использовать, а не обязаны» |
| Без цифр | «Снизить MTTR до 30 минут» | «Восстанавливаться после инцидентов быстрее, чем пользователи замечают» |
| Команда контролирует | «Запустить 3 новых сервиса к Q3» | «Создать надёжную основу для запуска любых новых сервисов» |
| Амбициозный | «Продолжать поддерживать текущие сервисы» | «Перейти от реактивной поддержки к проактивному предотвращению» |
| Критерий | Плохо ❌ | Хорошо ✓ |
|---|---|---|
| Измеримый результат, не задача | «Внедрить Prometheus + Grafana» | «Среднее время обнаружения инцидента (MTTD) снижено с 45 мин до 10 мин» |
| Начало и конец известны | «Повысить покрытие тестами» | «Покрытие unit-тестами с 42% до 70%» |
| Проверяемый бинарно | «Улучшить процессы on-call» | «Burn rate on-call нагрузки: среднее число алертов/ночь с 8 до 2» |
| 3–5 на Objective | 8 KR на один O | 3–4 KR, каждый необходим и достаточен |
| Баланс кол-во/качество | KR только на скорость деплоев | KR на скорость + KR на стабильность (change failure rate) |
# Уровень 1: Компания (получаете от бизнеса) company_okr: objective: "Удвоить скорость вывода фич на рынок в 2026 году" key_results: - "Time-to-market новой фичи: с 6 недель до 3 недель" - "Доля инцидентов в проде из-за деплоев: с 12% до 4%" # Уровень 2: IT-департамент (ваш уровень) dept_okr: objective: "Стать платформой, которая ускоряет разработку, а не тормозит" key_results: - "Deployment frequency: с 2/неделя до 5/день" # ← align с company KR1 - "Change failure rate: с 12% до <3%" # ← align с company KR2 - "MTTR P1-инцидентов: с 4ч до <45 мин" # Уровень 3: Команды внутри IT team_platform_okr: objective: "Дать разработчикам self-service деплой без тикетов" key_results: # ← align с dept KR1 - "Self-service deployments: 0% → 60% всех деплоев" - "Среднее время на деплой: с 3ч до 15 мин" - "NPS разработчиков по платформе: <20 → >50" team_support_okr: objective: "Перейти от тушения пожаров к их предотвращению" key_results: # ← align с dept KR3 - "P1 инциденты в месяц: с 8 до <3" - "% инцидентов обнаруженных мониторингом (не пользователем): 40% → 85%" - "Runbook покрытие топ-20 типов инцидентов: 0% → 100%"
OKR без операционного ритма — просто слайд в Confluence. Ритм — это конкретные встречи в конкретные недели с конкретными артефактами. Вот как это выглядит для IT-команды.
Конкретные примеры по четырём направлениям: надёжность и поддержка, CI/CD и DevOps, Platform Engineering, и AI/трансформация. Можно адаптировать под свой baseline.
DORA (DevOps Research & Assessment) — исследовательская программа Google, запущенная в 2014. Определила 4 метрики, которые предсказывают бизнес-результаты IT-команды. По данным DORA 2025: только 16% команд достигают on-demand deployment, 43.5% имеют lead time больше недели.
| Метрика | Что измеряет | Low (нижний) | Medium | High | Elite |
|---|---|---|---|---|---|
| Deployment Frequency | Как часто деплоим в прод | Раз в месяц и реже |
Раз в неделю–месяц |
Раз в день–неделю |
Несколько раз в день |
| Lead Time for Changes | Commit → Production | >6 месяцев |
1 неделя–1 месяц |
1 день–1 неделя |
<1 часа |
| Change Failure Rate | % деплоев вызвавших инцидент | 46–60% |
16–30% |
16–30% |
0–15% |
| MTTR / Failed Deploy Recovery | Время восстановления после отказа | >6 месяцев |
1 день–1 неделя |
<1 дня |
<1 часа |
| Reliability (5-я метрика, DORA 2021+) | Выполнение SLO/SLA целей | Нет чёткой шкалы — измеряется как % выполнения заявленных SLO | |||
// Шаг 1: Измерить текущий уровень (Low/Medium/High/Elite) по каждой метрике // Шаг 2: Сформулировать KR как переход на следующий уровень // Пример: команда сейчас на уровне Low по Deployment Frequency Плохой KR: "Улучшить частоту деплоев" Хороший KR: "Deployment frequency: с 1/месяц (Low) до 1/неделю (Medium) к Q3" Амбициозный KR: "Deployment frequency: с 1/месяц до ежедневного (High) к Q3" // Пример: MTTR Текущее: "4 часа (Medium)" KR: "MTTR: с 4 часов до <1 часа (Elite) к концу квартала" // Важно: DORA — не единственные метрики. Добавьте: - Developer Experience (DevEx) / NPS платформы - On-call burden (алерты/ночь, % wakeable incidents) - Toil percentage (% времени на неавтоматизированную рутину) - Platform adoption rate (% команд использующих IDP)
Главный практический паттерн для вашей ситуации. Команда, которая не разделяет эти треки явно, будет вечно «срывать» трансформационные OKR — инциденты всегда победят в битве за время.
Операционная надёжность. Обязательны. 100% = норма.
Трансформация. Амбициозные. 70% = успех.
Google SRE ввёл понятие «toil» — ручная, повторяющаяся, автоматизируемая работа. Цель: toil должен занимать <50% рабочего времени команды. Каждый % снижения toil — это время, которое освобождается для Aspirational трека.
# Шаг 1: Аудит toil (1–2 недели) measurement: method: "Каждый инженер логирует тип работы: toil vs project work" duration: "2 недели" categories: - "Manual deployment steps" - "Repetitive monitoring checks" - "Ticket handling (FAQ type)" - "Manual test execution" - "Access provisioning" # Шаг 2: Toil OKR objective: "Освободить инженерное время от работы, которую должны делать машины" key_results: - "Toil % времени команды: с [измеренный baseline]% до <30%" - "Top-5 toil-источников автоматизированы: 0 → 5" - "Время сохранённое автоматизацией: >X часов/неделю" # Шаг 3: Приоритизация что автоматизировать первым formula: frequency × time_per_occurrence × team_members_involved # → топ-5 по этой формуле автоматизируете в первую очередь
OKR-процесс требует конкретных встреч. Не добавляйте их поверх существующих ритуалов — интегрируйте в них. Ниже — минимальный набор для работающей системы.
| Встреча | Частота | Длительность | Участники | Артефакт | Цель |
|---|---|---|---|---|---|
| OKR Weekly Check-in | Еженедельно | 15–20 мин | Вся команда | Обновление % и статуса в OKR-тулзе | Пульс. Видим тренды, снимаем блокеры |
| 1-on-1 с owner'ами KR | Еженедельно | 30 мин | Руководитель + инженер | Заметки, action items | Coaching, поддержка, раннее выявление рисков |
| Incident Review | После каждого P1/P2 | 45–60 мин | Вся команда + стейкхолдеры | Postmortem, action items → KR | Обучение системы, не поиск виноватых |
| Mid-Quarter OKR Review | Ежеквартально (6–7 нед) | 1–1.5 ч | Команда + руководитель | Скорректированные OKR | Pivot или удвоить усилия по KR |
| Platform Demo | Раз в 2 недели | 30 мин | Команда + внутренние клиенты | Feedback лист | Показать прогресс IDP, собрать обратную связь |
| OKR Grading + Retro | Конец квартала | 2 ч | Вся команда | OKR Score Report, входные данные Q+1 | Обучение цикла, улучшение следующего |
| OKR Setting Session | За 2 нед до квартала | 2–3 ч | Вся команда | Финальные OKR следующего квартала | Bottom-up написание O и KR |
// Структура (строго 15–20 минут) [0:00–2:00] Контекст недели: есть ли изменения приоритетов? инциденты? [2:00–12:00] Обход по KR (1–2 минуты на каждый): - Текущий % прогресса - Статус: 🟢 On Track / 🟡 At Risk / 🔴 Off Track - Один главный blocker (если есть) [12:00–17:00] Блокеры: - Только те, которые требуют помощи руководителя - "Что мне нужно от тебя, чтобы разблокироваться?" [17:00–20:00] Шефство: - Нет ли KR, от которого нужно отказаться/скорректировать? - Action items с ответственным и дедлайном // Чего НЕ делать на Check-in: // ✗ Детальный разбор задач (для этого есть standup) // ✗ Решение проблем на встрече (офлайн, после) // ✗ Отчёт руководителю (это разговор команды) // ✗ Перенос Check-in "потому что инцидент" (критично не пропускать)
По данным OKR Benchmark Report 2026 (550 организаций): большинство провалов OKR не технические — они процессные. Вот самые распространённые ошибки и как их избежать.
KR: «Внедрить Grafana», «Провести тренинг», «Написать runbook'и» — это задачи, не результаты. Признак: KR можно «сделать», не достигнув результата. Правило: если KR начинается с глагола-действия (внедрить, написать, настроить) — это задача. Переформулируй как измеримый outcome.
Команды пишут 8–12 Objectives с 4–5 KR каждый = 40–60 метрик на квартал. Это не OKR — это spreadsheet. Лимит Дорра: 3–5 Objectives, 3–4 KR каждый. Если всё важно — ничего не важно. Принцип Google: «Set fewer, bolder goals».
«Поддерживать 99.9% uptime» — не OKR если это обязательный SLA. BAU (Business As Usual) — то, что команда должна делать в любом случае. OKR — то, что изменит состояние к концу квартала. Поддержка 24/7 — BAU, её нужно обеспечить. Снизить MTTR с 4ч до 45 мин — OKR.
По данным OKR Benchmark Report 2026: команды с еженедельным check-in выполняют OKR на 42% лучше, чем команды без регулярного ритма. Квартальный обзор без еженедельных check-in — не OKR-система, это отчётность.
Это уничтожает амбицию: люди будут ставить «безопасные» цели, которые гарантированно выполнятся. Google, Intel, LinkedIn — все ключевые OKR-компании явно разделяют OKR и перфоманс-ревью. OKR оценивают систему и направление, а не людей.
По данным Weekdone (2025): 59% организаций с bottom-up OKR имеют прямое влияние OKR на бизнес-результаты. Если руководитель единолично пишет OKR — у команды нет ownership. Рекомендация: руководитель формулирует Objectives, команда пишет Key Results.
Команда запланировала 30% времени на трансформацию. В реальности 60% съел support. OKR провалились. Не потому что команда плохая — потому что не было буфера на непредвиденное. Правило: закладывайте реальный исторический процент прерываний + 20% буфер. Не «хотим» — «факт прошлого квартала».
«Снизить MTTR» — измерить нельзя если не знаешь текущий MTTR. Перед написанием KR должен быть измеренный baseline. Если данных нет — первый KR в квартале: «Установить измерение X и зафиксировать baseline». Это легитимный и важный KR.
Инструмент важен, но не критичен для первых 1–2 циклов. Начните с самого простого — главное создать ритм. Потом мигрируйте на специализированную платформу.
| Уровень зрелости | Инструмент | Плюсы | Минусы |
|---|---|---|---|
| Старт (Q1–Q2) | Confluence + таблица / Notion | Уже есть, нет доп. затрат, низкий порог входа | Нет автотрекинга, легко забыть обновить |
| Зрелый (Q3+) | Tability / Weekdone / Perdoo | Специализированные, check-in ремайндеры, прогресс-трекинг, API | Стоимость, нужно внедрять |
| Enterprise | Betterworks / Profit.co / Lattice | Интеграция с HR, 1-on-1, performance management | Дорого, сложно, риск привязки OKR к ревью |
| DevOps-нативный | GitLab / Jira + OKR plugin + Grafana | Автоматическая привязка задач к KR, метрики из пайплайна | Требует настройки, высокая сложность |
# OKR Q[X] 2026 — [Название команды] # Составлен: [дата] | Owner: [имя руководителя] # Статус: 🟢 On Track / 🟡 At Risk / 🔴 Off Track --- ## O1: [Название Objective] 🟢 # Тип: Committed | Owner: [имя] # "Мы ________, что будет измеряться..." ### KR1.1: [Метрика] с [baseline] до [target] к [дата] - Текущее значение: [X] - Прогресс: [X]% | Confidence: 🟢 - Owner: [имя] - Последнее обновление: [дата] ### KR1.2: [Метрика] с [baseline] до [target] - Текущее значение: [X] - Прогресс: [X]% | Confidence: 🟡 - Owner: [имя] - Blocker: [описание если есть] --- ## O2: [Название Objective] 🟡 # Тип: Aspirational (70% = успех) | Owner: [имя] ### KR2.1: ... --- ## Еженедельный прогресс (заполняется каждую неделю) | Неделя | KR1.1 | KR1.2 | KR2.1 | Главный блокер | |--------|-------|-------|-------|----------------| | W1 | 10% | 5% | 0% | нет baseline | | W2 | 20% | 15% | 10% | ... |
Измерьте текущие DORA-метрики. Посчитайте реальное распределение времени команды. Зафиксируйте количество инцидентов/месяц, текущий MTTR, deployment frequency. Это ваши исходные точки для KR. Без этого нельзя писать OKR.
Согласуйте с бизнесом 2–3 ключевых направления на квартал. Ответьте на вопрос: что должно измениться в команде к концу квартала, чтобы бизнес заметил? Не «что мы сделаем», а «каким будет результат?».
Поделитесь черновыми Objectives. Попросите команду самостоятельно написать KR к каждому O в группах. Обсудите, отфильтруйте до 3–4 KR на O. Проверьте: есть baseline? KR измерим? Команда верит в достижимость? Зафиксируйте owners.
Опубликуйте OKR. Настройте инструмент (даже если это таблица). Установите повторяющиеся встречи: еженедельный check-in, mid-quarter review в календаре. Объясните команде: это не контроль, это навигация.
Ни разу не пропустите weekly check-in. На неделе 6–7 проведите Mid-Quarter Review. Если KR 🔴 — честно решите: корректируем цель или удваиваем усилия? Оба варианта легитимны. Документируйте причины.
Выставьте оценки (0.0–1.0) каждому KR. Проведите ретроспективу. Главный вопрос не «почему не выполнили» — а «что узнали и что изменим». Это вход для следующего квартала. Congratulate — даже частичный успех в первом цикле норма.
* Прогресс-бары — иллюстрация структуры трекинга, не конкретные данные. Ваши значения зависят от baseline.