TL;DR. Когда системный аналитик приходит к новому проекту с 4-5 разнородными источниками — PDF-контрактом, устаревшей Confluence-страницей, POC на Git и цепочкой писем с саппортом провайдера — обычная инвентаризация занимает 2-3 рабочих дня. Ниже — метод сборки System Context Pack (SCP) за час: карта источников с датой и статусом, структурированные утверждения с цитатами, отдельный слой Review Findings для противоречий и Task Pack с open questions к бизнесу. Разбор на реальном кейсе интеграции с эквайрингом Acme Pay v2.1. Все четыре источника, POC-код и готовые артефакты — открыты (ссылка на архив в конце статьи). Читаете параллельно, применяете к своему проекту. Без AI-инструмента; в конце — как то же самое делает Подмастерье аналитика.

---

1. Проблема: как обычно собирают контекст перед разработкой

Знакомая ситуация. К вам приходит задача: продуктовая команда собрала POC интеграции с внешним провайдером год назад, теперь нужно вывести в production. За это время:

• Провайдер выпустил новую версию API (v1 → v2.1).

• Часть договорённостей с саппортом лежит в почте PM.

• Автор POC уволился, code review проводили «на глаз».

• Confluence-страница на тему написана до релиза v2 и помечена «устарел» руками стажёра, который её не переписывал.

Что происходит дальше в среднем проекте:

1. Аналитик открывает Confluence-страницу первой (она в закладках, привычно). Читает 40 минут.

2. Обнаруживает, что страница про v1. Идёт искать v2.

3. Находит официальный PDF-контракт. 47 страниц. Читает ещё 90 минут.

4. Идёт в Git смотреть, как реализован POC. Ловит на глаз, что base URL всё ещё /v1/, а auth — API Key вместо OAuth. Помечает «надо переделать».

5. Пишет вопросы в чат PM. PM отвечает: «ой, ты почитай там переписку с Сергеем (account manager Acme) с марта, там есть уточнения». Пересылает 5 писем.

6. Ещё 40 минут на почту.

7. Аналитик садится собирать сводную таблицу. Замечает первое противоречие. Час ищет, что правда.

8. К концу дня 1 — примерная картина есть в голове, но структурировано только частично.

К концу дня 2-3 обычно рождается либо документ «SDD на 30 страниц», который читают полтора человека, либо набор ad-hoc Jira-эпиков со ссылками на PDF без цитат. И там, и там теряются противоречия, которые аналитик увидел в моменте, но не зафиксировал явно.

Через месяц на code review разработчик спрашивает: «А почему Idempotency-Key не передаётся, вы же требуете?» — аналитик открывает свой SDD и не находит. Помнит, что «это где-то было», но не помнит где. Идёт в PDF, ищет заново. Находит. Отправляет ссылку.

Проблема не в дисциплине. Проблема в том, что нет дешёвого способа зафиксировать источник, дату и текстовую цитату для каждого утверждения. Все инструменты — от Confluence-шаблонов до BABOK-техник — про содержание требований, но не про их трассируемость до источника.

2. Метод: четыре артефакта

Метод, который я использую последние два года и который лёг в основу продукта, называется System Context Pack. Четыре последовательных артефакта:

Source map. Плоская таблица источников проекта: ID, тип, дата обновления, статус (актуальный / устарел / требует проверки), owner. Собирается за 15 минут первой. Без source map остальное не имеет смысла — потому что не понятно, чему верить.

System Context Pack (SCP). Структурированный документ (обычно markdown или Confluence) с фактами о проекте, разбитыми по функциональным областям. Каждый факт снабжён явной цитатой источника — либо ссылкой на пункт PDF, либо inline-цитатой из письма. Противоречия между источниками не разрешаются молча — они помечаются знаком ⚠ и уходят в следующий слой.

Review Findings. Отдельный список находок четырёх типов: противоречие (два источника говорят разное), пробел (важное условие упоминается, но нигде не определено), неоднозначность (одну формулировку можно прочитать двумя способами), риск (условие есть, но выполнение под вопросом). У каждой находки — severity (HIGH / MEDIUM / LOW) и предлагаемое действие.

Task Pack. Заготовка постановки, которую можно принести PM и разработке. Содержит: scope, functional requirements с цитатами, open questions к заказчику, риски, оценку, acceptance criteria.

Метод не про AI. Его можно вести в Confluence-таблицах и Markdown-файлах руками — что я и делал два года подряд, прежде чем начал строить инструмент. AI ускоряет сборку, но методологический слой первичен.

Дальше — как это выглядит на реальном кейсе.

3. Кейс: интеграция с эквайрингом Acme Pay v2.1

Задача, которую разберём: продуктовая команда год назад (октябрь 2025) собрала POC с эквайрингом Acme Pay. Использовали v1 API. К июлю 2026 нужен production-релиз.

За полтора года Acme:

• выпустил v2.1 API с обязательной миграцией с v1 (sunset 01.09.2026),

• поменял auth-схему (API Key → OAuth 2.0 Client Credentials),

• сделал Idempotency-Key и customer_id обязательными,

• ввёл webhook signature (HMAC-SHA256),

• добавил Apple Pay / Google Pay / SBP.

Автор POC уволился. У нас в наследство:

• PDF официального контракта v2.1 от 12.03.2026 (47 стр).

• Confluence-страница «Acme Pay v1» от 17.10.2025, помечена как «устарел».

• Репозиторий POC — github.com/InnokentyB/acme_poc, последний коммит 22.10.2025.

• Пять писем с account manager Acme (Сергей) и support за март 2026.

Дедлайн — июль 2026, старт разработки — май 2026. То есть у аналитика есть примерно полтора месяца до старта, чтобы принести разработке чистый Task Pack. По классической схеме — 2-3 дня на разбор источников, потом неделя на согласования, потом Jira-эпики.

По методу SCP — час на связку четырёх артефактов до состояния, в котором с ними можно идти к PM.

Если хотите пройти этот путь вместе со мной по мере чтения — все четыре источника открыты и лежат одним архивом: analystcraft.ru/files/klub-2026-06-28-acme-pay-inputs.zip (235 КБ, ~24 файла). Внутри — PDF-контракт, md-исходники Confluence и email-треда, полный код POC и краткий overview кейса. Ссылки на всё остальное (repo POC на GitHub, handout PDF, готовые артефакты) — в самом конце статьи.

4. Шаг 1 — Source map (0-15 минут)

Первое, что делаю — таблица источников. Пять столбцов, ничего лишнего.

Что тут важно и что часто теряется:

«Статус» — обязательное поле. Не «есть/нет», а функциональная оценка: актуальный, устарел, актуален с оговоркой. По кейсу — S02 явно устарел (описывает v1, а мы мигрируем на v2.1), но полностью исключить его нельзя — там есть контакты, дизайн-решения предыдущей команды, история compromise. Он не «мусор», он «архив».

Дата — это не «когда открыл», а «когда обновлён источник». По кейсу с этой датой я сразу вижу: S02 писан за 5 месяцев до выхода v2, до релиза значимо. Значит, всё, что там про API — не верить без сверки с S01.

S04 (email-тред) — не «приложение», а полноценный источник. По моей практике, в email/чатах живёт 20-30% реальных договорённостей: rate limits, retry policy webhook-ов, corner-cases. Если не завести email в source map — их не будет ни в SCP, ни в Task Pack.

Идентификаторы S01–S04 дальше используются как якоря во всех артефактах. Так работает трассировка «утверждение → источник».

15 минут закладываю на сбор и оценку каждого источника — открыть, глянуть заголовок и оглавление, определить дату и статус. Не читать полностью, а именно классифицировать.

5. Шаг 2 — System Context Pack (15-45 минут)

SCP — это плоский markdown-файл с блоками по функциональным областям. По кейсу Acme Pay у нас 10 областей: authentication, создание платежа, webhooks, rate limits, chargebacks, PCI, валюты, tokenization для recurring, Apple Pay / SBP, sunset v1.

Каждая область структурирована одинаково. Пример из реального SCP:

markdown

## 1. Authentication

### 1.1 Auth flow в v2.1 — OAuth 2.0 Client Credentials

**Утверждение:** В v2.1 используется OAuth 2.0 Client Credentials Grant.
Access_token возвращается endpoint'ом POST /v2/oauth/token с Basic Auth
client_id/client_secret. Токен передаётся в header Authorization: Bearer {token}.

**Источник:** S01 §2.1.

### 1.2 ⚠ Auth token lifetime — конфликт источников

**Утверждение:** Auth token действует 4 часа (не 24, как указано
в публичной документации).

**Источники в конфликте:**
- S01 §2.1: "expires_in": 86400 (24 часа).
- S04 письмо Сергея 11.03: «Auth token lifetime изменили с 24 часов
  до 4 часов с релиза 2.1 (12 марта 2026). Документация в публичном
  reference ещё не обновлена».

**Resolution:** мастер берёт значение из email (более свежее),
запрашивает от Acme письменное подтверждение, обновляет свою
документацию. Передано как RF-01.

### 1.3 Хранение client_secret

**Утверждение:** client_secret хранится в secret manager. Ротация
раз в 90 дней.

**Источник:** S01 §2.3.

Что здесь работает:

Каждое утверждение — отдельный блок. Не абзац сплошного текста. Если через месяц разработчик спросит «а откуда мы взяли 4 часа», аналитик открывает SCP, находит блок 1.2, видит источник, копирует ссылку. 15 секунд, а не 30 минут.

Знак ⚠ — маркер противоречия. Как только вижу, что источники говорят разное — ставлю маркер, описываю оба источника (не сглаживая), указываю ссылку RF-XX на будущую находку. Само противоречие не разрешаю в SCP — это работа Review Findings.

«Источник» — это не общее упоминание документа, а конкретное место. «S01 §2.1» — параграф в PDF. «S04 письмо Сергея 11.03» — конкретное письмо, найденное по дате. По коду — путь и имя переменной: S03: git/poc/src/acme/client.ts, hardcoded 'RUB' в currency. Общее упоминание («см. PDF») означает, что читатель не сможет проверить утверждение без вас.

Вот пример конфликта посложнее — конфликт трёх источников по обязательности поля customer_id:

markdown

### 2.5 ⚠ customer_id — конфликт по обязательности

**Утверждение:** customer_id обязателен в v2.1.

**Источники в конфликте:**
- S01 §3.1: «обязателен начиная с v2.0».
- S02 §«Создание платежа»: «опциональное поле».
- S04 письмо Acme_Support от 17.03: «без customer_id recurring
  невозможен».
- S03 git: `// customer_id не передаём в POC`.

**Resolution:** v2.1 требует customer_id всегда. POC нужно
переделать. Передано как RF-03.

Обратите внимание: S02 (устаревшая Confluence) остался в списке как источник. Не «зачёркнут за неактуальностью». Это важно — если разработчик или другой аналитик через полгода откроет Confluence-страницу и найдёт там «опциональное поле», у него не будет когнитивного диссонанса. В SCP явно зафиксировано: да, Confluence так говорит, потому что она про v1, и это одно из противоречий, разрешённых в пользу свежих источников.

Отдельно про Note. У некоторых утверждений в SCP есть примечание с > Note: — контекстная сноска для будущих читателей. Например:

markdown

### 2.7 Checkout session lifetime

**Утверждение:** 30 минут с момента создания.

**Источник:** S01 §3.1.

> Note: S02 упоминает «до часа в письме», но точное значение
> для v2.1 — 30 минут (по S01).

Такие Note снимают вопросы вида «а где-то встречал час?» без разрастания секции. Ключевое утверждение — 30 минут. Note — почему видели другое число.

Время на SCP по кейсу — примерно 30 минут (10 областей, среднее 5-10 утверждений в области, у трети — конфликты источников). Три активности параллельно: чтение источников, экстракция утверждений, простановка ссылок.

6. Шаг 3 — Review Findings (45-55 минут)

Пока идёт SCP, я в отдельном файле собираю параллельный слой — Review Findings. Каждый маркер ⚠ в SCP порождает запись здесь.

Структура записи:

markdown

## RF-01 — Auth token lifetime: PDF vs email

**Тип:** Противоречие источников.
**Severity:** HIGH.
**Область:** Authentication.

**Что:** Две активные версии значения auth token lifetime.
- S01 §2.1 (PDF, 12.03.2026): `"expires_in": 86400` (24 часа).
- S04 письмо Сергея 11.03: «изменили с 24 часов до 4 часов с релиза
  2.1; публичная документация не обновлена».

**Влияние:** Если разработка сделает по PDF (24 часа) — токен
протухнет через 4 часа в production. Ошибка `auth_token_expired`
на всех запросах. Downtime до починки.

**Предлагаемое действие:**
1. Запросить у Сергея (account manager Acme) письменное подтверждение
   значения auth token lifetime в v2.1 (форма: email).
2. Обновить SCP §1.2 после подтверждения.
3. В client логике реализовать refresh за 30 мин до истечения
   (не за 60 — окно короче обычного).

**Отвечает:** аналитик (шаг 1), tech lead backend (шаг 3).
**Статус:** open.

По кейсу вышло 10 находок. Пять из них — HIGH severity, то есть блокеры production:

Пять HIGH — это про то, что нельзя запускать production до их закрытия. Аналитик не решает их сам — он приносит их PM и разработке как список конкретных вопросов и действий.

Дальше — важный принцип. Аналитик в этом кейсе конкретно не имеет права выбрать «правду» единолично. Что делать с customer_id, если Confluence говорит «опциональное», а Acme говорит «recurring без него не работает»? С точки зрения регламента — доверяем свежему источнику (email саппорта). Но окончательное решение — это диалог с PM и разработкой: успеваем ли мы переделать POC под обязательный customer_id к дедлайну, или запрашиваем у Acme временное послабление (обычно нет, но спрашивать надо).

Разделение труда:

• SCP: аналитик фиксирует, что говорит каждый источник.

• Review Findings: аналитик классифицирует противоречия и оценивает severity.

• Решение: совместно с PM и tech lead — по каждому HIGH-blocker отдельно.

Это разграничение — единственное, что защищает аналитика от ситуации «ты же читал документацию, что ж не увидел». Он увидел, зафиксировал в SCP §1.2, поднял в RF-01. Решение по RF-01 — это уже не его единоличная зона ответственности.

Time budget: 10 минут на 10 находок при готовом SCP. Основная работа сделана в шаге 2 — тут только формализовать.

7. Шаг 4 — Task Pack (55-60 минут)

Финальный артефакт — заготовка постановки. Она идёт PM и разработке. Формат — тот, в котором ваша команда уже читает постановки: Jira epic, Confluence-страница, markdown в GitHub, что угодно.

Структура Task Pack:

• Scope. Что в этом инкременте, что явно нет.

• Functional requirements. С цитатами на источники и ссылками на SCP.

• Non-functional requirements. Безопасность, performance, availability, compliance.

• Open questions к заказчику. Явный список.

• Risks. Из Review Findings, отсортированные по severity.

• Assumptions. Что мы принимаем без подтверждения (и что случится, если предположение окажется неверным).

• Acceptance criteria.

• Estimation.

По кейсу Acme Pay в Open questions пошло 7 пунктов:

1. Какой максимальный срок жизни checkout session устраивает бизнес? (Acme даёт максимум 30 минут — успеваем ли пользователи закончить оплату?)

2. Кто отвечает за PCI compliance процедурно — платёжный partner в компании или security team?

3. Operational flow chargeback-ов — кто из команды собирает evidence в 7-дневный срок Acme? (не «team», а конкретный человек, потому что 7 дней — очень мало).

4. Какие валюты включаем в текущую итерацию? (В POC хардкод RUB, Acme поддерживает 6 валют. Мультивалютность = отдельный дизайн-скоуп.)

5. Fallback при недоступности Acme — ручное переключение оператором или автоматика (retry, dead-letter, human-in-the-loop)?

6. Анонимные платежи (guest checkout) — есть ли в продукте? Если да, как формировать customer_id, который теперь обязателен?

7. Письменное подтверждение от Acme нового значения auth token lifetime (4h вместо 24h) — можно ли получить в течение недели?

Это те вопросы, ответы на которые нельзя выудить ни из PDF, ни из Confluence, ни из POC. Они существуют только на пересечении бизнес-контекста и техрешений. И именно они экономят разработке 2-3 недели переделок в конце — если задать их до старта разработки, а не после первого демо.

Time budget на Task Pack при готовых SCP и Review Findings — 5-10 минут. Основная работа — переструктурировать материал под формат команды и добавить бизнес-специфичные open questions.

8. Что получилось за час

Спустя час у меня на руках:

• Source map (4 источника с типом, датой, статусом).

• SCP (10 функциональных областей, ~40 утверждений с цитатами, 10 помеченных конфликтов).

• Review Findings (10 находок, 5 HIGH-severity).

• Task Pack draft (scope, 30+ functional requirements, 7 open questions, риски).

Что не сделано за этот час:

• Не сняты open questions с PM и разработкой.

• Не проведён sanity check с tech lead по assumptions.

• Не согласован scope и estimation.

• Не оценены RF-blockers на предмет закрытия к дедлайну.

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

Часовой Task Pack — это не финальный документ. Это фундамент, стоя на котором можно вести все остальные разговоры. Разница между «часовой Task Pack» и «двухдневный SDD» — в том, что первый явно показывает, чего не хватает, и куда идти дальше. Второй пытается создать иллюзию, что информация уже есть.

9. А что делает Подмастерье

До этого места ничего в тексте не требует AI-инструмента. Метод — про дисциплину и трассируемость, а не про модели.

Инструмент, который я разрабатываю параллельно с ведением метода уже полтора года — Подмастерье аналитика (AnalystCraft Coworker) — берёт на себя механическую часть:

• Индексация источников локально (Project-local RAG). Загружаете 4 файла — на выходе поисковый индекс на машине без выгрузки в облако. По ключевым запросам («auth token lifetime», «customer_id required», «webhook signature») — быстрый поиск с цитатами.

• Генерация первичного черновика SCP. Разбиение на функциональные области, экстракция утверждений с ссылками. Занимает 5-7 минут вместо ручных 30. Дальше мастер редактирует.

• Автоматическое обнаружение противоречий. По одним и тем же семантическим маркерам между источниками — модель находит места, где источники говорят разное. В моей выборке из 30+ реальных кейсов — покрытие ~80% ручных находок. Оставшиеся 20% — это тонкие противоречия, которые модель пока не видит; они всё ещё требуют аналитика.

• Approval gate. Перед каждой отправкой чего-либо во внешнюю модель (gpt-4, claude, любая по BYOK) — экран selected chunks: «сейчас уйдёт вот эти 4 фрагмента, раскрыть, отменить». Никаких «оно само что-то отправило».

Что Подмастерье не делает:

• Не принимает решения по разрешению противоречий. Показывает оба источника, помечает severity, оставляет решение мастеру.

• Не пишет финальную постановку. Готовит заготовку — мастер проверяет и доводит.

• Не заменяет диалог с PM и разработкой по open questions.

Экономия времени — с 60 минут до 14-20 минут (три-четырёхкратная), если у вас есть готовый метод. Если метода нет — экономия меньше, потому что редактирование черновика без критериев занимает столько же, сколько сборка с нуля.

Сейчас Подмастерье в закрытой alpha. Первый поток практикума мастерской стартует 14 июля 2026, запись открыта на analystcraft.ru/coworker/practicum. Кто хочет попробовать без практикума — лист ожидания там же на /coworker.

10. Что взять из статьи для своей работы

Пять вещей, которые можно применить с завтрашнего дня без всяких AI-инструментов:

1. Начинайте с source map. Пять минут на плоскую таблицу источников экономят вам 2-3 часа блужданий по устаревшим документам.

2. Каждое утверждение — с явной цитатой источника. Не «см. PDF», а «S01 §3.1». Через неделю вы сами не вспомните, где что было — и это нормально.

3. Противоречия не сглаживайте. Отдельный слой Review Findings с явным HIGH / MEDIUM / LOW — единственный способ не забыть о них к моменту разработки.

4. Open questions вычленяйте отдельно. Именно их вы принесёте PM. Если Task Pack не заканчивается списком open questions — вы либо гений, либо что-то не увидели.

5. Не пишите SDD «на всякий случай». Пишите Task Pack, который снимает конкретные open questions для конкретной команды. 5 страниц с цитатами полезнее 30 страниц без них.

Полный кейс Acme Pay — все четыре источника, POC-код, готовые артефакты SCP / Review Findings / Task Pack — открыты для скачивания. Можете взять и провести упражнение у себя или на команде.

• Архив с вводными и артефактами (235 КБ, 24 файла): analystcraft.ru/files/klub-2026-06-28-acme-pay-inputs.zip. Внутри: 00-CASE-OVERVIEW.pdf (обзор кейса, роли, дедлайны), четыре источника с префиксом S01–S04 (PDF-контракт v2.1, Confluence v1, POC repo, email-тред), готовые артефакты 05-scp-example.md / 06-review-findings.md / 07-task-pack-draft.md для сверки после собственной попытки, и README.md с инструкцией. Кейс синтетический (компания, имена, домены вымышлены), паттерны противоречий — реальные.

• Handout PDF (одностраничная выжимка SCP, была раздача участникам митапа): analystcraft.ru/files/klub-2026-06-28-scp-handout.pdf

• POC repo на GitHub (публичная копия для верификации): github.com/InnokentyB/acme_poc

Метод я применяю сейчас на своих проектах и на кейсах участников практикума. Если у вас есть проект, где 4-5 источников и вы задумались — «как бы это структурировать», — приходите в комментарии, разберём.

---

Об авторе. Иннокентий Бодров — автор Аналитической мастерской и Подмастерья аналитика (AnalystCraft Coworker). Сейчас — Senior PM в Sumsub (RegTech, AI evaluation infrastructure). Раньше — Director of Product в Finom и 13 лет системным аналитиком в enterprise IT. С 2021 веду курс «Системный аналитик. Advanced» в OTUS (2 000+ студентов), программный директор конференции EpicHey! Lisbon. Пишу про метод source map / SCP / Review Findings / Task Pack и границы AI-инструментов в проектной работе. Telegram: @analystcraft, LinkedIn: innokentyb.