Теневая система в продукте — это когда у тебя в доке одно, а в жизни тесты живут по законам племенного совета.

Теневая система в продукте — это когда у тебя в доке одно, а в жизни тесты живут по законам племенного совета.

Контекст: формально есть регламент экспериментов, SRM-чек, power analysis, guardrails. Де-факто решение о запуске/стопе принимает не дизайн, а самый громкий голос в комнате.
Действие: в одной компании сначала «обязали» считать MDE и длительность теста, но потом начали закрывать эксперимент на 2-й день, потому что «тренд хороший». SRM не смотрели, сегменты не резали, а негатив по retention списывали на шум.
Результат: победили не гипотезы, а иллюзия контроля. Через месяц выкатывали фичу, которая в проде сжигала метрику, потому что статистика была декорацией, а не фильтром решений. 📉

Теневая система всегда дороже, чем кажется: вы платите за лишние итерации, ложные победы и команды, которые учатся не делать выводы, а обходить процесс.
Если у вас «экспериментальный фреймворк» есть только в Confluence — у вас не процесс. У вас описание процесса.