Аналитическая мастерская

🛠 Две недели «Аналитической мастерской». Что успели сделать?

Честно говоря, за последние две недели произошло гораздо больше, чем я ожидал. Появились новые материалы, публичные выступления, первые кейсы, где коллеги начали применять метод у себя на проектах, и очень много полезной обратной связи.

Что уже сделали.

✅ Провели открытый доклад «Source Map для системного аналитика» в Клубе технических аналитиков.

На реальном кейсе интеграции с Acme Pay показали, как собрать System Context Pack всего за 14 минут из четырех разрозненных источников. После доклада подготовили handout с кратким описанием метода — его уже можно скачать на сайте.

✅ Полностью разобрали кейс Acme Pay.

За эти две недели по шагам прошли весь процесс:

• Source Map;
• Review Findings;
• Task Pack.

Параллельно обсуждали более философский вопрос — где сегодня проходит граница между AI и инженером, который принимает решения.

✅ Открыли все материалы кейса.

Контракт, Confluence, POC, переписка с провайдером и GitHub-репозиторий доступны всем желающим. Очень хотелось показать не выдуманный пример из презентации, а настоящие рабочие артефакты, на которых можно самостоятельно пройти весь процесс.

Неожиданно случился Habr.

Большая статья про System Context Pack уже была готова к публикации, но вместо публикации мой аккаунт неожиданно перевели в режим read-only с формулировкой «размещение сгенерированных статей».

Получилась довольно любопытная история, которую разберу отдельно. Думаю, многим, кто использует AI при подготовке технических материалов, она покажется знакомой.

Сам материал никуда не исчез — он просто переезжает в блог AnalystCraft и на VC.

Что дальше?

📚 Большой worked example «Как собрать System Context Pack».

📚 Каноническая статья про Source Map для системного аналитика.

🚀 И, наконец, открываем набор на второй поток «Вайб-аналитики».

Это по-прежнему не курс про один инструмент. Мы будем строить собственный AI Workspace, работать с проектным контекстом, собирать агентные пайплайны и учиться использовать AI как инженерный инструмент, а не как ещё один чат с красивыми ответами.

И в завершение — вопрос к коллегам.

Что в проектах с несколькими источниками требований оказывается самым сложным именно для вас?

— найти противоречия между документами;
— понять, какому источнику доверять;
— удержать весь контекст в голове;
— или что-то совсем другое?

Пишите в комментариях. Самые интересные истории обязательно разберём в следующих публикациях. 👇

🛠 Вопрос недели для аналитиков и интеграторов.

Практически у каждого, кто работает с интеграциями, есть свой «любимый» тип проблем, которые обнаруживаются уже после старта разработки. Причём чаще всего это не сложные архитектурные ошибки, а вещи, которые просто никто вовремя не заметил.

Интересно понять, что встречается чаще всего на реальных проектах.
Какой тип находок вы считаете самым распространённым?

🔸 Противоречие между источниками — ТЗ говорит одно, Confluence или API-документация — другое.
🔸 Пробел — важное условие упоминается, но нигде не определено.
🔸 Неоднозначность — формулировку можно интерпретировать несколькими способами, и каждая выглядит логичной.
🔸 Скрытое допущение — никто его не проверял, но команда воспринимает его как установленный факт.

В «Аналитической мастерской» мы всё больше убеждаемся, что именно такие, на первый взгляд, «скучные» находки чаще всего становятся причиной проблем в production. Не потому, что их невозможно обнаружить, а потому, что они оказываются разбросаны по разным источникам и редко попадают в единое поле зрения.

Поделитесь своим опытом в комментариях. Если есть показательный кейс — расскажите его. Самые интересные примеры соберём, разберём и опубликуем отдельным материалом.

Сегодня на Habr — лонгрид «Как собрать System Context Pack за часhttps://habr.com/ru/articles/1055504/».

По тому же кейсу Acme Pay, что разбирали на этой неделе. Но в формате пошагового практикума: что делать с каждым из 4 источников, как читать Review Findings, как собирать Task Pack. С реальными скриншотами и worked example.

Если вы хотите попробовать подход без Подмастерья — статья показывает, как ту же дисциплину source map / SCP / Task Pack можно вести в обычной Confluence-таблице. Это самостоятельная практика, не привязана к нашему инструменту.

Если вам зашло — поделитесь, кому может быть полезно. Или приходите в комментарии под статью — отвечу по делу.

Шаг 3. Task Pack — заготовка, а не готовая постановка.

После Source Map и Review Findings у нас наконец появляется материал, из которого можно собирать постановку. Именно этим и занимается Подмастерье.

На выходе получается Task Pack — структурированный черновик, в котором уже собраны границы задачи (scope), функциональные требования с ссылками на источники, открытые вопросы к заказчику, найденные риски, предварительная оценка и черновик acceptance criteria.

Важно понимать: это не постановка.

И я специально не пытаюсь сделать так, чтобы Подмастерье писал её за аналитика.

Потому что финальная постановка всегда зависит от вещей, которых не знает ни одна модель. От внутренних договорённостей команды, истории проекта, приоритетов бизнеса, отношений с PM, компромиссов, которые были приняты неделю или месяц назад.

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

И самое главное — ты идёшь обсуждать задачу не с пустыми руками.

Не с вопросом «что вообще делать?», а с семью конкретными open questions, списком найденных рисков, ссылками на первоисточники и пониманием того, где находятся основные противоречия.

Мне кажется, именно в этом и заключается роль хорошего AI-помощника. Не написать документ вместо аналитика, а сократить путь от хаоса в документации до осмысленного разговора с командой.

Завтра на Habr выйдет полный гайд «Как собрать SCP за час» с пошаговым worked example, где весь этот процесс — от Source Map до Task Pack — разберу на одном кейсе.

Шаг 2. Review Findings — найти проблемы до того, как они попадут в production.

После того как Source Map собран, начинается самое интересное.

Подмастерье проходит по всем источникам проекта и ищет четыре типа находок: противоречия, пробелы, неоднозначности и риски. Не пытается их исправить, не делает выводов за аналитика, а именно показывает, где проект перестает быть консистентным.

На кейсе Acme Pay получилось десять находок. Пять из них оказались блокерами для production.

Например, PDF-контракт утверждает, что срок жизни авторизационного токена — 24 часа, а в переписке с account manager после релиза v2.1 указано уже 4 часа. Если ориентироваться только на официальный PDF, интеграция успешно пройдет тестирование, а спустя несколько часов в production начнет падать с auth_token_expired.

Другие находки оказались не менее неприятными. В POC отсутствует обязательная проверка webhook-подписей через HMAC-SHA256, не передается обязательный customer_id, используется устаревший endpoint /v1/, который через пару месяцев будет отключен, а обязательный Idempotency-Key вообще отсутствует. Каждая из этих проблем по отдельности способна сорвать запуск интеграции.

И здесь, как мне кажется, проходит очень важная граница.

Подмастерье не пытается разрешить противоречия. Он не говорит, какой источник правильный и какое решение нужно принять. Он показывает оба источника, объясняет, почему между ними возник конфликт, оценивает критичность и оставляет решение человеку.

Потому что найти конфликт — это задача машины.

А выбрать, чему доверять, — по-прежнему задача аналитика.

Шаг 1. Source Map — карта источников проекта.
Если честно, еще полгода назад я не понимал, насколько это вообще важная вещь. Казалось, что Source Map — это просто реестр документов. Ну есть список файлов, ссылок и репозиториев. И что?
Но стоит один раз попасть в ситуацию, когда два документа противоречат друг другу, и отношение меняется моментально.
Возьмем простой пример. По кейсу Acme Pay у нас есть четыре источника:
• acme-pay-api-contract.pdf — 47 страниц, обновлен 12.03.2026, актуальный;
• Confluence Acme Pay v1 — написана в октябре 2025 года, помечена как deprecated;
• Git-репозиторий integration-acme-poc — proof of concept, последний коммит в октябре 2025;
• email-тред с поддержкой Acme — пять писем за март 2026 года.
Если просто открыть самый свежий PDF и начать писать постановку, кажется, что всё необходимое уже есть.
Но Source Map заставляет сначала ответить на другой вопрос: каким источникам вообще можно доверять?
И тут выясняется самое интересное. В переписке с поддержкой есть изменение, которого пока нет в публичной документации: после релиза v2.1 время жизни авторизационного токена сократили с 24 часов до 4 часов. Документация ещё не обновлена, а интеграция уже работает по новым правилам.
Если не знать о существовании этого письма, можно совершенно спокойно написать корректную с точки зрения PDF постановку… которая не будет работать в продакшене.
Именно поэтому я перестал воспринимать Source Map как ещё одну таблицу для аналитика.
Это карта доверия к информации. Она помогает понять, какие источники актуальны, какие уже устарели, где есть противоречия и чего ещё не хватает для принятия решения.
И только после этого имеет смысл открывать документы и начинать анализировать требования.
Потому что проблема редко заключается в том, что аналитик не умеет читать документацию. Гораздо чаще проблема в том, что он читает не ту документацию.

🔨 Почему ChatGPT не станет напарником системного аналитика

За последний год стало понятно: проблема не в том, что современные LLM плохо отвечают на вопросы.

Проблема в том, что они почти ничего не знают о конкретном проекте.

Для аналитика ответ без контекста редко имеет ценность. Требования живут одновременно в Confluence, Git, OpenAPI, диаграммах, переписках и десятках других источников. Пока эта информация не собрана в единую картину, любой ответ модели — лишь хорошо сформулированная гипотеза.

Именно поэтому в «Аналитической мастерской» мы пришли к простой идее.

Прежде чем что-то анализировать, нужно собрать карту проекта.

Не векторную базу.

Не очередной RAG.

А Source Map — карту источников, связей, противоречий и контекста, на которую уже может опираться аналитик.

Отсюда и родилась концепция «Подмастерья аналитика».

Подмастерье не пишет требования вместо человека и не принимает архитектурные решения. Его задача гораздо более приземлённая, но именно поэтому полезная: собрать материалы, показать связи между ними, подсветить противоречия, подготовить заготовку для дальнейшей работы.

Потому что решение по-прежнему остаётся за мастером.

Эта идея может показаться очевидной. Но именно вокруг неё сегодня строится разница между «чатом с ИИ» и настоящим рабочим инструментом аналитика.

В новой статье подробно разобрали:

• почему ChatGPT недостаточно для проектной работы;
• что такое Source Map и зачем он нужен;
• почему RAG — это только часть решения;
• и как меняется роль аналитика в эпоху AI.

Будем рады вашим вопросам, критике и обсуждению.

Вопрос на выходные.

Если бы рядом с вами на проекте появился AI-напарник, какую первую задачу вы бы ему отдали?

А именно ту, которую правда отдали бы — с нормальной долей сомнения, по реальному проекту.

Пишите в комментариях. Самые интересные ответы разберём подробно.

На верстаке.

Доработка интеграции с банком.

Исходные данные:

• страница Confluence двухлетней давности;
• репозиторий с OpenAPI;
• PDF от заказчика на 14 страниц;
• переписка в Telegram с уточнениями.

Каждый источник описывает систему по-своему. Каждый содержит часть контекста.

Обычно работа начинается с поиска ответа на простой вопрос: какой источник считать основным?

System Context Pack собирает карту источников и связывает утверждения между ними.

В этом примере были обнаружены два расхождения:

• обязательное поле AccountId описано по-разному в OpenAPI и PDF;
• значение таймаута отличается между Confluence и спецификацией API.

Review Findings помечает оба конфликта и прикладывает ссылки на источники.

Никаких выводов за аналитика.

Никаких попыток выбрать правильную версию.

Только заготовка для работы и места, которые требуют решения.

Проверка остаётся за мастером.

Дыры в заготовке.

Главная причина, по которой обычный ChatGPT плохо работает в аналитических задачах, — отсутствие проектного контекста.

Запрос выглядит просто:

«Составь требования для интеграции с банком».

В ответ появляется уверенный текст. В нём могут быть отраслевые практики, типовые требования и вполне разумные предположения. Проблема в другом: модель не знает, что уже принято в вашем проекте.

Она не видит страницу Confluence с архитектурными ограничениями. Не знает о договорённостях команды. Не видит старые постановки и результаты прошлых решений.

Поэтому в одной заготовке могут одновременно оказаться:

• требования, противоречащие существующей архитектуре;
• детали, которых нет ни в одном источнике;
• расхождения с уже согласованными требованиями;
• ссылки на документы, которые никто в проекте не использует.

Это не ошибка модели. Это дыра в контексте.

Подмастерье начинает не с генерации текста, а со сбора source map проекта. Какие документы существуют. Какие из них связаны между собой. Какие утверждения подтверждаются источниками, а какие существуют только в предположениях.

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

Если два источника противоречат друг другу, это тоже остаётся видимым.

Дыра остаётся дырой.

Подмастерье её показывает. Решение остаётся за мастером.

А где чаще всего теряется контекст в ваших проектах: в документации, переписках или устных договорённостях?

Как работает Подмастерье аналитика?

В комментариях часто спрашивают, чем Подмастерье отличается от очередного AI-чата для генерации требований.

Весь workflow укладывается в одну строку:

Sources → Project-local RAG → System Context Pack → Review Findings → Task Pack → Export

Sources — всё, что уже существует по проекту: Confluence, Jira, Git, OpenAPI, схемы, PDF, переписки и результаты встреч.

Project-local RAG — Подмастерье индексирует эти материалы и ищет ответы внутри проекта, а не в интернете. Работа строится на контексте вашей команды, а не на усреднённых знаниях модели.

System Context Pack — структурированная карта проекта со ссылками на источники, цитатами и связями между артефактами.

Review Findings — список противоречий, пробелов, неоднозначностей и потенциальных рисков в требованиях.

Task Pack — черновик постановки с вопросами, ссылками на источники и обоснованием выводов.

Export — выгрузка в Jira, Confluence, Markdown, PDF или любой другой формат, в котором работает команда.

Главное — Подмастерье не пишет требования вместо аналитика и не заменяет экспертизу команды. Он собирает контекст, помогает находить проблемные места и готовит основу для дальнейшей работы.

Как и положено хорошему подмастерью: материалы готовит он, решение принимает мастер.

А какая часть работы аналитика сегодня отнимает у вас больше времени: поиск контекста, анализ требований или подготовка постановок?

Аналитическая мастерская pinned «Аналитическая мастерская открывает новый рабочий слой — Подмастерье аналитика. Это AI-напарник системного аналитика. Не чат, не помощник, не замена. Напарник. Что он делает: подключается к источникам проекта, собирает System Context Pack, подсвечивает риски…»

Аналитическая мастерская открывает новый рабочий слой — Подмастерье аналитика.

Это AI-напарник системного аналитика. Не чат, не помощник, не замена. Напарник.

Что он делает: подключается к источникам проекта, собирает System Context Pack, подсвечивает риски в требованиях, готовит заготовку постановки.

Что не делает: не принимает решения. Не пишет требования за вас. Не отправляет ваши данные туда, где вы это не разрешили.

Эта неделя — про то, как Подмастерье встаёт рядом с мастером. Без магии и без обещаний.

Channel photo updated

Channel created