Project metrics на основе OKR и CSI — это система, где вы сначала фиксируете 2–4 измеримых результата (OKR), а потом доказываете, что они реально улучшают опыт клиентов через Customer Satisfaction Index (CSI) и операционные метрики; так метрики перестают быть «ради отчёта» и начинают управлять деньгами, сроками и качеством.

Самая частая боль в проектах (и у новичков, и у «джунов с опытом») выглядит так: метрик много, смысла мало. В Яндекс Трекере всё «зелёное», в отчёте к спринту 30 графиков, а прод всё равно падает, клиенты уходят, а бизнес внезапно просит «срочно ускориться». Метрики без целей — как логирование без алертов: вроде данные есть, а спать спокойно нельзя.

Вторая боль — карьерная. На собеседованиях в РФ Product/PM/BA всё чаще спрашивают «какие метрики вели?» и «как привязали их к целям?». В вакансиях в Яндексе/Тинькофф/Озон-экосистемах и сотнях компаний поменьше (HeadHunter, Хабр Карьера) почти всегда мелькают: OKR, продуктовые метрики, NPS/CSI/CSAT, unit-экономика, A/B. Про «я просто следил за сроками» рынок уже шутит без вас.

Карта понятий: OKR, KPI, project metrics и CSI — кто за что отвечает

OKR: «зачем» и «какой результат»

OKR (Objectives and Key Results) — это постановка целей через измеримые результаты. Важно: OKR — не список задач и не «сделать фичу Х». Это «чего хотим добиться» и «как поймём, что добились».

• Objective — качественная цель (коротко и по делу).
• Key Results — 2–5 измеримых результата (цифры, проценты, сроки).

Практический вывод: OKR — верхний слой системы метрик проекта. Он задаёт фокус, чтобы команда не мерила «всё подряд».

Подводный камень: превращать KR в список активностей («провести 10 встреч», «написать 20 страниц ТЗ»). Это имитация управления, а не управление.

Project metrics: «как идём» и «где течёт»

Project metrics — это метрики процесса доставки: срок, предсказуемость, качество, риск, стоимость. В российской реальности это часто данные из Jira/YouTrack, GitLab, CI/CD, Sentry, Grafana, Kibana, Yandex Cloud Monitoring.

Практический вывод: project metrics должны быть «подчинены» OKR: измеряем ровно то, что влияет на KR.

Подводный камень: метрики ради контроля людей (скорость разработчика, «сколько часов»). Это быстро ломает доверие — и метрики становятся фейком.

CSI: «что чувствует клиент» и почему это не “оцените по шкале”

CSI (Customer Satisfaction Index) — индекс удовлетворённости клиента. Обычно считается по опросу после взаимодействия (покупка, обращение в поддержку, доставка, использование функции). Часто путают с CSAT (средняя оценка удовлетворённости), но CSI обычно шире: может включать несколько вопросов и веса.

Практический вывод: CSI — слой проверки реальности. Можно «улучшить сроки», но посадить клиентский опыт. CSI ловит это раньше, чем вы увидите падение выручки.

Подводный камень: мерить CSI «в среднем по больнице». Если удовлетворённость падает у сегмента «новые пользователи из регионов», а среднее держится — вы узнаете об этом слишком поздно.

Инструкция: как построить систему метрик OKR + CSI за 10 шагов

Шаг 1. Определите контекст проекта: доставка ценности или «перекладывание проводов»

Для продуктовых проектов CSI почти всегда обязателен. Для инфраструктурных (миграция, рефакторинг, импортозамещение) CSI можно заменить на «внутреннего клиента» (саппорт, операторы, бухгалтерия — да, они тоже клиенты).

Вывод: сначала назовите клиента и его боль, иначе CSI получится декоративным.

Ошибка: называть «бизнес» клиентом. Клиент — тот, кто получает услугу и страдает от багов.

Шаг 2. Сформулируйте 1–2 Objectives на квартал

Один проект — максимум пару целей. Реальность такая: если целей 6, то целей 0. Они просто конкурируют за внимание.

Пример Objective: «Ускорить и стабилизировать оформление заказа в вебе для новых пользователей».

Ошибка: «Выпустить релиз 2.0». Это задача, не цель.

Шаг 3. Напишите 2–4 Key Results, которые можно проверить цифрой

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

• Снизить медиану времени оформления заказа с 3:40 до 2:20.
• Снизить долю ошибок оплаты (5xx/4xx) с 1,8% до 0,6%.
• Поднять CSI по сценарию «оплата» с 72 до 80.

Вывод: KR — это «что поменяется в мире», а не «что мы сделаем».

Ошибка: KR без baseline («улучшить CSI») — это обещание в стиле «стану лучше с понедельника».

Шаг 4. Привяжите каждый KR к 2–3 драйвер-метрикам проекта

Драйверы — это то, чем вы реально управляете каждую неделю. Например:

• Lead Time (время от идеи до продакшена)
• Cycle Time (время выполнения задачи в разработке)
• Change Failure Rate (доля релизов с откатами/инцидентами)
• MTTR (время восстановления после инцидента)
• Доля автотестов на критических сценариях

Вывод: если KR — это «куда», то project metrics — это «как едем».

Ошибка: пытаться управлять KR напрямую без драйверов. Это как «хочу похудеть», но без сна, питания и активности — только весы.

Шаг 5. Опишите CSI правильно: сегменты, точки измерения, частота

CSI надо проектировать как мини-исследование, а не как «влепим опрос в попап». Минимальный каркас:

1. Сценарий (что оценивали): регистрация, оплата, доставка, обращение в поддержку.
2. Сегмент: новые/старые, регион, устройство, канал.
3. Точка: сразу после события или через N часов.
4. Шкала: 1–5 или 1–10 (важно не менять каждый месяц).

Вывод: один CSI «на весь продукт» часто бесполезен. Нужен CSI по критическим сценариям.

Ошибка: собирать CSI, но не связывать его с событиями (логами). Тогда вы не поймёте, на что влиять.

Шаг 6. Соберите метрики в одну «панель правды»

В РФ типовой стек: Yandex DataLens / Redash / Grafana + источники (PostgreSQL, ClickHouse, Kafka) + трекинг (Jira/YouTrack) + инциденты (PagerDuty реже, чаще — Telegram/Service Desk). Главное — не инструмент, а единый договор по числам.

Вывод: один дашборд на KR и основные драйверы, обновление хотя бы ежедневно.

Ошибка: 12 дашбордов в разных системах. Это как 12 разных версий «правды» — в итоге побеждает самая громкая.

Шаг 7. Добавьте пороги и реакции: что делаем, если метрика упала

Метрика без правила реакции — это градусник без врача. Для каждой ключевой метрики задайте:

• порог «норма» и «красная зона»;
• ответственного (не обязательно одного человека, но роль);
• регламент действия (инцидент, постмортем, откат, заморозка релиза).

Вывод: вы строите не отчётность, а систему управления.

Ошибка: «посмотрим на ретро». Если реакция через 2 недели — это уже археология.

Шаг 8. Введите ритуалы: еженедельный обзор OKR и CSI

OKR любят регулярность. Раз в неделю: 30–45 минут на прогресс по KR, причины, гипотезы, риски. CSI — минимум раз в 2 недели, потому что опросы и выборка «дозревают».

Вывод: метрики живут в календаре, а не в Confluence.

Ошибка: обсуждать только delivery («закрыли 40 задач»), игнорируя outcome («клиенту стало лучше?»).

Шаг 9. Защититесь от «накрутки метрик»

Где метрика — там и желание её «улучшить» в отчёте. Антидоты:

• Пара метрик качества рядом со скоростью (например, Lead Time + Change Failure Rate).
• Сегменты по CSI (чтобы среднее не маскировало проблему).
• Отдельно фиксируйте инциденты и техдолг (иначе их «не существует»).

Ошибка: ставить премии напрямую за одну метрику. Вы получите красивую метрику и сломанный продукт.

Шаг 10. Сделайте документацию на 1 страницу

Да, всего одну. Что меряем, где смотрим, как считаем, кто отвечает. Можно в Notion/Confluence. И да, ссылку на методологические разборы и похожие материалы логично держать рядом — например, на itokno.ru, чтобы команда не «изобретала OKR заново» каждый квартал.

Ошибка: писать «методологию метрик» на 40 страниц. Её никто не прочитает, включая автора.

Пример системы: OKR + CSI + project metrics (шаблон)

Два кейса из практики: один про рост, второй — про «метрики ради метрик»

Кейс 1 (удачный): CSI как предохранитель от «ускорили, но сломали»

Команда в e-commerce ускоряла checkout. По project metrics всё выглядело идеально: Cycle Time упал на 20%, релизы пошли чаще. Но CSI по сценарию «оплата» внезапно просел в одном сегменте — Android, регионы, один конкретный банк-эквайер. Оказалось, оптимизация фронта «съела» ретраи на слабом интернете, и люди получали отказ чаще. Починили — CSI вернулся, а конверсия выросла уже честно.

Вывод: CSI отлавливает «не те улучшения» быстрее, чем финансы.

Ошибка, которую избежали: праздновать ускорение разработки, игнорируя опыт пользователя.

Кейс 2 (неудачный): OKR превратили в KPI-палку

Внутренний проект внедрил OKR, но KR были про «закрыть N задач» и «сделать N релизов». Люди научились дробить задачи и релизить микроскопические изменения. Показатели «выполнены», а баги и инциденты выросли. Через квартал OKR объявили «нерабочей методологией». Не методология виновата — формулировки и отсутствие CSI/качества.

Вывод: OKR без outcome и без балансирующих метрик качества — это KPI в новой упаковке.

Ошибка: мерить активность вместо результата.

Экспертный вердикт и инструмент: чек-лист системы метрик (OKR + CSI)

• 1) У меня есть baseline? Я знаю «сейчас», прежде чем обещать «станет лучше».
• 2) KR измеряют outcome? Не релизы и задачи, а эффект: время, ошибки, конверсия, CSI.
• 3) На каждый KR есть 2–3 драйвера? И я могу влиять на них каждую неделю.
• 4) CSI сегментирован? Хотя бы по 2–3 ключевым сегментам, иначе среднее вас обманет.
• 5) Есть пороги и реакции? Кто и что делает, если метрика в «красной зоне».
• 6) Метрики живут в ритуалах? Еженедельный обзор, а не «где-то в отчёте».
• 7) Система защищена от накрутки? Скорость уравновешена качеством и CSI.

Если вы «входите в IT» или апгрейдитесь до продакта/PM/аналитика, навык строить project metrics через OKR и CSI — это один из самых дешёвых способов выглядеть взросло на рынке. Потому что «я вел OKR, и вот как CSI изменился по сегментам, вот драйверы, вот решения» звучит намного убедительнее, чем «я делал задачи в Jira и старался».

Частые вопросы