PRO код для аналитика 💻

Нужно ли системному аналитику уметь писать код?
Нет. 🙅‍♂

Но я убеждён, что опыт кодирования сильно повышает компетентность системного аналитика. 🚀

Я начал программировать ещё в школе и это был Pascal. Потом в университете были C, C++, ассемблеры для RISC и CISC, программировал микроконтроллеры, писал прошивки и драйверы.

После университета писал программы для диссертации на MATLAB и C#, делал прошивки для DSP-процессоров, писал на PHP, Java, HTML, CSS. Делал Excel-макросы, собственные программы и инструменты для компании (например, написал систему управления рабочим временем), дорабатывал Redmine под наши процессы.

Сейчас чаще всего пишу на Python. Правда, значительную часть кода теперь пишут за меня нейросети. 🤖

Но дело не в количестве языков.

Когда ты сам хотя бы раз проходишь путь от идеи до работающего решения, начинаешь иначе смотреть на работу системного аналитика.

Ты понимаешь, что недостаточно спроектировать решение, которое работает сегодня.

Нужно подумать, что с ним будет завтра. Да, об этом мог бы подумать архитектор или разработчик, но тем не менее.

Постоянно нужно учитывать:

✔️Что произойдёт, если изменится бизнес-правило?
✔️ Появится новый сценарий?
✔️ Потребуется подключить ещё одну систему?
✔️Изменится существующий процесс?

Системный аналитик уровня senior, на мой взгляд , точно должен учитывать эти моменты.

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

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

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

А если вы пока только присматриваетесь к профессии системного аналитика, сейчас есть хороший способ попробовать её на практике.

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

Кстати спасибо за отзывы 🤝! На их основе улучшается бот)

Но это не предел.

Мы сделали небольшой 🆓 мини-практикум по интервью с заказчиком. 🎤

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

Начать можно здесь:
[ссылка на бота] 🐭

Это не лекция о профессии, а немного предметной теории и возможность попрактиковаться.

----

✌️ ПРО СА| 🆕 НСА 2.0

PRO шум вокруг ИИ 🤖

Здесь у нас канал про системных аналитиков, а значит вот эти все концепции: промты, скиллы, агенты, харнес, обсер(прошу прощения)вабилити, должны быть раскрыты до уровня вызовов API, а не поверхностно на уровне: "запилим агента".

У меня кончились лимиты (включился Fable 5.1 и за ночь все съел), а поэтому:

лет ми спик фром май хард

, т.е. пишу без использования ИИ. ✍️

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

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

Вот две ссылки, по которым стоит перейти и изучить информацию, если хочешь понимать, как это действительно работает:
1⃣OpenAI: Responses API
2⃣Anthropic: Messages API

А кому лень изучать: разберу эти темы в следующих постах.

--

❗️И небольшое объявление: 17 сентября с Владимир Соловьев, будем проводить открытое онлайн мероприятие, где расскажем про то, что изменилось в работе системного аналитиков за последний год из-за появления ИИ и что делать, чтобы не быть замененным "простым скриптом". 📅

Информация будет полезна:
➖как тем, кто уже в теме и планирует расти в профессии,
➖так и тем, кто кто хочет стать в 2026-2027 годах новым системным аналитиком.

----

✌️ ПРО СА| 🆕НСА 2.0

PRO то, что под капотом у агента 🤖 (часть 01).
Первый запрос.

Вчера написал (прямо вот тут👆), что весь этот шум вокруг ИИ в конечном итоге сводится к нескольким вызовам API. Давайте проверим.

Возьмем обычную задачу:

Проанализируй задачу TASK-123 в JIRA

Если запустить это через Codex или Claude Code, мы просто напишем задачу и через какое-то время получим готовый результат (ну или нет).

Что там происходило в фоне, можно вообще не знать.
Но давайте не будем брать готового агента. Попробуем собрать своего, используя только API.

И будем идти прямо по шагам. Запрос. Ответ. Следующий запрос. И так далее.
Начинаем с самого простого.

Отправляем модели POST /v1/responses:

{
"model": "gpt-5.6-luna",
"input": [
{
"role": "user",
"content": [
{
"type": "input_text",
"text": "Проанализируй задачу TASK-123 в JIRA"
}
]
}
],
"tools": []
}

На этом моменте ничего особенного не происходит. Мы просто отправили модели текст.

➖"model" говорит, какую модель использовать.
➖"input" содержит нашу задачу.

И всё.

Модель при этом не может зайти в Jira. У неё нет ни логина, ни доступа к API Jira, вообще ничего.

Поэтому вполне ожидаемый ответ:

Пришлите содержимое задачи TASK-123.

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

Вот это и посмотрим в следующем посте.

А дальше уже доберемся до tool calls, MCP, Skills и в итоге соберем весь этот «агентский» конструктор своими руками, чтобы понимать как эта "черная коробка" работает на самом деле.

----

✌️ ПРО СА| 🆕НСА 2.0

PRO то, что под капотом у агента 🤖 (часть 02).
Как агенту сходить в JIRA

В прошлом посте мы отправили модели простую команду: «Проанализируй задачу TASK-123 в JIRA». Модель получила текст, но не получила саму задачу. Она не знает, что такое наша Jira и тем более не может самостоятельно сходить туда за данными.

Значит, нужно дать ей такую возможность.

Для этого мы описываем доступную функцию для модели:

{
  "type": "function",
  "name": "jira_get_issue",
  "description": "Получает полную информацию о задаче из JIRA по её идентификатору",
  "parameters": {
    "type": "object",
    "properties": {
      "issue_key": {
        "type": "string",
        "description": "Идентификатор задачи, например TASK-123"
      }
    },
    "required": ["issue_key"]
  }
}

Обратите внимание: мы пока ничего не вызываем.

Мы просто сообщаем модели: у тебя есть операция jira_get_issue. Чтобы ей воспользоваться, нужно передать идентификатор задачи.

Теперь модель получает исходную команду, описание этой функции и может вернуть уже не обычный текст, а структурированный function_call:

{
  "type": "function_call",
  "name": "jira_get_issue",
  "call_id": "call_123",
  "arguments": "{\"issue_key\":\"TASK-123\"}"
}

По сути, модель говорит нашей системе:

Мне нужны данные задачи TASK-123. Вызови для этого функцию jira_get_issue

И вот здесь появляется важное разделение ответственности.

Модель: принимает решение, какую операцию нужно выполнить.
Наша система: реально вызывает Jira.

Но пока мы остановимся на этом месте. Инструмент выбран, но действие ещё не выполнено.

В следующем посте замкнём эту цепочку: разберём function_call, вызовем Jira API, получим результат и вернём его обратно модели.

После этого у нас впервые появится полный цикл взаимодействия модели с внешней системой.

——

Просматривая вакансии, я все чаще наблюдаю, что понимание базовых вещей связанных с работой с ИИ становятся требованиями к кандидатам. Поэтому 17 сентября с Владимир Соловьев, будем проводить открытое онлайн мероприятие, где расскажем про то, что изменилось в работе аналитиков за последний год из-за появления ИИ и что делать, чтобы не быть замененным "простым скриптом". 📅

А пока ждёте эфир:
➖потренируйтесь выявлять потребности у заказчика в нашем тренажере - это бесплатно 🔥
➖Так же продолжает улучшаться наш бот по оценке резюме (подробнее вот тут 👆).

——

✌️ ПРО СА| 🆕НСА 2.0

PRO то, что под капотом у агента 🤖 (часть 03).
Цикл замкнулся.

В прошлой части☝ модель выбрала инструмент jira_get_issue и вернула нам function_call.

На этом этапе легко подумать, что модель уже сходила в Jira. Но нет. Она только сформировала инструкцию для нашей системы.

Наша программа получает примерно такой ответ:

{
  "type": "function_call",
  "name": "jira_get_issue",
  "call_id": "call_123",
  "arguments": "{\"issue_key\":\"TASK-123\"}"
}

Теперь работа переходит к нашему коду. Он разбирает arguments, находит функцию jira_get_issue и вызывает уже настоящий Jira API.

Jira возвращает данные:

{
  "key": "TASK-123",
  "summary": "Добавить оплату картой",
  "status": "In Progress",
  "description": "..."
}

Но и здесь работа ещё не закончена.

Полученные данные нужно вернуть модели. Для этого мы отправляем в Responses API результат выполнения функции:

{
  "type": "function_call_output",
  "call_id": "call_123",
  "output": "{\"key\":\"TASK-123\",\"summary\":\"Добавить оплату картой\",\"status\":\"In Progress\"}"
}


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

Она может продолжить анализ и уже сформировать ответ пользователю.

Получилась первая полноценная цепочка:
1⃣ наш вопрос к модели + доступная функция →
2⃣ модель выбирает нужную функцию →
3⃣ модель возвращает function call →
4⃣ наш код парсит function call и делает запрос в JIRA →
5⃣ JIRA нам отвечает →
6⃣ наш код получает результат и отправляет в модель →
7⃣ модель получает дополнительные данные →
8⃣ модель возвращает нам ответ на наш вопрос.

И это, пожалуй, самый важный момент во всей конструкции.

Агент не является каким-то отдельным объектом. В основе его работы - обычный цикл, который связывает модель, инструменты и результаты их выполнения.

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


——

17 сентября, будем проводить открытое онлайн мероприятие, где расскажем про то, что изменилось в работе аналитиков за последний год из-за появления ИИ и что делать, чтобы не быть замененным "простым скриптом". 📅

Пока ждёте эфир можете:
➖потренируйтесь выявлять потребности у заказчика в нашем тренажере - это бесплатно 🔥
➖Так же продолжает улучшаться наш бот по оценке резюме (подробнее вот тут👆). На текущий момент уже 114👍 регулярных пользователей)

😳 Когда пилил, не думал, что будет такой спрос.

——

✌️ ПРО СА| 🆕НСА 2.0

PRO function calling

За несколько последних постов мы разобрали одну простую, но важную конструкцию.

Начали тут☝с обычного запроса к модели:

«Проанализируй задачу TASK-123 в JIRA».

Затем вот тут☝ посмотрели, что происходит внутри API и почему сама модель не может просто взять и прочитать нашу Jira.

После этого вот тут ☝ описали модели инструмент jira_get_issue и увидели, как она сама сформировала function_call.

Модель не вызвала Jira напрямую. Она сообщила нашей системе: «Мне нужны данные TASK-123, вызови вот эту функцию».

Дальше наша система выполнила функцию, получила данные из Jira и вернула результат обратно модели.

На этом месте мы фактически разобрали function calling.

И здесь стоит зафиксировать терминологию.

Function calling - это частный случай более общего понятия tool calling.

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

То есть пока мы собрали довольно простой механизм:
модель → tool call → наша система → внешний сервис → результат → модель.

Но это ещё не полноценный агент.

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

И вот тут уже появляются agent loop, MCP, Skills и другие элементы агентной архитектуры.

Но куда двигаться дальше?

🌟Что разобрать следующим?

1️⃣ Как модель выбирает нужный инструмент из десятков доступных
2️⃣ Как устроен agent loop и несколько последовательных вызовов
3️⃣ MCP и как через него подключать инструменты
4️⃣ Skills и чем они отличаются от инструментов

Пишите номер в комментариях и по результатам продолжим серию.

——

✌️ ПРО СА| 🆕 НСА 3.0

Уже завтра! 📊

Напоминание! ⚠️

Сегодня в 19:00 живой эфир. Поговорим о профессии аналитика и о том, как сделать, чтобы тебя не заменил ИИ.

Самых активных ждут подарки, а в конце устроим розыгрыш. 🎁

Вход по ссылке: ссылка 👆

Начинаем через 5 минут. ⌛

Вход по ссылке: ссылка 👆

PRO то, зачем нам MCP 🤖 (часть 01).

По результатам опроса вот тут: ссылка 👆 была выбрана тема MCP. Поэтому на этой неделе ее и раскроем и продолжим рассматривать нашу ситуацию, когда мы что-то хотим получить из JIRA.

До этого мы подключали Jira к нашей модели вручную.

Описали функцию jira_get_issue, получили от модели function_call, сами вызвали Jira API и вернули результат обратно.

Для одного инструмента всё довольно просто.

Но теперь представим, что у нашего агента есть Jira, Confluence, GitLab, корпоративная БД и ещё несколько внутренних сервисов. Для каждого нужно описать инструменты, реализовать вызовы, разобраться с авторизацией, обработать ошибки и поддерживать всё это при изменениях внешних систем.

И здесь появляется MCP.

Model Context Protocol предлагает стандартный способ подключать модель к внешним источникам данных и инструментам. Вместо того чтобы для каждого агента отдельно писать интеграцию с Jira, можно иметь MCP-сервер Jira, который предоставляет набор доступных возможностей.

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

Получается следующая последовательность:
1⃣ модель →
2⃣ MCP-клиент →
3⃣ MCP-сервер (со списком инструментов) →
4⃣ внешняя система

При этом важно не перепутать MCP с самим инструментом.
jira_get_issue может оставаться инструментом.

MCP определяет, как этот инструмент предоставляется и как с ним взаимодействовать.

И это принципиальное отличие от того, что мы делали раньше.

➖до MCP мы сами проектировали контракт между нашим агентом и каждым внешним сервисом.
➖с MCP часть этой работы стандартизируется.

В следующем посте заглянем внутрь MCP и посмотрим что на самом деле происходит, когда агент подключается к MCP-серверу: как он узнаёт, какие инструменты доступны, и откуда берутся их описания.

——

Раньше агенту приходилось для каждой системы писать свою интеграцию с нуля: контракт, авторизация, обработка ошибок заново. MCP даёт готовый стандартный способ подключения, чтобы не изобретать велосипед на каждый новый сервис. Аналитик часто в похожей ситуации: под каждый навык свой курс, свой формат, собирает по кусочкам.

Практикум {НСА} 3.0 🎓 даёт тот же принцип: готовый путь вместо сборки с нуля

Уже вот-вот стартуем наш практикум {НСА} 3.0 🎓, который не просто поднял свою версию, а существенно обновил подход к обучению. Теперь кроме стандартной практики появляется возможность многократно отточить навыки в наших тренажерах:
✔️ тренажер по разработке требований
✔️ тренажер по работе с базами данных
✔️ тренажер по работе с интеграциями
✔️ тренажер по работе с нотациями
✔️ тренажер по работе с пользовательским интерфейсом

После работы в тренажерах вы будете ощущать себя еще более уверенными как на собеседованиях, так и на испытательном сроке. 😎

За информацией обращайтесь в личку или пишите под постом + и я напишу вам сам.

——

✌️ ПРО СА|🎓 НСА 3.0