TserenTserenov Skill: /bottleneck-pick
see DP.SC.045, DP.ROLE.054, DP.WP.016
Носитель методики TOC для пилота: Goldratt Five Focusing Steps + Tendon TameFlow Replenishment Cycle + Dettmer Thinking Processes. Реализует роль Аналитика ограничений (DP.ROLE.054) через пятифазный ВДВ-каскад. Источник: WP-313 (Ф1 research: Tendon «Tame Your Work Flow», Dettmer, Schragenheim, Goldratt S&T; Ф11 IntegrationGate).
Триггеры
- Пользователь открывает зонтичный РП, эпик, проект и спрашивает «что делать сначала»
- Запрос «выбери bottleneck», «что важнее», «с чего начать»
- Стратегическая сессия с отбором НЭП («какое направление сейчас bottleneck»)
- Диагност (R28) запрашивает анализ для учебного конвейера пилота
- Явный вызов
/bottleneck-pick --target WP-NNN
Принцип SC-first (главное правило)
Документо-центричный подход — анти-паттерн. Начинать со списка pending-РП = риск принять канал доставки за продукт.
Правильно: Ф2 сканирует функциональные обещания (DP.SC) ДО Ф3 (signal-scan по структуре работ). Тест: если в Constraint Brief нет ссылок на конкретные DP.SC, которые «не работают» — это провал Ф2.
API
/bottleneck-pick --target <ref> [--layer intra|platform] [--horizon <горизонт>] [--depth <1|2|3>] [--scope <direct|direct+related|full>]
Параметры
| Параметр | Default | Описание |
|---|---|---|
--target |
обязательный | WP-NNN (зонтичный РП), weekplan (текущая неделя), pilot:<account_id> (учебный конвейер пилота), b2:aisystant (вся экосистема — требует --layer=platform), c2:platform (только техника — требует --layer=platform), project-name, repo-path |
--layer |
intra | intra = внутри одной системы (constraint = фаза / РП / блок). platform = между подсистемами C2 (constraint = подсистема / handover / роль B3). Опора: memory/project_iwe_systems_map.md |
--horizon |
all | day, week, month, wave-1, wave-2, quarter, next-stage |
--depth |
2 | 1 = Five Steps only; 2 = + EC для конфликтующих кандидатов; 3 = + Coupling-analysis SOTA.011 для top-3 handovers (только при --layer=platform) |
--scope |
direct+related | direct = только target; direct+related = + связанные РП из frontmatter; full = + reachable через граф связей ≤2 hops |
Источники по типу --target
| Target | Что читает скилл | Где живёт источник |
|---|---|---|
WP-NNN |
${IWE_GOVERNANCE_REPO:-DS-strategy}/inbox/WP-NNN-*.md + связанные РП + git за 7d |
governance |
weekplan |
${IWE_GOVERNANCE_REPO:-DS-strategy}/current/WeekPlan W{N}.md + active-wp.md + DP.SC поверх активных РП |
governance |
pilot:<id> |
learning.activity_log + learning.cp_assessments + learning.bh_metrics (Neon) |
платформа (учебный конвейер) |
b2:aisystant |
03-our-systems-map.md (S2R) + DP.MAP.002 + project_iwe_systems_map.md + cross-system SC |
governance + Pack |
c2:platform |
DP.MAP.002 (12 подсистем) + 15 новых Q2 из project_iwe_systems_map.md |
Pack + memory |
Error cases
| Ситуация | Поведение |
|---|---|
| target не найден | «Не нашёл <target>. Проверь номер или путь.» → СТОП |
| target = done-РП | «<target> уже закрыт. Укажи активный РП.» → СТОП |
| target пустой (нет структуры) | «Нет структуры для анализа в <target>.» → СТОП |
| Данные устарели (>7 дней без git-активности) | Добавить ⚠️ к signal-scan, не останавливаться |
| EC не сходится (пустые assumptions) | Fallback к Five Steps, отметить в output |
| Все кандидаты не agent-actionable | «Все кандидаты не agent-actionable. Нужна другая точка входа.» |
Алгоритм — пятифазный ВДВ-каскад
Принцип ВДВ (DP.M.060): выход фазы = вход следующей. Каждый вход и выход — физический артефакт.
Ф1 — Identify system
Вход: target-ref + --layer от пользователя.
Действие:
- Классифицировать тип системы-конвейера по
--target×--layer:- Учебный конвейер пилота —
--target pilot:<id>(FORM.089 RCS, источник: Neonlearning.*) - Конвейер работ (intra) —
--target WP-NNN | weekplan | project | repo-path,--layer=intra. Структура = направления A-И / фазы Ф1-ФN / блоки внутри одного РП - Платформенный (cross-system) —
--target b2:aisystant | c2:platform | WP-NNN-зонтичный,--layer=platform. Структура = подсистемы C2 (≈27 шт) + handovers + роли B3. ⚠️ Validation: при--layer=platformобязательно загрузить карту систем (memory/project_iwe_systems_map.md+DP.MAP.002) - Когортный конвейер —
--target cohort:<id> | wave-N
- Учебный конвейер пилота —
- Собрать контекст по типу:
# intra git log --oneline --since="7 days ago" <repo> cat <target-context-file> ls <related-PROCESSES.md> # platform ls PACK-digital-platform/.../08-service-clauses/ # cross-system SC cat memory/project_iwe_systems_map.md # карта 27 подсистем git log --oneline --since="7 days ago" --all # активность по подсистемам - Зафиксировать свежесть данных. Если ≥7 дней без активности — ⚠️. При
--layer=platform: проверить свежестьDP.MAP.002(стейл >30 дней → ⚠️).
Выход: System Card (в чат + calibration YAML):
Тип системы: учебный_конвейер | конвейер_работ_intra | конвейер_работ_platform | когортный_конвейер
Target: <target-ref>
Layer: intra | platform
Структура: <направления A-И | фазы Ф1-ФN | подсистемы C2 + handovers | RCS-слоты>
Подсистемы в scope: <N штук — только при layer=platform>
Свежесть данных: <дата + flags>
Незарегистрированные подсистемы: <list — только при layer=platform, если есть>
Ф2 — Scan promises (SC-first)
Вход: System Card.
Действие:
- Найти DP.SC по типу системы:
--layer=intra(WP / эпик / репо): SC из frontmatter РП + SC, потребляемые целевыми ролями + SC внутри одной подсистемы--layer=platform(b2 / c2 / зонтичный РП): cross-system SC — DP.SC.020 retention, DP.SC.012 онбординг, DP.SC.003 обучение, Г-К1 гипотеза. Дополнительно проверить B3-to-B2 SC (команда↔экосистема) — часто не формализованы, флаг- Учебный конвейер (
pilot:): FORM.089-разделы (специализация SC) - Когортный конвейер: SC из MAP.002 для wave-rollout, adoption, lifecycle
- Для каждого SC применить тест работоспособности:
При- «Работает?» (свежесть события, наличие потребителей, отсутствие active incidents) - «Сломано?» (явный open incident, отсутствие events за N дней, негативный feedback) - «Частично?» (some consumers получают, другие — нет)--layer=platformдополнительный тест: «Сломано на handover'е?» — одна подсистема даёт выход, другая не принимает (зазор между Bot и GitHub App, между Profiler и Stage Evaluator, и т.д.). - Пометить SC-failing и SC-partial как кандидатов в bottleneck.
Выход: SC-status map (формат зависит от --layer):
Для --layer=intra:
| SC ID | Обещание | Статус | Сигнал |
|---------------|------------------------------------|--------------|----------------------------------------|
| DP.SC.020 | Доставка персонального руководства| ⚠️ Partial | 5/9 пилотов не активировали репо |
| DP.SC.132 | Диагностика ученика | ✅ Works | cp_assessments записываются ежедневно |
| DP.SC.044 | Event ingest | ⚠️ Partial | subscription.contract_event = 0 строк |
Для --layer=platform (cross-system path):
| SC | Cross-system path | Статус | Слабое звено |
|-------------|----------------------------------------------------|--------------|-------------------------------------------|
| DP.SC.020 | Bot → /personal-guide-start → GitHub App → repo | ⚠️ Partial | handover Bot↔GitHub App (6/9 не активир.) |
| Г-К1 | Bot → Onboarding → Profiler → Stage Eval → Nudge | ❌ FAIL | отсутствует Nudge (WP-117 не запущен) |
| DP.SC.112 | YooKassa → Bot → CRM → Access Manager | ✅ Works | стабильно |
Ф3 — Identify constraint
Вход: SC-status map + структура работ из System Card.
Действие:
- Для каждого SC-failing/partial и каждого блока структуры (направление / фаза / РП / подсистема / handover) — signal-scan по сигналам TameFlow (порядок по predictive value):
| # | Сигнал | Триггер | Применим |
|---|---|---|---|
| 1 | Queue accumulation rate | Δ queue length / 7d ≥30% рост | все |
| 2 | Flow Efficiency drop | touch/lead <15% или Δ −10pp/неделю | все |
| 3 | Dependency fan-in / handover count | >3 handover в одном user journey = policy issue | все |
| 4 | Buffer consumption rate | CCPM fever chart: Жёлтый→monitor, Красный→act | все |
| 5 | Policy freeze markers | NLP-поиск: «требует согласования», «у нас принято», «правило» | все |
| 6 | Cognitive freeze | рост открытых вопросов без решений, признаки прокрастинации | все |
| 7 | Cross-system handover count | handovers >3 на user journey между подсистемами C2 = systemic | --layer=platform only |
| 8 | Coupling tightness (SOTA.011) | SC одного слоя зависит от внутренней реализации другого = tight coupling, candidate handover-constraint | --layer=platform only |
- Top-3 кандидата по суммарному сигналу.
- Классифицировать каждого:
- Trichotomy (Tendon): Work Flow / Work Process / Work Execution
- Class: Policy / Resource / Cognitive
- При
--layer=platformдополнительно — Locus (где сидит ограничение):Subsystem(одна подсистема C2 — узкое место) /Handover(две подсистемы работают, между ними рвётся SC) /Role(B3)(подсистема есть, но роль в команде не назначена / перегружена)
- FILTER: убрать не agent-actionable (внешняя блокировка, нет actionable шагов в 2-4h, done-блок).
Выход: Constraint Brief draft (top-3 + классификация + сигналы; для --layer=platform также Locus).
Ф4 — Choose TOC tool
Вход: Constraint Brief draft.
Действие — Decision tree:
[Все --layer]
Очевиден слабейший этап + данные есть?
→ Five Steps (linear)
≥2 policy-markers ИЛИ cognitive-freeze сигнал высокий?
→ Five Steps + EC
2 кандидата равны, нет явного «кто слабее»?
→ EC (core conflict)
«Exploit» интуитивно = «нанять/купить» (инстинкт к Elevate)?
→ EC first (маркер: policy-constraint)
Решение очевидно, но есть риск side-effects?
→ Five Steps + NBR
[--layer=platform только]
Locus = Subsystem отсутствует (WP не существует под нужную SC)?
→ Five Steps + WP Gate Ритуал (нужно новое РП на создание подсистемы)
Locus = Handover между 2 подсистемами?
→ EC обязательно: D = «починить подсистему A» vs D' = «починить подсистему B»
→ + Coupling-analysis SOTA.011 при --depth=3: можно ли убрать handover вообще?
Locus = Role(B3) перегружена?
→ EC: D = «нанять» vs D' = «автоматизировать роль»
→ NBR обязательно (риск heavy-coordination overhead)
Все подсистемы стабильны, но cross-system SC не выполняется?
→ Goldratt S&T Tree: missing assumptions (нет SC, не зафиксировано обещание)
Если EC: Quality gate ≥2 assumption на сторону:
A (Common Goal): ...
B (Need): ... C (Need): ...
D (Want): ... D' (Want): ...
Assumptions D→B: ...
Assumptions D'→C: ...
Injection: ... (в assumption, не в action)
Пустые / абстрактные assumptions → retry или fallback к Five Steps. EC только на actions, не на values.
NBR (обязательно после injection): 3 negative branches + trim:
1. [риск 1] → trim: [как нейтрализовать]
2. [риск 2] → trim: [как нейтрализовать]
3. [риск 3] → trim: [как нейтрализовать]
Выход: TOC tool trace (инструмент + EC details если применён + NBR-trims).
Ф5 — Compose stage map
Вход: Constraint Brief + TOC tool trace + список зависимостей (включая external).
Действие:
- Идентифицировать этапы достижения целевого состояния (устранения ограничения):
- Этап = состояние системы, не действие («Активация ≥5 пилотов» ≠ «Активировать пилотов»)
- Внутри узла — параллельные работы по жёсткому шаблону 4 категорий (см. ниже)
- Между узлами — жёсткая зависимость («иначе не сможем», не «желательно»)
- Внутри каждого этапа распределить параллельные работы по 4 канонам TOC/Dettmer (всегда показывать все 4, пустая = «—»):
- Техника (Platform/Technical) — код, инфраструктура, архитектура, интеграции, CI/CD, data pipelines
- Процессы (Organizational/Process) — процессы, коммуникации, координация между ролями, пользовательское тестирование, onboarding
- Правила (Policy/Governance) — стандарты, архитектурные решения, согласования, изменения политики
- Навыки (Cognitive/Capability) — обучение, документация, ментальные модели, формирование различений
- Определить external-зависимости — от работ в других РП, репо, внешних поставщиков (отдельный блок, всегда показывать)
- При
--layer=platform— параллельная ось Locus для каждого этапа: Subsystem / Handover / Role(B3) — кто конкретно меняется - Построить граф (формат DP.WP.016): узлы=этапы, рёбра=hard_dependency, external-рёбра явные
- Топологическая сортировка обязательна (нет циклов)
Принцип жёсткого шаблона: все 4 категории всегда показываются, даже пустые («—»). Аналогия: чек-лист безопасности самолёта — пункт «проверить шасси» оставляется даже для гидросамолёта, чтобы видно было что не забыли. Жёсткий шаблон ставит аудит-надёжность выше краткости.
Выход: Stage Dependency Map (формат DP.WP.016) — в чате как markdown + опционально в ${IWE_GOVERNANCE_REPO:-DS-strategy}/inbox/WP-NNN/stage-map.md:
## Stage Dependency Map: <target> (layer: intra | platform)
### Этап 1: <label-существительное-артефакт>
**Цель:** <состояние после этапа>
**Категории работ (жёсткий шаблон — всегда 4):**
**1. Техника (Platform):**
- работа A
- работа B (WP-NNN)
**2. Процессы (Process):**
- —
**3. Правила (Policy):**
- работа C → требует /archgate
**4. Навыки (Cognitive):**
- —
**External-зависимости:** <target в другом репо | нет>
[Только при --layer=platform — дополнительная ось:]
**Locus:**
- Subsystem: <подсистема X> — изменение внутри одной системы
- Handover: <A↔B> — изменение в зазоре между системами
- Role(B3): <роль> — изменение в команде
### → Этап 2: <label>
> Может начаться только после завершения Этапа 1 (причина: <reason>)
...
Output (полный артефакт, выводится в чат)
## System Card
**Тип системы:** учебный_конвейер | конвейер_работ_intra | конвейер_работ_platform | когортный_конвейер
**Target:** <target-ref>
**Layer:** intra | platform
**Структура:** <направления A-И | фазы | подсистемы C2 + handovers>
**Подсистемы в scope:** <N — только при layer=platform>
**Свежесть данных:** <дата + flags>
## SC-status map (Ф2 SC-first)
[--layer=intra:]
| SC | Обещание | Статус | Сигнал |
| --- | --- | --- | --- |
| DP.SC.NNN | ... | ✅/⚠️/❌ | ... |
[--layer=platform — cross-system path:]
| SC | Cross-system path | Статус | Слабое звено |
| --- | --- | --- | --- |
| DP.SC.020 | A → B → C → D | ⚠️ | handover B↔C |
## Constraint Brief
**Bottleneck:** <блок / направление / фаза / подсистема / handover / роль>
**Trichotomy:** Work Flow | Work Process | Work Execution
**Class:** Policy | Resource | Cognitive
**Locus:** Subsystem | Handover | Role(B3) [только при layer=platform]
**Затронутые SC:** [DP.SC.NNN, ...]
### Signal-scan
- Queue accumulation: <Δ за 7d или «нет данных»>
- Flow Efficiency: <% или «нет данных»>
- Dependency fan-in: <N handovers>
- Policy markers: <keywords или «нет»>
- Buffer: <статус или «нет данных»>
- Cognitive freeze: <признаки или «нет»>
- Handover count (cross-system): <N на user journey> [только при layer=platform]
- Coupling tightness (SOTA.011): low | medium | high [только при layer=platform]
## TOC tool: Five Steps | EC | Five Steps + EC | + Coupling-analysis
[Если EC:]
### EC — core conflict
**A:** ... **B:** ... **C:** ... **D:** ... **D':** ...
**Assumptions D→B:** ...
**Assumptions D'→C:** ...
**Injection:** ...
### NBR
1. <риск> → trim: ...
2. <риск> → trim: ...
3. <риск> → trim: ...
## Stage Dependency Map (DP.WP.016)
### Этап 1: <label>
**Цель:** ...
**Категории работ (жёсткий шаблон — всегда 4):**
**1. Техника (Platform):** ...
**2. Процессы (Process):** ...
**3. Правила (Policy):** ...
**4. Навыки (Cognitive):** ...
**External-зависимости:** ...
**Locus:** Subsystem | Handover | Role(B3) [только при layer=platform]
### → Этап 2: <label>
> Может начаться только после завершения Этапа 1 (причина: ...)
...
## Альтернативы (P2/P3 кандидаты)
- ...
## Skipped (не agent-actionable)
- ...
**Бюджет первого этапа: ~Nh**
---
Делаем Этап 1 «<label>» или хочешь начать с альтернативы P2 «<...>»?
Anti-patterns
- WP-сканирование без SC-first — начать со списка pending-РП без проверки функциональных обещаний. Риск: принять канал доставки за продукт.
- Stage Map с датами/часами — формат структурный, не временной. Даты → premature commitment.
- Soft-зависимости в edges — только
hard_dependency. «Желательно сначала» = они в одном этапе или независимы. - Skip Subordinate → Elevate («нанять больше людей» как первый вывод) — exploit capacity сначала.
- Policy mis-classified as Resource — нанимать когда надо менять правила. Применять discriminator из Schragenheim.
- Moving Herbie без policy-диагноза — если bottleneck мигрировал 2+ раз → policy-driven, не resource.
- EC с пустыми assumptions — retry или fallback к Five Steps.
- Five Steps на cognitive freeze — не ускорять flow, а упростить challenge или нарастить навык.
- Output >1 экрана для Constraint Brief — сжимать, не разворачивать дерево целиком (Stage Map может быть длиннее).
- EC на values (D/D' = «гибкость» vs «стабильность») — переформулировать в actions.
- Stage Dependency Map без external-зависимостей — если этап реально зависит от работ в другом РП — явное external-ребро.
- Stage Map с пустой категорией без «—» (мягкий шаблон) — нельзя отличить «забыл подумать» от «решил пропустить». Жёсткий шаблон: всегда 4 категории, пустая = «—».
- [platform-only] Сводить platform к одной системе — выбирать одну подсистему C2 как bottleneck без проверки cross-system SC. Симптом: ответ «WP-117 = bottleneck» без объяснения какие SC он закрывает.
- [platform-only] B3-blindness — bottleneck в роли (Юля, Ильшат, Tseren bus-factor) пропускается, потому что роли не в MAP.002. Force: явно проверить B3 в Ф3.
- [platform-only] Handover-blindness — обе подсистемы работают, но между ними рвётся SC. Force: handover = отдельная единица анализа в Locus.
- [platform-only] «Нанять менеджера» как первый Elevate для Role-constraint — Role(B3) решается через автоматизацию роли (subsystem), не через найм. Force: EC обязателен для Role-constraint.
- [platform-only] Coupling debt accumulation — Subordinate-plan не учитывает coupling-debt после фикса (SOTA.011). Force:
--depth=3с Coupling Model для Handover-constraint.
Calibration (после каждого применения)
Сохранить в ${IWE_GOVERNANCE_REPO:-DS-strategy}/inbox/bottleneck-pick-runs/<YYYY-MM-DD>-<target>.yaml:
date: YYYY-MM-DD
target: <target-ref>
layer: intra | platform
system_type: учебный_конвейер | конвейер_работ_intra | конвейер_работ_platform | когортный_конвейер
subsystems_in_scope: N # только при layer=platform
sc_failing: [DP.SC.NNN, ...] # из Ф2
identified_constraint:
location: <блок | подсистема | handover | роль>
trichotomy: work_flow | work_process | work_execution
class: policy | resource | cognitive
locus: subsystem | handover | role_b3 # только при layer=platform
instruments_used: [five_steps, ec, nbr, coupling_analysis]
stage_dependency_map:
num_stages: N
has_external_deps: true | false
categories_filled: [platform, process, policy, cognitive] # какие из 4 не пустые
action_taken: <что сделали>
was_correct: null # заполняется на Week Close
observed_throughput_change_after_2w: null
bottleneck_shifted_to: null # заполняется через 2 недели
После 5–10 runs → анализ precision на Week Close, recalibration весов сигналов.
Интеграция
- Bottleneck = архитектурное решение (тип Policy с alternatives) → предложить
/archgate - Stage Map содержит open-loop работу ≥3h → предложить Декомпозитору (
/decompose) для декомпозиции на физические артефакты - Bottleneck = нет покрывающего РП → предложить WP Gate ритуал
- Bottleneck-shift detection (повторное применение к той же target после fix) → DP.M.061 переоценка слоя (tech/operational/usage/поведенческий)
Связанные документы (Pack)
- DP.ROLE.054 — Аналитик ограничений (носитель методики)
- DP.SC.045 — обещание Constraint Analysis (что выдаём потребителю)
- DP.WP.016 — формат Stage Dependency Map
- DP.M.061 — Bottleneck-Shift Detection (поддерживающий метод после устранения ограничения)
- PD.PRINC.046 — Mental Model as Constraint (Tendon)
Staging
STAGING.md: S-42, status: testing
Промоция после: ≥2 smoke (выполнено) + ≥1 калибровочная сессия + пилот принял ≥3 выбора без редиректа + Pack-артефакты оформлены (выполнено Ф11).