Привет, меня зовут Юрий Черепов, я технический лидер системной аналитики в Альфа-Банке. Однажды на внутреннем «митапе» для аналитиков, где мы обсуждали, как AI применять в работе аналитика, мне задали вопрос: «Не делает ли AI людей «слабее? Не приведёт ли использование AI к деградации профессиональных навыков? Мы ему всё делегируем и разучимся думать сами».
Вопрос хороший. Хочется разобраться, что происходит и в какое будущее всё движется. Но сначала я бы хотел окунуться в прошлое.
Аналитик 1.0: «Толмач»
Первые системные аналитики появились в 50-х — 60-х как посредники между бизнесом и разработчиками. Работа аналитика была проста: собрать требования и передать дальше без итераций. Артефактом был большой SRS‑документ, который ждали долгие месяцы согласований, так как работали по ватерфолу. Успех работы аналитика зависел от точности ТЗ, а не от пользы для бизнеса.
Звучит дико? Но это была абсолютно логичная система для своего времени. Да и не только для своего — эта система работает и сейчас. К примеру, у одного нашего заказчика был огромный, растянутый на 5 лет, проект мастер-системы для оценки всех коммуникаций в компании системой оценки качества работы. Когда мы приступили к финальному этапу, то обнаружилось, что ТЗ не отображает реальные потребности заказчика, и что текущие интеграционные контракты не отображают его боли. Поскольку мы были в хороших отношениях с заказчиком, то переделали архитектуру и успешно закрыли последний этап. Но это были дополнительные усилия и расходы с нашей стороны.
Главная проблема Аналитика 1.0 это то, что называется «Стеной». Формальный документ не передавал главного, того, что люди понимают с полуслова — контекста и неявного знания. Соответственно, разработчик додумывал непрописанное сам и закрывал пробелы, что вызывало расхождения с ожиданиями.
Аналитик 2.0: Системный интегратор
Второе поколение это 2010-е (по моей хронологии). Если вы сейчас в профессии, то, скорее всего, вы аналитик 2.0, так как по сути дела это наш сегодняшний стандарт.
Аналитик 2.0 — это интегратор в кросс‑функциональной команде: связывает бизнес, UX и разработку. Базовый входной билет в архитектурную роль сегодня это такой набор:
SQL с оконными функциями и CTE;
API: REST, GraphQL, gRPC;
EDA — событийные архитектуры и очереди;
Security — OWASP Top 10 и threat modeling.
Аналитик 1.0 о таком наборе даже и не знал. Ответственность изменилась также колоссально, напримеру, контракт между сервисами стал прямой зоной ответственности аналитика, а Open API — это основной артефакт решения. Статус в коде отображает бизнес‑логику, а API‑спецификация задает прям поведение системы. Open API это новый язык, а JSON‑схема — это базовая грамотность: если аналитик не читает спецификацию, он просто работает слепую.
Ключевая метафора второго поколения — это T‑shape профиль.
Горизонталь — это широта: бизнес, UX, данные, архитектура. DevOps — достаточно, чтобы говорить на одном языке с каждой из команд.
Вертикаль (это глубина) — системный анализ и проектирование. Это та экспертиза, которая делает аналитика незаменимым интегратором. Аналитик 2.0 знает всё понемногу и одинаково глубоко. Звучит просто, но на это уходят годы работы, сами знаете.
Ещё одна сильная сторона аналитика 2.0 — это три роли в одном человеке.
Первый — это медиатор: сводит UX и бизнес, back‑end, скорость и безопасность, все противоборствующие стороны.
Второе — это интегратор, который видит систему целиком. Иногда системный аналитик видит больше чем системный архитектор.
Фасилитатор — переводит конфликт ролей в общее решение. Если вы когда‑то были на митинге, когда разработчик и дизайнер говорят на разных языках и бодаются, вы знаете, насколько это ценно.
По поводу последнего у меня есть небольшой случай из практики. Был у нас однажды проект — работали над проектом командой из двух разработчиков (фронтенд и бэкенд), QA, один BA и представитель сопровождения. Причем в проекте участвовало две абсолютно различные команды внедрения — они были из разных проектов.
Все участники были абсолютными профессионалами и каждый свою работу делал чётко, но в проекте были размыты границы ответственности и команда никак не могла выйти в прод, а по каждому разногласию уходили в переписки. В какой-то момент я на совещании просто вмешался с вопросом, есть ли блокеры для выхода в прод. Оказалось, что нет. Тогда я просто выдвинул дату выхода в прод — через два дня.
Все участники начали дискутировать, пытались уйти в офлайн, чтобы обсудить какие-то оставшиеся проблемы. Но я наставил, чтобы мы оставались и прямо на встрече все начали договариваться и сотрудничать совершенно на другом уровне. Все разногласия решились онлайн буквально за минуты. И даже поставку нам мы согласовали через 3 дня с учетом решения всех оставшихся проблем.
В этом случае я выступил и как фасилитатор, и как медиатор, и надавил на ту точку, что сплотила команду, и позволила достичь нужного результата в заданные временные рамки.
Видите какой огромный разрыв между Аналитиком 2.0 и 1.0? А теперь к другому разрыву, который ширится с 2023 года.
Аналитик 3.0: когда AI пишет код, а аналитик ставит задачу
Третье поколение формируется прямо сейчас, с 2023 года. У нас появился vibe coding — подход, где мы описываем желаемое поведение на естественном языке, а AI генерирует код. Вайб-кодинг снижает ручной кодинг, но повышает требования к постановке задачи, так как цена неточности выросла, потому что AI никогда не переспросит — он выполнит ровно то, что ему сказали, даже если это неправильно. Аналитик здесь становится прямым интерфейсом между бизнесом и кодом.
Системный промпт — это спецификация когнитивного процесса, это не просто диалог с нейросетью. Эффективный промпт строится как техдок.
Первое – это output, выход, формат и критерии результата.
Второе – это constraints, ограничения и границы поведения.
И третье – это контекст, роль, среда и бизнес-контекст.
И если вы узнаете структуру, то неудивительно, это ведь юзер-стори, только для машины, а не для человека.
Второй новый навык — это верификация AI‑аутпут, то есть вывода модели. Модель галлюцинирует, уверенно выдает несуществующие факты и ссылки, верные данные приводит к неверным выводам, при неправильном ответе модель не исправляется, а подстраивает аргументы под свою версию. Такое было много раз и перечислять не буду, можно почитать в прессе.
Вот пример из моей практики. Как-то я готовил исследование по загрузке одной из команд, используя модели банка и выгрузку всех задач, всех полей из Jira в текущем спринте. И модель мне построила очень крутой, очень красивый отчет с временным рядом данных по каждому участнику команды по спринтам.
Я отправил отчет на оценку. И только потом сообразил, что на входе задачи, которые я давал только за один спринт! Когда спросил модель, откуда же временные ряды, она мне ответила, «Я экстраполировала данные». Она предположила, что данные будут выглядеть так. Это было довольно серьезное фиаско, результаты которого я очень долго расхлебывал.
Аналитик должен проверять, где текст расходится с бизнес-логикой. В текущем моменте это не дополнение к работе, а новый минимум профессии.
И здесь может возникнуть вопрос: «Если за AI всё равно надо долго проверять результат — не теряется ли смысл его использовать?»
Это ловушка бинарного мышления: «или AI делает всё сам, или он бесполезен». На практике — ни то, ни другое. AI нужно воспринимать не как замену мышления, а как инструмент ускорения, который не снимает ответственности за итог. Калькулятор не упраздняет бухгалтера, но позволяет ему считать в тысячу раз быстрее, но ошибку в постановке задачи калькулятор не поймает — это по-прежнему работа человека.
К тому же, необходимость верификации — это не баг, а часть профессии! Если перестанет быть нужна проверка человеком — исчезнет и сама роль аналитика в её нынешнем виде. Так что пока AI требует надзора, профессия существует.
Так и AI — убирает рутинный черновик: первый вариант структуры документа, шаблон acceptance criteria, заготовку OpenAPI-описания. Аналитик тратит время на проверку, исправление и принятие решений, а не на набор boilerplate-текста.
Сокращается не ответственность, а стоимость первого шага.
Например, когда мне нужно спроектировать API-контракт, я использую AI для генерации черновика JSON-схемы по описанию полей. Это экономит около 15–20 минут на рутинном написании кода, позволяя мне сразу перейти к верификации бизнес-логики и обработки ошибок, которые модель может упустить.
Аналогично я использую AI для других задач:
Red Teaming: для поиска логических дыр в описании процессов.
Diagrams-as-Code: для генерации черновиков sequence-диаграмм (PlantUML/Mermaid) прямо на ходу.
SQL-запросы: для быстрого прототипирования аналитических выборок.
Оформление задач: для превращения хаотичных заметок со встреч в структурированные User Stories с критериями приемки.
Итак, аналитик 3.0 оркеструет AI-агентов и пайплайны. Он декомпозирует задачи и проверяет результат. Ключевые инструменты для него – промпт-инжиниринг, верификация AI-результата, AI-пайплайны, LLM и RAC. Казалось бы, выглядит это как что-то из будущего, но часть команд, я абсолютно точно знаю, уже живет в этой реальности.
Вот здесь может возникнуть другой вопрос: «Не приведёт ли использование AI к деградации профессиональных навыков?»
Ответ: «Нет». Это типичный страх любой новой технологии. Раньше так же говорили про книги («зачем запоминать, если можно записать?»), потом про калькуляторы, потом про интернет. Теперь — про AI. Деградации не происходит — меняется набор навыков: одни становятся менее важными (например, держать в голове шаблоны документов), другие выходят на первый план (критическое осмысление результатов, постановка задачи, верификация). При этом важно различать: умеренное использование AI не снижает критическое мышление, а избыточная зависимость — снижает.
Для аналитика это означает конкретный принцип: использовать AI для ускорения, но не для замены суждения. Промпт — это постановка задачи. Верификация — это ваше профессиональное решение. Если вы делегируете AI и то, и другое — деградация действительно наступит. Но вины инструмента я здесь не вижу.
Плюсом есть 3 вещи, которые AI не заменит никогда.
Эмпатия. AI не чувствует боль клиента и контекст запроса. Он обрабатывает текст, а не понимает людей.
Навигация. Конфликт из стейххолдеров решает человек, не алгоритм. Кто кому уступает, кто несет риск — это всё политика, это доверие, отношение. Робот такое не понимает.
Ответственность. За последствия отвечает человек. ИИ не может нести ответственность, он ничем не рискует.
Как я проходил этот путь
Когда я говорю коллегам «начните использовать AI», это не абстрактный совет. Я сам проходил этот путь последние несколько лет и набивал шишки в тех же местах, где сейчас сомневаются многие аналитики.
Мой первый шаг был максимально скромным. Я не начинал с промпт-инжиниринга, агентов или RAG. Я просто дал модели сырые заметки со встречи и попросил превратить их в структурированный список: решения, открытые вопросы, ответственные и следующие шаги.
Это был хороший старт по двум причинам. Во-первых, задача была безопасной: я сам присутствовал на встрече и сразу видел, где модель ошибается. Во-вторых, даже несовершенный результат экономил время на первом черновике.
Сомнения у меня были те же, что и у коллег: «Не перестану ли я думать сам, если начну отдавать всё модели?» Но заметил, что AI хорошо убирает механическую часть работы, а то, за что аналитик ценен, не трогает: проверить логику, увидеть пробел в процессе, понять последствия решения, договориться с людьми и принять ответственность.
Серьёзным уроком стал случай с исследованием загрузки команды, что рассказывал выше, когда передал модели выгрузку задач за один спринт и попросил подготовить отчёт, а получил правдоподобную картину там, где данных не было. Только после этого случая я не отказался от AI, а поменял способ работы. Теперь для любого отчёта или расчёта действует простое правило: я должен суметь показать, из какой конкретной строки исходных данных получен каждый значимый вывод. Если модель не может провести такую трассировку, результат не попадает в рабочий документ.
Внедрение шло постепенно. Сначала я использовал AI только для себя: делал черновики OpenAPI-схем, SQL-запросов, диаграмм, структурировал заметки и искал логические дыры в описаниях процессов. Когда накопились реальные примеры — и успехи, и ошибки, — я начал показывать их коллегам в формате: «Вот задача, вот мой промпт, вот что получилось, вот где модель ошиблась, а вот сколько времени это сэкономило». Такой подход работает лучше директивы, потому что коллеги могут применить его к собственной работе и сами увидеть границы инструмента.
Если бы я мог дать себе советы в начале пути
То первый звучал бы так: не пытайся сразу построить идеальный промпт и изучить все агентные фреймворки. Начни с одной знакомой рутинной задачи, результат которой ты способен проверить сам, например:
Превратить заметки встречи в черновик User Story.
Сгенерировать вопросы к неполному требованию.
Сделать первый вариант OpenAPI-описания или JSON Schema.
Подготовить Mermaid или PlantUML-диаграмму по текстовому сценарию.
Написать черновой SQL-запрос.
Провести Red Teaming: попросить модель найти противоречия, пропущенные сценарии и риски в процессе.
Сформировать тест-кейсы и негативные сценарии по готовой спецификации.
А вот с решений, где ошибка дорого обходится и плохо обнаруживается, я бы не начинал: финансовых расчётов, юридических выводов, production-изменений, критичных архитектурных решений или отчётов для руководства без ручной проверки. Если тема кажется слишком большой, не нужно сначала изучать все модели, фреймворки и агентные платформы.
Верификация поначалу будет казаться лишней нагрузкой. Но именно она — неотъемлемая часть новой профессиональной роли. AI может подготовить черновик. Аналитик отвечает за то, чтобы черновик стал решением, которому можно доверять.
Я выработал привычку верифицировать AI-output и особенно внимательно проверял результат там, где он выглядит слишком красивым, цельным и убедительным. Модель может уверенно выдать несуществующие факты, придумать ссылки, достроить отсутствующие данные или сделать логичный на вид, но неверный вывод.
Мой минимальный чек-лист перед использованием результата AI в работе:
Все ли цифры можно проследить до исходных данных?
Не появились ли в ответе факты, которых не было во входных материалах?
Действительно ли ссылка подтверждает утверждение, рядом с которым она приведена?
Не перепутала ли модель бизнес-правила, статусы, роли или границы ответственности?
Что произойдёт в негативном сценарии: ошибка интеграции, дубль события, отсутствие данных, таймаут?
Может ли другой аналитик или разработчик воспроизвести этот результат без «магии в чате»?
Практика индустрии идёт в ту же сторону: промпты и AI-выводы стоит проверять на репрезентативных сценариях, фиксировать тестовые примеры и измерять качество результата, а не оценивать его по одному удачному ответу. Об этом подробно пишет OpenAI в руководстве по evaluation и оптимизации модели.
Дальше можно изучать RAG и AI-агентов. Но не начинайте с многoагентности. Важнее понимать, как устроен контур: откуда агент получает данные, какими инструментами может пользоваться, какие решения принимает сам, а где обязан передать задачу человеку. Для аналитика полезно уметь разобрать любой AI-процесс по пяти вопросам:
Какая бизнес-задача решается?
Какие источники данных разрешено использовать?
Какие инструменты может вызывать агент?
В каких случаях он обязан остановиться и эскалировать решение человеку?
По каким метрикам мы поймём, что система действительно полезна и безопасна?
Начать можно с бесплатного курса Microsoft AI Agents for Beginners. Отдельно рекомендую урок What is agentic RAG?: он хорошо объясняет отличие обычного RAG от агентного подхода.
Важно не попадать в ловушку «если есть AI, нужен агент». Во многих сценариях обычный детерминированный workflow надёжнее, дешевле и проще в сопровождении. Агент оправдан там, где действительно нужно выбирать следующий шаг, инструмент или маршрут обработки запроса.
И, главное, инвестируйте в soft skills. Эмпатия, фасилитация, переговоры, навигация среди стейкхолдеров, работа с конфликтами и способность принимать решения в условиях неполной информации — это не «дополнительные» навыки. В мире AI они становятся premium-компетенцией.
Модель может подготовить варианты решения, но не почувствует, что заказчик формально согласился, а фактически не готов брать на себя риск. Не поймёт, почему две команды избегают прямого разговора. Не сможет выстроить доверие между бизнесом, разработкой, безопасностью и сопровождением.
Чем больше рутины забирает AI, тем выше стоимость человека, который способен собрать людей вокруг одного решения и провести его до результата.
Списко полезной литературы
Промпты и работа с моделями:
OpenAI: Prompt engineering — официальный практический гайд: структура инструкций, примеры, контекст, ограничения и проверка качества промптов.i
OpenAI: Prompting — как версионировать, улучшать и повторно использовать промпты в командной работе.
Anthropic: Prompt engineering overview — базовые техники: ясность формулировок, примеры, XML-структура, role prompting и цепочки промптов.
OpenAI: Six strategies for getting better results — полезный материал о том, как давать модели контекст, декомпозировать задачу и проверять изменения системно.
Проверка и оценка результата:
OpenAI: Model optimization and evals — почему AI-результат нужно оценивать на наборе реальных кейсов, а не доверять одному хорошему ответу.
OpenAI: Production best practices — материал о переходе от экспериментов к более управляемому использованию AI в рабочих процессах.
Агенты и RAG:
Microsoft: AI Agents for Beginners — бесплатный курс из десяти уроков: от основ до построения AI-агентов.
Microsoft: Что такое агентическая RAG — короткое введение в разницу между базовым RAG и агентным RAG.
Microsoft: What is agentic RAG? — англоязычная версия с примером построения решения.
Аналитик 3.0 — реальность сегодняшнего дня. Пока мы осваиваем этот уровень и учимся управлять одним AI-ассистентом, горизонт уже сдвигается. Что будет, когда одного агента станет недостаточно, и нам придется управлять целой их сетью? Давайте заглянем на пару лет вперед.
Аналитик 4.0: архитектор смыслов
Важная оговорка: этот блок принципиально отличается от предыдущих трёх. Аналитик 1.0, 2.0 и 3.0 описаны на основе того, что уже произошло и что можно подтвердить практикой — своей или чужой. Аналитик 4.0 — это не описание существующего стандарта, а футурология: экстраполяция трендов 2025–2026 годов на горизонт нескольких лет вперёд.
Здесь пока физически не может быть большого числа «примеров из практики», потому что и устоявшейся практики ещё нет. Есть первые эксперименты отдельных компаний, технологии, которые быстро меняются, и множество открытых вопросов. Поэтому этот раздел стоит читать не как инструкцию, а как приглашение к размышлению: куда движется профессия и на что стоит обратить внимание уже сейчас, не дожидаясь, когда всё «устоится».
Если Аналитик 2.0 проектировал контракт между сервисами, а Аналитик 3.0 — контракт между человеком и AI-агентом, то Аналитик 4.0 проектирует контракт между бизнес-смыслом и целой сетью машинных исполнителей.
В агентных системах главная сложность в том, как координируются агенты, инструменты, память, внешние данные и human-in-the-loop-проверки. Оркестрация — это слой, который определяет, кто запускается следующим, какие данные доступны конкретному агенту, где нужна эскалация и в какой точке человек обязан вмешаться.
Аналитик здесь (теоретически, опять же) меняет точку приложения усилий. Если раньше он отвечал на вопрос: «Что должна делать система?», то теперь всё чаще будет отвечать на другие вопросы:
Какую задачу вообще допустимо поручить агенту?
Какие данные и инструменты ему разрешены?
Где проходят границы автономии?
В каких случаях агент должен остановиться, запросить уточнение или передать решение человеку?
Как мы поймём, что система приносит пользу, не создавая неприемлемый риск?
Кто и как отвечает за последствия решения, которое предложила или выполнила машина?
Это скорее не проектирование требований, а проектирование смысла, контекста и ответственности.
Представим обычный для банка процесс: клиент обращается в поддержку по спорной операции. В модели Аналитика 2.0 аналитик описывает интеграции между CRM, процессингом, системой обращений и базой знаний. Он проектирует API-контракты, статусы, очереди, правила маршрутизации.
В модели Аналитика 3.0 появляется AI-помощник оператора. Он читает историю обращения, ищет релевантные статьи в базе знаний, формирует черновик ответа и предлагает следующий шаг сотруднику. А в модели Аналитика 4.0 возникает уже целый контур агентов:
Один агент классифицирует обращение и определяет его тип.
Второй ищет сведения о транзакции в разрешённых системах.
Третий проверяет сценарий по базе регламентов и знаний.
Четвёртый формирует вариант коммуникации с клиентом.
Пятый оценивает риск: можно ли закрыть обращение автоматически или нужно передать его сотруднику.
Человек принимает решение в точках, где цена ошибки высока: возврат денег, подозрение на мошенничество, конфликт с клиентом, неоднозначность регламента.
В такой системе аналитик уже не просто пишет требования каждому сервису, а определяет границы автономии: например, агент может подготовить ответ, но не может самостоятельно обещать компенсацию; может предложить блокировку карты, но не может выполнить её без подтверждения; может собрать факты, но не может подменять юридическую или риск-оценку.
Именно здесь появляется новая зона ответственности: не «написать хороший промпт», а спроектировать управляемую систему принятия решений.
Что становится важным:
Системное мышление на максималках. Нужно видеть не хэппи-пэт, а весь контур: риски, данные, зависимости и последствия ошибок агента.
Навигация среди стейкхолдеров. Агенты не чувствуют политику, скрытые мотивы и борьбу приоритетов команд, а аналитик — чувствует.
Этика и ответственность. Если агент ошибется или уйдет в галлюцинацию, отвечать будет не модель. Ответственность остается на тех, кто задал рамки ее работы.
Observability (наблюдаемость). Недостаточно «запустить агентов». Нужно видеть: какие инструменты они вызвали, где ошиблись, сколько раз эскалировали задачу человеку и почему.
В академической среде для этой новой роли уже придумали точный термин — Context Architect (архитектор контекста). Смысл ровно в этом: связывать бизнес-намерение с возможностями AI и не дать системе уйти в бред, оторвавшись от исходной цели.
Пока это не массовая практика системных аналитиков, но направление уже видно. McKinsey описывает переход к «агентной организации», в которой люди и AI-агенты действуют как единая рабочая сила; ключевой задачей становится не просто внедрить технологию, а встроить её в процессы, управление и принятие решений. McKinsey — The agentic organizationmckinsey
В исследовании McKinsey Global Institute о партнёрстве людей, агентов и роботов акцент сделан не на простом замещении профессий, а на перераспределении задач и изменении набора навыков. Это важная мысль для аналитика: автоматизация одного вида работы повышает ценность тех, кто способен проектировать процесс целиком и управлять его последствиями.
Интересно, что в академической среде для этой новой роли уже появляется язык. В статье Ангелы Уик «The evolving role of business analysis in the age of enterprise agentic AI» аналитик назван context architect — архитектором контекста. Автор утверждает, что с развитием агентного AI роль аналитика не ослабевает, а становится критичной: он связывает бизнес-намерение, возможности AI и human-in-the-loop-модель, предотвращая «AI slop» и дрейф системы от исходной бизнес-цели.
Пока это не стандарт профессии, а скорее сильная гипотеза. Но сама постановка вопроса полезна уже сейчас: если AI будет всё лучше создавать тексты, схемы, код и гипотезы, то ценность аналитика смещается к умению определить, какие из этих результатов вообще имеют смысл, в каком контексте и с какой ответственностью их можно применять.
Мы освоили архитектуру, интеграции, CI/CD — стали отличными Аналитиками 2.0. Но главная ценность никогда не заключалась в написании идеальных спецификаций или JSON-схем. Она всегда была в системном мышлении. AI не заменит аналитика. Он заменит Аналитика 2.0, который боится переходить на следующий уровень. А вы что думаете?
Телеграм-канал Alfa Digital, где рассказывают о работе в IT и Digital: новости, события, вакансии, полезные советы и мемы.
Читайте также: