---
title: Демо-прогон №1 — продуктовая секция Codenv: жалобы → приоритизация → измерение → KPI → эксперимент с AI-агентом
date: 2026-10-06
roles: интервьюер — Дмитрий (инженер-лид Codenv, ассистент); кандидат — «Сергей» (голос пользователя, ассистент); наблюдатель — пользователь
format: по методике training/demo-protocol.md; реплики сжаты относительно живого диалога, приложение сохраняет пояснения наблюдателю
---

# Прогон №1: полный час продуктовой секции

## 🎬 Сеттинг

Час дня, переговорка Яндекса. Дмитрий, руководитель группы Codenv, играет заказчика и отвечает на уточнения как «представитель команды» (включая честное «не знаю»). Кандидат — лид продукта Codenv.

## Ход 1. Кейс: три жалобы в `#codenv-help`

**Дмитрий:** За месяц в канал стабильно приходят три темы: (1) окружения тормозят при сборке; (2) нет общего доступа к окружению; (3) пару раз в месяц всё висит по 10 минут. Тебе приносят: «жалуются, разбирайся». Что делаешь?

**💭 Что проверялось:** не полезет ли кандидат сразу решать (красный флаг «90%»), или начнёт с масштаба и источников. Три жалобы — возможно, три разные проблемы с разной ценой.

## Ход 2. Уточняющие вопросы кандидата

**Сергей:** Сколько всего активных пользователей и сколько пожаловались (доля, не число)? Кто жалуется на тормоза — сегмент? «Висит 10 минут» — один и тот же симптом, есть ли постмортемы? Канал — единственный источник?

**Дмитрий:** Активных ~800 из ~4000 разработчиков. Тормоза: ~40 человек, почти все — большие монорепы (C++, тяжёлый Go). Шаринг: ~25 человек, разброс по стекам. Висения: 5 событий по 100–300 человек; постмортемы: 2 из 5 — миграции образов при деплое, остальное — деградация стораджа, один корень не найден. Ещё есть квартальный CSAT 6/10 и телеметрия сборок, которую никто не смотрел.

**💭 Каждое уточнение создало гипотезу:** тормоза = качество для сегмента (5%), лечится инженерно; шаринг = отсутствующая фича (3%), лечится продуктом; висения = reliability с известной механикой у 2/5 и охватом до ~1500 человеко-инцидентов — по охвату больше первых двух вместе. Подслушан приём «данные важнее мнений» (телеметрия, CSAT).

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

**Сергей:** Сначала вопрос о цели: рост adoption или удержание? **Дмитрий:** рост, план +1000 к концу квартала.

**Сергей:** Тогда:
- **Висения — первым**: до ~1500 человеко-инцидентов/мес; 2 из 5 причин известны → это не исследование, а «взять постмортемы и закрыть», 2–3 спринта; и главное — нестабильность читают те 3200, кто ещё не перешёл. Reliability = базовая гигиена для adoption.
- **Тормоза — вторым, начиная с диагностики**: телеметрия пишется → за неделю карта «что/у кого/насколько хуже локали». 40 жалующихся — верхушка айсберга: молчуны тихо остаются на локали. Дёшево; после неё effort фикса станет известен и приоритет пересчитается честно.
- **Шаринг — в бэклог, но не в мусорку**: жанр другой — не поломка, а отсутствующая фича; 3% пользователей, разбросанных; effort большой (права, изоляция секретов, совместный терминал). Сначала понять, какую работу фича «нанимается» делать — подозреваю «вместе посмотреть на продовую проблему»; возможно, read-only доступ или шаринг логов закроет 80% за 20% усилия (похожий опыт: ✳ сессии совместной отладки инцидентов в Райфене закрылись шарингом логов и терминала).
- **Закрыть петлю**: ответить 25 людям в канале — «услышали, вот почему непросто, вот критерии, когда вернёмся». Иначе следующая жалоба улетает не в канал, а в «останусь на локали».

**Дмитрий (провокация):** А если директор скажет «шаринг — стратегически, делайте первым»?

**Сергей:** Спрошу, какая задача за этим стоит (может, «теряем команду X, нужен парный дебаг» — решение другое). Если это ставка на AI-сценарий — окей, пересчитаю приоритет и покажу цену: что откладываем (висения на 1500 человеко-инцидентов). Цена выбора часто делает решение очевидным.

**💭 Показаны: приоритет от цели продукта; числа вслух; разные жанры проблем → разные методы; молчаливое большинство; закрытие петли; HiPPO-ответ без конфликта и капитуляции — «декомпозиция давления до задачи».

## Ход 4. Измерение до/после (висения)

**Дмитрий:** Закрыли две причины. Как через месяц поймёшь, что стало лучше?

**Сергей:**
- **Baseline до релиза**: частота 5/мес (~2 класса «миграция»), длительность 5–15 мин (медиана ~8), охват 100–300. Свернул в primary: **человеко-минуты недоступности** ≈ 5 × 200 × 8 ≈ 8000/мес.
- **Критерий заранее**: «миграционные события — 0 за 4 недели, человеко-минуты −40% и больше».
- **Метод**: A/B нельзя (инфраструктурный фикс, среда общая) → **canary по пулам ёмкости** (перенос миграций сначала на 10% машин), затем до/после с поправкой на сезонность (тот же месяц год назад, тренд релизной активности; «ноль событий при выросшем трафике миграций» — ещё сильнее).
- **Guardrails**: деплой не удлинился, сторедж не ляжет в пике — иначе купили стабильность ценой скорости.
- **Качественный сигнал**: упоминания «висит» в канале; CSAT придёт с лагом квартала — подтвердит, что заметили люди, а не только дашборды.

**Дмитрий (добивка):** Миграционных — ноль, а человеко-минуты упали только на 20%?

**Сергей:** Значит, фикс сработал, а прогноз структуры проблемы — нет: остальные три причины тяжелее. Это не провал критерия, а информация. Дальше — либо копать сторедж глубже, либо идти к тебе с диаграммой: вот цена следующего шага, вот что он даст.

**💭 Все четыре кита §4: baseline до, человеко-единицы, критерий заранее, A/B нельзя → инструмент по контексту (canary + сезонные поправки). Добивка — тест на «психологию результата»: промах прогноза читается как данные, план пересобирается, цель нет.

## Ход 5. Система KPI Codenv

**Дмитрий:** Забудь про жалобы. По чему ежемесячно понимаешь, что продукт жив и хорош?

**Сергей:** Начну не с метрик, а с «зачем продукт существует»: Codenv = ноль головы на окружения. Северная звезда: **число разработчиков, для которых Codenv — основной способ работы** (≥3 рабочих дня в неделю с реальной работой: коммит, сборка). Не логины (зайти-уйти легко), не созданные окружения (действие, не результат). Сейчас ~800 из 4000.

Дерево (каждая с «что делаю, если падает»):
1. **Активация**: доля дошедших «создал окружение → первый коммит» и время до него; падает → воронка по шагам. (✳ Дикси, DevContainers: time-to-first-commit был главным маркером, снижали с ~40 минут до минут.)
2. **Глубина перехода**: доля рабочих дней с сессией; доля задач, доделанных в Codenv, а не убежавших на локаль; падает → ищу сегмент (стек, размер репо).
3. **Удержание когортами**: месячная когорта новичков через 4 недели; ушла — разбираю конкретных: самое честное зеркало.
4. **Guardrails**: доступность (человеко-минуты из хода 4 живут здесь), p95 сборки, **стоимость на разработчика в месяц** (забывают чаще всего — именно она убивает внутреннюю платформу на бюджетном срезе), CSAT; для AI-сценария — доля окружений с агентом и guardrail «не переделывает ли он за собой».

Пары-антагонисты, явно: adoption ↔ стабильность; активация ↔ стоимость (прогретые кэши); глубина ↔ p95. Без противовесов через квартал будет красивый график миграции и депрессивный CSAT.

**Дмитрий:** Через полгода директор спросит: «1800 разработчиков — сколько это в деньгах?»

**Сергей:** Два слоя: **ёмкость** — экономия времени × люди × стоимость инженера, консервативно (допущение «всего 1 час/мес на человека» → ~34 инженерных месяца в квартал; лучше заниженная правда, чем красивое «ROI 300%», которое нечем защитить); **инфраструктура** — не покупаем топ-машины и не греем их на столах. Неколичественный слой: онбординг за минуты, единая среда без «у меня локально работало».

**💭 Порядок важнее списка: сначала «зачем» → звезда из ценности → дерево с действиями → guardrails с cost-per-user (дифференциатор внутренней платформы) → пары-антагонисты вслух. Связность: доступность из хода 4 всплыла guardrail'ом — система, а не набор фактов. Ответ про деньги: ёмкость + инфра + консервативность — заготовка на обязательный вопрос директоров.

## Ход 6. Эксперимент с AI-агентом

**Дмитрий:** Запускаем агента, который сам настраивает окружение под таск. Как поймёте, что работает и стоит ли раскатывать на всех?

**Сергей:**
- **T-triplets**: меняем ручную настройку на агентную; задача — «получить готовое окружение под таск»; проверяем на создающих новые окружения.
- **Гипотеза**: p50 времени «открыл таск → готов работать» падает с ~15 до ~5–8 минут без потери качества настройки.
- **Метрики**: primary — медиана и p95 времени; guardrails — доля окружений, где после агентной настройки что-то не запускается (главный риск LLM: уверенно настроить криво), переделки руками, стоимость токенов на окружение; secondary — adoption (доля повторных включений).
- **Критерий заранее**: «раскатываем, если p50 −треть, сломанные настройки ±2 п.п. к baseline, стоимость ≤ N ₽/окружение; primary держится, guardrail нет — не раскатываем, чиним».
- **Метод**: A/B 50/50 честно посчитать нельзя — при ~60 новых окружениях/день нужны тысячи на ветку → месяцы. Поэтому: рандомизация **по пользователю** (не по окружениям — иначе перенос навыка и доверия загрязнит ветки); **staged**: 10% на 2 недели — канарейка (ловим катастрофы: сломанные настройки, SRM) → расширение до 50/50 и набор мощности; **целые недели**, минимум 4; **сегменты** — джун-онбординг vs монорепы (решение может быть «новичкам и типовым проектам», а не «всем»). Опыт жанра: агент code review — adoption рос, но guardrail «не удлиняет ли ревью и не плодит ли глупые комментарии» был критичнее (✳ Самокат): у AI-фич риск не «не понравится», а «тихо навредит — и доверие не вернётся».

**Дмитрий (добивка):** Месяц: primary −25%, не треть. Guardrails чистые.

**Сергей:** По этому критерию на всех не раскатываю — я его сам записал. Но не выкидываю: (1) сегменты — если у новичков −40%+, а у монореп ноль, решение «по сегменту, там критерий выполнен»; (2) если 25% уже упираются в одну стадию (агент ждёт кэш) — точечный фикс быстрее признания провала. Если эффект ровный — к тебе: вот цена масштабирования, вот риск; это твоё решение с моими данными, а не тихая подгонка. По опыту, треть идей вообще без эффекта — нулевой результат = сэкономленные месяцы.

**Встречный вопрос:** кто отвечает, когда агент настроил криво и человек потерял час? Заложил бы «эскалацию доверия»: сначала предлагает — человек подтверждает, потом полная автономия.

**Дмитрий:** *(закрывает ноутбук)* Спасибо. Жалобы, приоритеты, KPI, эксперименты — ровно то, зачем секция задумана.

**💭 Полный скелет §7.2 + все усилители Kohavi (T-triplets, нулевые эксперименты, OEC-логика «критерий до»); честный отказ от 50/50 с ценой; третья за час провокация «почти получилось» — та же архитектура ответа; встречный вопрос про эскалацию доверия — попадание в AI-first болевую точку команды.

**Моделирование фидбека Дмитрия:** «Структурный, считает вслух, отличает действие от ценности, держит критерии под давлением, понимает ограничения A/B и специфику внутренней платформы, все части связаны в одну систему. Продуктовое мышление инженерного лида — да. Рекомендую».

---

# Приложение: пояснения наблюдателю (сохранены из живого диалога)

## П1. North Star — подробная теория

Одна метрика, отвечающая «доставляем ли ценность, ради которой продукт существует». Главный фильтр: **исход, а не действие** (действие — кликнул/создал; исход — получил искомое). Формула: `[сколько людей], для которых [событие ценности], за [период]` — людей, не событий; период — неделя/месяц.

Примеры: такси — завершённые поездки/нед (не «заказы»: заказ может не состояться); музыка — время прослушивания/нед; Airbnb — забронированные ночи; мессенджер — люди, отправившие ≥N сообщений (сообщение = сама ценность, поэтому «действие» здесь допустимо: вопрос всегда «событие = ценность или шаг к ней?»); доставка — завершённые заказы.

Анти-примеры (ванити): регистрации, скачивания, число аккаунтов, логины, page views, число созданных окружений.

Тест из 4 вопросов к кандидату в NS: (1) стал ли пользователь успешнее в этот момент; (2) растёт ли бизнес при росте метрики; (3) может ли команда на неё влиять; (4) сложно ли нарисовать рост в обход смысла (если легко — нужны guardrails, Goodhart).

Для Codenv вслух: перебираем «число окружений» (действие), «WAU логинов» (зашёл-вышел) → звезда: число разработчиков, делающих реальную работу (коммиты) N дней в неделю.

## П2. «Зачем критерий 40%, если вышло 20%» — цель / прогноз / решение

Различать: **цель** (стабильность, −40% человеко-минут — не отменялась), **прогноз** («2 из 5 причин дают ~половину вреда» — модель проблемы, а не обещание), **решение** (что делаем по сравнению результата с критерием). Результат «миграционные = 0, всего −20%» сравнили с критерием и узнали: фикс верен, прогноз структуры неверен — остальные три причины тяжелее. Критерий сработал как детектор истины: без порога «−20%» легко объявили бы успехом.

Три честных исхода: достигнут → закрыть; нулевой/отрицательный → откат/прекращение; частично (одна часть подтверждена) → подтверждённое оставить, план пересобрать, цель не трогать. Игнор критерия выглядит наоборот: «20% — тоже успех, расходимся» — тихая переписка цели задним числом. Kohavi: ценность эксперимента — сужение неопределённости, не подтверждение.

## П3. CSAT и «сколько в деньгах» для внутренней платформы

**CSAT** = Customer Satisfaction: опрос «насколько доволен?» 1–5, метрика = доля 4–5 (для Codenv — средняя ~6/10). Не путать с NPS («порекомендовал бы») — CSAT про «доволен сейчас», для внутреннего продукта уместнее.

**Деньги — расчёт, а не число.** Кандидат не может знать бюджеты Яндекса; проверяют умение **построить расчёт**. Слой 1 (ёмкость): 1800 чел × 1 ч/мес (нарочито консервативно; реальные оценки 2–6) × 3 мес = 5400 ч ÷ 160 ч (инженерный месяц) ≈ **34 инженерных месяца за квартал** → при all-in ~400–500 тыс ₽/мес ≈ 13–17 млн ₽ возвращённой ёмкости. Слой 2 (инфра): не купленные топ-машины, унификация, кэши. Слой 3 (неколичественный): онбординг за минуты, единая среда. Почему не «ROI 300%»: у внутренней платформы нет выручки, красивый процент провоцирует «откуда цифра?» — и если за ним пусто, сгорает доверие ко всем следующим цифрам. Заниженная правда с показанной арифметикой бьёт завышенную красивость.

**ROI** = Return on Investment = (выгода − затраты)/затраты × 100%; «вложили 1 млн, вернулось 1,5 млн → 50%».

## П4. Перцентили, целые недели, SRM

**p50** (медиана) — половина случаев быстрее; «типичный пользователь». **p95** — 95% быстрее, 5% медленнее; «хвост несчастья». Пример: p50=5 мин, p95=25 мин — типично быстро, но каждый 20-й сидит полчаса; жалобы и отток рождает хвост, среднее его прячет. У AI-фич p95 критичен: редкие, но чудовищные провалы агента.

**Целые недели**: поведение циклично внутри недели (пн — всплеск новых окружений, пт — «доделать», выходные пусты). Эксперимент «с четверга по среду» даёт веткам разные наборы дней → разница метрик будет «днём недели», не фичей. Длительность = целое число недель, каждая полная.

**SRM** (Sample Ratio Mismatch): планировали 10% в лечение, в данных 14% → раздача сломана (не случайно) → группы несопоставимы → все выводы мусор, даже красивые. Первый чек после старта, до всякого анализа — как калибровка весов перед взвешиванием.

## П5. Дизайн: параллельные группы, и почему НЕ «сначала без, потом с»

Схема staged: случайные 10% — агент включён (treatment), остальные 90% — контроль; **оба мира живут одновременно** 2 недели; вся разница принадлежит фиче, потому что календарь, релизы и нагрузка общие. «Те же люди: 2 недели до, 2 недели после» — слабее: за 4 недели меняется всё (сезон, код, навык), эффект смешивается с фоном; это запасной метод (до/после, diff-in-diff) для случаев, когда групп сделать нельзя — как с инфраструктурным фиксом висений.

## П6. 50/50 vs 10/90 — математика компромисса

Мощность: Var(разности средних) = σ²/n₁ + σ²/n₂; при фиксированном N минимальна при **n₁=n₂** — контроль в 90% почти не улучшает точность (его ошибка уже мала), лечение в 10% доминирует. Числа: 1680 окружений за 4 нед → 840/840: SE = 0.049σ; 168/1512: SE = 0.081σ — в 1.67× шире → для той же MDE нужно в **~2.8× больше суммарного трафика** (штраф = (n₁+n₂)²/(4n₁n₂); для 10/90 ≈ 2.78). Для бинарных метрик то же: p(1−p)/n₁ + p(1−p)/n₂.

Так почему staged? 50/50 оптимизирует мощность; 10% — ограничение ущерба (blast radius): если агент портит каждый десятый проект, при 50% это инцидент на 400 человек и невосстановимое доверие к AI-сценарию, при 10% — откат за час. **Идеальный ответ называет обе фазы и цену:** канарейка 10% на ~2 нед (ловим катастрофы, SRM, guardrails — тонкие эффекты там не нужны) → расширение до 50/50 и набор мощности для primary. Штраф ×2.8 по выборке — плата за безопасность, проговорить цифрой.

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

- [`demo-protocol.md`](demo-protocol.md) — методика прогонов
- [`cases.md`](cases.md) — банк кейсов (кейс №1 и №5 легли в основу)
- [`../methodology.md`](../methodology.md) · [`../knowledge-base.md`](../knowledge-base.md)