Как я научил Claude Code работать бизнес-аналитиком по руководству BABOK. Вот что получилось

AIналитик (AInalyst) — это AI-ассистент, который работает рядом с вами как опытный коллега бизнес-аналитик. Он прекрасно знает методологию BABOK v3, умеет строить карты стейкхолдеров, планировать интервью и обрабатывать его результаты: собирать требования, трассировать и приоритизировать их, оформлять артефакты. Вы описываете задачу своими словами — AIналитик предлагает следующий шаг, задаёт уточняющие вопросы и делает работу.

BABOK guide, которое является руководством, регламентирующим работу бизнес аналитиков — это более 500 страниц структурированной экспертизы. AIналитик встроил её в свой процесс: он не даст вам пропустить важный шаг, предупредит о рисках и подскажет следующее действие. BA, который плохо ориентируется в методологии, с платформой начинает работать по методологии BABOK так же уверенно, как опытный специалист.

Исходники Платформы вы найдете на гитхабе: Репозиторий AIналитика на GitHub

Привет, Хабр! Я бизнес-аналитик, последнее время перешедший в AI разработку, хочу представить вам свой пет-проект: AI Платформа AIналитик. Или коротко AIналитик (AInalyst).

AI Платформа AIналитик это опенсорсный проект, распространяющийся по лицензии AGPL v3. Телеграм с новостями проекта

Документация проекта

В папке репозитория docs/ содержится подробная и исчерпывающая документация по проекту: пользовательская инструкция, руководство разработчика и примеры сценариев использования Платформы.

Целевая аудитория: кому это может быть полезно?

Платформа помогает бизнес-аналитикам работать по методологии BABOK v3 — последовательно и без лишних усилий. Когда я только начинал работу над проектом, я держал в уме две категории:

Опытный бизнес-аналитик получает инструмент, который снимает рутину: структурирует транскрипты, строит матрицы трассировки, генерирует коммуникационные пакеты для разных аудиторий — и освобождает время для анализа, интерпретации и принятия решений.

Начинающий BA получает надёжного проводника. Платформа помогает все делать “правильно”: задаёт нужные вопросы, подсказывает, вовремя предупреждает, объясняет почему формулировка не прошла валидацию, показывает как должно выглядеть хорошее требование, готовит артефакты.

Но потом понял, что целевая аудитория AIналитика не ограничивается только бизнес-аналитиками. Он также может быть очень полезен продактам, проджектам и стартаперам:

Продакты, проджекты и технические директора. Иногда на проекте нет выделенного бизнес-аналитика. Его роль могут взять на себя product manager, project manager или технический директор. У них есть высокоуровневое понимание продукта и бизнес-процессов, но нет глубоких компетенций в методологии сбора и анализа требований. AIналитик в таком случае подставит им свое плечо и поделится своей экспертизой.

Стартаперы и основатели новых продуктов. Когда бюджет сильно ограничен, нанимать бизнес-аналитика бывает нет возможности. Но грамотно собранные требования — это разница между продуктом, который работает, и продуктом, который приходится переделывать. Как же быть? В этой ситуации Платформа также может выручить. Она поможет разобраться со стейкхолдерами, структурировано собрать требования и передать их команде разработки в том виде, в котором с ними можно работать. Стартапер легко сможет примерить на себя роль бизнес-аналитика.

AI Платформа AIналитик на момент написания статьи покрывает все задачи четырёх ключевых областей знаний BABOK:

Планирование и мониторинг бизнес-анализа (Глава 3)

• 3.1 Планирование подхода к бизнес-анализу

• 3.2 Планирование вовлечения заинтересованных сторон

• 3.3 Планирование руководства бизнес-анализом

• 3.4 Планирование управления информацией бизнес-анализа

• 3.5 Определение возможностей улучшения эффективности бизнес-анализа

Выявление и сотрудничество (Глава 4)

• 4.1 Подготовка к выявлению

• 4.2 Проведение выявления

• 4.3 Подтверждение результатов выявления

• 4.4 Предоставление информации бизнес-анализа

• 4.5 Управление сотрудничеством с заинтересованными сторонами

Управление жизненным циклом требований (Глава 5)

• 5.1 Трассировка требований

• 5.2 Поддержание требований

• 5.3 Приоритизация требований

• 5.4 Оценка изменений требований

• 5.5 Утверждение требований

Анализ стратегии (Глава 6)

• 6.1 Анализ текущего состояния

• 6.2 Определение будущего состояния

• 6.3 Оценка рисков

• 6.4 Определение стратегии изменения

Анализ требований и определение дизайна (Глава 7)

• 7.1 Спецификация и моделирование требований

• 7.2 Верификация требований

• 7.3 Валидация требований

• 7.4 Определение архитектуры требований

• 7.5 Определение вариантов дизайна

• 7.6 Анализ потенциальной ценности и рекомендация решения

Задачи Главы 8 в планах.

Что это даёт на практике

Для бизнес-аналитиков. В первую очередь использование AIналитика на проекте приводит к снижению когнитивной нагрузки. Проект может длится месяцами — стейкхолдеры, решения, требования, история изменений. Удержать всё в голове невозможно. Конфлюенс снимает только часть проблем. AIналитик же фиксирует каждый шаг живого BA в структурированных артефактах. В любой момент можно спросить «что сейчас открыто по согласованиям» или «почему было принято это решение» и получить ответ немедленно.

Для руководителей. Внезапный уход бизнес-аналитика с большого проекта (в силу увольнения или болезни) может сильно ударить по команде. Это большая головная боль для руководителя. Требования хоть и отражены в конфлюенсе (или еще где-то), но все равно основная масса информации по проекту находится в голове ушедшего бизнес аналитика. Если же работа велась с помощью AI Платформы AIналитик, информация никуда не пропадает. Она остается в его недрах в виде структурированных данных. И главное она может быть быстро доступна для нового бизнес-аналитика! Онбординг нового BA на порядок сокращается по времени. Ему не нужно будет часами копаться в документации, переспрашивать коллег и стейкхолдеров о принятых решениях. Ему нужно только задать вопросы. AIналитик быстро введет нового BA в курс дела!

Сценарии использования Платформы

Обширные сценарии использования Платформы вы найдете в репозитории в папке docs/use-cases/. Два примера я привожу в этой статье чуть ниже.

Что из себя представляет платформа AIналитик?

В основе платформы — большая языковая модель (LLM) Claude от Anthropic. Конечно, вы можете просто открыть обычный чат с Claude и задавать вопросы ему. Это работает. Но у такого подхода есть принципиальное ограничение: если вы сами не знаете, что спросить и в какой последовательности, то чат превращается в умного, но неструктурированного собеседника.

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

AI Платформа AIналитик решает эту проблему через три слоя:

• Claude Code — AI-агент, который не просто отвечает, а действует: читает файлы, выполняет команды.

• Skills (скиллы) — 21 специализированный модуль, каждый из которых глубоко «знает» конкретную задачу BABOK: как её правильно выполнить, на что обратить внимание, какие артефакты создать. Это встроенная экспертиза методологии.

• MCP-инструменты — 22 сервера со 111 инструментами, которые выполняют конкретные аналитические операции: строят реестры стейкхолдеров, анализируют транскрипты интервью, создают матрицы трассировки, оценивают риски, формируют спецификации требований.

Вместе эти три слоя создают то, чего не даёт обычный чат: чёткую канву работы, по которой вы движетесь от начала проекта до финального артефакта. С помощью Платформы бизнес-аналитик (или лицо, выполняющее на проекте его роль), — как трамвай, движущийся по рельсам. Рельсы вас практически гарантировано доставят до места назначения, не дадут вам свернуть в сторону!

Подробное описание Платформы в формате пользовательской инструкции

Подробное описание Платформы в формате: краткое описание задачи BABOK -> боли и проблемы бизнес-аналитика в контексте этой задачи -> какие решения в этом случае предлагает AIналитик, вы найдете в файлах пользовательской инструкции (см. папку docs/user-guide репозитория).

Вам не нужно разбираться, что у Платформы под капотом

Это, пожалуй, самое важное, что нужно понять про AIналитика. Вам не нужно знать названия скиллов. Не нужно изучать, как работают MCP-инструменты. Не нужно заучивать никакие команды. Просто разговаривайте с AIналитиком на человеческом языке:

«Мне нужно подготовиться к интервью с финансовым директором» «У меня есть транскрипт встречи, нужно выявить требования» «Пришёл запрос на изменение, помоги оценить»

AIналитик сам определит, какой скилл и какие инструменты нужны, и запустит их.

Каждый скилл написан по строгой спецификации Антропика и содержит YAML-заголовок с триггерами — смысловыми паттернами, которые описывают, когда именно этот скилл должен сработать. Когда бизнес-аналитик пишет что-то в чат, AIналитик (посредством Claude Code) анализирует запрос, сопоставляет его с триггерами, активирует нужный скилл — и тот вызывает соответствующие инструменты из MCP-серверов. Бизнес-аналитик не знает, что именно происходит под капотом. Ему это и не нужно: он просто забирает результат, который использует для целей проекта.

Зона ответственности бизнес-аналитика

Платформа берёт на себя методологию и техническую работу. Но три вещи остаются за BA.

Формирование контекста: входные данные и результаты

Бизнес-аналитик ответственен за формирование правильного контекста. BA со своей стороны должен поставлять в Платформу для ее работы сырые данные: транскрипты интервью, анкеты, протоколы встреч, бизнес-документы, регламенты, нормативные акты. Они кладутся в папку inputs/. Просто скопируйте файлы туда и скажите AIналитику, что обработать. Поддерживаются форматы .txt, .md, .pdf и .docx.

Все результаты работы платформа сохраняет в папку governance_plans/reports/ в формате Markdown. Это ваши рабочие артефакты: планы, реестры, спецификации, протоколы.

Если вам нужен PDF — воспользуйтесь специально написанной утилитой export_pdf.py, либо какими-то внешними сервисами.

Папка governance_plans/data/ — служебная. Там хранятся JSON-файлы, которые платформа использует внутри для своей работы: граф требований, данные приоритизации, результаты оценок. Вам туда заходить не нужно — это внутренняя «память» платформы о проекте, пожалуйста, ничего не трогайте в ней.

Принятие решений

AIналитик будет задавать вам вопросы в ключевые моменты: когда нужно выбрать методологию, расставить приоритеты, утвердить требования или оценить риски. Конечно, он даст рекомендации и предупредит о последствиях, но финальное решение всегда за бизнес-аналитиком! Методология помогает принять хорошее решение, но не принимает его вместо живого бизнес-аналитика. Это нужно понимать!

Управление фазами

Как я уже сказал выше, движущей силой, которая направляет BA в нужном направлении (та самая концепция рельсов), являются скиллы и mcp сервера с инструментами. Если скиллы в начале сессии грузятся в контекстное окно только в виде заголовков, и в дальнейшем в процессе работы, когда срабатывает триггер, подгружаются полностью, то mcp сервера грузятся в контекстное окно полностью сразу. А в проекте AIналитик они большие и объемные. Это может привести к забиванию контекстного окна, что в свою очередь может привести к галлюцинациям LLM во время сессии. Я надеюсь, вы понимаете, как важно при работе с LLM следить за контекстным окном? Для решения этой проблемы было принято архитектурное решение разделения работы на фазы.

Каждая фаза соответствует всем задачам одной области знания BABOK. Например, в фазу lifecycle входят 5 задач области знания управления жизненным циклом требований.

Всего выделено пять фаз по каждой реализованной области знаний:

Таким образом, AI Платформа AIналитик работает в режиме активной фазы: в каждый момент загружены только те MCP-инструменты, которые нужны для текущего этапа проекта.

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

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

Прямо его спросите: какая сейчас фаза?

Он вам ответит. Когда вы решите поработать над задачами из других областей знаний BABOK, то сообщите об этом AIналитику. Попросите сменить фазу: укажите другую. Платформа сама сменит фазу (даст команду в терминале). Или просто скажите над какими задачами планируете работать. И AIналитик вам подскажет, какая фаза нужна.

После смены фазы вам нужно будет рестартануть AIналитика.

Для этого вам нужно будет дать в терминале команду /restart.

Это нужно сделать обязательно! В противном случае перезагрузка mcp серверов не произойдет, и AIналитик не сможет выполнять работу.

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

Если хотите, то контролировать фазы можете вручную самостоятельно. Чтобы узнать текущую фазу, нужно дать команду в терминале:

python phase.py

Скрипт выведет вам название текущей фазы проекта, в рамках которой AIналитик в данный момент работает. Если вы хотите перейти на другую фазу, например с задач Главы 4 на задачи, относящиеся к Главе 5, то укажите ее название явно:

python phase.py lifecycle

Только не забывайте, после смены фазы потребуется перезапустить сессию командой /restart.

Но если у вас опыта работы с терминалом нет, то не переживайте! AIналитик и тут вам поможет, просто общайтесь с ним и просите, что нужно.

Сценарии использования Платформы

Варианты использования AIналитика покрывают все задачи областей знаний BABOK, описанных в главах 3, 4, 5, 6, 7. Но чтобы вам было проще вкатиться в процесс работы и быстрее освоиться, я подготовил моковые сценарии. Вы их найдете в репозитории в папке docs/use-cases/. Здесь приведу только пару штук.

UC-01 — Когда аналитик уходит из проекта

Для кого: Руководители отделов бизнес-анализа, технические директора, PM. Боль: Ключевой BA уволился, ушёл в отпуск, заболел — и весь контекст проекта исчез вместе с ним! Фичи: Реестр стейкхолдеров (3.2), Decision Log (4.5), граф трассировки (5.1), история CR (5.4), статусы согласования (5.5)

Ситуация

Идёт 5-й месяц проекта по внедрению системы управления ассортиментом в крупной розничной сети. Ключевой бизнес-аналитик Антон — человек, который знает всех стейкхолдеров лично, помнит почему было принято решение убрать FR-034 ещё в марте, и держит в голове три незакрытых условия согласования с финансовым директором — внезапно увольняется.

На проекте: 14 стейкхолдеров с разной историей вовлечённости, 87 требований в разных статусах, 9 принятых Change Request, и через 3 недели презентация Steering Committee.

Руководитель отдела BA в панике. Новый аналитик Юлия выходит на проект в понедельник.

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

С AIналитик эта история выглядит иначе.

Что делает Юлия

Она открывает AIналитик, смотрит на папку проекта и пишет одну фразу:

Юлия: Я только вышла на проект assortment-2026. Предыдущий бизнес аналитик Антон уволился. Расскажи мне о текущем состоянии: стейкхолдеры, открытые вопросы, незакрытые согласования.

Как отвечает AIналитик

AIналитик читает все артефакты проекта и за несколько секунд выдаёт структурированную сводку:

---

AIналитик: Проект assortment-2026, активная фаза — lifecycle. Вот текущий контекст:

Стейкхолдеры (14 человек): — Ирина Соколова (финансовый директор) — Key Player, Manage Closely. Статус: ⚠️ Concerned с 28 марта. Последнее взаимодействие: 3 апреля, письмо без ответа. Требует внимания. — Михаил Дроздов (IT-директор) — Context Setter. Статус: ✅ Champion. Активен. — (ещё 12 участников с историей и статусами)

Открытые вопросы по согласованию: 3 conditional approval не закрыты. Один просрочен: условие финансового директора по FR-037 (security review) — дедлайн был 1 апреля.

Последние решения из Decision Log: — 15 марта: FR-034 перенесён в v2. Причина — высокая стоимость, low priority по итогам приоритизации. Решение принято Антоном совместно с Product Owner. — 22 марта: CR-008 (интеграция с ERP) одобрен с условием — реализовать асинхронно.

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

---

Юлия продолжает:

Юлия: Покажи детально ситуацию с финансовым директором — почему Concerned и что с просроченным условием?

---

AIналитик: Ирина Соколова перешла в статус Concerned 28 марта — после встречи по CR-008. В Decision Log: она выразила опасения по безопасности интеграции с ERP. Антон пообещал security review до 1 апреля.

Условие CR-008: «FR-037 должен пройти security review до начала разработки интеграционного модуля». Статус: ⛔ Просрочено. Ответственный: Антон (уволился).

Рекомендую: написать Ирине сегодня — представиться, объяснить ситуацию, договориться о новом сроке. Подготовить письмо?

---

Юлия: Да, подготовь. И обнови ответственного по этому условию на меня.

Что получает Юлия

За 20 минут она знает:

• Кто из стейкхолдеров требует немедленного внимания и почему

• Почему было принято каждое ключевое решение за последние два месяца

• Что конкретно нужно сделать сегодня, чтобы не провалить презентацию через 3 недели

• Полную историю каждого требования — откуда взялось, как менялось, кто согласовал

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

Что происходит под капотом

Бизнес-аналитик с этим не работает напрямую — всё делает AIналитик автоматически.

При первом запросе AIналитик обращается к нескольким источникам одновременно: читает реестр стейкхолдеров с историей изменений статусов (MCP-сервер главы 3 — planning_mcp), достаёт Decision Log со всеми зафиксированными решениями (MCP-сервер задачи 4.5 — elicitation_collaborate_mcp), проверяет статусы согласования и открытые условия (MCP-сервер задачи 5.5 — requirements_approve_mcp). Граф трассировки (MCP-сервер задачи 5.1 — requirements_traceability_mcp) позволяет по любому требованию мгновенно ответить «откуда это взялось и что за ним тянется».

Вся эта информация накапливалась в структурированных JSON-файлах в папке governance_plans/data/ на протяжении всего проекта — каждый раз когда Антон сохранял результаты интервью, обновлял статус стейкхолдера, фиксировал решение или закрывал CR. Автоматически, как побочный эффект обычной работы.

Для Юлии это означает: она получает не папку с документами, которые нужно читать часами, а живую структурированную память проекта, с которой можно сразу разговаривать.

UC-08 — Impact Analysis при внезапном Change Request

Для кого: Бизнес-аналитики на активных проектах Боль: Change Request «звучит просто» — но за ним тянется половина артефактов проекта, и никто этого не видит до разработки Фичи: BFS-обход графа трассировки, скоринг CR (задачи 5.1 + 5.4)

Ситуация

Логистическая компания. Проект — система управления маршрутами. Идёт процесс работы, всё по плану. И тут коммерческий директор пишет BA Андрею короткое сообщение: «Нужно добавить расчёт CO₂-эмиссии для каждого маршрута в реальном времени — для ESG-отчёта. Это же несложно, правда?»

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

Он открывает Платформу.

Что делает Андрей

Андрей: Открой Change Request: коммерческий директор просит добавить расчёт CO₂-эмиссии для каждого маршрута в реальном времени. Говорит что несложно.

Как отвечает AIналитик

---

AIналитик: CR-011 создан. Запускаю impact analysis по графу трассировки…

Затронутые артефакты (11):

— FR-022 (расчёт стоимости маршрута) — прямая зависимость. CO₂ нужно считать на тех же данных о маршруте, что и стоимость. Изменение логики расчёта может затронуть FR-022. — NFR-003 (производительность: отклик API не более 500 мс) — ⚠️ конфликт. Расчёт CO₂ в реальном времени требует обращения к внешнему API эмиссий. Это добавляет минимум 200-400 мс к каждому запросу. NFR-003 окажется под угрозой. — ADR-002 (архитектурное решение: кэширование данных о маршрутах) — нужен пересмотр. Кэшированные данные не подходят для расчёта CO₂ в реальном времени. — TC-014, TC-015, TC-017 (три тест-кейса) — потребуют обновления. — (ещё 5 артефактов второго уровня зависимости)

Оценка CR: Score: 5.8 — Modify (принять с условием).

Рекомендация: принять CR-011, но изменить требование — убрать «реальное время». CO₂ считается асинхронно и доступен при следующем открытии маршрута. Это снимает конфликт с NFR-003 и не требует пересмотра ADR-002.

Вынести на согласование с коммерческим директором?

Андрей: Да. И подготовь аргументы — почему реальное время невозможно без последствий.

AIналитик: Готово. Аргументы для встречи:

Реальное время означает обращение к внешнему API при каждом открытии маршрута. Сейчас система обрабатывает до 800 запросов в минуту в пиковые часы. Добавление внешнего вызова увеличит среднее время отклика с текущих 320 мс до расчётных 680-900 мс — это нарушает SLA, согласованный с клиентами в NFR-003.

Асинхронный вариант: CO₂ пересчитывается в фоне раз в 15 минут. Для ESG-отчёта это абсолютно достаточно — отчёты формируются раз в квартал.

---

Что получает Андрей

Он приходит к коммерческому директору не с отказом, а с данными и альтернативой. Разговор из «вы не хотите делать» превращается в «вот почему именно так и как мы это реализуем». CR принят — но в варианте, который не создаёт технического долга.

И важное: никто не «забыл» про три тест-кейса и архитектурное решение по кэшированию. Они в списке затронутых артефактов — их обновят до начала разработки, а не после.

Что происходит под капотом

Бизнес-аналитик с этим не работает напрямую — Платформа всё делает автоматически.

MCP-сервер задачи 5.4 (requirements_assess_changes_mcp) при получении CR выполняет обход графа трассировки в traceability_repo.json по алгоритму BFS (поиск в ширину) — находит все артефакты, связанные с изменяемыми требованиями, включая зависимости второго и третьего уровня. Инструмент score_cr присваивает оценку на основе количества затронутых артефактов, наличия конфликтов с NFR и сложности изменений. Статусы всех затронутых требований обновляются автоматически — помечаются как «требуют проверки в связи с CR-011». Результат сохраняется в Decision Log через elicitation_collaborate_mcp.

Что вам понадобится для работы

Перед установкой убедитесь, что на компьютере есть:

1. Python 3.10 или новее — если не уверены, проверьте командой python --version в терминале. Питон нужен для работы 22-ух mcp серверов и 3-х скриптов (common.py и phase.py — два очень важных архитектурных скрипта и export_pdf.py — скрипт для экспорта .md в .pdf).

2. pip — менеджер пакетов Python (обычно идёт вместе с Python)

3. Учётная запись Anthropic — план Pro или выше, можно оформить на claude.ai.

Опционально нужен редактор, я рекомендую использовать с Claude Code редактор VS Code.

VS Code можно скачать на code.visualstudio.com

Руководство разработчика

Подробную документацию об архитектуре Платформы вы найдете в руководстве разработчика, файл с документом находится в репозитории в папке docs/developer-guide/

Установка платформы

# 1. Скачайте репозиторийgit clone https://github.com/chaussky/ainalyst.gitcd ainalyst# 2. Установите зависимостиpip install -r requirements.txt# 3. Настройте переменные окружения, для этого переименуйте файл .env.example  -> .envcp .env.example .env# Откройте .env и заполните API-ключи для конфлюенс# Запустите claude codeclaude

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

Планы на будущее

Самые ближайшие это разработать специализированных субагентов, которые можно было бы запускать параллельно. Каждый субагент будет выполнять какой-то свой большой объем работы, при необходимости коммуницировать с другими, запущенными параллельно. Я думаю, что субагенты могут зайти в задачах Главы 4. Так же полагаю, что субагенты будут полезны для обработки change request. Пока вопрос глубоко не изучал еще.

Есть также идея разработать чат-бота, который проводит интервью со стейкхолдерами. Эта идея процентов на 60% реализована. Бот будет задавать вопросы стейкхолдеру с учетом всей имеющейся информации о проекте. Проводить интервью через бота или самостоятельно бизнес аналитик будет решать сам. AIналитик только даст свои рекомендации и советы по целесообразности такого сценария на основе данных о стейкхолдере и собранного контекста. Возможно применять бота для интервьюирования споносора и других важных стейкхолдеров не стоит, лучше это сделать лично, а вот для довыявления и задавания уточняющих вопросов — можно.

Среднесрочные планы это попробовать запустить AIналитика на разных больших языковых моделях (китайских) и других агентах. Наибольший интерес с практической точки зрения представляют локальные модели и опенсорсные агенты типа OpenCode. Нужно будет поэкспериментировать с разными, посмотреть какое качество они дают. Тогда можно будет обеспечить работу AIналитика внутри контура компании, не отправляя данные во вне.

Более детальную информацию по Платформе вы найдете в папке docs/ репозитория.