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

• Знание всегда контекстно. То, что работало в одной аудитории/сезоне/канале — может не работать в другом.
• Знание устаревает. Фича «вчера» и «после релиза iOS/Android/SEO-апдейта» — это разные реальности.
• Знание неполно. Логи, опросы, метрики — это срезы, а не весь слепок мира.

Значит, цель — не достичь мифического «полного понимания», а настроить систему итераций, где каждая следующая версия (продукта, процесса,hypothesis pipeline) статистически чаще и существеннее лучше предыдущей.

Практическая философия: «решают HADI-циклы»

HADI — Hypothesis → Action → Data → Insight.

1. Hypothesis
2. Формулируем проверяемое предположение в формате «если…, то…, измеряем по…». Важно зафиксировать:

• целевой эффект (основная метрика + guardrail-метрики),
• ожидаемую величину эффекта (MDE — minimum detectable effect),
• риски и критерии остановки.

1. Action
2. Делаем самый дешёвый и быстрый шаг к проверке: прототип, фича-флаг, эмуляция, “fake door”, не всегда сразу полноценный релиз.
3. Data
4. Сбор ровно тех данных, которые заранее определены планом: временные окна, сегменты, событийная схема, дедупликация, анти-fraud, мониторинг SRM (Sample Ratio Mismatch).
5. Insight
6. Интерпретация и решение: продолжать/скейлить/откатить/повторить с иной формулировкой. Инсайт должен конвертироваться в новую гипотезу — иначе цикл глохнет.

Ключевая мысль: скорость и надёжность прохода цикла важнее героизма в одной «идеальной» итерации. В IT выигрывает команда с предсказуемыми короткими циклами и накатанными конвеерами проверки гипотез.

Конвейер тестирования гипотез: как превратить удачу в фабрику

Представим конвейер от идеи до решения:

• Бэклог гипотез (прозрачный, приоритизированный RICE/ICE/PIE/WSJF; у каждой гипотезы — владелец и дата «best before»).
• Design-док/One-pager (цель, метрики, MDE, риски, дизайн эксперимента, план внедрения).
• Фича-флаги и продвинутая система rollout (переключатели, прогрев, percentage-rollout, canary).
• Стабильная событийная схема (версионирование, контрактные тесты аналитики, алерты на поломки трекинга).
• Экспериментальная платформа (рандомизация, аудит SRM, CUPED/CRA для снижения дисперсии, стратификация/кластеризация при необходимости).
• Репозиторий знаний (ADR — Architecture/Analysis Decision Records, записи экспериментов: гипотеза → дизайн → данные → выводы → артефакты).

Такой конвейер убирает «магическое мышление» и снижает зависимость от харизмы отдельных людей.

А/Б-тесты: опора на статистику, а не на ощущения

A/B — не панацея, но это дисциплина. Важные практики:

• Фиксируйте план заранее. Метрики (основная + guardrails), MDE, длительность, правила остановки.
• Силовой анализ (power). Без достаточной выборки даже сильный эффект «не бросится в глаза».
• Контроль SRM. Несоответствие долей трафика группам — тревожный флаг (бага в рандомизации/флагах/логах).
• Учёт сезонности и «новизны». Эффект часто «пузырится» в первые дни; планируйте окна стабилизации.
• Интерференция. В соц- и сетевых продуктах пользователи влияют друг на друга; иногда нужен кластерный дизайн.
• Мультивариантность и p-value хакерство. Коррекция на множественные сравнения, предрегистрация плана, Bayes/Sequential — осознанно.
• Качественная аналитика рядом. Квант подтверждает «что», качественные методы помогают понять «почему».

Критерий успеха: «каждая итерация статистически значимо лучше предыдущей» — корректная мысль, если вы проверяете именно те метрики, которые коррелируют с бизнес-целями, и умеете отличать статистическую значимость от практической (лифт в 0,3% может быть статистически значим, но экономически бессмысленен).

Когда A/B неуместен — и что вместо

• Малый трафик/редкие события → квазиэксперименты, интерраптед тайм-серии, Bayesian updating, симуляции, экспертная оценка + флаги.
• Высокий риск/регуляторика → канареечный релиз, dark launch, белые списки, пилоты по сегментам.
• Долгая обратная связь → leading-metrics и прокси-метрики + регулярные ревью.

Роль экспертов и LLM: «использовать все инструменты»

Нет противоречия между «нет абсолютного знания» и «используйте экспертов/LLM» — наоборот, это инструменты для ускорения цикла.

Профильные эксперты:

• формируют здравые priors и ограничения (безопасность, архитектура, домен),
• помогают спроектировать корректный эксперимент,
• выполняют «pre-mortem»: как эксперимент может нас обмануть, где риски.

LLM (включая специализированные агенты):

• генерация гипотез и вариантов UX/копирайта,
• автоматическая проверка событийной схемы и аномалий в логах,
• подсказки по дизайну эксперимента, расчёт MDE/power,
• быстрый разбор пользовательских отзывов/тыкета,
• код-скелеты для прототипов и feature-flag интеграций.

Важно: у LLM есть галлюцинации и смещения. Лечится процессом: верификация, «chain-of-thought» для себя (а в артефакты — только проверенный вывод), промт-шаблоны, тест-кейсы для агентов, приватность данных.

Метрики: как не стрелять себе в ногу

• Единицы анализа. Пользователь vs сессия vs устройство; выберите согласованно.
• Guardrails. Не ухудшаем скорость/стабильность/ретеншн ради CTR.
• Lagging vs leading. Деньги и LTV — лагирующие; нужны прокси (активация, частота целевых действий), валидированные исторически.
• Здоровье данных. Алёрты на изменения схемы, задержки, outliers; «Observability first».
• Единый словарь метрик. Соглашения, дефиниции, владельцы.

Культура, без которой конвейер не поедет

• Публичные пост-мортемы и «право на ошибку» — итерации должны быть безопасны.
• Документируйте решения (ADR) даже когда «ничего не получилось» — это тоже знание.
• Скорость важна, но не ценой качества данных. «Быстро-грязно» допустимо в прототипе, но не в эксплуатационной аналитике.
• Регулярные «эксперимент-ревью». Что запустили? Чему научились? Что масштабируем? Что удаляем?
• Долгосрочные треки. Не всё меряется неделей А/Б: инфраструктура, скорость сборки, DX — это инвестиции с отсроченным, но огромным ROI.

Мини-процедуры, которые повышают шансы на «каждую итерацию лучше»

1. Шаблон гипотезы
2. «Если мы [изменим Х для сегмента Y], то [метрика Z] вырастет на [Δ] за [T], не ухудшив [guardrails]. Проверка: [метод], MDE = […], риски: […].»
3. Pre-flight чек-лист эксперимента

• Рандомизация ок? SRM?
• Метрики считаются одинаково для A и B?
• Логи приходят, дедуплицируются, нет дропа событий?
• Фича-флаг отрабатывает, нет утечек между группами?
• План остановки/этики/поддержки пользователей — зафиксирован?

1. Post-flight

• Решение: roll out / iterate / rollback.
• Что в репозиторий знаний? (гипотеза, код, SQL, графики, конклюзии)
• Следующая гипотеза на основе инсайта — когда идёт в работу?

Частые ловушки и как их обходить

• Слепая вера в «лучшие практики». Они контекстны. Переносите принципы, а не готовые рецепты.
• Оптимизация только одной метрики. Всегда держите набор guardrails.
• Игнор сегментации. В среднем «лучше», но ключевой сегмент пострадал. Проверяйте гетерогенность эффекта.
• Эффект регрессии к среднему и «охота за победой». Планируйте эксперименты пакетами, а не «стрелой в яблочко».
• Отсутствие «уборки». Похороните фичи-неудачники; технический и продуктовый мусор замедляет новые итерации.

Как «использовать все инструменты» разумно

• Эксперты — формируют рамки и повышают качество постановки задачи.
• LLM/агенты — ускоряют перебор, документирование и аналитику.
• A/B/квазиэксперименты — дают проверяемость.
• Фича-флаги и платформы — дают управляемость и обратимость.
• Репозиторий знаний — даёт накопление эффекта.

Складываем это в систему, где скорость*качество итераций растёт, а стоимость ошибок — контролируема.

Итог

Абсолютного знания нет — и это не проблема, если у вас есть конвейер управляемого незнания: HADI-циклы, дисциплинированные эксперименты, грамотные метрики, карьерка документации и культура пост-мортемов. Тогда гипотезы превращаются в решения, решения — в эффекты, а эффекты — в капитал знаний.

И да — используйте все инструменты: экспертов, LLM, экспериментальные платформы, фича-флаги, дизайн-доки. Но помните, что инструмент — это ускоритель, а не замена процессу. Выигрывают те, у кого каждое следующее «неидеальное знание» чётко и измеримо лучше предыдущего.