После того как бизнес-проблема или возможность сформулирована (см. 02.01.01 Определение бизнес-проблем и возможностей), необходимо определить, как будет выглядеть успех. Без измеримых целей проект рискует превратиться в бесконечный процесс без понятного финиша и окупаемости. Задача аналитика — помочь бизнесу зафиксировать цели, выбрать KPI и задать пороги успеха до детального сбора требований.

1. Суть темы

Стратегический анализ на этом этапе отвечает на вопрос: по каким признакам мы поймём, что проблема решена или возможность реализована. Базовая цепочка:

Цель → KPI → Критерий успеха (target)

УровеньЧто этоПример
Бизнес-цель (Business Goal)Желаемое изменение для организации или продукта«Увеличить долю онлайн-продаж»
KPI (Key Performance Indicator)Измеримый показатель прогресса к цели«Доля онлайн-продаж в общей выручке, %»
Критерий успеха (Success Criterion / Target)Конкретное пороговое значение KPI«≥ 40 % к итогам Q4»
МетрикаЛюбое измеряемое значение; KPI — метрика, значимая для цели—

В ISO 29148 и BABOK термин success criteria иногда шире — включает условия приёмки решения в целом (см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)). В этой статье критерий успеха проекта или продукта — числовой target по KPI; проверяемое поведение системы на уровне story — отдельный артефакт (02.04.02 Критерии приёмки (Acceptance Criteria)).

Baseline (as-is) — обязательный вход: без текущего значения KPI target и проверка «Achievable» в SMART необоснованны. Baseline берётся из результата 02.01.01 Определение бизнес-проблем и возможностей: зафиксированная проблема уже содержит «сколько сейчас плохо» (65 % брошенных корзин, 8 минут на заказ).

Если baseline нет или данные ненадёжны — типичная ситуация на старте IT-проекта. Не подставляйте target «с потолка»: зафиксируйте прокси-метрику (опрос, выборка транзакций, ручной замер), пилотное измерение на ограниченном периоде или диапазон «от X до Y» с явной пометкой «уточнить после 2–4 недель сбора». Без хотя бы приблизительного as-is SMART-пакет остаётся черновиком, а не согласованным target.

Иерархия целей. На типичном IT-проекте аналитик чаще работает на уровне продукта, программы или релиза, а не корпоративной стратегии. Цели верхних уровней задают контекст; SMART и KPI фиксируются для того уровня, где принимаются решения о scope и приоритетах. В Agile цель релиза («сократить checkout к Q3») и продуктовый KPI («доля брошенных корзин») — связанные, но разные артефакты: релиз может закрыть часть пути к продуктовой метрике (контекст — 05.02 Scrum и Kanban (аналитик в Agile)). Корпоративные цели на мотивационном слое архитектуры — см. 06.03.01 Мотивационный слой.

Два уровня «критериев успеха». На уровне проекта/продукта критерий успеха — числовой target по KPI («65 % → 45 %»). На уровне User Story — 02.04.02 Критерии приёмки (Acceptance Criteria): проверяемое поведение системы («гостевая покупка доступна без регистрации»). Это разные артефакты и уровни абстракции. AC не дублируют SMART-target, а трассируются к нему через цепочку: цель → KPI → функциональность → AC (механика — в 02.03.04 Трассировка требований (концепция) и 02.04.01 Верификация и валидация (V&V)). UAT проверяет, что решение в целом двигает KPI, а не отдельную story.

2. Ключевые понятия

SMART — проверка качества цели

Фреймворк SMART (Doran, 1981) — фильтр для бизнес-цели в связке с KPI, target и сроком, а не синоним «хорошей формулировки». На практике проверяют единый пакет:

КритерийНа что смотретьПример
SpecificЧто именно меняется«Снизить долю брошенных корзин» (не «улучшить UX»)
MeasurableKPI и единица измерения«% брошенных корзин от начатых сессий»
AchievableРеалистичность от baseline65 % → 45 % за квартал, а не до 5 % за месяц
RelevantСвязь со стратегией и проблемой из 02.01.01Снижение оттока напрямую бьёт по потерям выручки
Time-boundСрок пересмотра target«К концу Q3 2026»

При необходимости SMART-check делают отдельно для KPI (измерим ли?) и target (конкретен ли порог?), но итоговая формулировка для согласования со стейкхолдерами — одна: цель + показатель + порог + срок.

Антипример: «Сделать систему удобной и современной».
SMART-пакет: «Сократить среднее время оформления заказа с 8 до 3 минут к концу Q2 2026 года» (KPI: среднее время сессии checkout; target: ≤ 3 мин).

GQM (Goal–Question–Metric)

GQM (Basili & Weiss, 1984) выводит метрики из целей через вопросы. В отличие от перечисления KPI, каждый показатель обоснован: зачем мы его мерим.

Два уровня «Goal» в GQM. На вершине дерева GQM — концептуальная цель: purpose, object, viewpoint, context. На практике проекта SMART-target с числом часто становится верхним измеримым Goal: измеримая бизнес-цель задаёт рамку, а вопросы раскладывают как её достичь. Концептуальная формулировка полезна, когда target ещё не согласован — тогда сначала Goal без числа, затем Questions выводят KPI и target.

  1. Цель (Goal): «Оценить и снизить отток клиентов на этапе оформления заказа с точки зрения покупателя интернет-магазина».
    SMART-target для согласования: с 65 % до 45 % к Q3 2026.

  2. Вопросы (Questions): На каком шаге уходят? Почему? Достаточно ли быстро оформление? Насколько довольны процессом?

  3. Метрики (Metrics): % отказов по шагам чекаута; топ-3 причины отказа (exit intent, опрос); среднее время заполнения форм; CSAT после оформления.

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

graph TD
    G["Goal (концептуальный): снизить отток на checkout<br/>(viewpoint: покупатель)"]
    T["SMART-target (верхний Goal проекта):<br/>брошенные корзины 65% → 45% к Q3 2026"]
    Q1["Q1: На каком шаге уходят?"]
    Q2["Q2: Почему уходят?"]
    Q3["Q3: Достаточно ли быстро оформление?"]
    Q4["Q4: Насколько довольны процессом?"]
    M1["M1: % отказов по шагам"]
    M2["M2: топ-3 причины отказа / exit intent"]
    M3["M3: среднее время заполнения форм"]
    M4["M4: CSAT после оформления"]

    G --> T
    T --> Q1
    T --> Q2
    T --> Q3
    T --> Q4
    Q1 --> M1
    Q2 --> M2
    Q3 --> M3
    Q4 --> M4

GQM связывает бизнес-цели с 08.02 Нефункциональные требования (НФТ) — классификация и стандарты (метрики производительности, доступности) и с трассировкой KPI к целям по аналогии с 02.03.04 Трассировка требований (концепция). Согласование дерева вопросов удобно проводить на воркшопе (02.02.02 Воркшопы, фасилитация и совместные сессии) с владельцами процесса и продукта.

Опережающие и запаздывающие KPI

  • Запаздывающие (Lagging) — итоговый результат; измеряются по факту периода. Пример: доля брошенных корзин за месяц.
  • Опережающие (Leading) — прогнозируют результат и позволяют корректировать процесс. Пример: среднее время заполнения форм на checkout.

На одну бизнес-цель / один измеряемый процесс держите 1–2 запаздывающих и 2–3 опережающих KPI; больше — риск «vanity metrics» (см. 01.07 Когнитивные искажения и критическое мышление). Владелец KPI, источник данных и способ измерения фиксируются при согласовании со стейкхолдерами (см. 02.01.03 Анализ заинтересованных сторон (Stakeholder Map)): без этого target нереализуем.

Инструментирование. Если KPI нельзя получить из существующих систем (CRM, аналитика, отчёты BI), в scope проекта попадают требования на измерение: события в продуктовой аналитике, поля в отчётах, NFR на наблюдаемость и качество данных. Это не SA-детализация архитектуры — достаточно зафиксировать в бэклоге как бизнес- или нефункциональное требование (02.03.01 Классификация требований (БТ, ФТ, НФТ), 08.02 Нефункциональные требования (НФТ) — классификация и стандарты): что должно измеряться, кто владелец, откуда берётся значение.

Соседние рамки (кратко)

  • OKR — альтернатива KPI в agile-компаниях: Objective (качественный) + Key Results (измеримые). Не путать с project success criteria; OKR живут на уровне команды/продукта, KPI проекта могут быть их частью. Связь с корпоративными целями на архитектурных моделях — 06.03.01 Мотивационный слой.
  • Counter-metrics — показатели нежелательных эффектов (ускорили checkout — вырос fraud). Задавайте хотя бы один counter-metric для критичных целей.
  • KPI процесса анализа (08.01 Метрики и KPI процесса анализа) — скорость elicitation, дефекты требований; это не бизнес-KPI проекта. Рекомендация «3–5 KPI на проект» относится к бизнес-показателям, не к метрикам работы аналитика.

3. Как применяется в работе аналитика

Порядок работы

  1. Убедиться, что проблема/возможность зафиксирована с baseline или планом его получения (02.01.01 Определение бизнес-проблем и возможностей).
  2. Сформулировать SMART-пакет (цель + KPI + target + срок); согласовать с ключевыми стейкхолдерами — при необходимости через воркшоп GQM (02.02.02 Воркшопы, фасилитация и совместные сессии).
  3. Разложить цель через GQM: вопросы → метрики → leading/lagging; проверить, что каждый KPI можно измерить (или завести требования на инструментирование).
  4. Зафиксировать цели и KPI в 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD) (Vision & Scope, раздел BRD о целях).
  5. Перевести цели в критерии отбора требований, scope и трассировку — см. блок «Мост к требованиям» ниже.

Связь с циклом GQM. Шаги 1–4 — разовая (и пересматриваемая) постановка целей до и в начале разработки. Четырёхшаговый GQM-цикл ниже — сквозной: после поставки шаги «Сбор данных» и «Интерпретация» повторяются по согласованному периоду измерения; при расхождении факта с target инициируется пересмотр scope и приоритетов, а не только отчёт.

GQM на проекте: четыре шага

  1. Планирование: цели, стейкхолдеры, baseline, период измерения (когда пересматриваем target).
  2. Определение: Goal → Questions → Metrics; назначить владельцев, источники данных и требования на измерение.
  3. Сбор данных: организовать измерение по согласованным метрикам (в том числе после релиза).
  4. Интерпретация: ответы на вопросы → решения о scope, приоритетах и корректировке target.

Мост к требованиям

Цели и KPI задают критерии отбора и приоритета требований, а не заменяют спецификацию:

GQM+Strategies

Расширение GQM для enterprise: согласование программ измерения между подразделениями и стратегическими инициативами. Нужно, когда несколько программ/продуктов делят одни KPI или когда измерения должны стыковаться с корпоративной стратегией. Для одного продукта или проекта достаточно классического GQM.

Сквозной пример

Проблема (02.01.01): 65 % брошенных корзин, ~5 млн руб./мес. потерь.

SMART-пакет: снизить долю брошенных корзин с 65 % до 45 % к Q3 2026 (KPI: % сессий checkout без покупки).

GQM: Q1 → отказы по шагам; Q2 → причины отказа; Q3 → время форм; Q4 → CSAT. Leading — время форм и отказы по шагам; lagging — % брошенных корзин.

Следствие для бэклога: гостевая покупка, сокращение полей 15 → 5, оплата через СБП — приоритет по потенциальному влиянию на опережающие метрики; при отсутствии exit intent в продукте — требование на сбор причин отказа. Детали приоритизации — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано).

4. Типовые ошибки и ограничения

  • Цели-лозунги: «Стать лидером рынка» — нет KPI, нет трассировки к требованиям (риск подтверждения желаемого — 01.07 Когнитивные искажения и критическое мышление).
  • Подмена цели решением: «Внедрить CRM» — средство, не результат. Цель: «Сократить время ответа клиенту с 2 дней до 4 часов». На уровне портфеля «запустить платформу X» может быть стратегической инициативой; для аналитика на проекте всё равно нужен outcome-KPI (что изменится для клиента после внедрения).
  • Смешение SMART-target и AC: одна формулировка в BRD и в User Story без связи — дублирование или расхождение на приёмке.
  • Пропуск baseline: target «45 %» без «сейчас 65 %» — нельзя оценить Achievable и ROI; «нет данных» не отменяет план пилотного измерения.
  • Несвязные пары Q–M в GQM: метрика времени под вопросом «почему уходят» — ложный шаблон; каждый вопрос должен иметь метрику, которая на него отвечает.
  • KPI без инструментирования: target согласован, а события аналитики и отчёты не запланированы — измерение не случится после релиза.
  • Слишком много KPI: 3–5 бизнес-показателей на проект/цель; остальное — вспомогательные метрики GQM.
  • Конфликт целей: «Сократить time-to-market вдвое» vs «снизить стоимость разработки на 20 %» — явно выносите на согласование (02.01.03 Анализ заинтересованных сторон (Stakeholder Map), 09.07 Управление ожиданиями заказчика).
  • Vanity metrics: сбор данных, не связанный с вопросами GQM и решениями.
  • Игнор counter-metrics: рост одного KPI при деградации смежного (безопасность, качество).
  • Путаница с метриками аналитика: бизнес-KPI проекта ≠ KPI процесса elicitation (08.01 Метрики и KPI процесса анализа).
  • Качественные цели без числа: CSAT в GQM допустим; для SMART-target задайте порог («CSAT checkout ≥ 4,2 из 5») или зафиксируйте, что target качественный и пересматривается по результатам исследований.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • BABOK v3, Chapter 5 «Strategy Analysis» (Define Future State), Chapter 10 «Techniques» (KPI и метрики). International Institute of Business Analysis (IIBA). iiba.org
  • Victor Basili, David Weiss «A Methodology for Collecting Valid Software Engineering Data». IEEE Transactions on Software Engineering, 1984. DOI: 10.1109/TSE.1984.5010285
  • George T. Doran «There's a S.M.A.R.T. Way to Write Management's Goals and Objectives». Management Review, 1981.
  • Hubbard, Douglas W. «How to Measure Anything: Finding the Value of Intangibles in Business», 3rd ed. John Wiley & Sons, 2014. Страница издания (Wiley)
  • Southekal, Prashanth. «Data for Business Performance: The Goal-Question-Metric (GQM) Model to Transform Business Data into an Enterprise Asset.» Technics Publications, 2017. ISBN 978-1634621847
  • Basili, V. et al. «Linking the Software Measurement Process to Enterprise Goals.» Fraunhofer IESE, 2009 (GQM+Strategies). publica.fraunhofer.de

Статьи

  • Lavazza, Luigi et al. «Putting Business Goals in Context for Measurement» (SOFTENG 2025). PDF
  • MindTools «SMART Goals: How to Make Your Goals Achievable». mindtools.com