KPI проекта: система показателей для IT — KPI, OKR и CSI без путаницы

KPI проекта — это набор измеримых показателей, по которым видно: проект приносит пользу или просто красиво горит в Jira. OKR проекта отвечает на вопрос «куда и зачем бежим», KPI — «как поймём, что добежали», а CSI показывает «насколько довольны пользователи и заказчик» — и это три разные линейки, которые не стоит складывать в одну кашу.

Самая частая боль у новичков и джунов: вам говорят «сделай KPI», а на деле ждут либо отчётность ради отчётности, либо магию «повысить эффективность на 30%» без базовой метрики. В итоге команда меряет скорость вместо результата, и все уверены, что работали как проклятые — просто бизнес почему-то не богатеет.

Из практики: если в проекте есть OKR, KPI и CSI, но никто не может за 30 секунд объяснить, чем они отличаются — считайте, что у вас есть только PowerPoint. Точнее… PowerPoint и чувство вины.

Три системы, три смысла: KPI, OKR и CSI

KPI проекта: «что считаем и где красная зона»

Тезис: KPI проекта — это измеримые показатели результата и процесса, которые регулярно контролируются и имеют пороги (норма/риск/пожар).

Обоснование: в IT KPI чаще всего привязывают к срокам, бюджету, качеству и пользе (value). Если у вас нет порогов и периодичности — это не KPI, а «интересная статистика».

Практический вывод: формулируйте KPI так, чтобы их можно было снять из систем (Jira, GitLab, Яндекс Метрика, AppMetrica, Service Desk) без шаманства в Excel.

Подводный камень: KPI «количество задач закрыто» и «story points в спринт» превращают проект в фабрику тикетов. Производим много, продаём мало.

OKR проекта: «зачем это всё и какой outcome ждём»

Тезис: OKR проекта (Objectives and Key Results) — это цель (Objective) и 2–5 измеримых результатов (Key Results), которые описывают изменение, а не активность.

Обоснование: OKR хорош там, где не всё предсказуемо: продуктовые гипотезы, рост, UX, новая фича. Он фиксирует направление и проверяемые результаты, но не превращает команду в бухгалтерию.

Практический вывод: используйте OKR как верхний уровень смыслов, а KPI — как приборную панель контроля.

Подводный камень: «Objective: сделать редизайн. KR: нарисовать 50 макетов» — это план работ, а не OKR. Outcome потерялся по дороге.

CSI: «насколько довольны, и кто именно»

Тезис: CSI (Customer Satisfaction Index) — индекс удовлетворённости пользователей/заказчика, обычно по опросам после релиза, инцидента или этапа.

Обоснование: CSI помогает поймать то, что не видно в техметриках: удобство, доверие, предсказуемость, качество поддержки. В корпоративных проектах CSI часто важнее, чем «мы уложились в сроки», потому что проект могут закрыть даже идеально по плану — если людей от него воротит.

Практический вывод: если думаете, как применить CSI — начните с микроскопического опроса 3–5 вопросов после ключевых событий (релиз/сдача этапа/устранение P1).

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

Шпаргалка: чем KPI, OKR и CSI отличаются

Система	Отвечает на вопрос	Тип метрик	Частота	Где ломают чаще всего
KPI проекта	«Насколько мы в контроле?»	Сроки, бюджет, качество, стабильность, value	Еженедельно/ежемесячно	Подменяют результат активностью
OKR проекта	«Зачем делаем и чего хотим добиться?»	Outcome/изменение поведения/бизнес-эффект	Квартал (часто)	Пишут список задач вместо результатов
CSI	«Довольны ли люди?»	Оценки по шкале, комментарии	После событий + тренд	Опрос “для галочки”, без действий

Как собрать KPI проекта без фетиша метрик

Шаг 1. Привязать показатели к типу проекта

Тезис: KPI проекта для внедрения 1С и KPI проекта для мобильного приложения — разные звери.

Обоснование: внедрение живёт этапами, актами, SLA и обучением. Продукт живёт retention, конверсией, выручкой, ошибками и отзывами.

Практический вывод: сначала выберите «род метрик», потом конкретные численные KPI.

Подводный камень: тащить продуктовые метрики в чисто проектную разработку «по ТЗ» и наоборот.

Внутренний корпоративный проект: SLA, время реакции, число критических инцидентов, CSI внутренних пользователей.
Внедрение/интеграция: % выполненных требований, просрочка этапов, дефекты на UAT, нагрузка поддержки.
Продукт/сервис: DAU/MAU, конверсия, CAC/LTV (если есть), crash-free, скорость доставки изменений.

Шаг 2. Определить «снимаемость» (доступность данных)

Тезис: KPI, которые нельзя стабильно измерять, превращаются в религию и споры.

Обоснование: например, «качество кода» без определений — идеальный повод для бесконечных митингов. А вот «дефекты P1 на проде за месяц» — сурово, но честно.

Практический вывод: при выборе KPI напишите рядом источник данных: Jira, GitLab, YouTrack, Zabbix, Grafana, Service Desk, Яндекс Метрика, AppMetrica.

Подводный камень: KPI, которые можно «подкрутить» руками. Их подкрутят.

Шаг 3. Поставить пороги и договориться о реакции

Тезис: KPI без порога — это просто число. KPI без реакции — просто тревожная кнопка без батареек.

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

Практический вывод: на каждый KPI заведите три зоны: зелёная/жёлтая/красная и короткий playbook действий.

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

Примеры KPI проекта (чтобы было от чего оттолкнуться)

Область	KPI (пример)	Зачем	Чем опасен, если не подумать
Сроки	% задач, закрытых в плановый срок по критичному пути	Контроль delivery	Начнут дробить задачи до «закрылось быстро»
Бюджет	План/факт затрат по этапам, burn rate	Не вылететь в космос по деньгам	Экономия на тестировании = дорогой прод
Качество	Количество дефектов P1/P2 на проде в месяц	Стабильность	Будут занижать приоритеты дефектов
Производительность процесса	Lead Time изменения (идея → прод)	Скорость поставки ценности	Погоня за скоростью убьёт качество
Польза	Доля пользователей, использующих ключевую фичу (adoption)	Понять, что сделали не «в стол»	Можно накрутить через принудительные сценарии
Удовлетворённость	CSI после релиза/этапа + тренд по кварталу	Понять эмоцию и доверие	Спрашивать «ну как?» без действий по фидбеку

Кейс из жизни: как OKR спасает от «KPI ради KPI»

Успешный: команда внутреннего портала в крупной компании держала KPI «кол-во релизов в месяц». Релизы шли бодро, но сотрудники продолжали писать в поддержку и обходить портал через почту. Переписали систему: OKR проекта — «снизить ручные заявки через почту», KR — «минус 25% писем в общий ящик + рост доли самообслуживания». KPI оставили технические (Lead Time, P1 на проде), а CSI ввели после крупных изменений. Через квартал почтовый хаос реально просел, а релизов стало меньше — и это было нормально.

Неудачный: внедрение Service Desk. KPI поставили «закрывать 95% тикетов за 24 часа». Исполнители начали закрывать тикеты «решено» и тут же открывать «уточнение», чтобы уложиться в SLA. Формально — зелёная зона, фактически — пользователи в ярости. Здесь как раз не хватило CSI и контроля качества решения (например, доля повторных обращений).

Коммерческие факторы: где KPI реально стоят денег

Метрики — не бесплатные, даже если вы пишете их в Notion. Платите временем людей и инструментами.

Скрытая цена №1: ручной сбор данных. Если аналитик или PM тратит 4 часа в неделю на «свести отчёт», за месяц это один рабочий день. В рублях — зависит от роли, но логика простая: отчёт должен окупаться управленческими решениями.
Скрытая цена №2: внедрение событий и логирования (для продуктовых KPI и CSI по поведению). Это задачи разработчикам и тестировщикам, их надо планировать.
Скрытая цена №3: неправильные KPI. Они создают «оптимизацию под отчёт», а это почти всегда дороже, чем отсутствие KPI.

Нормальная практика: начинать с 5–9 KPI проекта, а не с «прибора самолёта». И допиливать по мере зрелости. На itokno.ru периодически выходят разборы таких управленческих шаблонов — полезно сверять подходы, когда в компании начинается сезон KPI-охоты.

Экспертный вердикт и инструмент: как не перепутать KPI, OKR и CSI

Мини-чеклист: что у вас сейчас — KPI или просто числа

Показатель измеряется регулярно и одинаково (источник данных фиксирован)?
Есть пороги (зелёный/жёлтый/красный) и владелец реакции?
Метрика отражает результат или хотя бы критичный риск, а не «занятость»?
Её сложно накрутить без реального улучшения?
Связь с целью проекта понятна человеку «не из IT» за 30 секунд?

Рецепт связки «OKR → KPI → CSI» (без путаницы)

OKR проекта формулирует смысл: какой outcome хотим и почему это важно.
KPI проекта фиксирует контроль: сроки/качество/риски/ценность, чтобы не развалиться по пути.
CSI проверяет реальность: пользователи почувствовали улучшение или вы просто «в срок закрыли этап».

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

Сколько KPI должно быть у проекта, чтобы это работало, а не раздражало?

Обычно 5–9 KPI проекта достаточно: 1–2 по срокам, 1 по бюджету, 1–2 по качеству, 1 по скорости поставки, 1 по пользе и (если есть пользователи) CSI. Больше — начнётся отчётность ради отчётности.

Можно ли использовать velocity (story points) как KPI проекта?

Как внутреннюю техметрику — да, но как KPI «успеха» — опасно. Velocity легко раздувается оценками и не гарантирует бизнес-результат. Лучше смотреть lead time и качество на проде.

OKR проекта — это только для продуктовых команд?

Нет. OKR полезен и в проектной разработке, если есть неопределённость и важен outcome (например, снижение ручного труда, рост самообслуживания, ускорение процессов). Если проект строго «по ГОСТу и ТЗ», OKR может быть коротким, но всё равно задаёт смысл.

Как применить CSI, если пользователи — внутренние сотрудники и им «всё не так»?

Делайте CSI событийным (после релиза/инцидента), задавайте 3–5 конкретных вопросов и обязательно публикуйте, какие изменения вы сделали по обратной связи. Иначе CSI превращается в сбор жалоб без лечения.

Что важнее: KPI проекта или CSI?

Они про разное. KPI держит проект в управляемости, CSI показывает принятие результата людьми. Игнорировать KPI — риск провалить сроки/качество, игнорировать CSI — риск сделать «идеально внедрённое, никому не нужное».

Какая типичная ошибка при внедрении KPI в IT-команде?

Путать метрики занятости с метриками результата: «закрыто задач», «написано строк кода», «проведено встреч». Это почти гарантированно ведёт к оптимизации под отчёт и конфликтам между бизнесом и разработкой.

Как понять, что KPI проекта пора менять?

Если метрика перестала влиять на решения (вы её смотрите и ничего не делаете), если её начали «обходить», или если цель проекта сместилась (например, с delivery на стабилизацию). KPI — инструмент управления, а не татуировка.