Как сформулировать измеримые результаты проекта: от целей заказчика к согласованным метрикам

Главная причина споров при сдаче проекта — разное понимание успеха. Заказчик ждёт «роста продаж», команда сдаёт «функционал по ТЗ», а в конце выясняется, что продажи не выросли, а функционал не решает бизнес-задачу. Измеримый результат — это не просто цифра в отчёте, а заранее согласованный критерий, по которому обе стороны без двусмысленности определяют: проект успешен или нет. Статья разбирает, как перевести расплывчатые пожелания заказчика в чёткие метрики, зафиксировать их в договоре или Соглашении об уровне сервиса (SLA) и не потерять связь с реальной пользой для бизнеса.

Почему «сделать по ТЗ» — это не результат

Техническое задание описывает что делаем (функции, экраны, интеграции). Измеримый результат описывает зачем и как поймём, что цель достигнута. Если проект — разработка интернет-магазина, ТЗ требует «корзину и оплату». Результат бизнеса — «конверсия в покупку не ниже 2% и средний чек от 3000 руб. через 3 месяца после запуска». Первое — объём работ, второе — ценность.

Разделение на выходы (outputs) и результаты (outcomes) критично. Выходы: выпущенный код, настроенные серверы, написанная документация. Результаты: сокращение времени обработки заявки на 40%, снижение оттока клиентов на 15%, рост выручки от нового канала на 1 млн руб. в квартал. Заказчик платит за результаты, команда производит выходы. Без связи между ними проект рискует стать «успешным» по формальным признакам и бесполезным для бизнеса.

Иерархия целей: от миссии к метрике

Прежде чем писать цифры, восстановите цепочку: Бизнес-цель → Продуктовая цель → Метрика проекта → Целевое значение. Пропуск ступени ведёт к метрикам «для галочки».

• Бизнес-цель — язык владельца денег: «Увеличить прибыль от онлайн-канала на 20% к концу года».
• Продуктовая цель — что должен сделать продукт: «Обеспечить удобный повторный заказ без звонка менеджеру».
• Метрика проекта — измеримый индикатор продуктовой цели: «Доля повторных заказов через личный кабинет».
• Целевое значение (Target) — конкретная цифра с дедлайном: «Доля повторных заказов через ЛК ≥ 35% к 30.11.2024».

Если заказчик называет только бизнес-цель — спросите, какой продуктовый механизм её реализует. Если называет только функцию («сделайте кнопку повтора») — спросите, какое изменение поведения пользователей ожидается. Без этого диалога метрика будет висящей в воздухе.

Фреймворки для формулировки: SMART, OKR, KPI — что и когда применять

Три популярных подхода решают разные задачи. Не смешивайте их в одну кашу.

SMART — для договорных обязательств и приёмки

Классическая схема для фиксации критериев приёмки (Acceptance Criteria) в договоре или акте сдачи-приёмки. Каждая метрика должна быть:

• Specific (Конкретной) — «Скорость загрузки главной страницы», а не «быстрый сайт».
• Measurable (Измеримой) — «Time to Interactive ≤ 1.5 сек по данным Lighthouse в эмуляции Mobile 3G», а не «быстро грузится».
• Achievable (Достижимой) — основана на бенчмарках, технических ограничениях и ресурсах, а не на желании «хочу в 10 раз быстрее».
• Relevant (Релевантной) — напрямую влияет на бизнес-цель. Скорость загрузки релевантна конверсии и SEO; оценка PageSpeed 100/100 — часто нет.
• Time-bound (Ограниченной во времени) — «на момент приёмки 15.10» или «в течение 30 дней после запуска при нагрузке 1000 RPS».

SMART идеален для фиксированных условий контракта: штрафы, бонусы, факт приёмки.

OKR — для стратегических инициатив и неопределённости

Objectives and Key Results работают, когда путь к цели не известен заранее (R&D, запуск нового продукта, вход на рынок).

• Objective (Цель) — качественная, вдохновляющая, временная: «Сделать мобильное приложение основным каналом продаж к концу Q4».
• Key Results (Ключевые результаты) — 3–5 количественных маркеров прогресса: «DAU приложения ≥ 5000», «Доля заказов из приложения ≥ 40%», «Retention Day 30 ≥ 25%», «Rating в App Store ≥ 4.5».

OKR не являются жесткими KPI для расчёта бонусов. Это компас для команды. Если KR не достигнуты на 70% — это сигнал сменить тактику, а не повод штрафовать. Используйте OKR для внутреннего управления проектом, а SMART — для внешних обязательств перед заказчиком.

KPI — для оперативного управления и SLA

Key Performance Indicators — работающие метрики здоровья процесса или продукта в реальном времени. В проекте их два типа:

• Проектные KPI (в процессе): Velocity (SP/спринт), Lead Time (идея → прод), Bug Escape Rate (баги в проде), Budget Burn Rate.
• Продуктовые KPI (после запуска): Conversion Rate, Churn Rate, LTV, CAC, NPS, Uptime, Error Rate.

KPI нужны для дашбордов и еженедельных статусов. Они отвечают на вопрос «нормально ли идёт работа прямо сейчас?».

Фреймворк	Где применяется	Срок жизни	Жёсткость	Пример формулировки
SMART	Договор, Акт приёмки, SLA, ТЗ на этап	До приёмки / гарантийного периода	Жёсткая (да/нет)	API отвечает за ≤ 200 мс (p95) при нагрузке 500 RPS на стенде stage к 01.11
OKR	Внутренний трекинг инициативы, квартальное планирование	Квартал / фаза проекта	Направляющая (0–100%)	KR: Доля оплаченных заказов через новый чекаут ≥ 60% к концу квартала
KPI	Дашборды, еженедельные статусы, мониторинг продакшена	Постоянно (пока жив продукт)	Пороговая (зелёный/жёлтый/красный)	Error Rate < 0.1% за последние 5 мин; Deploy frequency ≥ 1 в день

Категории измеримых результатов: что можно и нужно замерять

Не существует универсального набора. Подбор зависит от типа проекта. Ниже — чек-лист категорий. Выберите 1–2 главные из каждой группы, релевантные вашему случаю.

Бизнесовые метрики (Outcome) — язык заказчика

• Финансовые: Выручка от проекта, ARPU/ARPPU, LTV, CAC, ROI, Payback Period, Marginal Profit.
• Маркетинговые/Продажи: Conversion Rate (по воронке), Lead Cost (CPL), MQL→SQL rate, Average Deal Size, Sales Cycle Length.
• Пользовательские: Retention (Day 1/7/30), Churn Rate, NPS/CSAT, DAU/MAU, Stickiness (DAU/MAU), Feature Adoption Rate.

Ловушка: Обещать бизнес-метрики, которые проект не контролирует полностью. Сайт не гарантирует продажи, если маркетинг не привёл трафик, а отдел продаж не обработал лиды. Формулируйте как «условия, необходимые для результата»: «При трафике ≥ 10 000 уник. в месяц и качестве лидов (SQL ≥ 20%) конверсия ЛК ≥ 3%».

Продуктовые и технические метрики (Output Quality) — язык команды

• Производительность: Latency (p50, p95, p99), Throughput (RPS), Time to First Byte (TTFB), Core Web Vitals (LCP, FID, CLS).
• Надёжность: Uptime (SLA 99.9% = 43 мин простоя в месяц), Error Rate (HTTP 5xx < 0.1%), MTBF, MTTR, RPO/RTO для DR.
• Качество кода/процесса: Code Coverage (≥ 80% на критических путях), Critical Bugs Open = 0 на релиз, Technical Debt Ratio, Deploy Success Rate.
• UX/Usability: Task Success Rate (юзабилити-тестирование), Time on Task, Error Rate в сценариях, SUS Score.

Процессные метрики — для управления ожиданиями заказчика

• Скорость доставки: Lead Time (запрос → прод), Cycle Time (в работе → готово), Deployment Frequency.
• Предсказуемость: Say/Do Ratio (план/факт по спринту), Scope Creep % (рост объёма без изменения дедлайна).
• Бюджет/Ресурсы: Cost Variance (CV), Schedule Variance (SV), Resource Utilization.

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

Базовые значения (Baseline): без «до» нет «после»

Самая частая ошибка — поставить цель «конверсия 5%», не зная текущую. Если сейчас 0.5% — цель нереальна за месяц. Если 4.8% — цель слишком легка. База нужна для:

1. Реалистичности таргета. Рост на 10–20% от базы — типичный здоровый шаг для зрелых продуктов; 2–5x — для новых каналов или редизайнов с нуля.
2. Изоляции влияния проекта. Сравниваете дельту до/после с контролем внешних факторов (сезонность, маркетинг).
3. Защиты от «переговоров по факту». Зафиксированная база в акте приёмки или приложении к договору устраняет споры «а мы думали, у вас там было лучше».

Как получить базу: аналитика (GA4, Amplitude, Mixpanel), логи бэкенда, замеры производительности (Lighthouse, k6, JMeter), опросы пользователей, данные CRM. Если данных нет — проведите замеры до старта разработки и зафиксируйте их официально (письмо, протокол встречи, коммит в репозиторий с отчётом).

Ведущие и отстающие индикаторы: управляйте причинами, а не следствиями

Лагинговые (Lagging) — следствие: выручка, отток, NPS. Их видно постфактум, управлять ими напрямую нельзя.

Лидинговые (Leading) — причина: количество демо-звонков, глубина онбординга, частота использования ключевой фичи, скорость загрузки. На них можно влиять прямо сейчас.

В проекте договаривайтесь о целях по лагингам (бизнес хочет результат), но управляйте еженедельно по лидингам (команда двигает ручки). Пример: цель — LTV +15%. Лидинг — «пользователи, прошедшие новый онбординг, делают 2-й заказ в 1.5 раза чаще». Еженедельно следите за прохождением онбординга и конверсией во 2-й заказ у когорты. Если лидинг не двигается — лагинг не двинется.

Процесс согласования метрик с заказчиком: пошаговый алгоритм

Не приносите готовый список KPI на подпись. Проведите сессию (или серию встреч) по такому сценарию:

1. Раскопайте истинную цель. Спросите «Зачем?», «Как вы поймёте, что проект удался?», «Что изменится в бизнесе через 3/6/12 месяцев?». Запишите ответы языком заказчика.
2. Переведите на язык продукта. Сформулируйте 3–5 гипотез: «Если мы сделаем X, то пользователи начнут Y, что приведёт к Z».
3. Подберите метрики к гипотезам. Для каждой гипотезы — 1–2 метрики (один лидинг, один лагинг). Отсекайте vanity metrics (лайки, скачивания без активации, посещения без целевого действия).
4. Зафиксируйте базу. Соберите текущие значения. Если данных нет — договоритесь о периоде сбора (2 недели) перед стартом активной фазы.
5. Поставьте таргеты (SMART). Используйте бенчмарки отрасли, исторические данные, экспертную оценку команды. Запишите: Метрика, База, Таргет, Дедлайн, Источник данных, Частота отчёта.
6. Согласуйте условия валидности. «Таргет актуален при трафике ≥ X, бюджете маркетинга ≥ Y, отсутствии форс-мажоров». Это защита от внешних шоков.
7. Оформите в артефакте. Приложение к договору, SLA, Отдельное Соглашение о целях проекта (Project Success Agreement), Confluence-страница с подписями стейкхолдеров.
8. Настройте автоматизированный дашборд. Grafana, DataLens, Metabase, Amplitude — не важно какой, важно, что обе стороны смотрят на одни цифры в реальном времени без ручной выгрузки в Excel.

Типичные ошибки и как их избежать

1. Метрики тщеславия (Vanity Metrics)

Пример: «10 000 установок приложения», «100 000 просмотров страницы», «500 зарегистрированных пользователей».

Проблема: Не коррелируют с деньгами и удержанием.

Исправление: Заменяйте на «CPI ≤ 200 руб. и Retention Day 7 ≥ 20%», «Конверсия просмотр → лид ≥ 3%», «Активированных пользователей (сделавших ключевое действие) ≥ 1000».

2. Слишком много метрик

Проблема: 15 KPI в договоре — команда размывает фокус, заказчик не понимает, что главное.

Исправление: Правило «One Metric That Matters» (OMTM) на текущую фазу + 2–3 охранные метрики (guardrails), которые не должны ухудшиться (например, не рости Error Rate, не падать Uptime). В договоре фиксируйте только OMTT и guardrails.

3. Неизмеримые «качественные» критерии

Пример: «Удобный интерфейс», «Современный дизайн», «Масштабируемая архитектура».

Исправление: Операционализируйте. «Удобный» → Task Success Rate ≥ 90% на юзабилити-тесте с 5 пользователями, SUS ≥ 80. «Масштабируемая» → Автоскейлинг держит 10x текущей нагрузки без ручного вмешательства, p95 latency не деградирует более чем на 20%.

4. Игнорирование базы (Baseline)

Проблема: Цель «снизить время отклика до 200 мс». Текущее — 50 мс (цель бесполезна) или 5000 мс (цель нереальна за спринт).

Исправление: Обязательный этап «Замер базы» в плане проекта с дедлайном до старта спринтов разработки.

5. Метрики вне зоны контроля команды

Пример: Команда делает CRM-интеграцию. Метрика — «Рост продаж на 20%». Продажи зависят от лидов, менеджеров, сезона, конкурентов.

Исправление: Метрика команды — «Интеграция передаёт 100% лидов в CRM без потерь, время синхронизации ≤ 1 мин, ошибок синхронизации 0 в сутки». Бизнес-метрику owns продажи/маркетинг, проект даёт им инструмент.

6. Отсутствие источника истины (Source of Truth)

Проблема: Заказчик смотрит в Яндекс.Метрику, команда — в Amplitude, финансы — в 1С. Цифры расходятся на 15–30%.

Исправление: В соглашении пропишите: «Официальным источником для метрики X является система Y, отчёт Z, сегмент/фильтр A». Настройте единый дашборд, который подписывают обе стороны.

Чек-лист: готовы ли ваши метрики к приёмке?

Перед подписанием акта или приложения к договору прогоните каждую метрику по списку:

• [ ] Метрика привязана к бизнес-цели заказчика (проходит тест «А что, если мы её достигнем, но бизнес не вырастет?»).
• [ ] Сформулирована по SMART (конкретна, измерима, достижима, релевантна, ограничена во времени).
• [ ] Известно базовое значение (Baseline) на дату старта / подписания.
• [ ] Определён источник данных и метод расчёта (SQL-запрос, ID дашборда, формула).
• [ ] Задано целевое значение (Target) и дедлайн измерения.
• [ ] Прописаны условия валидности (трафик, нагрузка, сезонность, внешние зависимости).
• [ ] Есть guardrails — метрики, которые не должны ухудшиться (качество, скорость, баги).
• [ ] Частота отчёта и формат согласованы (автодашборд / еженедельный отчёт / ежемесячный ретро).
• [ ] Ответственные за достижение и за отчётность назначены (RACI).
• [ ] Предусмотрена процедура пересмотра таргетов при изменении условий (Change Request на метрики).

Сценарии: как адаптировать подход под тип проекта

Фиксированный бюджет / ТЗ (Waterfall-контракт)

Метрики жёстко закреплены в договоре как критерии приёмки. Используйте только SMART. Ограничьтесь 3–5 ключевыми метриками результата + 2–3 техническими guardrails. Любое изменение таргета — доп. соглашение. База замеряется и подписывается до старта работ.

Time & Materials / Agile-партнёрство

Метрики живут в OKR на квартал. Каждый спринт/инкремент проверяется на вкладе в Key Results. Таргеты могут корректироваться на планировании квартала. В договоре фиксируется только процесс: «Стороны ежеквартально согласовывают OKR проекта, отчётность ведётся в общем дашборде».

Внутренний проект (автоматизация, рефакторинг, платформа)

Заказчик — внутренний стейкхолдер (CTO, Head of Ops, BizDev). Бизнес-цель часто опериционная: «Сократить ручную обработку заказов на 80%», «Снизить инциденты деплоя до 1 в месяц». Метрики — процессные и технические: Lead Time, Change Failure Rate, Manual Hours Saved. Подход тот же: гипотеза → метрика → база → таргет.

MVP / Новый продукт (высокая неопределённость)

Бизнес-метрики пока неизвестны. Фокус на метриках обучения (Learning Metrics): количество проведенных интервью, конверсия в ранний доступ, retention когорт ранних пользователей, качественные инсайты. OKR здесь: Objective — «Найти Product-Market Fit», KR — «≥ 20 интервью с целевой аудиторией», «≥ 30% респондентов готовы платить», «Retention Week 2 ≥ 40% у ранних пользователей». SMART применим только к техническим ограничителям (бюджет, дедлайн демо-дня).

Как защитить проект, если заказчик отказывается от метрик

Бывает: «Мы не знаем, какие цифры, просто сделайте хорошо». Варианты действий:

• Предложите «минимум жизнеспособных метрик» (MVM). «Давайте зафиксируем хотя бы три: дата запуска, бюджет, критический нефункциональный требование (uptime / скорость / безопасность). Остальное — в бэклоге приоритетов».
• Внедрите метрики качества доставки. Даже если бизнес-метрики нет, команда отвечает за процесс: Lead Time, Bug Escape Rate, Code Review Coverage, Deploy Frequency. Это профессиональный стандарт.
• Пропишите в договоре процедуру определения метрик постфактум. «В течение 30 дней после запуска Стороны совместно определяют KPI успеха на основе реальных данных. До момента согласования приёмка производится по техническим критериям ТЗ».
• Документируйте риски. Письменно зафиксируйте: «Отсутствие согласованных бизнес-метрик не позволяет оценить ROI проекта и может привести к расхождению ожиданий при приёмке». Это защита репутации команды.

Отчётность: показывайте динамику, а не снимки

Единовременный отчёт «мы достигли таргета» слабее, чем тренд. Настройте дашборд с:

• Графиком базы → таргет → текущее значение во времени.
• Аннотациями событий (релизы, маркетинговые кампании, инциденты).
• Сегментацией (по каналам, устройствам, когортам) — среднее по больнице скрывает проблемы.
• Статусом светофора: Зелёный (на траектории), Жёлтый (риск провала), Красный (провал).

Еженедельный статус заказчику: 1 слайд / 1 экран — тренд главной метрики, блокеры, решение, нужно от заказчика. Раз в месяц — глубокий разбор: почему лидинги двигаются / не двигаются, корректируем тактику.

Практический итог: с чего начать завтра

Главный принцип: метрика без базы и источника данных — это пожелание, не критерий приёмки. Не пытайтесь покрыть всё сразу. Алгоритм на ближайшую неделю:

1. Возьмите текущий проект / ближайший контракт.
2. Выделите 1 главную бизнес-цель заказчика (спросите лично, не гадайте).
3. Сформулируйте 1 продуктовую гипотезу и подберите к ней 1 лидинг и 1 лагинг метрику.
4. Замерьте или запросите базу по этим двум метрикам сегодня.
5. Поставьте реалистичный таргет на ближайший контрольный пункт (спринт, месяц, релиз).
6. Настройте простой дашборд (даже в Google Sheets / DataLens) и дайте доступ заказчику.
7. Добавьте в план следующей встречи: «Согласование метрик успеха проекта (15 мин)».

После прочтения статьи у вас должен быть чёткий алгоритм: как перевести «хочу хорошо» в «конверсия 3% к 30 ноября по данным Amplitude, при трафике 10к». Это язык, на котором говорят деньги. Используйте его.

Материал носит информационный характер и не заменяет юридическую или финансовую консультацию. Формулировки метрик в договорах, SLA и актах приёмки имеют правовые последствия. При работе с фиксированными контрактами, штрафными санкциями или сложными B2B-сделками рекомендуется согласовывать итоговые формулировки с юристом и финансовым директором заказчика.