Как работать с меняющимися требованиями и внедрять ИИ-агентов
Поговорим об этом на «Коде аналитика» — бесплатном митапе ЮМопеу для системных аналитиков. В программе четыре доклада от экспертов ЮМопеу, Сбера и Бындюсофт о задачах, с которыми аналитики сталкиваются каждый день:
как работать с постоянно меняющимися требованиями и большим количеством стейкхолдеров;
чем промышленный ИИ-агент отличается от прототипа и что нужно для его работы после релиза;
как автоматизировать работу с архитектурой с помощью тестов и автогенерации;
какие ИИ-инструменты помогают системным аналитикам, а какие подходы не оправдывают ожиданий.
Разберём практические решения и опыт команд, а также обсудим, как меняется работа системного аналитика.
Когда: 22 октября, четверг, 19:00 (мск). Приходите на митап в Санкт-Петербурге или подключайтесь к онлайн-трансляции.
Зовите коллег, которым интересны системный анализ, архитектура и применение ИИ в работе. Все подробности и регистрация на сайте «Кода аналитика».
Многие эксперименты сейчас идут в сторону того, чтобы ИИ-агенты совершенствовали собственный Harness (обвязку, которая управляет работой модели), адаптируя его под задачи. Уже есть научные статьи на эту тему (например, свежайший сентябрьский пирожок — https://arxiv.org/pdf/2609.38372). Есть и проекты (Exo, Google Harness²), в которых уже пробуют применять эту логику.
Но вот какой возникает парадокс. История развития Harness, самых современных методов развития агентов и тому подобного — это история передовых технологий, которым от силы полгода, а самые лучшие решения и того не старше пары месяцев. И вот ведь в чём проблема. ИИ-модели обучены на «слепке» данных на определённую дату. ChatGPT, по крайней мере, по моей грубой оценке, имеет такой слепок примерно до мая 2026 года (пытался определить по вопросам «жива ли такая-то знаменитость по твоей памяти», хотя способ, конечно, не слишком надёжный).
То есть ИИшки, которые должны модифицировать собственные обвязки, будь они трижды умны, далеко не всё про это ещё знают. В их обучении передовые Harness только зарождаются и не являются той технологией, которую мы с вами уже вовсю пытаемся применять. Мне кажется, это довольно весомый фактор, сдерживающий развитие качественных самописных обвязок и появление работающих «самомодифицирующихся агентов».
Почему это вообще может быть проблемой? Представим, что мы попросили модель написать агента, который должен самостоятельно улучшать свою работу. Она вполне способна написать рабочую систему, которая будет анализировать собственные ошибки, переписывать промпты и менять инструменты. Но насколько вероятно, что она самостоятельно предложит современные подходы к управлению контекстом, независимой проверке результатов, частичному пересчёту отдельных этапов или экспериментам с несколькими вариантами обвязки? Особенно если эти подходы стали массово обсуждаться буквально пару месяцев назад. Получается, что модель может просто не предложить хорошее решение не потому, что недостаточно умна, а потому, что ещё не знает о существовании некоторых эффективных подходов.
Конечно, здесь есть и контраргумент. Модель ведь не обязана знать о готовом решении, чтобы придумать его самостоятельно. Более того, никто не мешает дать ей доступ к свежим статьям, исходникам и результатам экспериментов. Собственно, те же исследования по самоулучшению обвязок как раз и показывают, что модели способны находить полезные решения самостоятельно. Но мне кажется, что между способностью изобрести какой-то подход с нуля и умением уверенно применять уже известный набор лучших практик есть существенная разница. Особенно когда нужно не просто получить работающий код, а построить сложную и надёжную систему.
Из этого вытекает, что уже через какой-нибудь год, когда данные по Harness сформируются и актуальные знания будут «догружены» в модели, может произойти очередной «фазовый переход». Модели станут гораздо лучше приспособлены для подобных решений просто потому, что современные практики построения агентных систем станут для них такими же привычными, как сейчас, например, практики разработки обычного ПО. Что, естественно, отразится и на рынке подобных решений.
Если вам интересны подобные размышления об ИИ, агентных системах и всём, что вокруг них происходит, приглашаю в свой телеграм-канал «Метод утёнка».
Можно искать его среди всех котов по очереди, а можно заранее разделить их на группы, чтобы сузить круг поисков. Похожий принцип работает и с большими объемами данных, когда среди миллионов записей нужно быстро найти нужные.
Катя, руководитель группы системной аналитики, работала над оптимизацией больших таблиц с помощью секционирования.
Онарассказала, как работает этот подход, что важно учитывать при его реализации и при чем здесь коты.
🔸 Разбираемся с большими таблицами
В больших таблицах могут храниться миллионы записей. При таких объемах поиск нужных данных иногда занимает много времени, замедляя загрузку списков и отчетов.
Есть разные способы оптимизации: можно улучшать запросы, добавлять индексы или менять организацию данных.
Один из подходов — секционирование, то есть разделение большой таблицы на части.
🔸 Рассаживаем котов по коробкам
Представьте комнату, в которой живет сотня котов, а нам нужно найти кошку Мусю.
Можно искать ее среди всех животных, а можно заранее рассадить котов по коробкам, например, по возрасту.
Мусе два года — значит, ищем только в коробке с котами от года до семи лет.
С данными похожий принцип: система может искать только в нужной части таблицы.
🔸 Выбираем правило разделения
Чтобы секционирование было полезным, важно правильно выбрать, какую таблицу разделить и по какому правилу.
Вернемся к котам. Если все они примерно одного возраста, делить их на возрастные группы бессмысленно: почти все окажутся в одной коробке.
Зато, если коты разных пород, можно рассадить их по породам и искать Мусю только в нужной коробке.
🔸 Продумываем перенос данных
Выбрать способ разделения — только часть задачи. Данные из заполненной таблицы еще нужно перенести в новую.
Перенос может дополнительно нагружать систему, поэтому мы, например, предусмотрели возможность приостанавливать его в часы пик и продолжать позже.
А если секционирование не подойдет, данные можно перенести обратно в обычную таблицу.
Сильный отчёт от СберУниверситета, но к некоторым рекомендациям есть вопросы. Разберём одну из них: "Интегрировать ИИ только после оптимизации процессов."
СберУниверситет выпустил отчёт о том, как ИИ меняет работу руководителя. Он хорошо структурирует тему, рекомендую.
Один из советов — не внедрять ИИ поверх старых процессов: разложить процесс на этапы и спросить по каждому, можно ли его исключить, объединить с другим или передать ИИ. Для переданных этапов зафиксировать, откуда модель берёт контекст, кто принимает итоговое решение, какая система источник правды и когда результат уходит человеку.
Я задаю ещё один вопрос, и раньше остальных: сколько стоит проверить результат?
Если для проверки нужно то же время, что для самой работы, выигрыша нет. Но стоимость проверки — не данность. Её можно снизить, если менять саму работу (состав данных, операции и их последовательность), а не только делить её на этапы. Это и означает проектировать работу для ИИ.
У этого есть цена. Чтобы понять, можно ли удешевить проверку, приходится перепроектировать работу и записать правила, которые раньше держали в голове. И даже после этого проверка может остаться дорогой. Тогда эту работу разумнее оставить человеку. И лучше узнать это до того, как передавать её ИИ.
Есть ли у SRE продукты? Разбираем с руководителем Developer Experience Авито
В гостях у подкаста «В SREду на кухне» Артём Арюткин, руководитель направления Developer Experience в Авито. Разбираемся, как продуктовый подход меняет работу инженерных команд и платформ.
Начнём с главного: в какой момент инженерный инструмент превращается в продукт и зачем платформенным командам продуктовое мышление?
Еще обсудили, как измерять adoption, зачем каждому инженерному продукту нужны контрметрики и как не потерять баланс между надёжностью и удобством. А в финале отвечаем на краеугольный вопрос: что важнее, надёжность или Developer Experience?
Этот выпуск будет полезен всем, кто создаёт внутренние инструменты, исследует потребности инженеров или если вы просто хотите понять, как продуктовый подход работает за пределами классического продакт-менеджмента.
Скрытая цена ИИ-решения: что учесть при расчёте окупаемости
Часто слышу вопрос: как посчитать окупаемость ИИ-решения на базе LLM?
Давайте разбираться.
Готовый расчёт окупаемости поставщик не покажет: кроме его цены, все числа в нём ваши. Как подойти к построению модели расчёта и что в ней учесть?
Начинать стоит с рисков. От того, какие ошибки недопустимы, зависит, где и насколько строго придётся проверять результат. А проверка часто становится главной статьёй затрат.
Запишите недопустимое. Заранее определите для процесса, какие последствия ошибки компания не примет ни за какую экономию. Список утверждает владелец процесса. От инструмента он не зависит: он одинаков для любого ИИ и для человека.
Найдите место проверки и замерьте её цену. Где такую ошибку можно поймать до того, как её последствия станут необратимыми? Проверка должна быть независимой от ИИ и опираться на внешние факты, а не на его выводы. Сколько стоит такая проверка на один случай, замерьте на выборке: в ваших системах этого числа, скорее всего, нет. Часто проверка съедает ровно то время, которое обещал поставщик.
Если поймать ошибку нечем, меняйте распределение операций между исполнителями — человеком, ИИ и программным кодом. Цель — чтобы критичный факт приходил к ИИ уже подтверждённым. Если и это невозможно, откажитесь от ИИ.
Заложите затраты на сохранение навыков у проверяющих. Человек, который каждый день видит подсказки ИИ, со временем проверяет хуже. Навык приходится поддерживать намеренно, и это время людей. Без этого качество проверки со временем деградируют.
Считайте затраты и эффект целиком. Затраты — это не только цена поставщика. Это ещё время людей на проверку и исправления, потери от пропущенных ошибок, интеграция и обучение, а также цена сохранить возможность вернуться к работе без ИИ. Эффект — не только экономия на текущей работе, но и новые результаты, до которых раньше не дотягивались.
Окупается решение, которое приносит больше, чем стоит проверка работы ИИ.
У аналитиков есть много задач, к которым уже можно подключать ИИ: искать информацию, разбирать требования, фиксировать итоги встречи, работать с документами или проверять гипотезы.
Часть работы так действительно идет быстрее. Но результат все равно нужно проверить, учесть контекст и понять, подходит ли предложенный вариант для конкретной ситуации.
Ваня и Динара, аналитики Naumen, рассказали, для чего используют ИИ сейчас, что по-прежнему контролируют сами и какие навыки становятся важнее.
Что можно делегировать ИИ
Ваня, системный аналитик:
Чаще всего использую ИИ для:
поиска необходимой информации;
обработки встреч и фиксации итогов и договоренностей;
написания скриптов;
работы с документацией.
А еще с ИИ бывает проще разобраться в новой для себя области.
Динара, бизнес-аналитик:
Я использую ИИ, чтобы быстро разбирать документы и требования, находить связи, противоречия и то, что могло ускользнуть от внимания.
Еще его можно подключить на этапе «белого листа»: получить несколько подходов, от которых можно оттолкнуться.
А когда решение уже есть — проверить гипотезу: найти слабые места, задать вопросы, которые я могла не учесть, или предложить другой вариант.
Почему ИИ нужно проверять
Ваня, системный аналитик:
На мой взгляд, полностью доверять ИИ нельзя нигде. Он может галлюцинировать и терять консистентность, поэтому результат нужно проверять.
В конечном итоге ответственность за то, что получилось, будешь нести ты, а не ИИ.
Динара, бизнес-аналитик:
Тоже не воспринимаю ответ ИИ как готовое решение: его нужно проверить и понять, подходит ли он для конкретной задачи.
К тому же в начале работы не всегда ясно, какой результат нужен: мы исследуем проблему, задаем вопросы и уже в процессе уточняем цель.
ИИ может предложить варианты и другой взгляд, но определить нужный результат и учесть условия должен аналитик.
Какие навыки становятся важнее
Ваня, системный аналитик:
Важно глубже разбираться в своей области и видеть картину целиком: ИИ часто выдает отдельные фрагменты, которые аналитик должен связать между собой.
Еще один навык — работа с самим ИИ: точно ставить задачу, передавать контекст и понимать, какие данные безопасно ему отдавать.
Динара, бизнес-аналитик:
ИИ быстро подсказывает паттерны, кейсы и лучшие практики, которые раньше приходилось искать отдельно. Поэтому само знание того, «как принято делать», уже не такое большое преимущество.
Важнее сформулировать собственный замысел: понять проблему, нужный результат и ограничения. Часть условий может вообще не проговариваться, хотя именно они часто влияют на то, получится ли реализовать задуманное.
Как ИИ изменит работу аналитика
Ваня, системный аналитик:
Думаю, рутина и дальше будет уходить в автоматизацию. Будут развиваться агенты, и, скорее всего, мы придем к тому, что ИИ сможет сам генерировать гипотезы, предлагать изменения, создавать документацию и поддерживать ее в актуальном состоянии.
Аналитику при этом все равно придется валидировать результат.
Динара, бизнес-аналитик:
Для меня ИИ — не самоцель, а способ освободить время для мышления.
Чем больше рутины можно передать инструменту, тем больше времени остается на то, ради чего нужен аналитик: понять проблему, сформулировать замысел и принять решение.
ИИ может ускорить работу, но создать условия для реализации решения и взять за него ответственность остается задачей человека.
Сейчас все говорят о внедрении ИИ. Внедрение инструментов ИИ становится мемом - "Зачем надо? Мы не знаем. Когда надо? Сейчас."
Редко, когда можно услышать четко сформулированные причины и ГЛАВНОЕ - целевое состояние после реализации инструментов ИИ.
Среди коллег и клиентов, я не так часто слышу, но все же слышу такую фразу, что-то подобное - «Наш отдел/блок/компания тратит слишком много времени на рутину, нужно внедрять ИИ», либо «ИИ модно/это будущее, если мы не реализуем, то реализуют другие, а мы опоздаем, потеряем, упустим…»
Если вы сталкивались с таким, а вы с таким сталкивались... то какие ОСНОВНЫЕ вопросы вы зададите, чтобы ПОНЯТЬ нужно ли, а если нужно, то можно ли, а если можно – то, что и как будет реализовано?
Задавайте вопросы, они помогают людям думать.
Я для себя сформулировал и стараюсь задавать следующие. Пользуйтесь:
Какие именно процессы вы считаете рутинными? Чтобы понять, где проблема.
Сколько времени сотрудники тратят на эти процессы? Чтобы оценить масштаб.
Какие данные и системы используются в этих процессах и какие будут? Чтобы понять, есть ли база для автоматизации и какие будут созданы новые зависимости и риски.
Являются ли указанные вами процессы точными, надежными, обеспечивают ли процессы качество данных? Чтобы понять возможность, применимость и последствия реализации ИИ инструментов.
Как внедрение инструментов ИИ повлияет на компанию, вовлеченных и ускоренных сотрудников, в долгосрочной перспективе? Чтобы понять, что произойдет с опытом и знаниями, обучением, развитием и сохранением преемственности знаний и опыта сотрудниками и компанией после внедрения инструментов ИИ.
Кто будет владельцем процесса и результата после внедрения? Чтобы понять кто будет нести ответственность за работу, и кто будет отвечать за результат.
Готовы ли люди, которых затронет изменение, работать по-новому? Чтобы понять, приживется ли решение.
ИИ является инструментом. Но инструмент без цели превращается в хайп и мемы. В хайп, в какой-то мере, способный нести риски для бизнеса. Как в части базовой информационной безопасности, так и долгосрочных перспектив ведения бизнеса.
Задавайте правильные вопросы до того, как начнёте. Какой бы вы вопрос задали, в дополнение к моим?
В общем, оставил ручную проверку при подтверждении публикаций на чужих сайтах. И уже не уверен, что это косяк.
А что делать, если признаки противоречат друг другу? Сделаю проверку жёстче — начну отбрасывать нормальные публикации после редактуры. Ослаблю — появятся ложные совпадения.
Кажется, проблема обходится проще: пусть CMS издателя сама присылает подписанное подтверждение публикации. Сильный сигнал, но он доказывает одно: CMS сообщила, что публикация вышла. А страница потом может сменить адрес или перестать открываться.
Допустим, сегодня мы сами всё проверили и подтвердили публикацию. Через неделю её удалили. Получается, первоначальная проверка была ошибочной. Или это два разных факта: «публикация была подтверждена тогда» и «публикация доступна сейчас»?
Думаю, однозначные случаи стоит закрывать автоматически, спорные отдавать человеку, а исторический факт и текущее состояние хранить отдельно.
Как считаете, ручная проверка редких спорных случаев — нормальная часть автоматизации или признак её отсутствия?
Выпустили с командой учебное пособие по моделированию систем транспортных средств - "REPEAT VISION для электромобильности".
Это пошаговое руководство и сборник моделей для работы в REPEAT: в нём собраны типовые решения для моделирования систем накопителя электроэнергии, электроприводов, систем управления, систем термостатирования. Книга поможет инженерам и студентам быстрее разобраться с платформой — и сразу перейти к практическим задачам.
Одно из первых учебных пособий по REPEAT: подойдёт тем, кто осваивает мультифизическое моделирование и цифровые двойники.
Можно ли получить от агента надёжный результат, не спроектировав для него работу? Судя по тому, как мы с агентами работаем, многие на это рассчитывают.
Мы научились писать агентам промпты и учимся принимать у них результат. А проектировать для них работу так и не начали. Поэтому ошибки повторяются от эксперимента к эксперименту и не исчезают ни с новой моделью, ни с более длинной инструкцией. Ниже — почему так происходит и три принципа, которые можно взять на вооружение, когда проектируете работу для агента.
Когда появились компьютеры, работу для них не стали описывать так же, как для служащих. Машина не понимает замысла, поэтому появились алгоритмы: работу пришлось описывать так, как её способен исполнить новый исполнитель.
Для людей своя дисциплина сложилась задолго до этого: регламенты, квалификация, руководитель, последствия. Она работает, потому что человек понимает смысл правил и меняет поведение после оценки.
Агент — третий тип исполнителя. Он интерпретирует ситуацию, как человек, но без норм, опыта и последствий, которые человек приносит с собой.
Посмотрите, как в статьях об агентах разбирают их ошибки. Агент выдал неприемлемый результат, и дальше обсуждается, как такую ошибку поймать и кто за неё отвечает. Вопрос, можно ли было устроить работу так, чтобы этой ошибки не было, почти не возникает.
Хотя с такими ошибками можно разобраться раньше, ещё при проектировании: часть исключить, а остальные ловить там, где это проще. Для этого работу нужно проектировать с учётом того, что агент интерпретирует информацию. Три принципа ниже — об этом.
Проектируйте от работы, а не от агента. Сначала определите, какую ошибку вы не готовы принять и после какого действия её уже не исправить. Только потом решайте, что поручить агенту.
Решите, что агенту не нужно интерпретировать. Всё, что можно установить независимо, передайте ему уже подтверждённым. Интерпретацию оставьте там, где ради неё агент и нужен.
Определите, как примете результат, до запуска и отдельно от агента. Когда критерии приёмки известны заранее, работа для агента проектируется точнее, а результат принимать проще.
Почему, на ваш взгляд, работу для агентов почти не проектируют: не знают как, не видят смысла или ждут, что следующая модель справится сама?
Когда точечные интеграции перестают работать: как выбрать ESB и собрать команду
Интеграции редко проектируют сразу как отдельный слой. Обычно сначала появляется несколько обменов между системами, потом еще несколько — и постепенно всё превращается в сложный контур, который трудно развивать и поддерживать.
29 сентября вместе с EvApps проведем вебинар о двух связанных задачах:
когда компании уже нужна ESB, а когда точечных интеграций достаточно;
как собрать команду, которая сможет внедрить и дальше сопровождать интеграционный слой.
Разберем:
место ESB в корпоративной архитектуре и связь с MDM и КХД;
российский рынок интеграционных платформ;
подрядчика, аутстафф, внутреннюю и смешанную команду;
типовые точки, где проект начинает буксовать по ресурсам;
что делать с поддержкой после запуска.
Спикеры — Сергей Скирдин, технический директор «Белого Кода», и Альфред Столяров, директор EvApps.
Участники получат обзор российских шин, опросный лист для выбора ESB и чек-лист проверки подрядчика.
17 бесплатных вебинаров для аналитиков: ИИ, требования, бизнес-процессы и микросервисы
Привет, Хабр. Хороший анализ начинается не с документа и не с диаграммы. Сначала нужно понять, какую задачу решает бизнес, затем — разобраться с требованиями, договориться со стейкхолдерами, описать процессы и превратить всё это в понятное техническое решение.
Чем сложнее становятся продукты и системы, тем важнее для аналитика видеть картину целиком: от бизнес-целей и клиентского опыта до требований, бизнес-логики, данных и архитектуры. А ещё — уметь работать с изменениями и использовать ИИ там, где он действительно помогает ускорить рутинную работу.
В этом посте собрали 17 открытых вебинаров для тех, кто хочет развивать навыки системного и бизнес-анализа.
Когда обращений становится больше, кажется логичным расширить команду. Но вместе с новыми людьми растет и другая нагрузка: нужно помогать и передавать контекст новичкам, отвечать на одни и те же вопросы. При этом один сотрудник может заново искать решение, которое другой уже нашел.
С этим столкнулась команда клиентского сервиса ITSM 365. Кира, бизнес-аналитик клиентского сервиса и куратор командной базы знаний, рассказала, как команда постепенно выстроила систему работы со знаниями.
1️⃣ База знаний сама по себе проблему не решает
Можно написать сотни инструкций, но если их сложно найти, они дублируются или быстро устаревают, коллеги продолжат спрашивать друг друга. Поэтому работу с базой мы строим вокруг четырех принципов:
Актуальность — обновляем материалы и следим, чтобы они не дублировались.
Доступность — встраиваем статьи в рабочий процесс.
Признание — публично отмечаем всех, кто участвовал в подготовке материалов.
Ответственность — поддерживаем базу всей командой.
Как куратор, я проверяю, нет ли уже статьи на нужную тему, и помогаю авторам. Если коллеги замечают неточности, сообщают мне — я вношу правки сама или передаю материал автору.
При этом новые статьи пишем не ради количества, а когда видим повторяющийся вопрос или решение, которое пригодится другим.
2️⃣ Нужные инструкции должны быть под рукой
Важно, чтобы сотруднику не приходилось отдельно вспоминать, где искать нужную информацию. Поэтому стараемся сделать знания частью самого рабочего процесса.
Например, при выборе категории заявки портал сразу предлагает коллегам подходящие материалы. Клиентам он тоже подсказывает статьи: например, перед регистрацией обращения с высоким приоритетом предлагает инструкции, которые могут помочь восстановить работу приложения самостоятельно.
3️⃣ Иногда достаточно простого решения
Не все задачи требуют ИИ или большой автоматизации. Чтобы не подключать инженеров к вопросам, с которыми можем справиться сами, мы используем шаблоны комментариев. С их помощью проверяем базовые сценарии, собираем информацию и понимаем, нужна ли дополнительная экспертиза.
Еще один инструмент вообще выглядит максимально просто — обычное текстовое поле с комментариями по клиенту. Туда записываем договоренности: кому обещали рассказать о новой функции, к кому нужно вернуться после релиза, кого предупредить об изменениях. Это решение появилось как временное еще семь лет назад, но ничего удобнее мы пока не нашли.
4️⃣ ИИ там, где он действительно экономит время
Для работы с длинными обсуждениями мы используем ИИ-ассистента. Прямо в заявке можем получить краткое содержание переписки, собрать контекст для другой команды или выделить основные требования.
Раньше на такую работу могло уйти около получаса, сейчас — в среднем 3–5 минут.
Еще с помощью ИИ ищем похожие обращения по смыслу, а не только по ключевым словам. Это выручает, когда не знаем, как такую проблему описывали раньше.
5️⃣ Что изменилось в работе
Раньше на вопрос «Как добавить новую колонку в список заявок?» специалист в среднем тратил около 25 минут, а стажер — почти час. Сейчас открываем готовую статью и обычно закрываем такой вопрос примерно за минуту.
При этом часть типовых обращений вообще перестала доходить до нас: клиенты находят ответы самостоятельно. Новичков стараемся раньше подключать к реальным задачам и учим искать нужные статьи по ходу работы. В итоге тратим меньше времени на повторяющиеся вопросы, а знания становятся менее зависимыми от конкретных людей.
Культура обмена знаниями начинает работать тогда, когда найти нужную информацию самостоятельно проще, чем ждать ответа коллеги.
→ Подробнее своим опытом Кира поделилась в статье.
Luma: объединяем Data Governance, Business Intelligence и Искусственный интеллект
Вместе с Arenadata на вебинаре представили совместное решение Luma и рассказали, как интеграция каталога данных, BI-платформы и искусственного интеллекта помогает выстроить единое пространство для управления корпоративными данными и аналитики.
На мой взгляд ключевой вызов системе образования сегодня в том что мы умеем выпускать джунов, а они уже в работе растут дальше до мидлов и синьоров. А в мире победившего ИИ джуны не нужны работодателям. Да и мидлы не факт. А вот сеньоры нужны, хоть и в меньших количествах.
Если мы внимательно посмотри на анализы рынка труда, в которых фиксируется недостаток работы для джунов, например тут — «Forbes: „джуны“ сейчас не нужны или почему выпускникам IT‑курсов стало сложнее найти работу» https://habr.com/ru/news/681468/, то видим, что проблема не в ИИ, который заменил джунов, а в целом в сокращении потребности отрасли в специалистах и большом количестве переученных выпускников курсов. На самом деле джуны также нужны и сейчас и в будущем пригодятся по тем же самым причинам, что и раньше:
Им можно меньше платить.
Они больше мотивированы и готовы расти.
Они меньше спорят и больше делают.
Но конечно меня спросят, а что насчет того, что всю работу джунов может заменить ИИ? На этот счет у меня есть история из моей лабораторной практики. Когда я поступил в аспирантуру, общей практикой было то, что все новички: студенты и аспиранты, сначала в лаборатории моют посуду. Многие студенты на практике и аспиранты в первые пару месяцев только этим и занимались. Такой же подход был показан в сериале Теория Большого взрыва. Когда Шелдон приходит к Эми в лабораторию и предлагает помощь, она отправляет его мыть посуду.
Но в скором времени, наша лаборатория стала переходить на одноразовую пластиковую посуду, и потребность в мытье посуды просто отпала. По аналогии с ИИ, лаборатория должна была отказаться от студенческих практик и молодых аспирантов. Ведь теперь посуду мыть не надо, значит эти люди не будут приносить пользу. Но это не так. Просто студентам на практике стали давать больше заданий в рамках реальной экспериментальной работы.
Эта история мне всегда напоминает о том, что в реальном производственном или исследовательском процессе всегда остается много того, что пока может сделать только человек. И если у вас есть потребность в разработке, аналитике и так далее, то с помощью ИИ джун может сделать много того, что раньше мог делать только опытный разработчик.
Изначально предприятия берут MES, чтобы автоматизировать что-то, а потом сталкиваются с тем, что автоматизации минимум, и не так всё это просто запустить. В основном сейчас внедряют цифровизацию, которая собирает данные контроля и выводит красивые мнемосхемы. Никакой автоматизации в принятии решений, а зачастую нет даже подсказок, в какую сторону надо принимать решение. Все красивые технологии, о которых говорят, пока больше в презентациях. Есть и другие проблемы.
Ключевые проблемы внедрения MES:
Устаревшее оборудование, линии связи, отсутствие автоматизированных средств контроля;
Отсутствие производственных регламентов, нет проработки процессов;
Неватка компетентного персонала;
Сложности в интеграции существующих системы;
Несогласованность нормативно-справочной информации (НСИ)
Разрывы в данных, которые нужны и которые могут быть собраны;
Ограничения бюджета, невнятные KPI при высоких затратах.
Но тут ещё другая проблема выстреливает, вот позавчера наткнулся Ирония автоматизации (ссылка).
В 1970х годах когнитивный психолог Лизанна Бейнбридж проводила дни, наблюдая за операторами больших индустриальных печей. Она просила их проговаривать вслух, что именно они делают и почему, и разбирала, как устроено их знание о производственном процессе, управляемом автоматикой.
Из этой серии интервью в 1983 родилась статья "Ironies of Automation".
Ирония автоматизации состоит в том, что человеку достаются задачи, которые не удалось автоматизировать, то есть по определению самые трудные и плохо формализуемые. Плюс к ним – надзор за автоматикой, которую внедрили как раз потому, что она работает лучше человека. И эта система концептуально сломана:
Человек физиологически неспособен удерживать внимание на источнике, где почти ничего не происходит.
Умения оператора деградируют без практики. Если ты годами только наблюдаешь за системой, то в момент аварии, когда нужно перехватить управление и проявить мастерство, его уже не осталось.
Знания в долгосрочной памяти остаются доступными, только когда к ним регулярно обращаются. Оператор, не пользующийся этими знаниями, теряет способность быстро их извлечь. Кроме этого, протухает ментальная модель того, как работает система, и в каком состоянии прямо сейчас она находится.
Все эти проблемы стали ярко видны в произошедшей примерно в то время аварии на АЭС в Пенсильвании (ссылка). Скакнуло давление, один из клапанов не закрылся, и пошло-поехало. При этом все части автоматики сработали как надо, но итоговый сценарий был не знаком операторам, а из-за показаний приборов их ментальная модель разошлась с реальностью. В итоге они совершили кучу ошибок, произошел выброс радиации, а блок теперь законсервирован навсегда.
В общем история о том, что теряется субъектность персонала, люди перестают думать и доверяют машине, а когда машина подводит, не могут сами принять решение и выполнить правильные действия.
Сравните с тем, как много сейчас говорят об ИИ. Мол ИИ заберет простые задачи, но мы будет за ним проверять и думать о сложном. Не будем мы проверять, и возможно не будем думать. Это конечно плохо.
Аналитик между бизнесом и разработкой: что нужно знать сегодня
Задача поставлена, но никто не может точно объяснить, что именно нужно сделать. Бизнес ждёт результат, разработчики задают десятки уточняющих вопросов, а изменения продолжают появляться по ходу проекта.
Работа аналитика — превратить этот хаос в понятную систему: выявить потребности, зафиксировать требования, найти слабые места и помочь команде прийти к правильному решению.
Подобрали бесплатные уроки, которые помогут усилить практические навыки системного и бизнес‑анализа.
Системный анализ и работа с требованиями
8 сентября, 20:00. «Системный аналитик и его ценность глазами компании». Записаться
23 сентября, 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться
🤖 Типовые задачи, на которые уходит время: сбор требований, user stories, документирование as-is / to-be, ТЗ и спецификации 🤖 Инструменты: ChatGPT, GigaChat, YandexGPT с промптами для аналитика; RAG-ассистенты на корпоративной базе; ИИ для диаграмм и моделирования 🤖 Оркестрация нейросетей: одна модель (Claude) распределяет задачи между специализированными моделями и собирает результат 🤖 Кейс из практики: задача, цепочка ИИ-агентов, результат, что дорабатывалось вручную 🤖 Границы применимости ИИ: контекст, стейкхолдеры, внутрикорпоративные процессы. Критическое мышление.
📆 Когда: 8 сентября в 18:00 (Мск) 👨🎓 ️Спикер: Новичков Александр, L&D-стратег, руководитель образовательных проектов
