Системный аналитик — это своего рода детектив в мире бизнеса: он собирает разрозненные требования, уточняет их, превращает в живые модели процессов, проверяет, что всё держится на прочном фундаменте, и постоянно находится на связи с заказчиками, разработчиками и дизайнерами. Сейчас к его «расследованиям» подключаются новые помощники – искусственный интеллект и машинное обучение. Они берут на себя скучные, повторяющиеся задачи, ускоряют анализ и даже способны самостоятельно создавать черновики проектных артефактов.
В этой статье я делюсь тем, как за последние полгода я превратила ИИ в своего партнёра по работе. Показала, как нейронные сети, большие языковые модели (LLM) и удобная инфраструктура MCP + IDE Cursor (или её аналоги) могут стать настоящими союзниками системного аналитика, облегчая рутину и открывая новые возможности для творчества.
Общаясь с коллегами, часто сталкиваюсь с некорректным использованием терминов, что иногда приводит к недопониманию и хаосу в голове. Если вы уже давно живёте в мире ИИ, машинного обучения и больших языковых моделей, эту терминологическую эпопею можно смело пропустить — вы знаете, о чём речь.
Скрытый текстИскусственный интеллект — это почти как волшебный набор инструментов, позволяющих машинам вести себя как люди. В него входят машинное обучение, обработка естественного языка (NLP), компьютерное зрение, планирование и прочие фокусы, которые делают машины умнее.
Но не забывайте: любой ИИ — это всё равно лишь набор железа, а железо работает на базе алгоритмов. Алгоритмы становятся всё более хитрыми, всё менее детерминированными, и предсказать их результат — уже почти как попытка угадать, что произойдёт, когда рекурсия захватит функцию в бесконечный танец. Чем глубже вызов рекурсии — тем труднее понять, какой будет выход, даже если входные данные известны. С ИИ ситуация похожа, только масштабируясь до миллионов таких танцев.
Инструменты, которые не попадают под машинное обучение, обычно опираются на классические алгоритмы принятия решений — их логика доступна человеку, но их реализация часто требует серьёзных инженерных навыков (электроника, встраиваемые системы и т.п.). Примеры: промышленные роботы, датчики, которые «видят» свет и расстояние, и всё, что построено на прямой, понятной логике.
Алгоритмы машинного обучения, в свою очередь, умеют глотать огромные массивы данных, извлекать из них скрытые взаимосвязи и находить паттерны, которые человеку было бы сложно разглядеть. Их минус — потребность в гигантском количестве обучающих примеров и то, что решения в этих моделях превращаются в «чёрные ящики», недоступные для человеческого понимания.
Нейронные сети — это, по сути, продвинутый предсказательный механизм, почти как супер‑мощный прокаченный T9 из вашего телефона, который учится на данных. Без обучения они представляют собой просто набор сложных математических формул, а с хорошей диетой данных превращаются в живого ребёнка: сначала ничего не знает об окружающем мире, а потом, получая опыт (например, обжегшись от горячей плиты), начинает делать выводы. Без данных и обучения, нейронка остаётся пустым алгоритмическим каркасом, способным лишь выполнять фиксированные вычисления.
Большие языковые модели (LLM) – это уже гигантские нейронные сети, специально натренированные для того, чтобы понимать и генерировать естественный язык. Они способны вести диалог, писать статьи, переводить тексты и делать многое другое, потому что их мозг построен из триллионов параметров, откормленных колоссальными массивами текста.
Давайте разберём, какие фишки скрывают большие языковые модели, — чтобы при выборе своей модели для системного анализа не попасть впросак, а получить именно тот инструмент, который будет работать как швейцарский нож, а не как громоздкая мусорка. Ниже приведена таблица с характеристиками моделей и их описанием.
Показатель | Описание |
Количество параметров | Чем больше — “умнее”, но растёт память и время инференса. Пример: Qwen2.5‑VL‑32B (32 млрд параметров). |
Контекст (длина окна) | Сколько токенов модель может видеть одновременно (например, 8 к токенов у GPT‑4). Чем длиннее окно, тем лучше модель работает с большими документами, но выше требования к памяти. |
Температура | Степень случайности в ответе (0 — детерминированный, 1 — более творческий). |
Top‑p (nucleus sampling) | Ограничивает выбор токенов до наиболее вероятных — контролирует «разброс» ответа. |
Penalties (frequency/ presence) | Снижают повторение одинаковых фраз, делают текст более разнообразным. |
Как и в любой работе, здесь нужен компромисс между красотой и скоростью. Если вам нужно быстро выудить кусок фактов — берите модели с небольшим числом параметров: они молниеносно выдают ответ. А когда перед вами сложный сценарий, требующий тонкой проработки, включайте тяжеловесов с большим числом параметров — они медленнее, но дают гораздо более глубокий и точный результат.
Как подобрать «дом» для своих ИИ‑инструментов? Выбор инфраструктуры для развертывания инструментов ИИ зависит от множества параметров: доступность инструментов, безопасность, конфиденциальность, стоимость, наличие аппаратного обеспечения и пр. Но главный вопрос, на который стоит ответить перед началом внедрения ИИ в работу системных аналитиков — это какой набор задач вы собираетесь решать. От этого и будет зависеть, какой «технический кокон» вам лучше всего подойдёт.
IDE Cursor — наша рабочая станция. Если захотите альтернативу с открытым кодом, взгляните на VoidEditor — по дизайну и удобству почти дублирует Cursor.
Ollama — локальный магазин современных языковых моделей: скачиваем, ставим, запускаем без лишних облачных хлопот.
Транскрибаторы с ИИ — для превращения разговоров в текст. Наиболее популярные у нас:
tl;dv – «too long; didn’t view» (по‑русски «слишком долго, не смотрел» или «многабукф») — https://tldv.io/ru/;
MyMeet AI — https://app.mymeet.ai/ru/.
IDE мы подружили с MCP‑сервером, и теперь в один клик получаем доступ к статьям в Confluence, задачам в Jira и макетам в Figma.
MCP (Model Context Protocol) — открытый протокол, который задаёт единый язык общения между клиентом (например, вашим IDE), MCP‑сервером и большой языковой моделью (LLM). Благодаря MCP LLM умеет запрашивать внешний контекст (файлы, БД, API) и заставлять внешние сервисы выполнять действия от её имени.
Три участника диалога:
Роль | Что делает | Пример |
Клиент (например, IDE) | Начальная точка, с которой начинается взаимодействие, запускает разговор, отправляет запросы к серверу и получает ответы от модели | Cursor, VS Code, VoidEditor |
MCP‑сервер | Предоставляет определенные услуги или сервисы (поиск в файловой системе, запросы к GitHub API, работа с базой и т.д.) и предоставляет их через стандартизированный API. | Наш локальный сервер с набором tools |
LLM | Принимает промпт + описание доступных инструментов, решает, какой из них нужен, вызывает его через сервер и формирует окончательный ответ | GPT‑4, LLaMA, Mistral и др. |
MCP Server:
Предоставляет сервисы в виде инструментов (tools), ресурсов и промптов.
Выступает в роли стандартизированного API, через который клиент может запрашивать и выполнять функции сервиса.
Клиент (например, IDE):
Инициирует запросы к MCP серверу для получения списка доступных инструментов.
Передает полученную информацию о сервисах в LLM вместе с промптом.
LLM:
Обрабатывает переданный промпт с информацией о доступных инструментах.
Определяет, какой инструмент необходим для решения конкретной задачи, и сообщает об этом клиенту.
Получает результаты выполнения инструмента и формирует финальный ответ.
На диаграмме взаимодействия это выглядит примерно так:
Таким образом, MCP становится мостом, который позволяет модели выходить за пределы своего собственного контекста, а вам — получать от ИИ всё, что действительно нужно для анализа, проектирования и автоматизации.
Итак, инструменты выбраны, рабочая среда уже завелась — переходим к самому интересному! Где же ИИ может стать надёжным помощником системного аналитика? В таблице ниже я собрала конкретные примеры задач с разных этапов работы системного аналитика. А дальше — в статье: реальные кейсы из моего собственного опыта, где искусственный интеллект уже успел показать, что умеет.
Область | Конкретные задачи | Как ИИ помогает |
Анализ и обработка требований | Автоматическое извлечение требований из текстов (от бизнес‑аналитика) Классификация на функциональные/нефункциональные | LLM‑парсеры, обученные на примерах ТЗ, способны выделять ключевые фразы и классифицировать их |
Моделирование процессов | Генерация BPMN‑диаграмм из описания Преобразование текста в UML‑ и ER‑диаграммы Проверка корректности моделей Генерация документации к моделям | С помощью LLM + MCP‑инструментов (например, |
Сценарии и пользовательские кейсы | Описание основных, негативных и альтернативных сценариев | LM может предложить варианты сценариев (в том числе негативных и альтернативных), а также сформировать пользовательские истории |
Сверка макетов с ТЗ | Сравнение дизайна (Figma) с техническим заданием | Через MCP‑команды |
Но есть и тёмные зоны, где ИИ (пока ещё?) не заменит человека — это мир софт‑скиллов, эмоционального и социального интеллекта. Ниже в таблице собраны типичные задачи, в которых пока только человек может проявить сочувствие, интуицию и живой контакт.
Задача | Почему ИИ не справится |
Переговоры с заказчиком | Требуется чувство эмпатии, чтение невербальных сигналов |
Выявление истинных потребностей | Неочевидные мотивы и скрытые цели часто выражаются невербально |
Уточнение требований | Нужен диалог в реальном времени, уточнение деталей, обсуждение компромиссов |
Обсуждение нюансов реализации с разработчиками | Технические ограничения, компромиссы в архитектуре требуют совместного мышления |
Согласование макетов с дизайнерами | Визуальная эстетика и бренд‑соответствие – сфера субъективных решений |
Эти задачи требуют живого общения, а не сухих вычислений — это по‑прежнему чисто человеческая зона ответственности. ИИ может лишь подкинуть справочную подсказку (например, быстро вывести текущий статус задачи в Jira), но настоящего диалога и эмпатии от него ждать не стоит.
В Cursor вы сразу попадаете в три уютных уголка — редактор кода, где пишете и правите код (например, в UML), превью, где мгновенно видите, как материализуется результат вашего кода, и чат, в котором можно задавать вопросы модели и получать подсказки на лету.
Допустим, вам нужно превратить техническое задание в диаграмму последовательности. Пишите ТЗ в Confluence, кидаете запрос в чат‑бота (например: «Сгенерируй диаграмму последовательности для описанного сценария»), а готовую графику сразу получаете в превью — без переключения окон и копипаста:
В Cursor это превращается в короткую сценку. В данном примере запрос в чат-боте звучал так: «Построй ER-диаграмму по ТЗ <ссылка на ТЗ в Confluence>». При этом в ТЗ не обязательно должно быть описание таблиц базы данных, с сущностями, связями, ключами и прочим. Достаточно просто указать, какие данные должны храниться и как они могут или будут использоваться.
И, кстати, Cursor не ограничился только красивой UML‑схемой — он сразу выдал набор готовых SQL‑скриптов: от простых SELECT‑ов до сложных JOIN‑ов по только что созданным таблицам. Такие запросы пригодятся и аналитикам, и службе поддержки, и любой команде, которой нужно быстро выжать данные из новых таблиц.
В редакторе уже живут умные подсказки — autocomplete, которые подсказывают имена полей, функции и даже готовые шаблоны. В окне чата аналитик задает промпты: «сгенерируй модель заказ‑пользователь», «напиши README для микросервиса», — и получает готовый код, диаграммы или документацию в считанные секунды.
Горячие клавиши, ускоряющие работу:
Ctrl + K
— открывает поле для ввода инструкции (промпта) — быстро задаёте задачу генерации кода
Ctrl + L
— переключается в чат и выводит консольный результат выбранного инструмента — мгновенный отклик без потери фокуса
И, конечно, в правом углу можно переключить модель, с которой работаете в данный момент: от лёгкой, быстрой tiny‑LLM до мощного GPT‑4‑like для сложных аналитических задач. Выбираете нужный «мозг», который дальше всё делает сам:
Важно. После установки MCP‑Server в его UI сразу раскрывается полный список доступных инструментов — Jira, Confluence, Bitbucket, Figma и многие другие. Наведите курсор на любую команду — появится короткая подсказка‑описание, и даже новичок быстро поймёт, как ею пользоваться. Это делает обучение аналитика почти интуитивным: всё, что нужно, уже под рукой, а объяснения появляются в реальном времени.
Система | Команды | Что делают |
Confluence |
| Поиск страниц, чтение/создание/обновление контента, работа с вложениями |
Jira |
| Получение задач, поиск, создание/обновление, добавление комментариев, привязка к эпикам |
IDE делает запрос – «дай список всех доступных инструментов».
MCP‑Server отвечает перечнем команд (например, jira_search, confluence_get_page) и эти названия сразу включаются в промпт, который отправляется в LLM.
LLM «читает» задачу, решает, какой инструмент нужен (скажем, «нужен поиск требования в Confluence») и посылает соответствующий запрос обратно серверу.
MCP‑Server исполняет команду, возвращает результат, а LLM, получив данные, формирует готовый ответ — будь то BPMN‑диаграмма, таблица требований или отформатированный текстовый документ.
Итог: аналитик работает только с одним чат‑окном, а все тяжёлые операции (поиск в Jira, скачивание вложений, генерация кода) прячутся за единым, стандартизированным API. Всё, что нужно – задать вопрос, а остальное делает система.
Запускаем чат в Cursor и делаем запрос:
«Сгенерировать BPMN‑диаграмму процесса «Оформление заявки» из текста ТЗ (ссылка на ТЗ в Confluence).»
IDE шлёт к MCP‑Server запрос о том, какие инструменты доступны. Сервер отвечает списком, где уже видно confluence_get_page, jira_search и другие фишки.
LLM читает наш промпт, быстро понимает, что нужна именно страница из Confluence, и выбирает команду confluence_get_page.
MCP‑Server вытаскивает содержимое нужной Confluence‑страницы и передаёт его обратно модели. LLM парсит текст, формирует PlantUML‑скрипт BPMN‑диаграммы и отсылает его в IDE.
Cursor мгновенно рендерит полученный код в окне превью, а в чат‑окне выводит готовую диаграмму с небольшими пояснениями.
Весь «волшебный» цикл занимает всего несколько секунд и полностью освобождает аналитика от ручного копипаста, редактирования и мучительных проверок синтаксиса.
Заказчик просит добавить в уже существующее мобильное приложение новый финансовый отчёт.
В отчёте 4 категории, в каждой — по 8 одинаковых подкатегорий.
Данные будет выгружать финансовый менеджер в привычном CSV‑файле (он умеет только Excel, от него не уйти).
Транскрибатор фиксирует всё, а аналитик сразу кладёт протокол в Confluence.
Небольшой инсайд: Юрий Куприянов в своей статье об уровнях проектирования архитектуры (см. https://t.me/c/1724566167/5839) упоминает неявные 8 и 9 уровни. Данный кейс является ярким примером 8‑го уровня — уровня политики и влияния. Никакая LLM в здравом уме не предложила бы использовать csv-файлы, но «заказчик всегда прав», так что работаем с тем, что есть.
Обсуждаем текущую архитектуру мобильного клиента. Пришли к решению:
Создать новую конечную точку GET — будет отдавать новый отчёт.
Определить JSON‑пакет — формат, который приложение будет парсить.
Написать конвертер CSV → JSON — чтобы финансовый менеджер мог просто загрузить файл.
Пользователь мобильного приложения будет по‑прежнему открывать страницу отчёта, теперь уже запрашивая новый эндпоинт и получая готовый JSON.
Транскрибатор опять фиксирует всё в резюме.
В Cursor открываем чат, вставляем ссылку на запись в Confluence и просим создать:
UML‑диаграмму последовательности, описывающая взаимодействие клиент‑сервер‑конвертер
JSON‑шаблон с транскрибированными русскими названиями категорий/подкатегорий и CSV‑трафарет (пример файла) для финансового менеджера
LLM мгновенно генерирует PlantUML‑код диаграммы, JSON‑структуру и CSV‑пример. Аналитик копирует полученные артефакты в техническое задание.
После быстрой валидации UML‑диаграммы аналитик просит Cursor запушить её в репозиторий проекта (в папку Docs). MCP‑сервер берёт файл, делает git commit + push, и готово — документация уже в репозитории кода проекта.
Последний шаг: аналитик просит Cursor разбить работу на задачи в Jira. На основе бизнес‑требований генерируются тикеты:
Дизайн макетов нового отчёта.
Реализация эндпоинта GET.
Написание CSV → JSON‑конвертера.
Тестирование и покрытие unit‑тестами.
Cursor через MCP‑сервер создаёт эпики, задачи и подзадачи, проставляя ссылки на Confluence‑статью и готовые артефакты.
За несколько минут от записанной встречи мы получили:
Полную UML‑диаграмму процесса.
JSON‑шаблон и CSV‑трафарет для финансового менеджера.
Код уже попал в репозиторий.
План работы в Jira готов к спринту.
ИИ‑ассистент в виде Cursor + MCP‑сервер полностью автоматизировал рутину, а аналитик оставил себе лишь творческое решение и контроль качества.
Как и при внедрении любого изменения, начать использовать ИИ в своей работе системным аналитикам не так просто. Многих из них приходится «пушить». Когда я проводила опрос сотрудников, почему они не используют или используют мало ИИ в своей работе, я выявила две основные причины:
«Боюсь, что потеряю свою компетенцию» Вполне обоснованное опасение. Когда всё делаешь сам, шаг за шагом, образуются нужные нейронные связи, навык закрепляется лучше и надолго. Если же доверить выполнение задач ИИ, то кажется, что нейронные связи образуются не у тебя. Но мне есть, что возразить на это: думать за тебя ИИ не будет; чтобы грамотно сформулировать промпт, надо осознать задачу, пропустить ее через себя; а после выдачи результата, его надо снова пропустить через себя, найти неточности, наложить предложения ИИ на существующую архитектуру, выполнить fine-tuning решения, задать ИИ уточняющие вопросы, если ИИ предложит использовать какую-то новую технологию, о которой ты не знал/не слышал, то у ИИ же можно узнать больше про нее, задав кучу уточняющих вопросов. Таким образом, компетенция не будет теряться, а наоборот, углубляться.
«Не разберусь с настройкой окружения – там же столько всего!». Да, пока (!) настройка окружения не делается в пару кликов. Но это пока. Мы привлекали девопсов, опсов, читали кучу статей. Но в итоге справились. И для нивелирования этого страха привлекли технического писателя, который подготовил инструкции по настройке окружения и основным сценариям использования ИИ.
LLM в сочетании с MCP Server позволяют аналитикам работать в едином чат‑интерфейсе, скрывая сложные операции (поиск, генерацию кода, построение диаграмм).
MCP + IDE Cursor предоставляет гибкую, расширяемую платформу, где новые инструменты (Jira, Confluence, Figma и др.) легко подключаются и сразу же становятся частью рабочего процесса.
Человек всё равно нужен: эмпатия, креативное мышление незаменимы в тех областях, где требуется эмоциональное взаимодействие и субъективные решения.
Поднять такую инфраструктуру сегодня значит:
Сократить часы (да и дни) на подготовку ТЗ
Сделать модели процессов точнее
Разгрузить аналитика из рутинных задач
Короче, меньше возни с кодом, больше аналитической работы и коммуникаций.