🎯Вопрос целеполагания рано или поздно касается каждого сотрудника компании. Часто к целям относятся формально: как к обязательному полю в performance review и способу доказать, что ты весь год работал не зря.

Но сила целей гораздо больше. Они не просто фиксируют ожидаемый результат — они напрямую меняют поведение людей и команд. Особенно когда от их выполнения зависят оценка, бонус или повышение.

Кажется, логика простая: выбираем релевантную метрику, рассчитываем для неё амбициозное, но достижимое значение — и записываем себе в цели.

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

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

Причём чаще всего это происходит не из-за злого умысла. Команда просто адаптируется к правилам игры, которые для неё установили.

Например:
➡️ есть цель по росту числа регистраций — упрощаем вход и получаем множество аккаунтов, которыми никто не пользуется;
➡️ есть цель по числу закрытых аналитических задач — декомпозируем одно большое исследование на множество маленьких тикетов. Задач закрыто больше, а пользы создано столько же;
➡️ есть цель по росту числа заказов — активно привлекаем низкоинтентных пользователей скидками. Заказов становится больше, но вместе с ними растут отмены, возвраты и издержки, а прибыль почти не меняется.

И что с этим делать?
1. Проводить стресс-тест цели. Перед тем как закрепить KPI, стоит задать простой вопрос:

Как можно формально выполнить эту цель, не сделав продукт или процесс реально лучше?

2. Добавлять контрметрики. Они помогают проверить, не была ли цель достигнута за счёт ухудшения качества или соседних показателей. Здесь важно не сводить проблему только к прямому фроду — сотрудники могут совершенно добросовестно выбирать более простые задачи, привлекать пользователей низкого качества или перекладывать негативный эффект на соседнюю команду.

3. Делать метрику устойчивее к играбельности.

Можно растить не просто число зарегистрированных аккаунтов, а число новых пользователей, совершивших хотя бы одно целевое действие.

Не просто количество заказов, а количество успешно выполненных и экономически оправданных заказов.

Чем ближе метрика к реальной ценности для пользователя или бизнеса, тем сложнее выполнить её исключительно на бумаге.

4. Смотреть не только на цифру, но и на поведение. Даже хорошая метрика может испортиться после того, как к ней привязали мотивацию. Поэтому после постановки цели важно следить не только за её значением, но и за тем, какое поведение она начала создавать.

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

А какие цели в вашей практике выполнялись на 120%, хотя продукту или бизнесу от этого лучше не становилось? 👇

Зелёные тесты и сырники, рассказываем про кайфушечки аналитиков

❤️ Когда чей-то дэш помог ответить на все вопросы за 2 минуты

❤️ Задачу, рассчитанную на день, получилось сделать за полчаса

❤️ Скрипт, обрабатывающийся обычно час, выполнился за 5 минут — и как будто ничего оптимизировать уже не надо

❤️ Тест оказался зелёным, и можно не копать дальше

❤️ Расчёты, сделанные по разным методологиям, сошлись

❤️ Заказчики решили, что больше не нужна выгрузка

❤️ На кухне дают сырки

❤️ Встречу на час закончили за 20 минут

❤️ Аналитическое исследование действительно прочитали до конца и задали актуальные вопросы по нему

❤️ Не получилось подключиться на собес, но нашёлся коллега, готовый подхватить

❤️ Причину просадки метрики поняли за первые пять минут

❤️ Скинули код другого аналитика — и в нём ничего не нужно было чинить

Что забыли?)

В последнее время поднялся очередной шум вокруг ИИ — на этот раз из-за математики. OpenAI заявила, что её внутренняя AI-система предложила решение задачи Навье — Стокса — одной из знаменитых открытых математических задач. В решение был включён текст доказательства и формализация на Lean (языке для формальной проверки математических доказательств).

На этом фоне Теренс Тао, один из ведущих современных математиков, опубликовал заявление A Severe Misalignment of AI in Mathematics, подписанное 25 лауреатами Филдсовской премии.

Главная мысль, как я её понял: в математике важен не только финальный ответ. Решение большой задачи ценно ещё и тем, какие идеи, методы и обсуждения появляются по пути.

И мне кажется, что в аналитике прослеживается что-то похожее.

➡️ Если ИИ способен подходить к таким сложным задачам, то агентские системы будут всё лучше строить большие цепочки рассуждений и самостоятельно «копать данные»: искать сегменты, замечать аномалии, предлагать объяснения и формулировать инсайты. Вероятно, таких инсайтов будет становиться всё больше и больше.

Но, как и с большими математическими результатами, сам факт появления ответа ещё не всегда закрывает вопрос. Нужно понимать, как именно возникло исследование: какие гипотезы проверялись, какие шаги привели к выводу, что было отброшено, где осталась неопределённость и какое решение из этого действительно следует.

➡️ Возможно, роль аналитика будет смещаться не только в сторону поиска инсайтов, но и в сторону их валидации. Нужно будет следить за путём решения, проверять ограничения и объяснять, почему найденному выводу можно или нельзя доверять.

А как вы думаете: если ИИ будет приносить всё больше готовых инсайтов, что станет главным навыком аналитика — находить ответы, проверять путь к ним или превращать их в правильные решения для бизнеса?

#АрменЕс

Спрашивает меня как-то подруга-аналитик: «Слушай, как посчитать эффект от выкатки нового тарифа в новом городе? Чтобы посмотреть каннибализацию других тарифов». 

(Продукт существует, но в новом городе выкатили новый тариф, который уже раскатан в нескольких других городах)

😊 «А есть похожий город, где вы уже были раскатаны?» — спрашиваю я

👩‍💻 «Ну они сильно другие»

😊 «Окей, выкатывали ли вы на всех пользователей эту фичу?»

👩‍💻 «Исключали новичков — тех, кто сделал менее 10 пользований сервиса, — а так на всех, да»

😊 «Ага, супер. Тогда можно сравнить 2 группы и то, как они пользовались другими тарифами»

Тут важно сказать, что не стоит просто сравнивать пользователей «до порога» и «после порога». Человек, который пользовался сервисом 2 раза, и человек, который пользовался им 50 раз, очевидно, отличаются не только наличием нового тарифа. Они и без всякой выкатки могли бы по-разному пользоваться остальными тарифами.

Но здесь есть условная граница, и можно найти пользователей, которые плюс-минус похожи, но при этом в разных группах: кто увидел новый тариф, и кому он недоступен. Если тариф становился доступен после 10 использований сервиса, можно сравнить, например:

8–10 использований ➡️ тарифа ещё нет
11–13 использований ➡️ тариф уже есть

Это уже гораздо более похожие пользователи. В идеальном мире единственное значимое отличие между ними — это доступность нового тарифа. А дальше смотрим, начали ли пользователи справа от порога реже выбирать старые тарифы.

И обязательно проверяем устойчивость результата: берём окно поуже — например, 9–10 vs 11–12, потом пошире — 7–10 vs 11–14. Если вывод каждый раз примерно один и тот же, доверия к нему становится сильно больше.

Если вам это что-то напоминает — да, это Regression Discontinuity Design, про который я уже писала в отдельном посте 👀

Что интересно, именно в момент этого разговора я сидела и считала по такому же методу свой «псевдотест». Изначально это не планировалось как АБ-тест, а просто было плавной раскаткой коммуникации на пользователей. Но в механике раскатки тоже нашлась условная граница, вокруг которой можно было сравнить очень похожих пользователей.

Спойлер, мой «псевдотест» не показал никаких аплифтов. Я проверила на разных границах (брала пользователей и поближе к границе, и подальше, разницы не было никакой), а у подруги-аналитика как раз такое исследование показало жёсткую каннибализацию других тарифов.

Дальше, конечно, стоит сделать обратный АБ, чтобы точно замерить негативный эффект на метрики других тарифов и получить данные для принятия решения. Ну или понять, что совсем всё плохо, и не катить тариф в этом городе :)

Вот так и поговорили.

Ну делитесь, а как бы вы попробовали обсчитать такой запуск?