Как ИИ изменил правила отбора системных аналитиков, и что проверять теперь

Ещё пару лет назад по образцу ТЗ можно было за десять минут понять, кого вам прислали. Сейчас нельзя: нейросеть оформляет требования аккуратнее, чем средний живой аналитик. Документы всех кандидатов стали одинаково приличными, а разница между сильным и слабым никуда не делась — просто она больше не видна там, где вы привыкли смотреть. Разбираемся, где теперь ее искать.

Сначала о том, как аналитика вообще выбирают. Схема почти везде одна и та же. Рекрутер просматривает отклики и отсеивает по резюме — на одну вакансию их приходят десятки. Тех, кто прошёл, зовут на HR-интервью: там выясняют опыт, мотивацию, зарплатные ожидания и то, насколько с человеком вообще получается разговаривать. Дальше техническое собеседование с лидом или сильным аналитиком команды, иногда в два раунда. Часто где-то посередине встраивают тестовое задание или разбор кейса, а в финале кандидата показывают нанимающему менеджеру или заказчику.

А теперь присмотритесь, что именно оценивается на каждом шаге. Резюме — текст. Сопроводительное письмо — текст. Тестовое задание — текст. Образец ТЗ из прошлого проекта — снова текст. Даже на техническом интервью аналитик по большей части рассказывает, как он пишет документы и почему именно так. Другого материала у этой профессии просто нет: аналитик не покажет работающий сервис и не запустит при вас свой код. Вся оценка держится на текстах и на разговорах о текстах.

Все привычные способы оценить аналитика держались на одном допущении: хороший документ может написать только тот, кто умеет работать. Резюме, сопроводительное письмо, тестовое задание, образец ТЗ из прошлого проекта — вы смотрели на текст и делали вывод о человеке. Это работало, потому что написать убедительное ТЗ было трудно, а прочитать — легко и быстро.

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

Инструментом пользуются практически все. В «Яндексе» ИИ регулярно применяют 73% разработчиков, и компания в июле 2026 года объявила программу, которая обещает довести этот показатель до 75%. По данным hh.ru, 45% соискателей хотя бы раз применяли ИИ на этапах поиска работы, а за первый квартал 2026 года число вакансий с требованиями к навыкам работы с ИИ выросло в 2,7 раза год к году.

К весне 2026 года, как описывает «Российская газета», ситуация дошла до логического предела — если не сказать «до абсурда»: соискатели пишут резюме нейросетью, работодатели отдали нейросети первичный разбор откликов, и на первом этапе друг на друга смотрят уже не люди, а два алгоритма.

А виноват во всем, конечно, ИИ. С аналитиками ситуация та же, только хуже: тексты и документы — единственные артефакты его деятельности.

Важная оговорка: эта статья не про мошенников и «волчью стаю». Проблема в том, что проверка перестала работать и на обычных честных кандидатах. Аналитик, который прогнал своё резюме и ТЗ через модель, чтобы убрать канцелярит и выровнять структуру, ничего плохого не сделал. Просто теперь вы не отличите его документ от документа того, кто, кроме промпта, ничего не написал.

Причём не отличают и сами аналитики! Мы спросили своих коллег, изменилось ли что-то в том, как они читают чужие документы. Один ответил: «Всё ещё плохо вижу сгенерированный ИИ текст, всегда кажется, что это супер умные люди на той стороне и они сами так классно придумали». Другой: «Иногда видна поверхностность в описании требований — человек не углублялся в контекст, а использовал ИИ». Одна профессия, один вопрос, противоположные ответы. Если внутри профессии согласия нет, у ИТ-директора, который читает документ незнакомого кандидата, шансов еще меньше.

И это беда не только небольших компаний. Руководитель сектора подбора Fix Price Татьяна Богословская описывает провалившуюся попытку автоматизировать скрининг ИТ-резюме: сервис показывал «совпадение 30%», рекрутер открывал файл — и видел стопроцентное попадание. «ИИ лишь видит наличие названия, например языков программирования, в описании, но не умеет думать». В итоге в компании вернулись к ручному первичному скринингу именно для ИТ-специалистов. И отдельно про наш случай: системные аналитики, по её наблюдению, сейчас в избытке, а среди кандидатов-аналитиков «нередко встречаются фродеры». Резюме при этом «стали пугающе однотипными».

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

Здесь полезнее всего один конкретный эксперимент. Исследователи из University College Dublin и Университета Бари провели его в международной ИТ-консалтинговой компании: три модели получали материалы предпроектного обследования (презентации, протоколы встреч) и шаблон функциональной спецификации, а затем генерировали эпики и пользовательские истории. Результат сравнили с документами, которые по тем же исходникам написали штатные аналитики. За прошедший год это по-прежнему единственный эксперимент такого рода: системных аналитиков отдельно почти не исследуют, профессия слишком узкая для больших выборок.

Выводы неудобны для обеих сторон спора.

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

Содержание — хуже. Эпики оказались упрощёнными набросками без полного покрытия функциональности, технические спецификации — недостаточно детальными, чтобы вести по ним разработку. Формулировки аналитиков, даже при худшей структуре, были менее двусмысленными.

И главное. Часть пользовательских историй все три модели пропустили одинаково — потому что нужной информации не было в исходных документах вообще. Знание аналитика может быть неявным, не записанным ни в какой документации. Модель же не может извлечь то, чего нет на входе; человек, который сидел на тех встречах, — может.

Экономия времени по оценке аналитика, участвовавшего в эксперименте — 10–15% на подготовке документов. Не «в разы».

Вот и весь ответ на вопрос, что случилось. Нейросеть научилась хорошо оформлять, но так и не научилась хорошо думать (по крайней мере, пока). А отбирали мы всегда по оформлению — просто потому, что раньше аккуратный документ означал думающего автора.

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

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

Ошибки, которые они вспоминают, объединяет одно свойство — все они правдоподобны, например:

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

Точнее всего механику описал один из аналитиков:

Запомните эту фразу: к ней сводится всё, что нужно проверять в кандидате.

Здесь возникает резонное возражение: требования не уходят в спринт без проверки. Их читает тестировщик, он же пишет тест-кейсы, он же первым замечает дыры в сценариях. Разве не он поймает ошибку аналитика?

Часть ошибок действительно поймает. Внутренние противоречия, незакрытые ветки сценария, требование, которое невозможно проверить — всё это тестировщик видит на этапе разбора и возвращает аналитику. В этом смысле требования проверяются не хуже кода.

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

Тестировщик проверяет соответствие продукта требованию. Он не проверяет соответствие самого требования реальности клиента. Если модель дозаполнила пробел правдоподобно (то есть описала непротиворечивый, полный, проверяемый сценарий, которого заказчик никогда не имел в виду), тест-кейс на него напишется без сучка и задоринки. Реализация пройдёт проверку. Продукт будет соответствовать требованию идеально.

Вот в чём разница с кодом. У кода критерий верности внешний и явный: работает или не работает. У требования критерия верности внутри контура разработки нет вообще — он находится в голове у заказчика и у тех, кто был на встречах. Поэтому неверное требование успешно проходит проверку.

Отсюда практическое следствие для ИТ-директора: если вы спросите свою команду, были ли проблемы из-за сгенерированных требований, и услышите «нет» — считайте, что ответа вы не получили. Неверное требование не сообщает о себе. Оно превращается в аккуратно сделанную не ту функциональность, и к моменту, когда это заметят, никто уже не свяжет её с формулировкой в ТЗ трёхмесячной давности.

Кстати, о том, что «проблем не было». Мы спросили аналитиков, на каком этапе обнаружилась ошибка модели, и все восемь ответили одинаково: сразу, при вычитке. Звучит как хорошая новость, но на деле означает другое: люди вспоминают только те ошибки, которые заметили. Та, что прошла вычитку, в такой ответ не попадёт по определению.

Работодатели отреагировали на слом привычного механизма проверки двумя противоположными способами.

Лагерь первый: запретить и смотреть всех вживую. В отчёте Greenhouse об ИИ в найме, основанном на опросе более 4100 соискателей, рекрутеров и менеджеров, 39% HR-менеджеров в США сообщили, что стали проводить больше личных собеседований именно «для проверки» кандидата. В отчёте за 2026 год тенденция усилилась: работодатели добавляют практические этапы. Google, Cisco и McKinsey вернули очные встречи на части этапов.

Логика понятна: если по онлайн-заданию нельзя отличить кандидата от его ИИ, надо посадить человека перед собой без возможности получать подсказки.

Лагерь второй: разрешить и смотреть, как он с этим работает. Google запустил пилот, в котором кандидату на позицию инженера разрешено пользоваться одобренным ИИ-помощником. Cisco переходит от классических задач к проектным упражнениям, в которых наблюдают, как кандидат работает в процессах с ИИ. Вице-президент Cisco по привлечению талантов Скотт Макгакин формулирует смысл так: «человеческий фактор контроля и экспертных знаний важен как никогда».

Логика противоположная и не менее здравая: в работе он всё равно будет пользоваться ИИ, так проверяйте то, как сотрудник с ним взаимодействует, еще на этапе найма.

Для системного аналитика второй подход выглядит перспективнее, потому что запрет проверяет, что человек умеет без инструмента, а узкое место в работе аналитика совсем другое: важно не то, напишет ли он ТЗ без нейросети, а увидит ли он, что нейросеть половину придумала от себя. Это проверяется только в присутствии инструмента.

Практический вывод: если вы собираетесь разрешить ИИ на проверке, задача смещается с «решил или не решил» на «где он остановился, усомнился и перепроверил». Дайте кандидату сгенерированный фрагмент требований с правдоподобной ошибкой внутри и посмотрите, найдёт ли он её и какие вопросы задаст.

Ниже — все подходы, которые сейчас применяются, с честными минусами каждого.

1. Домашнее тестовое задание

Классика: «напишите ТЗ по этому описанию, срок — три дня».

Плюсы. Дёшево для работодателя, ничего не нужно организовывать, кандидат работает в комфортных условиях.

Минусы. Способ умер первым. Неограниченное время, никакого наблюдения, шаблонная постановка задачи — идеальные условия для генерации. Проверяя такое задание, вы измеряете качество модели, а не кандидата. Наши аналитики говорят о нём то же самое: «Домашние тестовые легко делаются с помощью ИИ, на интервью можно "натаскаться", чтоб от зубов отскакивало, тем более сейчас есть столько "сливов" с реальных интервью».

2. Живое техническое интервью

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

Плюсы. Работает. HH.ru собрал признаки подсказки в реальном времени: неестественные паузы, расфокусированный взгляд, повтор вопроса вслух, идеально гладкая, но обезличенная речь без примеров из практики, резкий переход на академический язык. Там же — рабочие форматы: задача на виртуальной доске, разбор кейса компании, просьба объяснить то же самое своими словами или предложить альтернативу.

Минусы. Дорого: на каждого кандидата уходит примерно час технического лида, и лид этот (как и его время) в дефиците. Плохо масштабируется, результат зависит от того, кто интервьюирует. Кроме того, это не гарантия: инструменты подсказок развиваются быстрее, чем навыки их распознавания.

3. Очное интервью

То же самое, но в переговорной, без возможности смотреть на второй экран.

Плюсы. Единственный способ гарантированно исключить подсказку. Именно поэтому к нему вернулись Google, Cisco и McKinsey.

Минусы. Для распределённых команд и аутстаффа это фактически отказ от половины рынка кандидатов. Дорого по логистике, медленно, плюс сильные кандидаты с выбором на такое соглашаются неохотно. Плюс вопрос, который стоит задать себе честно: если человек всё равно будет работать с ИИ, что именно вы проверили, посадив его в комнату без него?

4. Ваш реальный кейс

Дать кандидату не абстрактную задачу, а реальную ситуацию вашей команды — с вашей терминологией, вашими ограничениями, вашей регуляторикой.

Плюсы. Устойчив к подсказкам: модель не знает вашего контекста. Проверяется главное — способность задавать вопросы там, где постановка задачи неполная.

Минусы. Требует, чтобы кто-то внутри потратил время на подготовку кейса и его обновление. Кейс устаревает и утекает на рынок. Кроме того, есть возражение, которое мы услышали от собственного аналитика: «Кейс заказчика предполагает погружение в предметную область. В рамках собеседования не каждый специалист сможет так быстро сориентироваться в новой области. А это не является показателем уровня подготовки». Возражение справедливое. Проверять надо ход мысли, а не знание вашей отрасли: ни один специалист не спроектирует за час решение, над которым команда обычно работает пару спринтов.

5. Разбор реальной задачи в первые недели

Оплачиваемый пилот: человек выходит на проект, но первые две-три недели считаются продолжением отбора.

Плюсы. Единственный формат, который показывает работу целиком. Наши аналитики назвали его самым показательным чаще других: «Реальная задача показывает, как человек собирает требования, задаёт вопросы, работает с неопределённостью, коммуницирует с бизнесом и принимает решения при недостатке информации. Именно это и составляет основу работы системного аналитика».

Минусы. Самый дорогой и самый медленный. Требует явной точки принятия решения, иначе пилот превращается в наём по умолчанию: человек уже в команде, расставаться с ним уже как-то неудобно.

6. Ответственность подрядчика (наша модель)

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

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

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

Спрашивать кандидата, насколько он стал эффективнее с ИИ. Этот вопрос не даёт информации, и тому есть прямое доказательство.

Исследовательская организация METR в опросе 349 технических специалистов, проведённом в феврале–апреле 2026 года, получила от медианного участника две разные оценки одного и того же собственного месяца работы: рост скорости в три раза и рост ценности в два. Ответ меняется в полтора раза от того, как задан вопрос. Год назад тот же человек, по собственным воспоминаниям, работал с прибавкой в 1,3 раза, а через год ожидает 2,5. Показательная деталь: ниже всех эффект оценили сотрудники самой METR — те, кто лучше других знает про разрыв между ощущением и замером.

Та же организация в феврале 2026 года признала, что не может корректно замерить эффект ИИ инструментально: от 30 до 50% участников её эксперимента отказывались сдавать задачи, которые не хотели делать без ИИ, и контрольная группа просто развалилась. Получается, что, если ни замер, ни самооценка не дают ответа, вопрос кандидату о его эффективности — это вопрос ни о чём.

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

Способность сказать бизнесу «то, что вы просите, не решает вашу проблему» не измеряется ни тестовым, ни кейсом, ни сертификатом. Она проявляется на третьей неделе проекта.

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

Самый практичный совет на эту тему мы услышали от собственного senior-аналитика:

Итак, вот наш список для ИТ-директора. Часть пунктов выходит за периметр ИТ — это нормально, их полезно переслать в HR, закупки и безопасность.

В своём процессе отбора

У подрядчика

В регламенте (за периметром ИТ)

В первые недели работы

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

У нас в EvApps технический скрининг — это обязательный этап независимо от срочности и от того, сколько специалист провёл на бенче. Его проводят наши собственные девлиды и делают это не для галочки — на один скрининг уходит не меньше часа.

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

Если вам нужны системные аналитики, за которых есть кому отвечать, расскажите о своих задачах — обсудим.

Оставить заявку