Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Системный и бизнес-анализ доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 32
Спасибо. Поковыряюсь, сразу нашёл что улучшить. Я бы поставил 7 фазу первой и сделал ее источником правды еще и самообновляющимся. Тогда будет цикличность. Ну и моё любимое - BDD сразу встроить в десигн
1. DESIGN (vision/target state - живёт первым, единственный источник истины) ↓ 2. DECOMPOSE (stakeholders, requirements, decisions - выводятся из Design) ↓ 3. BDD (Given/When/Then на каждое requirement) ↓ 4. MAINTAIN (автоматический контур: drift detection, traceability, reports)
Ну смотрите, с одной стороны BABOK не дает четких указаний в какой последовательности какую задачу выполнять. С другой стороны область знаний Планирование и мониторинг бизнес анализа определена как базовая. Это как фундамент, на основании которого стоится работа БА. Здесь выбор методологии, инструментарий того как мы будем "сортировать" стейкхолдеров, и вообще, как мы будем строить свою работу на проекте.
В Айналитике всего 5 фаз, кстати. Я так понимаю, что под 7 фазой вы имели в виду задачи 7 Главы? "7 фаза" же относится к задачам области знаний "Управление жизненным циклом требований". Здесь мы готовим артефакты. Предполагается, что стейкхолдеров мы выявили, сбор требований мы уже провели. Тут мы сырые требования оформляем в виде документов.
Поэтому "7 фазу" не получится поставить первой. Инструменты mcp сервера planning_mcp (задачи Главы 3) загружены в Айналитика всегда и с самого начала. И на них опираются инструменты других mcp серверов, в том числе фазы design.
AIналитик? Серьёзно? Может, лучше Анал-Итик, чтобы не вляпаться с иностранными языками в названии?
Не так много таких проектов на гитхабе. Интересно.
Автор забыл добавить пункт об установке Claude code и git и npm. :(
Расширение claude code для vs code не будет работать без самого claude code.
Claude code не будет работать без git и npm.
И vs code здесь совсем лишний. Питона хватит.
Писать про установку Claude code я не стал сознательно. Статья и так получилась объемной. Про Claude code вообще много можно было чего написать. Одна тема обхода региональных ограничений Клода для российских пользователей чего только стоит :( Плюс некоторые наши российские службы им в этом активно помогают. Это какой-то треш просто.
А вроде сейчас установка Клода через npm не актуальна стала? В документации Клода npm убрали же...
Не совсем понял про "питона хватит". Вы имели в виду терминала? Не все любят работать в терминале. Многих он сильно пугает. VS Code он чуть снимает барьер. В нем можно сразу видеть папки и файлы. Открывать для просмотра файлы.
Сам Claude Code может работать без питона без проблем.Питон в Айналитике нужен для выполнения инструментов из mcp серверов. Инструментов в общей сложности 111 штук.
А какую бизнес-задачу решаете, если не секрет?
Вы имеете в виду, какую бизнес задачу я решаю, создавая айналитика? Задачу оптимизации работы бизнес аналитиков. Чтобы было проще, быстрее и качественнее. А еще чтобы те же продакты и проджекты могли легко брать на себя роль бизнес аналитика.
Следующими будут две задачи: 1) задача снижения входного барьера и 2) запуск айналитика на локальных моделях. Первая: планирую разработать либо вебприложение, либо десктопное (через апи нейросетей). Все-таки многим работать через клод код не привычно и тяжеловато. Вторая: многие компании по соображениям безопасности не могут отправлять данные в нейросети, им хотелось бы, чтобы данные не покидали контур компании - запустить айналитика на локальных моделях.
Задумка супер! Можно пример прикладной задачи, которую поможет решить агент? Тут сегодня статью прочитал, что куча BI, которые используют агрегированную информацию, не умеет в среднее. Так как "A/B + C/D ≠ (A+B) / (C+D)", и все до лампочки привыкли так считать, значит, так и будем. Так что надо доступ к данным, причем, желательно, к сырым.
Как вариант, кстати, можно просить проверить данные на чистоту...
В репозитории в папке docs папка use-cases лежит одноименный файл в формате md (+pdf). Там описано очень много сценариев использования Айналитика.
Не совсем понял про "A/B + C/D ≠ (A+B) / (C+D)" Хочу отметить, что в данной данный проект никак не связан с анализом данных, BI и дата саенсом. Тут про бизнес анализ: работу со стейкхолдерами, сбор требований, подготовку артефактов.
Часто стейкхолдерами являются первые лица старой школы. Многие из них будут против давать интервью роботу.
Да, есть такой момент. Слышал подобное от коллег, что интервьюирование ботом это не правильно - стейкхолдеры могут "обидеться". Но это живому бизнес аналитику решать - можно ли с тем или иным стейкхолдером провести интервью вживую или все-таки можно через бота. Кроме того, мы же каких-то стейкхолеров анкетируем, а не интервьюируем. Интервью ботом можно рассматривать как очень продвинутый вариант анкетирования. Вот тем, кого мы решаем анкетировать, мы можем присылать ссылку на бота.
Отличный проект и статья - спасибо.
Несколько вопросов для уточнения:
1) я правильно понял что все skill.md / CLAUDE.md и другие аналогичные файлы для Claude Code - написаны на русском?
На своем проекте столкнулся с этой же дилеммой. В целом это вроде не критично. Claude прекрасно справляется с инструкциями на русском. Но вопрос "экономии токенов". Вроде русские инструкции это +2-7% к объему токенов, потребляемых Claude? Не анализировали этот момент?
Я пока пошел по пути формирования всех SKILL и CLAUDE файлов на английском. А для "языковой" синхронизации и удобства работы для русскоязычной аудитории формируется отдельный файл: skill-spec-ru. Он не подгружается Claude - но помогает при разработке и сверке.
Интересно было узнать ваши решения по этому вопросу.
2) CLAUDE.md в корневой папке проекта - 320 строк - не многовато?
Не тестировали вариант, когда корневой CLAUDE - это больше навигационный файл + жесткие запреты, а далее в каждой папке проекта есть свой CLAUDE.md, который уже детализирует точечные инструкции для конкретного кейса использования?
Это вроде снижает нагрузку на контекстное окно при запуске сессии?
1) Да, пока все скиллы, клод.мд на русском. Для цели оптимизации токенов это не очень хорошо. Лучше писать скиллы на английском, конечно. Но я при разработке этой первой версии целям оптимизации не отдавал приоритет. Для меня главное было, чтобы а) хотя бы стабильно работало, 2) и было понятно. На русском мне проще понять смысл скилла. Русский дает ощущение контроля. Да и вам - пользователям тоже удобней и комфортней. Можете прочитать и понять, что происходит. А так да, в дальнейшем, когда вопросы оптимизации выйдут на первый план, лучше перевести на английский. Еще посмотреть, какие результаты будут на разных моделях (opus, sonnet, haiku). Кстати, еще когда встанет вопрос по оптимизацию, то надо бы проверить как будет работать система на других LLMках и с другими агентами (codex, opencode и т.д.). Сейчас я Антропика с его агентом выбрал из-за их топовости.
2) Да, 320 строк это многовато :( Что-то я упустил из виду этот момент совсем. Спасибо! Надо будет сократить.
В айналитике есть еще один момент, который позволит снизить нагрузку на контекстное окно... Возможно, весь код на питоне будет лучше перенести прям внутрь скиллов. Сейчас питоновский код оформлен в виде mcp серверов. Но мне сам клод посоветовал так сделать. Когда я в начале обсуждал с ним архитектуру, он мне сказал, что делай в виде mcp серверов, так типа будет надежнее.
Задумка с опорой на BABOK — это жирный плюс, структурированность подкупает. Но есть одно большое «но»,инструмент выглядит отлично ровно до тех пор, пока ты находишься в зоне доступности API Anthropic и у тебя нет территориальных ограничений, плюс использование по подписке накладывает ограничение на конфиденциальность данных. Как только начинаются танцы с проксями, зарубежными аккаунтами и риском внезапного бана, вся эта магия продуктивности превращается в тыкву.
О, да! Все эти телодвижения для того, чтобы пролезть незаметно в клод (да и в другие западные нейросети) напрягают очень сильно. Это действительно сжирает много сил и временных ресурсов. Да и наш РКН не отстает - всеми силами помогает западным сервисам реализовывать санкции. Но это мелочи, большим препятствием является другое - требования к конфиденциальности. Многие компании не согласны отправлять свои данные куда-то там за пределы.
Но, на мой взгляд, это не повод, чтобы сдаваться. Прогресс двигается. Опенсорсные локальные модели умнеют. Если не сегодня, то завтра их мощностей станет достаточно, чтобы обеспечить приемлемое качество работы для айналитика. Надо пробовать и тестировать. Локальные модели у меня в большом приоритете. Буду тестировать. Единственное, это все дополнительные накладные расходы для меня.
Sonnet 4.6:
Анализ проекта AInalyst: соответствие лучшим практикам Claude Code
Изучил README, CLAUDE.md, CHANGELOG и структуру репозитория. Анализирую по двум осям: Skills и MCP.
✅ Что сделано правильно
Архитектурное мышление. Авторы реально поняли фундаментальную идею: контекстное окно — дефицитный ресурс. Система фаз (planning, elicitation, lifecycle, analysis, design, full) — это именно то, что нужно делать: загружать только нужные инструменты в нужный момент. В CHANGELOG даже указана экономия токенов как метрика.
CLAUDE.md как системный промпт агента. Файл написан грамотно — чёткая роль, пошаговый workflow, таблица фаз с примерами, инструкции про /restart. Это правильная практика: CLAUDE.md должен быть операционным руководством для агента, а не документацией для людей.
Разделение данных и артефактов. governance_plans/reports/ для Markdown-артефактов, governance_plans/data/ для JSON-состояния системы — чистое разделение между human-readable outputs и machine state.
Hooks (SessionStart, PostToolUse) упомянуты в CHANGELOG. Это продвинутый приём — автоматическое управление контекстом между вызовами инструментов.
Структура проекта (inputs/, governance_plans/, skills/, docs/) логична и предсказуема.
⚠️ Отклонения от канонических практик по Skills
Здесь ключевое расхождение. В стандарте Anthropic скилл — это самодостаточная папка с одним файлом SKILL.md, содержащим YAML frontmatter и инструкции GitHub. YAML-заголовок содержит поля name и description, по которым Claude Code решает, когда активировать скилл.
В ainalyst авторы описывают в README, что скиллы содержат «YAML-заголовок с триггерами». Это правильно по духу, но есть нюанс: скиллы лежат в skills/ в корне проекта, а не в .claude/skills/. Каноническое расположение для project-level скиллов — .claude/skills/. Из-за этого они не подхватываются автоматически Claude Code marketplace/plugin-системой. Авторы, судя по всему, задействуют их через CLAUDE.md вручную, а не через встроенный механизм <available_skills>.
Это не критическая ошибка — рабочий workaround — но если система масштабируется, интеграция со стандартным путём дала бы прогрессивную загрузку скиллов «из коробки».
⚠️ Отклонения по MCP
Нет mcp.json / .mcp.json в репозитории (или он в .claude/, которая не видна из-за robots.txt на деревья). Стандартная практика — хранить конфигурацию MCP-серверов в .mcp.json (для project-scope) или передавать через settings.json. Авторы управляют этим через phase.py, который, судя по всему, динамически переписывает конфигурацию при переключении фаз — нестандартный, но рабочий подход.
Ручной /restart при смене фазы — это UX-проблема. Стандарт предполагает, что смена набора MCP-серверов должна происходить прозрачно. Требование вручную вводить /restart — следствие архитектурного ограничения (Claude Code перезагружает MCP при старте сессии). Это известное ограничение платформы, авторы компенсируют его через явную инструкцию в CLAUDE.md — решение приемлемое, но неизящное.
22 MCP-сервера — впечатляющий масштаб. Идея разбить их на фазы вместо одной монолитной конфигурации — правильная инженерная интуиция.
🔴 Потенциальные проблемы
Нет settings.json для Claude Code с явным mcpServers блоком в репозитории (по крайней мере публично). Новый разработчик, клонирующий репо, не сразу понимает как именно подключаются MCP-серверы — только через README и phase.py.
export_pdf.py и phase.py в корне — утилиты уровня tooling лучше выносить в scripts/ или tools/, чтобы корень проекта не загромождался.
Тесты в tests/ есть, это хорошо. Но непонятно, покрывают ли они логику самих скиллов или только Python-утилиты — тестирование prompt-логики нетривиально.
Итоговая оценка
Аспект Оценка Комментарий
Архитектурная идея★★★★★Фазовое управление контекстом — сильное решение CLAUDE.md★★★★☆Хорошо написан, операционален
Skills (расположение)★★★☆☆Не в .claude/skills/, нестандартно
MCP (конфигурация)★★★☆☆phase.py вместо mcp.json, работает но нестандартно
UX смены фазы★★☆☆☆Ручной /restart — костыль
Документация★★★★★README, use-cases, developer-guide — отличная
Резюме: проект демонстрирует нестандартное, но продуманное использование Claude Code. Главное расхождение с каноническими практиками — в физическом расположении скиллов и способе управления MCP-конфигурацией. Это не баги, а сознательные архитектурные компромиссы — авторы явно понимают ограничения платформы и работают вокруг них. Для production-use достаточно. Для примера «как делать правильно» — стоит перенести скиллы в .claude/skills/ и добавить явный .mcp.json.
Интересно было почитать ревью соннета, спасибо :)
Значит, по поводу местонахождения скиллов. В корне папка должна быть или все-таки в .claude/skills/ Я тоже задавал ему этот вопрос: типа а че ты их положил не в .claude? Он ответил, что все нормально. Что в папку .claude скиллы нужно класть, когда мы разрабатываем веб приложение, а у нас типа скиллы это рабочий инструмент. Типа так правильней. Еще какие-то аргументы приводил.
Про .mcp.json С этим файлом какая-то мутка была. Там пути относительные должны быть. Из-за этого возникала ошибка. Во время одного из ревью проекта Клод в лице соннета мне посоветовал генерировать .mcp.json при старте работы на конкретном ноуте. Так что он есть - генерируется при начале работы. В репо его нет, верно./restart да, костыль. И это важный момент. Поэтому я в статье тему правления фазами так подробно расписал. Я подумаю в следующих версиях, что с этим можно сделать
Отличное начало по ИИ-зации БА:
Что из главы 3 BABOK не попало в AInalyst
Сначала таблица соответствий — что есть, потом детально по каждому разделу о пробелах.
3.1 — Планирование подхода к бизнес-анализу
Что реализовано: suggest_ba_approach() принимает change_frequency, uncertainty, regulatory_need и по матрице APPROACH_MATRIX из common.py выдаёт Predictive / Agile / Hybrid с compliance override. Сохраняет методологию и набор техник в ba_plan.json.
Что не попало:
BABOK 3.1.4 описывает шесть элементов подхода к планированию. Инструмент закрывает элемент .1 Подход к планированию (выбор методологии) и частично .5 Сложность и риск (через uncertainty). Остальные четыре элемента отсутствуют:
.2 Формальность и уровень детализации результатов— BABOK требует явно определить, насколько формальной будет документация. В инструменте этого нет: нет параметра или логики, которая бы фиксировала, будут ли артефакты по шаблонам или в свободной форме..3 Действия бизнес-анализа— BABOK говорит о разбиении работы на конкретные действия и задачи с итерациями.suggest_ba_approach()возвращает список техник ([«Workshops», «User Stories»]), но не план действий — нет связи с конкретными задачами BABOK и нет понятия итерации или фазы..4 Определение сроков работ по бизнес-анализу— когда и в какой последовательности выполнять задачи BA. Полностью отсутствует..6 Приемка подхода— BABOK требует, чтобы подход был рассмотрен и согласован ключевыми стейкхолдерами. В системе нет механизма подтверждения подхода стейкхолдерами;save_ba_plan()финализирует документ без шага одобрения.
3.2 — Планирование вовлечения заинтересованных сторон
Что реализовано: plan_stakeholder_engagement() строит Power/Interest Grid, классифицирует по четырём квадрантам, назначает стратегию и частоту коммуникации.
Что не попало:
BABOK 3.2.4 описывает три элемента. Первый — анализ заинтересованных сторон — реализован хорошо: роли, influence, interest, attitude есть в модели Stakeholder. Но второй и третий элементы закрыты лишь частично:
.2 Определение сотрудничества с заинтересованными сторонами— BABOK требует планировать конкретные формы сотрудничества (воркшоп, интервью, wiki, лично или онлайн) для каждой группы. В инструменте определяется только квадрант и частота коммуникации («Еженедельно»,«При вехах»), но не конкретные форматы взаимодействия..3 Потребности коммуникации с заинтересованными сторонами— BABOK перечисляет восемь параметров: что сообщать, метод доставки (письменный/устный), аудитория, когда, частота, географическое положение, уровень детализации, уровень формальности. В инструменте из этого восьмёрки присутствует только частота. Остальное отсутствует — нет плана коммуникации как такового, только матрица вовлечения.
Также принципиально: BABOK подчёркивает, что анализ заинтересованных сторон выполняется многократно в течение всей инициативы. В AInalyst plan_stakeholder_engagement() вызывается один раз при планировании. update_stakeholder_registry() из 4.2 добавляет стейкхолдеров итеративно — это правильно, но обновления реестра не перезапускают процесс анализа Power/Interest и не пересматривают стратегии вовлечения для уже известных участников.
3.3 — Планирование руководства бизнес-анализом
Что реализовано: plan_ba_governance() фиксирует decision_makers, процесс контроля изменений, критичность проекта.
Что не попало — наибольший пробел в главе 3.
BABOK 3.3.4 определяет четыре элемента. Инструмент покрывает .1 Принятие решений (кто принимает решения, пути эскалации) на базовом уровне. Остальные три — существенно не закрыты:
.2 Процесс управления изменениями— BABOK описывает семь конкретных вещей, которые нужно определить при проектировании процесса CR: как запрашивать изменения, элементы запроса (стоимость, выгоды, риски, приоритет), как приоритизировать, как документировать, как сообщать, кто анализирует влияние, кто санкционирует.plan_ba_governance()принимаетchange_control_processкак свободный текст. Реальный процесс управления CR проектируется не здесь, а существует как факт вrequirements_assess_changes_mcp.py— но без связи с решениями, принятыми на этапе планирования..3 Планирование подхода к приоритизации— BABOK требует заранее определить формальность процесса, участников, техники и критерии приоритизации. В планировании это не фиксируется.requirements_prioritize_mcp.pyпросто предлагает три метода на выбор, но это решение принимается на ходу, а не планируется в начале проекта..4 Планирование одобрения— BABOK требует заранее определить, что именно подлежит одобрению, в какие сроки, по какому процессу и кто одобряет. Это не планируется явно:requirements_approve_mcp.pyработает по умолчанию, без связи с решениями, принятыми при governance-планировании.
3.4 — Планирование управления информацией бизнес-анализа
Что реализовано: plan_information_management() фиксирует инструменты хранения, уровень трассировки, типы артефактов, правила доступа.
Что не попало:
.2 Уровень абстракции— BABOK говорит о том, что разным стейкхолдерам нужны разные уровни детализации, и это нужно планировать заранее. В инструменте этого нет. Архитектура требований (сервер 7.4) создаёт представления для разных аудиторий позже, но без опоры на план, созданный здесь..4 Планирование повторного использования требований— BABOK выделяет это отдельным элементом: как структурировать требования, чтобы они были пригодны для будущих инициатив. В инструменте планирования этого нет.find_reusable_requirements()из 5.2 находит кандидатов реактивно, уже после создания требований, а не планирует повторное использование заранее..6 Атрибуты требований— BABOK перечисляет девять стандартных атрибутов: абсолютная ссылка, автор, сложность, владелец, приоритет, риски, источник, стабильность, статус, срочность. Вplan_information_management()набор атрибутов не планируется. Фактические атрибуты вtraceability_repo.jsonопределены жёстко внутри серверов 7.1 и 5.1 — но решение о том, какие атрибуты использовать в проекте, на этапе планирования не принимается.
3.5 — Определение возможностей улучшения эффективности
Что реализовано: evaluate_ba_performance() фиксирует текущие проблемы, метрики и генерирует план улучшений.
Что не попало:
Здесь содержательный пробел меньше, чем в других разделах, но он есть.
.1 Анализ эффективностии.3 Анализ результатов— BABOK описывает мониторинг как непрерывный процесс на протяжении всей инициативы. В AInalystevaluate_ba_performance()вызывается разово, как инструмент планирования. Нет механизма периодического повторения — хука или напоминания, который бы предлагал BA запустить оценку в середине проекта или в конце фазы..2 Оценочные показатели— BABOK описывает семь показателей: правильность и полнота, знание, эффективность, организационная поддержка, значимость, стратегический аспект, своевременность. Инструмент принимаетmetrics_jsonв свободной форме, но не предлагает эти стандартные BABOK-метрики как шаблон.
Системный пробел: мониторинг
В названии главы 3 — «Планирование и мониторинг бизнес-анализа». Слово «мониторинг» в коде практически отсутствует. BABOK явно говорит, что планы обновляются в ответ на изменяющиеся условия, эффективность отслеживается непрерывно, а подход к BA может меняться по ходу инициативы.
В AInalyst глава 3 работает как одноразовый setup — создал план, сохранил в ba_plan.json, перешёл к следующей фазе. Нет ни одного инструмента для:
сравнения запланированного с фактическим по ходу проекта,
обновления подхода при изменении условий,
периодических check-in на соответствие плана реальности.
По сути, ba_plan.json создаётся в начале и больше никем не читается — ни один из 21 остальных серверов не обращается к нему как к входящему контексту.
У вас инструкция заканчивается на запуске claude. А как вы себе весь пайплайн представляете? Вот сходил BA на звонок с бизнесом, (Клод же ещё пока не умеет этого) и дальше будет Клоду пересказывать?
И ничего не сказано про интеграции со всякими системами которые любят аналитики чтобы загружать туда результаты своего анализа
БА все сырые материалы, в том числе транскрипты интервью, загружает в паку inputs. И дает указание клод коду их обработать. Все результаты - готовые артефакты получает в папке governance_plans/reports.
Транскрибация аудиозаписей производится какими-то сторонними сервисами, их очень много. Если же стейкхолдер не дает разрешение на аудиозапись, то это косяк, да.
Если все же дал, то транскрибируете в стороннем сервисе, и текст интервью (воркшопа) кладете в папку inputs. Пайплайн стандартный и подробно писан в документации: Айналитик обрабатывает и фиксирует, результаты складывает в папки: governance_plans/data и governance_plans/reports. Это "выходные" папки.
С единственной разницей. В reports выдаются готовые артефакты для БА - эта папка для вас. Папка data это база данных проекта, в ней хранятся файлы формата json, в которых содержаться промежуточные результаты (стейкхолдеры, принятые решения и т.д.). Сюда БА лучше не лезть и ничего не трогать.
Ну про сторонние сервисы не сказано в статье, да. В нее не все поместилось. Но в документации сказано. На данный момент по дефолту есть интеграция с конфлюенсом в виде mcp сервера. Если нужны еще какие-то сервисы, то можно их подключить. Нужно только соответствующий mcp сервер. Его надо либо найти у разработчика нужного вам сервиса, либо самостоятельно разработать.
В файле use-cases описан сценарий использования айналитика с конфлюенс. Требования можно хранить не только в виде json файлов, но и выгружать в конфлюенс. Если вы начали проект раньше и у вас уже есть требования в конфлюенсе, то можно выгрузить их в айналитика и работать с требованиями в нем. Т.е. начать использовать айналитика можно не с самого начала проекта.
"Чтобы получить правильный ответ, нужно задать правильный вопрос." - Козьма Петров
Я преподаю BABOK третий год( в IBS). Закончила курс по нейросетям( приТомском государственном университете). Работающий бизнес-аналитик. Внимательно прочитала. Очень здорово, что рутинную работу бизнес-аналитика можно будет поручить ИИ, методы ВАВОК достаточно трудоёмки, иногда их просто не выполняют, не хватает ресурсов. В этом вопросе ИИ поможет. Но давайте не забывать, что главная цель бизнес-анализа по BABOK - решение проблем заказчика. Разработка информационной системы может быть(но не обязательно) таким решением. Сертификация по BABOK включает не просто ответы на вопросы, но и решение кейса. При его решении можно применять техники BABOK. Но какой инструмент применять, как выявлять проблему- в BABOK нет, поэтому сертифицируют тех, кто набрался опыта. То, что описано в статье- техническая работа, когда решение проблемы найдено. Его можно уточнять и детализировать, и здесь ИИ сильно облегчит (но не упростит) работу. Но автор статьи лукавит, называя ее " я научил ИИ работать бизнес-аналитиком". Секретарем бизнес -аналитика -да, научил. Но не бизнес -аналитиком. Бизнес -аналитик - это в первую очередь тот, кто думает. И кто способен проверить результат работы ИИ. Времена сильно меняются, и старые рецепты( на которых обучена ИИ) могут перестать работать. BABOK - это собранные техники, но можно выучить их все и... Не научиться решать проблемы.
ИИ не заменит человека, по крайней мере, я на это надеюсь. Но очень сильно изменит его работу, возможно, где-то даже немножко вытеснит. Однако все равно human in the loop останется. Сможет ли ИИ решать реальные серьезные проблемы? Вопрос философский. Спорить тут трудно. Время покажет. Но то что уже сейчас ИИ решает некоторые проблемы это факт. Лично мне он много раз подсказывал хорошие решения. Да, ему для этого нужно дать хорошую четкую инструкцию, следить за контекстным окном.
Теперь насчет того, чем же все-таки является AIналитик? Секретарем? Да, для опытных аналитиков он им является. Может взять на себя много рутинной работы. А для неопытных аналитиков он кто? Тут он уже больше методолог. Он подсказывает и ведет человека по процессу, который он - человек не знает. Я в статье вроде описал же все целевые аудитории...
Ну так вот , я не согласна с тем,что неопытного аналитика должна вести ИИ -нужно понимать, что именно и зачем делаешь. Слепое доверие к ИИ чревато проблемами. Далеко не надо ходить, на неделе было совещание, безопасник не хотел открывать порты(а мы не могли работать дальше без этого), требовал выполнения некой системной операции. И выяснилось, что такой операции просто нет, И ее просто придумала! Вам не кажется, что это простот опасно давать людям в руки инструмент, которым они не умеют пользоваться?
Коллеги, я вижу, что мне в личку приходят сообщения. В частности, были сообщения от @DrDruid @Aleks_Merz К сожалению, я не могу прочитать ваши вопросы - сообщения не открываются. Не пойму, то ли мне прав не хватает, то ли еще что. Используйте другие каналы коммуникации. Например, мой тг: @achaussky
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я научил Claude Code работать бизнес-аналитиком по руководству BABOK. Вот что получилось