---
title: Продуктовое интервью — база знаний (требования и жалобы, KPI и конверсия, эксперименты)
source: подготовлено 2026-10-06, TASK-47; основа — бриф рекрутера (формулирование требований, аналитика жалоб, приоритизация, измерение до/после; KPI, конверсия, эксперименты); спецификация — Yandex Codenv, этап 3
---

# База знаний: продуктовая секция

Три блока знаний ровно под формулировку рекрутера: **§1–§4** — требования, жалобы, приоритизация, измерение эффекта; **§5–§6** — KPI, метрики, конверсия; **§7–§8** — эксперименты. §9 — специфика продуктов для разработчиков (наш случай: Codenv), §10 — шпаргалка формул и терминов. Как вести секцию по времени и что говорить — в `methodology.md`, тренировка — в `training/cases.md`.

---

## 1. Формулирование требований к сервису/фиче

### 1.1 Откуда берутся требования (и что проверить до формулирования)

Требование не стартует с «сделать фичу» — оно стартует с **проблемы пользователя и цели бизнеса**. Перед формулировкой проверить:

- **Кто пользователь** (персона: для Codenv — разработчик, тимлид, платформенная команда; в B2C — сегмент), **какой у него job-to-be-done** («когда я [ситуация], я хочу [действие], чтобы [результат]»).
- **Какая боль/цель**: что сейчас плохо, как измеряется (частота, стоимость, потери времени), что будет, если не делать.
- **Контекст решения**: цель квартала/стратегии, ограничения (сроки, ресурсы, зависимости), что уже пробовали.

### 1.2 Как формулировать: три уровня

| Уровень | Инструмент | Пример (Codenv) |
|---------|-----------|-----------------|
| Проблема | Проблемное заявление: пользователь + боль + метрика | «Разработчик тратит ~40 мин на настройку окружения под задачу; это замедляет time-to-first-commit» |
| Сценарий | User story: «Как <роль>, я хочу <действие>, чтобы <ценность>» + scenario-шаги | «Как разработчик, я хочу создать готовое окружение одной командой, чтобы начать писать код через 2 минуты» |
| Требование | Функциональные требования + acceptance criteria (критерии приёмки) | «Создание окружения из шаблона ≤ 2 мин в p95; при отказе — понятная ошибка и ретрай без потери данных» |

**Acceptance criteria** — проверяемые условия приёмки (дано / когда / тогда или чек-лист). Требование без критерия приёмки — не требование, а пожелание.

### 1.3 Нефункциональные требования (NFR) — то, что отличает инженера

Список по памяти: **производительность** (latency p50/p95/p99, throughput), **масштаб** (сколько пользователей/сущностей сейчас и через год), **доступность** (SLA/SLO, %, бюджет ошибок), **надёжность** (RTO/RPO, поведение при отказах), **безопасность** (изолированность окружений, секреты, доступы), **совместимость** (обратная совместимость API, миграции), **эксплуатация** (наблюдаемость, диагностика), **стоимость** (юнит-экономика ресурса).

Для инфраструктурного продукта SLO — это и есть требования: «создание окружения доступно 99.9% времени, p95 ≤ 2 мин» звучит лучше, чем «быстро и надёжно».

### 1.4 Полнота и валидация требований

- **Трейдоффы называть**: скорость vs стоимость, гибкость vs простота, консистентность vs доступность. «Сделаем всё и сразу» — красный флаг.
- **Проверка полноты**: пройтись по счастливому пути + 3–4 краевых (отказ, таймаут, отмена, конкурентный доступ, новая версия клиента), по каждой роли пользователя.
- **Метрика успеха формулируется вместе с требованием**: «сделаем и проверим, что <метрика> изменилась с X до Y».

---

## 2. Аналитика жалоб («пользователи жалуются, что не хватает фичи Y»)

### 2.1 Пайплайн работы с жалобами (скелет ответа)

1. **Собрать** — все источники, не только самые громкие (см. §2.2).
2. **Классифицировать** — кластеризация: вручную (разметка выборки тикетов) или автоматически (тематическое моделирование / эмбеддинги + кластеризация); у каждой темы — частота, кто жалуется, серьёзность.
3. **От жалобы к проблеме** — жалоба («не хватает фичи») ≠ проблема («не могу быстро развернуть окружение»). 5 почему; иногда жалоба — симптом другой проблемы или запрос «обходного пути», который уже существует.
4. **Валидировать данными** — подтверждаются ли жалобы поведением: где пользователи отваливаются в воронке, что реально используют, сколько тратят времени. Жалобы — качественный сигнал, метрики — количественный; решения принимаем на их пересечении.
5. **Оценить масштаб** — сколько пользователей затронуто (абсолютно и в % от активных), как часто, какая цена (потерянное время × ставка, отток, блокировка работы).
6. **Приоритизировать** — §3.
7. **Ответить пользователю** — закрыть цикл: что приняли в работу/отклонили и почему. Для внутреннего продукта это половина ценности: пользователь, которого услышали, продолжит приносить обратную связь.

### 2.2 Источники обратной связи (для внутреннего продукта — наш случай)

| Источник | Что даёт | Ограничение |
|----------|----------|-------------|
| Тикеты поддержки / канал в мессенджере | Частота и формулировки болей | Голосуют самые активные/недовольные |
| Прямые интервью + шаркинг сессий (смотреть, как работает) | Причины, контекст, workarounds. Правила вопросов — по Мом-тесту (Fitzpatrick): о жизни пользователя и конкретике прошлого («как в последний раз…»), не о мнении о фиче; комплименты идее — ложный сигнал (materials/10, TASK-49) | Мало респондентов, субъективность |
| Опросы (CSAT/NPS/конкретные вопросы) | Широта, тренд во времени | Уровень удовлетворённости ≠ причина |
| Продуктовая аналитика (воронки, adoption, retention) | Объективное поведение | Не объясняет «почему» |
| Косвенные сигналы: workarounds, самодельные скрипты, «теневые» инструменты | Самая честная боль — люди уже решают её сами | Надо целенаправленно искать |
| Сопровождающие команды/тимлиды (для платформы — «клиентские» команды) | Блокеры на уровне процессов | Агрегированный интерес, не отдельного человека |

### 2.3 Ловушки

- **Громкость ≠ важность**: 50 жалоб от одной команды на одну тему — это одна жалоба.
- **Visible users bias**: жалуются те, кто остался; ушедшие молчат — смотреть на отток и «неактивацию».
- **Жалоба на симптом**: «не хватает кнопки» может значить «не находится существующая кнопка».
- **HiPPO / последний разговор**: приоритизировать системно (§3), а не по последнему разговору с самым громким пользователем.

---

## 3. Приоритизация

### 3.1 Базовые фреймворки

**RICE**: `Score = Reach × Impact × Confidence / Effort`.
- Reach — сколько пользователей/команд затронем за период; Impact — насколько сильно (шкала 0.25–3); Confidence — насколько верим в оценку (50/80/100%); Effort — человеко-недели.
- Сила: заставляет вытащить все допущения наружу. Слабость: ложная точность, недооценивает стратегические вещи.

**Impact / Effort (2×2)**: quick wins (высокий impact, низкий effort) → большие проекты → fill-ins → избегать. Хорош для быстрого ответа на собесе как старт, потом уточнить RICE.

**Cost of Delay / WSJF**: `ценность / длительность` с учётом того, как ценность горит во времени. Уместно упомянуть для инфраструктуры: блокирующая другим командам проблема имеет высокий cost of delay.

**Kano-модель**: базовые ожидания (их отсутствие = боль, наличие не радует) / performance (линейно) / delighters (неожиданная ценность). Полезно в ответе на «жалуются на нехватку фичи»: сначала понять, к какому классу относится запрос.

### 3.2 Инфраструктурная специфика приоритизации

- **Сколько команд разблокируем** — платформенная фича умножается на число потребителей (это наш Reach в RICE).
- **Стабильность против нового**: для молодого сервиса (как Codenv) доля на надёжность объективно выше — фреймворк должен это выражать (impact через инциденты/потерянные часы, а не только «новые фичи»).
- **Технический долг** — приоритизируем через цену: рост инцидентов, замедление доставки, риск перед Scaling-событием. «Долг без цены» — не приоритет.
- **Зависимости и sequence**: иногда порядок важнее оценки (сделать фундамент до фич).

### 3.3 Как отвечать на собесе

Не называть фреймворк, а **применять**: «возьму RICE — прикинем Reach: сколько команд…» Числа можно брать с потолка, но вслух и с обоснованием; показать, что при изменении допущения меняется решение (чувствительность). Завершить: «итоговый порядок такой, главная неопределённость — X, я бы проверил её вот так».

---

## 4. Измерение качества продукта/фичи до и после запуска

### 4.1 Каркас ответа

1. **Метрика успеха (primary)** — одна, напрямую отражает ценность фичи. До запуска зафиксировать: текущее значение (baseline), целевой эффект (что считаем успехом).
2. **Guardrails (защитные)** — что не должны сломать: перформанс, стоимость, смежные метрики, satisfaction.
3. **Способ сравнения** — по убыванию строгости: A/B (§7) → staggered rollout с контрольными сегментами → до/после с поправками (когорты, сезонность, diff-in-diff) → только качественные сигналы (последний вариант — признать слабость метода).
4. **Окно наблюдения** — учесть новизну-эффект и недельную/месячную сезонность: сравнивать с тем же днём недели, минимум 1–2 полных цикла.
5. **Решение** — заранее определённый критерий: «если primary +≥X% и guardrails целы — раскатываем на всех; иначе откат/итерация».

### 4.2 До/после без эксперимента — как не обмануться

- **Сезонность/тренд**: рост +10% в декабре ≠ эффект фичи. Сравнивать с аналогичным периодом и с трендом до запуска.
- **Состав пользователей изменился** (selection): новые пользователи ведут себя иначе → сравнивать когорты, а не агрегат.
- **Diff-in-diff**: (до-после в целевой группе) минус (до-после в похожей группе без фичи) — простейшая честная оценка.
- **Surrogate-метрики**: если целевую не измерить напрямую («стало удобнее»), выбрать прокси, ближайшую к ценности (время до первого коммита, доля сессий без обращений в поддержку).
- Если фича обязательная (нет «не-пользователей»), строгий A/B невозможен — честно назвать метод и его ограничения.

### 4.3 Качественная оценка (дополняет, не заменяет)

CSAT/опросы до/после, интервью, шаркинг-сессии, NPS сегмента. Формула NPS — §10. На собесе упомянуть, что числа интерпретируем вместе с «почему» из качественных источников.

---

## 5. KPI и метрики продукта

### 5.1 Дерево метрик (главный инструмент ответа «какие KPI выбрать»)

```
Северная звезда (исход, ценность для пользователя, 1 шт.)
├── Вход (input): что мы контролируем — запуск фич, качество, каналы
├── Промежуточные: активация → вовлечённость → удержание
└── Guardrails: что не должны сломать (перформанс, стоимость, NPS, анти-метрики)
```

Правила:
- **Северная звезда — исход, не действие**: «число разработчиков, успешно работающих в окружениях еженедельно», а не «число созданных окружений» (создал и бросил — ванито).
- **Каждая метрика дерева — с владельцем и ответом «что делаем, если упала»**.
- **Пары-антагонисты**: скорость vs качество, adoption vs стабильность, краткосрок vs долгосрок. Одиночная метрика без пары ведёт к перекосу (Goodhart: «когда метрика становится целью, она перестаёт быть хорошей метрикой»).

### 5.2 Подходящие семейства метрик

| Семейство | Метрики | Когда смотреть |
|-----------|---------|----------------|
| Adoption (принятие) | % активных пользователей, использующих фичу; time-to-adoption после релиза | Новая фича/продукт |
| Activation (активация) | % прошедших до первой ценности (первый успех) | Онбординг, конверсия |
| Retention (удержание) | возвраты на 2-й/н-й день/неделе, cohort retention | Живучесть ценности |
| Время/скорость | time-to-first-commit, time-to-environment, экономия часов | Инфраструктура, инструменты |
| Удовлетворённость | CSAT, NPS сегмента, число жалоб/тикеты | Качество опыта |
| Экономика | стоимость на пользователя/окружение, ресурсная эффективность | Платформенные продукты |

### 5.3 KPI для внутреннего продукта-платформы (наш случай Codenv)

Кандидаты в северную звезду: **число разработчиков, для которых Codenv — основной способ работы (WAU с retention)** или **суммарное сэкономленное время разработчиков в неделю**. Дерево: активация (создал окружение → сделал первый коммит ≤ N мин) → вовлечённость (доля рабочих дней с окружением) → удержание (команды не уходят обратно на локальные окружения) → guardrails (инциденты/недоступность, время создания p95, стоимость на окружение, satisfaction-опрос).

Метрики нельзя выбирать в вакууме: на собесе начать с вопроса «какая цель у сервиса сейчас — рост adoption или надёжность у существующих?» — от цели метрика и выбирается.

---

## 6. Конверсия и воронки

### 6.1 Как анализировать («конверсия низкая — ваши действия»)

1. **Определить воронку** — этапы от первого контакта до ценности. Для Codenv: узнал → установил/зашёл → создал окружение → сделал первый коммит → вернулся на следующий день → сделал частью ежедневной работы.
2. **Посчитать конверсию каждого шага** и найти **узкое место** (largest drop-off относительно бенчмарка, не относительно соседнего шага).
3. **Сегментировать** — по типу пользователя/команде/ОС/источнику: часто падение — не глобальное, а один сегмент тащит.
4. **Качественная проверка** — на найденном шаге: шаркинг-сессии, интервью с отвалившимися (усыновить «ушедшие молчат» — смотреть не-конвертировавшихся).
5. **Гипотезы причин** — трение (слишком сложно/долго), ценность (не понял зачем), доверие (не верю, что безопасно), технические блокеры (не работает на их конфигурации).
6. **Гипотезы улучшений → приоритизация → эксперимент** (§7).

### 6.2 Что улучшает конверсию (словарь приёмов)

- **Убрать трение**: меньше шагов, дефолты, шаблоны «в один клик», прогресс-индикатор, отложенная регистрация.
- **Ускорить время до ценности** (time-to-value): первая ценность до просьбы о настройке; преднастроенное окружение = готовый первый коммит.
- **Контекстные подсказки** и ошибки, которые объясняют, что делать дальше.
- **Реактивация**: письма/уведомления по сегментам, вернувшимся к незавершённому шагу.
- **Ценообразование трения**: если шаг объективно долгий (создание окружения) — показать прогресс и занять пользователя полезным (дока, пример кода).

### 6.3 Статистика конверсии — что не проговорить

- Конверсия — доля; для малых чисел (мало пользователей на шаге) колебания — шум; доверительный интервал обязателен (§10).
- Среднее время шага обманчиво при тяжёлых хвостах — медиана и p90.
- Агрегированная конверсия может расти, когда каждая сегментная падает (композиция/парадокс Симпсона) — сегментировать всегда.

---

## 7. Эксперименты (A/B и не только)

### 7.1 Зачем: корреляция ≠ каузальность

Эксперимент — единственный способ при прочих равных ответить «фича вызвала эффект». Всё остальное (до/после, корреляции) — оценка с допущениями. На собесе это первая фраза про эксперименты.

### 7.2 Дизайн A/B по шагам (скелет ответа)

1. **Гипотеза** — формулируем как проверяемую: «Изменение X улучшит метрику M на ≥Δ, потому что <механизм>, не сломав guardrails G».
2. **Метрики** — primary (одна), secondary, guardrails; их совокупность = **OEC** (Overall Evaluation Criterion, канон Kohavi, materials/14) — заранее!
3. **Единица рандомизации** — пользователь (для платформы — разработчик; осторожно с командными/сетевыми эффектами: если фича меняет общие ресурсы, рандомизировать командой).
4. **MDE** — минимальный обнаруживаемый эффект: какой эффект нас интересует практически. От него считается выборка; если нужная выборка нереальна (недели ожидания) — либо признаём, что эффект не измерим этим способом, либо ищем более чувствительную метрику/прокси.
5. **Размер выборки и длительность** — расчёт (§10); длительность = целые недели (недельная сезонность), не «до значимости».
6. **Запуск и валидация** — A/A-проверка, SRM (sample ratio mismatch: доля пользователей в ветках не соответствует плану — эксперимент бракуем), проверка стратов.
7. **Анализ** — сравнение primary с доверительным интервалом; guardrails; сегменты (эффект может быть у сегмента, а не в среднем — тогда решение по сегментам).
8. **Решение** — раскатить/откатить/итерировать по заранее определённому критерию; зафиксировать результат в базе знаний экспериментов.

### 7.3 Статистика минимум (называть уверенно)

- **H0/H1, p-value**: вероятность получить наблюдаемое или большее различие, если эффекта нет. Порог α = 0.05 — конвенция, не истина.
- **Ошибка I рода** (ложный эффект, α) и **II рода** (пропустили эффект, β); **мощность = 1 − β**, стандарт 80%.
- **Пикинг (peeking)**: смотреть на p-value каждый день и останавливаться при p<0.05 — раздувает α; решать по зафиксированному протоколу или использовать последовательные методы (group sequential, always-valid p-values).
- **Множественные сравнения**: 20 метрик — почти наверняка одна «значима» случайно; поправка (Бонферрони/Benjamini-Hochberg) или заранее одна primary.
- **Новизна-эффект**: ранний всплеск спадает; смотреть на стабильное окно или продлевать наблюдение.
- **Интерференция**: пользователь меняет поведение других (общие окружения, шаринг) — нарушает независимость; решение — кластерная рандомизация.
- **SRM** — sample ratio mismatch (см. выше): первый чек после старта.
- **Большинство экспериментов нулевые**: по опыту тысяч тестов Kohavi успех у ~1/3 идей — неудачный результат норма и ценность (экономит деньги, учит о пользователях); «рассказать про неудачный эксперимент и что из него вынес» — сильный ход (materials/14, TASK-49).
- **T-triplets (Treatment–Task–Target population)**: эксперимент определяется тройкой «что меняем / какую задачу пользователя трогаем / на ком» — ответ на «что вы тестируете?» одним кадром.

### 7.4 Когда A/B нельзя (критично для внутреннего продукта!)

Мало пользователей (сотни, не миллионы), нельзя дать половине «плохой» опыт, сетевые эффекты, этика. Альтернативы — знать по названию и когда применять:

| Метод | Суть | Когда |
|-------|------|-------|
| Staged rollout + контрольный сегмент | Раскатка по % с сохранением маленькой контрольной группы | Апгрейды платформы |
| Switchback | Рандомизация периодами времени (A/B/A/B), а не пользователями | Мало пользователей, эффект быстрый (latency-изменения) |
| Interleaving | Смешанные варианты в одном интерфейсе, сравнение позиций | Ранжирование/рекомендации |
| До/после + diff-in-diff с когортами | Поправка на тренд и состав | Обязательные фичи |
| Квази-эксперименты (синтконтроль) | Подбор похожей группы по историческим метрикам | Нет рандомизации |
| Качественные методы: интервью, usage-анализ, экспертная оценка | Не дают каузальности, дают понимание | Всё вышеперечисленное дорого |

Для Codenv честный ответ на собесе: «пользователей порядка сотен/тысяч, классический A/B по многим фичам маломощен — комбинирую staged rollout, switchback для инфраструктурных изменений, когорты и интенсивные качественные методы; там, где трафик есть (веб-док, онбординг), — полноценные A/B».

### 7.5 Яндекс-контекст экспериментов

Культура: Яндекс — одна из самых «экспериментальных» компаний РФ; A/B — рутинный инструмент и в поиске, и в продуктах, команда неоднократно публиковала о своей инфраструктуре экспериментов (статьи на Хабре от команд Яндекса о проведении A/B-тестов, слоях экспериментов и типичных ошибках). На собесе: опираться на общую методологию (§7.2–7.4), не приписывать себе знание внутренних инструментов; если спросят «проводили ли A/B в вашей практике» — честно: в высоконагруженных B2C-командах (Самокат/Дикси) эксперименты и staged rollout были частью процесса запуска фич; в платформенных командах чаще rollout + метрики + контрольные сегменты. Готовый пример — агент code review в Самокате: включали разработчикам поэтапно и замеряли adoption/эффект, а не «выкатили и верим».

---

## 8. Связка: «жалобы → фича → эффект» сквозной пример (заготовка для секции)

Сценарий: «Разработчики жалуются, что в Codenv не хватает фичи Y» (например, Y = «перенос окружения между машинами»).

1. **Аналитика жалоб**: источники (тикет-канал, интервью, теневые workarounds — кто-то пишет свои скрипты снапшотов); кластеризация за квартал: Y — 40 обращений от 25 разработчиков из 3 команд; смотрим поведение: у жалующихся доля сессий без коммитов выше, отток после неудачных переносов ручным способом.
2. **Проблема за жалобой**: не «нет фичи», а «потеря настроенного окружения = потерянный день».
3. **Оценка масштаба**: 25 из ~N активных = X%; цена — среднее время восстановления (по метрикам/интервью) × частота.
4. **Альтернативы**: фича Y vs дешёвые обходы (снапшоты, лучшие дефолты, экспорт конфигурации) — RICE по каждому.
5. **Требования к выбранной** (§1): user story + AC + NFR (время переноса p95 ≤ T, сохранность секретов, обратная совместимость).
6. **Измерение**: primary — число потерянных окружений/неделя и time-to-recovery; guardrails — время создания, стоимость хранения, satisfaction; метод — staged rollout с контрольными командами (мало пользователей) + до/после с когортами; критерий решения заранее.
7. **Ответ пользователям**: кто из жалующихся — в пилот, закрыть цикл обратной связи.

Такой сквозной ответ закрывает сразу три темы рекрутера: жалобы, приоритизацию, измерение.

---

## 9. Специфика: продуктовая секция для инженерного лида

Что проверяют (в вакансии это дословно: «продуктовый подход: общение с пользователями, поиск сценариев, воплощение» + «AI-first»):

- **Мышление от проблемы, не от решения**: не «как сделать», а «стоит ли делать и что это даст».
- **Связь инженерии и продукта**: метрики, трейдоффы, стоимость владения — наша территория, используем её.
- **Работу с пользователями без PM**: у лидов платформенных команд PM нет — сам собираешь обратную связь, сам приоритизируешь, сам отвечаешь за результат.
- **Зрелость решений**: «нет данных — так и скажи, и скажи, как их получишь» вместо выдумывания точных цифр.

**Подтверждение формата эмпирикой (TASK-48, октябрь 2026)**: бриф рекрутера дословно совпадает с официальной страницей Яндекса (yandex.ru/jobs/interview/pm) — секция берётся из банков вопросов практического интервью («жалобы → аналитика → приоритизация → измерение» и «KPI → конверсия → эксперименты»). В стандартном бэкенд-треке продуктовой секции нет — она добавлена под роль. Детали и источники: `materials/01`, `materials/02`.

Наши живые примеры (использовать как иллюстрации, каждый — в 2–3 предложения):

| Пример | Продуктовая суть |
|--------|------------------|
| Баланс Платформа: RPC Core/фреймворк | Внутренний продукт для десятков команд: стандарты, DX, приёмка требований от команд-потребителей; прямой аналог Codenv |
| Code review агент (Самокат) | Вырос из боли команды; поэтапное включение, замер adoption и эффекта — мини-эксперимент в реальности |
| DevContainers-онбординг (Дикси) | Сокращение time-to-first-commit новичка — готовая история про активацию и time-to-value |
| Запуски с нуля в Самокате (3 продукта, 800K+ заказов) | Сценарии от пользователей → запуск → метрики; масштаб и ответственность |
| Voice bot (Райф, ~7% автопилот) | Измеримый эффект фичи: baseline → цель → результат |

---

## 10. Шпаргалка: формулы и термины

| Термин | Формула / определение |
|--------|----------------------|
| Конверсия шага | перешедших далее / вошедших в шаг |
| Retention cohort | вернувшиеся из когорты дня N / размер когорты |
| NPS | % промоутеров (9–10) − % критиков (0–6) |
| CSAT | удовлетворённые / опрошенные |
| RICE | Reach × Impact × Confidence / Effort |
| WSJF | стоимость задержки / длительность |
| A/B выборка (на ветку, быстро) | n ≈ 16 · p(1−p) / Δ² — при α=5%, мощности 80%, двустороннем тесте (Δ — абсолютный эффект; сравнение средних по z-статистике) |
| MDE | минимальный эффект, который обнаружим с заданной мощностью при данной выборке |
| Lift | (B − A) / A |
| SRM | наблюдаемое соотношение веток ≠ плановое → брак эксперимента |
| Ошибка I / II рода | ложный эффект (α) / пропущенный эффект (β=1−мощность) |
| Длительность эксперимента | max(выборка/трафик в день, 1–2 полные недели) |
| Diff-in-diff | (после−до) в целевой − (после−до) в контрольной |

Термины одним словом: **north star** — главная метрика ценности; **guardrails** — метрики-ограничители; **activation** — первая ценность; **peeking** — подглядывание в результат до конца; **novelty effect** — временный всплеск новизны; **анти-метрика** — рост как побочный эффект вреда.

---

## Связанные документы

- [`methodology.md`](methodology.md) — как вести секцию: тайминг, скелеты ответов, паттерны, ошибки
- [`training/cases.md`](training/cases.md) — тренировочные кейсы под Codenv и протокол самотренировки
- [`../case.md`](../case.md) — статус кейса
- [`../system-design/`](../system-design/README.md) — закрытый этап 2 (архитектурная секция)