design-kpis
Design KPIs — официальный skill OpenAI для построения системы метрик, которая помогает принимать продуктовые и бизнес-решения. Он охватывает outcome-метрики, driver-метрики, guardrails, targets и план измерения, но не превращает набор показателей в универсальный шаблон. Входной вопрос должен быть связан с решением: что команда хочет понять, кто будет действовать по результату и как часто показатель будет пересматриваться. Без этого даже правильно посчитанная метрика может не помогать управлению. Перед проектированием KPI источник предлагает проверить качество и происхождение уже существующих данных. Если задача состоит в согласовании метрик, dashboard, таблиц, владельцев или источников истины, сначала следует использовать data-quality workflow, а к Design KPIs вернуться, когда нужно определить будущую метрику, пересобрать систему KPI, выбрать guardrails или задать target. Это разделяет две разные работы: примирение фактических данных и проектирование того, что команда будет измерять дальше. В разделе discovery навык требует искать все доступные релевантные источники, включая каталоги, схемы, datasets, tables, views, models и metrics в структурированных системах. Известный semantic layer рассматривается как стартовая карта, а не как полный предел поиска. Если источники дублируют друг друга или конфликтуют, их нужно сопоставить по владельцу, свежести, определению, grain, покрытию и прямоте связи с вопросом. Затем выбирается наиболее авторитетный источник или комбинация взаимодополняющих источников, а выбранные данные проверяются свежим чтением. Если обязательный источник недоступен, workflow требует остановить этот путь и не заменять его слабым аналогом; необязательный пробел можно продолжить, но его нужно обозначить. Основной процесс начинается с уточнения решения и operating context: какая задача поддерживается метриками, в каком контексте они будут обсуждаться и кто будет действовать. Затем собирается бизнес-контекст — цель, текущее состояние, аудитория, ограничения, предыдущие решения, baseline и target, если они уже есть. После этого формируется широкий набор кандидатов: outcome показывает итог, driver объясняет возможный механизм изменения, guardrail защищает качество и другие важные свойства. Сначала полезно выписать кандидатов, а не сразу закреплять первый знакомый показатель. При сравнении кандидат оценивается по нескольким признакам. Он должен отражать цель или честно объяснять, почему используется как proxy; движение показателя должно менять решение, а не только украшать отчёт. Сигнал должен быть полезен на нужной cadence, команда должна иметь реалистичные рычаги влияния, а расчёт должен быть воспроизводимым в эксплуатации. Наконец, метрику нужно проверять на возможность misleading improvement: рост показателя не должен скрывать ухудшение качества, доверия, удержания, стоимости или другого guardrail. Обычно skill рекомендует 1–3 primary KPI, для каждого при необходимости 1–2 driver и 1–2 guardrail; лишние метрики добавляются только при реальной диагностической ценности. Target выбирается отдельным решением после выбора показателя. Top-down подход может опираться на benchmarks, историю, сопоставимый продукт или рыночный контекст; bottom-up — на планируемую работу, ожидаемое принятие и то, что команда способна изменить. Для target нужно указать anchor, assumptions, методологию и confidence. Если сильнейший способ требует отсутствующих данных, источник предлагает описать, что именно нужно измерить, и не выдавать provisional range за твёрдый факт. Так target остаётся управляемым ориентиром, а не произвольным числом. Итоговый материал должен быть decision-oriented: краткое summary инициативы, выбранные метрики с определением и rationale, target при необходимости, просмотренные evidence, assumptions и недостающий контекст, risks и guardrails, открытые вопросы. Skill не назначает KPI без знания цели, не подтверждает качество недоступного источника, не задаёт универсальные числовые пороги и не заменяет владельца решения. Его практическая ценность — в дисциплине выбора: связать метрику с действием, проверить данные и ограничения, ограничить систему несколькими полезными показателями и явно показать, что пока остаётся неизвестным.
Для чего подходит
- Формирование KPI-фреймворка
- Определение targets и guardrails
- Подготовка плана измерения результата
Установка
Сначала прочитайте SKILL.md и scripts в исходном репозитории. Затем выполните команду в каталоге проекта:
npx skills add https://github.com/openai/role-specific-plugins/tree/main/plugins/data-analytics/skills/design-kpis