Прошел очередной Летний аналитический фестиваль. В этом году он проходил в Иваново: в связи с тяжелой ситуацией на рынке ЛАФ вернулся из Подмосковья на ту площадку, на которой начинался в далеком 2010 году. И к тому же формату: суббота – в офисе Консультанта, вечером – переезд за город, на турбазу, там шашлыки и движуха, а в воскресенье – продолжение мастер-классов уже на турбазе. И громадная благодарность организаторам, что провели фестиваль! Было много нетворкинга и интересные доклады, два трека выступлений и два – мастер-классов. А относительно камерный формат, в котором было всего 120 человек, многие из которых были на фестивале многократно, создал прекрасную атмосферу. Обсуждения многих насущных тем продолжались практически всю ночь до утра. А началось это на препати, который был еще в пятницу вечером.

LLM – основная тема

Естественно, основной темой фестиваля было применение LLM, об этом были выступления и мастер-классы. Освоение LLM идет быстро, и, как обычно это бывает, есть лидеры и те, кто следует за ними. Лидеры уже не просто используют ИИ в качестве личного помощника, а встраивают в рабочие процессы. При этом повышение эффективности получается от 30% до нескольких раз. Эффективность меряют по возрастанию производительности на потоке задач. Иногда это еще и сопровождается сокращением числа сотрудников, но чаще обходится без этого – работы много, и ее просто быстрее делают, что дает новые возможности бизнесу.

Возможности LLM – очень велики. Один из повторяющихся сюжетов круглого стола по ИИ – вопрос из зала «как вы думаете, сможет ли ИИ когда-нибудь делать это», и ответ «он уже это делает». Например, обучает джунов: Татьяна Половинкина из Неофлекс рассказала, что у них новичков созданию хранилищ данных и работе с ними учит виртуальный DWH-ментор.

Применение ИИ требует реорганизации рабочих процессов. При этом новых шаблонов еще не выработано, люди действуют эмпирически, опытным путем. Если говорить методологическим языком, то речь идет о реорганизации системы разделения труда. Этот процесс проходил в ИТ много раз при появлении новых технологий или управленческих практик. Так, появление персональных компьютеров и массовая потребность в разработке привело к созданию Agile-методов, а развитие интернет – к появлению web-мастера, который разрабатывал сайты, а позднее – к разделению его позиции на несколько специализаций. Поэтому хорошо бы, проектируя такую реорганизацию, знать соответствующие подходы и методологии. В частности чтобы не забывать про то, что всякая новая позиция, в том числе позиция ИИ-агента, должна быть спроектирована в окружении: снабжена необходимыми знаниями, определены критерии допустимого входа для задачи (DoR) и успешного завершения (DoD) и так далее. И думать об этом сразу на этапе проектирования, а не наступив на соответствующие грабли. О методологиях организации системы разделения труда у меня недавно статья Об организации труда ИИ-агентов.

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

Но вот принципиальное изменение, которое несет вайбкодинг – это переход от традиционного цикла разработки, начинающегося с тщательного проектирования, к быстрой разработки через прототипы и MVP, которое может делать сам бизнес. Раньше разработка через прототипы тоже была, но применялась очень ограничено, для новых экспериментальных фич и проектов. А сейчас может стать основным способом. И дальше надо так организовать процесс, чтобы к большому продукту, находящемуся в эксплуатации, с помощью вайбкодинга можно было примешать новый функционал или поправить существующий, не снижая устойчивость. То, что раньше делали ограниченно, позволяя, например, декларативно описать новый тарифный план или промо-акцию. Вайбкодинг позволяет много больше.

И в практике это тоже активно происходит. Один из кейсов на круглом столе: из 5 аналитиков остались двое, один сеньор, а другой – джун, потому что у них было открыто сознание для перестройки, а трое ушли, не захотели или не смогли перестроиться. Потому что изменения сильные: ты не документы пишешь, а систему вайбкодишь и приносишь ее заказчику, огребая при этом обратную связь. Что интересно, пятнадцать лет назад я слушал выступление Paul Turner на ReqLabs-2011, он там рассказывал модель, в которой аналитик не только снимает требования заказчика и пишет постановку, но и принимает результат от команды разработки и несет ее заказчику – потому что именно он формировал ожидания в ходе первоначальной коммуникации. Эта часть роли аналитика – отнести результат – ушла в тень. И вот оно вернулось, только вместо команды разработки у вас могут быть вайбкодинг и ИИ-агенты.

Ну а теперь перейдем к отдельным выступлениям, в том порядке, в котором я их слушал. Среди них я хочу особо отметить выступление Юлии Литвинюк – там интересный кейс работы над повышением устойчивости системы. Напоминаю, что здесь далеко не все, потому что на конференции было четыре параллельных трека. Видео выступления будет выложено.

Максим Цепков. Опора в эпоху перемен: логика и культура лидерства Китая и опыт китайских tech-гигантов

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

А в целом я очередной раз рассказывал про менеджмент и корпоративную культуру китайских компаний и ро происходящие в мире изменения, связанные с перехватом Китаем технологического и политического лидерства у Штатов. Основой – личный опыт поездки по китайским технологическим компаниям (Baidu, Xiaomi, SenseTime, Little Red Book и других), и последующее углубление в тему. Презентация выложена на странице выступления на моем сайте. Видео будет опубликовано, а пока можно читать мою книга «Китай: дао менеджмента и культурный код будущего лидера мира» или смотреть вебинар Влияние технологий на изменение мирового порядка и глобальную конкуренцию, который я проводил в январе. Отмечу, что этой весной у меня много выступлений на эту тему, однако они не являются повторением: я меняю логику рассказа и адаптирую рассказ под аудиторию. Хотя, конечно, в них много общего.

Евгений Виноградов. Выбор модели для построения AI-агента

Основной тезис выступления в том, что сейчас выбор модели – не главное, что определяет успех внедрения, хотя, конечно, модель должна быть адекватна задаче. Главное – это обеспечить модель необходимым контекстом. И надо уметь отделять работу с контекстом от самой модели, в том числе – для того, чтобы можно было проверять и сравнивать разные модели. И Евгений рассказывал о средствах для этого, которые, в том числе, позволяют организовать автотесты работы с контекстом, а не просто управлять им.

И перед тем, как рассказать про вступление подробнее, я хочу дать ссылку на другое выступление: Дарья Шатько. Как мы внедрили LLM-судей в автоматизациях клиентского сервиса: подход, грабли, уроки (AIconf). Дарья рассказывала про сложную структуру обработки обращений техподдержкой Яндекса из людей и агентов, и важным аспектом там как раз является система мониторинга качества работы агентов, для чего применяются выборочные проверки ответов другими агентами и людьми. По сути, получается аналог регулярной системы performance review, только не для людей, а для агентов.

А теперь вернемся к выступлению Жени.

Выбор LLM – для разных задач подходят разное.

• Стоимость токенов. Но для базовых экспериментов 20$ на человека – нормально.

• Скорость ответа. Иногда очень долго – от LLM для перевода вопросов в поддержке отказались, потому что для киргизских и подобных языков перевод вопроса и ответа – пара минут.

• Возможность работы с чувствительными данными.

Это – отсекающие очевидные пункты. А вот дальше – пригодность для ваших задач. Качество работы агента принципиально зависит от передаваемого контекста, RAG. Поэтому вам надо уметь оценивать и тестировать качество RAG. Можно ли написать автотест для RAG? Можно, но сложно, потому что ответ недерминирован. Что можно делать?

• База вопросов и правильных ответов, иногда это просто, но не всегда. Даже названия государств имеют альтернативы: Саудовская Аравия или КСА. Формулируют эксперты. Эксперты делают медленно, поэтому генерация. Но генерация – она из широкой рамки, может не видеть нюансов от эксперта. Плюс внешний мир меняется, выходят новые нормы.

• Фильтрация ответов после получения на пригодность выдачи пользователю. Это – отдельная тема.

• Специфические метрики: context relevancy, faithfullness, answer correctness (Fact TP/FP/FI и semantic distance): Идет ли речь о том, что пользователь спросил? Нет ли галлюцинаций – все части связаны с нашей фактологической базой?

Инструменты.

• Фреймворк RAGAS для проверки ответов. Его можно встроить в середину процесса, но надо покодить.

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

• И надстройки над ними.

Расчет метрик: pairwise comparisons – дорого. Но это можно встроить в рабочий процесс, например, когда идея ответа выскакивает сотруднику, то тот его оценивает – и получаем реакцию.

И тут интересный кейс: они поставили ИИ чтобы подсказывал сотрудникам – а время выросло, потому что там – сами писали, часто сразу, а тут надо вчитаться и оценить. До экономии надо идти отдельно: она возникает, когда большинство ответов начинает выдавать ИИ без оценки сотрудникам, а это – следующий этап. Об этом рассказывала Дарья на AIconf, и надо не просто довести систему до такого уровня, нужен постоянный мониторинг, что система не деградировала.

LLM as a judge – direct scoring. Хорошо работает на общих областях, но в конкретной предметке может не поймать различия, которые очевидны специалисту, и даже противоположные ответы опознает как совпадающие.

Сравнение по тексту (дистанция Левенштейна и тому подобное) практически не работает.

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

С моделями есть вопрос, как с любым API. Если есть особенности – под них клиенты адаптируются. Каждый раз когда меняется модель – особенности меняются, и важно используемые особенности фиксируют – перетестирование функциональности.

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

Игорь Рыбаков. Impact Mapping: сначала понять проблему, потом подключать ИИ

Это был рассказ про метод Impact Mapping. А про ИИ Игорь говорил лишь то, что «его можно использовать на многих шагах», без деталей. Хотя опыт использования у них есть, в ответах на вопросы это было.

Impact Mapping мне давно знаком, более того, сейчас у него есть современное развитие – Карта гипотез Александра Бындю, где предложен формат, в котором надо описывать гипотезы, чтобы не потерять существенные логические связи. На мой взгляд, это – прорыв, сопоставимый с изобретением в свое время формата user story. Про карту гипотез есть книги автора, подробнее вы можете посмотреть мою рецензию.

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

Кейс – программа лояльности. Бизнес часто приносит готовое решение: нужна программа лояльности – надо поднять повторные покупки. Задача имеет несколько уровней и не факт, что проработано. При этом даже когда заказывают исследование и оно показывает, что решение не работает, бизнес говорит «мы лучше знаем». Но в том, что не работает по-любому виноват подрядчик: он сделал не то и не так. Бизнес -не виноват.

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

1. Что мы хотим сделать

2. Через кого сделать – люди

3. Как поменяется поведение

4. Какой инструмент изменения.

Этот путь надо пройти самим.

Impact mapping – метод, который позволяет перевести вопрос с уровня «что надо сделать» на «что должно измениться и зачем», связать ожидания по каждой фиче с конкретными метриками, автор – Гойко Аджич. До impact mapping они пробовали плоский бэклог, user story mapping – в нем не всегда есть ценность, и Feature Slice Design (FSD)/ТЗ – не всегда есть связь.

Кейс подробнее. Есть магазин одежды, первая покупка есть, а вторая проседает – клиент не возвращается. Магазин посмотрел у конкурентов – есть программа лояльности, и говорит: давайте внедрим. Очень популярный путь, хотя обычно не работает, потому что формальный перенос без понимания механик оказывается недостаточным.

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

1. Принять решение в том виде, как предлагает бизнес

2. Спросить и согласовать: как мы поймем, что цель достигнута, какие будут метрики

3. Подумать над рисками и ограничения предложенного варианта

4. Если есть возможность – утрируем риски или потери возможностей

5. Переформулируем запрос через цели и метрики

6. Переходим в пространство решений – предлагаем альтернативы

7. Выбираем приоритетный вариант

На втором этапе нужно 1-3 цели, 1-3 метрики для каждой. Не все бизнесы переходят к цифрам, надо аккуратно.

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

На последних этапах появляется скелет карты и альтернативы. Цели → ключевой актор → влияние.

Приземляем сценарий на наш кейс. Повторная покупка – что такое? Возвращается в течении 180 дней. Средство – личный кабинет участника программы лояльности. Тут появляются идеи: мы не ждем возвращения, а подмешиваем следующий товар в слайдеры, чтобы клиент за ним быстро шел. А кроме личного кабинета могут быть триггерные коммуникации. И проработка: где клиент отваливается, что мешает повторной покупки, какие проблемы повторяются, что можно проверить без полной системы, что работает у конкурентов и аналогов в похожих сценариях. ИИ может вытаскивать гипотезы и собирать данные с рынка.

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

Как проверять гипотезы? Можно полноценно проверить на А/Б тесте, но это дорого. Поэтому для начала собираем качественные оценки высокий/средний/низкий – экспертов, команды, ИИ (мнения и публичные кейсы) и так далее. Это можно показывать бизнесу. И можно сравнивать варианты решений. ИИ может валидировать все это.

HADI-цикл. Повод вернуться – триггерная коммуникация – А/Б тест – оценка гипотезы.

Где Impact Mapping живет в Agile-процессе? На старте продукта/фичи; при работе с бэклогом; в спринтах и HADI-циклах. Impact mapping живет как отдельный артефакт, ссылки – на детальные, используется как трассировка. Каждая story проверяется на встройку в impact mapping – влияние на бизнес.

С чего начать?

• Метрики. Если нет – как-то пробуем их создать, делаем черновой список показателей.

• Если метрики есть, но субъективно – пробуем их связать с задачами в бэклоге

• Если метрики связаны с бэклогом – то можно делать альтернативные гипотезы

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

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

Ответ про ИИ. Первичная декомпозиция – сами, ИИ проверяет, что забыли. А дальше на каждом этапе ИИ помогает со сбором данных, метриками и проверкой гипотез. И дальше – детализация – эпики, user story и так далее. ИИ – экзоскелет, продолжение мысли аналитика.

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

Скорость отработки задач аналитиков увеличилась на 30%

Вопрос. А лучше ли смотреть долгосрочное, может, лучше было один раз сделать систему лояльности и пусть уйдет? Ответ. Работать в долгую лучше, клиенты – ценные. Если он настаивает – принимаем решение с учетом этого.

Дмитрий Семчук. Черный список ИИ-агентов: как агентироваться и не проиграть

В выступлении – опыт работы с ИИ-агентами: общая конструкция, разные типы и типовые ошибки.

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

Есть 5 уровней агентности Google. От коробки, которая отвечает на вопросы – трогает инструменты – декомпозирует задачи – работает вместе – самообучается и совершенствуется.

Уровни ИИ-системы: интеграция с LLM – BB-сервис – ИИ-агент – мультиагентская система. Дальше в презентации было несколько архитектурных схем, которые показывали усложнение с ростом уровня. В чем отличие сервиса от агента? ИИ-сервис выполняет функцию, а агент – решает задачу. Сервис – простое API, запрос-ответ. А в агента вбрасывают задачу, он декомпозирует и выполняет поток запросов.

Состав ИИ-агента: LLM, Память – контекст, Оркестратор процессов, Инструменты (tools). Очень важный элемент, определяющий результативность – память, в разных вариантах. Оркестратор процессов отвечает за декомпозицию и управление очередями, исполнение. Все это надо проектировать и реализовывать. И аналитик – хороший кандидат на эту роль.

Архетипы ИИ-агентов.

• LLM-workflow: ИИ-система выполняет сложные сценарии. n8n и аналоги. Он не решает, как выполнять задачу, а просто вызывает цепочку вызовов. Сгенерить документ, презентацию и нет сложной логики. Главный кейс – Прототип за один день. Но: не масштабируется, не работает под большой нагрузкой, не адаптируется к недерминированным ситуациям, на больших workflow портятся данные (json плохо парсится).

• Толстый агент – ChatGPT, Claude, Gemini. Один агент делает все, остальное – внутри. Классно выполняют сложные задачи. Но требует умения формулировать сложные задачи. Очень дороги и для большинства задач – не окупите. Все модели – внешние, и данные туда сливать, хотя можно анонимизировать, но с этим свои проблемы. А еще не все нас любят, прокси, есть риски.

• Вертикальный агент – агенты под конкретные задачи. Например, юридический анализ. Много дешевле, классно выполняют конкретные задачи. Сделать агентов не очень просто – надо дообучать, data science или ML. Важно качество входа, иначе на выходе будет фигня. Поэтому RAG.

• Агент поддержки. Встроен в инструмент – notion, Claude code – туда встроено много агентов поддержки. Они логично встраиваются. Требует работы с инструментами, зависимость от базы знаний и встраивания human-in-the-loop

• Мультиагентные системы – сборка многих агентов под комплексные задачи.

Почему агенты не работают? Ошибки и заблуждения проектирования. Сложности – не технические, а бизнесовые и архитектурные.

1. Концепт «агент решит все сам», это волшебная кнопка, он сам сделает. Нет, его надо проектировать и настраивать. Иначе он не работает, делает не то. Спецификация – карточка агента, там набор типовых задач, контекст и так далее. Дальше делаем реестр и публикацию через него.

2. Отсутствие обработки ошибок. Агент стучится в API, и не всегда не всегда получает ожидаемое. Обработка, retry, сохранение состояния. Иначе они могут сожрать все ресурсы, стучась в сервис, который лег.

3. Нет логирования и наблюдаемости. Каждое действие складываем в файлы. Есть инструменты – Chain-of-Through, LongFuse.

4. Игнорирование контекстного окна. Оно переполняется, над чистить или утрамбовывать, иначе он забывает, что делал и что просили. Минимум – есть плугин, который показывает контекстное окно, и смотрите. Цепочка суммаризации – по мере наполнения контекстного окна, суммаризуем. RAG – классный концепт, как можно работать с большими базами данных, но это сложно.

5. Слепое доверие к LLM. Почему-то многие дают все права, вместо того, чтобы дать ограниченные – как джуну. Валидация результата. Структурированный результат – json вместо текста.

6. Переусложнение архитектуры. В большинстве случаев агенты не нужны, идити от минимального к максимального, а до этого посмотрите, что у вас уже есть.

Куда идти осторожно?

• Сложные LLM-workflow. Если больше 10-15 вызовов – упрощайте, передумывайте процесс.

• RAG для простых решений. Он – для сложных, в большинстве он не нужен.

• Агенты на frontier-моделей без НФТ. Поставьте ограничения и мониторинг бюджетов.

• Мультиагентные системы без LLMOps – не забегайте вперед, сначала освойте использование отдельных.

Итого.

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

• Используйте агентов уже сейчас, как получается.

• Не надо упарываться в технологии. Prompt-engineering, который казался профессией будущего – сдох, LLM сами это делают.

И был слайд с вариантами агентского стека под разные цели.

Еще есть сложность, если агентами начинает заниматься data scientist. Дело в том, что data science – про дообучение, обработку данных. А LLM – это коробка, сама работает, и ее надо использовать с учетом ее ограничений, дообучение слабо реально. Data scientist часто усложняет.

Перестройка процессов – отдельная тема. Были классические команды: аналитик, бэк, фронт, data scientist. Сейчас есть проекты, где аналитик с разработчиком совместно в Claude работают в тройках. B scrum – он для людей, а с агентами процесс меняется.

Николай Поташников. LLM как независимый аудитор: от генерации к оценке артефактов

Основная проблема архитектора – обеспечить такую архитектуру, чтобы система не деградировала. Как это проверить и чем тут может помочь LLM?

В выступлении были такие кейсы.

1. Несоответствие пользовательской документации продукту.

2. Несоответствие архитектурных диаграмм проекту.

3. Оценка качества данного доклада – релевантность ЛАФ, ценность и так далее

Работу делает человек, а LLM его оценивает. И такое использование LLM повлияет на качество наших проектов. Об этом будет выступление.

Основная проблема системы – деградации качества со временем. Например, долго эксплуатируемое решение не соответствует регламентом ИБ, потому что они менялись, а решение – нет. Но есть и другие проблемы, например, неоправданная сложность решений. И тут потенциальный конфликт. Аналитик говорит разработчику: «зачем 8к строк кода, это же сложно», разработчик отвечает «так работает же…». Да, работает, но его же потом дорабатывать и развивать, а для этого нужно аргументировано показать, что с таким кодом будет сложно, ИИ в этом может помочь. Или аналитик приходит к бизнесу с вопросами, а тот отправляет в регламенты. Они немаленькие, и ИИ тут помогает разобраться. А сейчас появилась новая штучка, от руководителя теперь может прилететь: «Claude считает, что ты плохо работаешь…»

Принципиальная сложность с LLM – оценка качества результата. Если есть формальные критерии для проверки – то можно запускать автомат. Если нет – надо как-то проверять.

Для оценки результата формулируем критерии с метриками, каждую оцениваем независимо, на их основе – интегральная оценка. Оценка пользовательской документации продукту запускается регулярно. Если оценки стабильно небольшие, значит все хорошо, деградации нет. Аналогично поступаем и с проверкой соответствия архитектурных диаграмм проекту. Выступление он тоже проверял несколько раз в ходе работы по выбранным критериям.

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

При этом не надо выводить качество в абсолют. Есть кривая Шипелева, производительность можно быстро увеличить вначале, потом надо вкладывать ресурсы, а дальше выходим на не-улучшаемую область. Если этот доклад оценен на 6, а другие на 8 – доводим. Но не выше.

Про методики оценки LLM знает – не открываем учебник метрологии, а спрашиваем у нее.

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

Кейс про доклад – модельный, но на нем можно показать детали, которые на других кейсах закрыты.

• Выделена задача вытащить все картинки в контексте использования без вычитки картинок и оценки их качества

• По картинке делаем описание для дальнейшей работы, и это делаем однократно, а не при каждой доработке доклада.

• По каждому критерию сначала оцениваем доклад независимо.

• Потом просим обновить оценки по отдельным критериям, посмотрев на картинку в целом

• И лишь затем – сформулировать общую оценку и выдать рекомендации.

Рекомендации – не главное, и не надо их выполнять безусловно. Вполне может быть, что надо систему оценок менять. С докладом LLM посоветовала добавить в оформление котика (эмблему ЛАФ), а там непросто, потому что надо попасть в размеры.

Инструменты есть разных классов.

• Диалоги LLM – простейшая настройка

• Классический ассистент – claude и другие

• Агентский фреймворк под конкретную задачу lang chain, spring AI, JetBrains Koog

Он сторонник использования фреймворков, а не ассистентов. Промпт – он для разовой работы, которая не повторяется. А если серийно – агент.

Ключевые подходы. - Асинхронность: оценка по одному критерию не влияет на другие - Structure output - Tool calling, например, для описания картинок - Prompt assembly|rewriting – пересоздание или симуляция запроса к llm – нам нужны только описания картинок, а не размышления агента над ними. - SGR – structure guided reasoning – вы ведете агента по своей логике.

DDD. Часто ли бизнес это пробует? Тут был интересный пример про тест: с точки зрения бизнеса пункт теста может быть не вопросом с вариантами ответа, из которых один правильный, а пара (вопрос и правильный ответ), плюс дистракторы, которые отвлекают от правильного.

Everything as a code. Надо собирать контекст: Api, код, схемы сборки и так далее. Если все в разных местах – не получится.

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

У них требовалось описание бизнес-процесса, но BPMN – слишком сложный. Они придумали простое описание, из которого порождали простые диаграммы, а разработчик – использовал в коде.

Итого. LLM может стать независимым аудитором. Агент для оценки – не беседа модели, а модуль системы. Требует архитектуры и прочих артефактов.

Анастасия Кайнова. Языковые игры команды разработки: аналитик и искусство перевода

Аналитик обеспечивает трансляцию смыслов между бизнесом и командой разработки. И в этом могут помочь подходы, которые в своей работе используют профессиональные переводчики. До того, как придти в ИТ, Анастасия была переводчиком и в выступлении – рассказ о методах их работы.

Если хочешь работать со смыслами и языком – надо быть дотошным. Почему важно уметь работать с пониманием?

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

• Согласовали документ, а оно все равно не работает – потому что согласовано формально, документ реально не поняли.

• Расшифровка для команды сказанного другими людьми на интервью и совещаниях.

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

Витгенштейн. Слова имеет смысл в контексте деятельности. Пример – шутки, понятные только друзьям. ИТ-жаргон – пример языковой игры.

Когда обсуждают новую фичу, у разных участников – разные фокусы: разработчик – код, менеджер – сроки, тестировщик – способы проверки, девопс – доставка. Разработчик говорит «работает», менеджер понимает «все сделано, пошел рапортовать», тестировщик «могу проверять», а девопс «куда деплоить?».

Составляющие процесса перевода.

• Автор текста пишет на языке оригинала

• Переводчик – порождает текст на языке перевода

• Адресат – читает перевод.

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

Что важно для аналитика.

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

• Понимать, почему и зачем этот запрос или документ принесли.

• Понимать ожидаемые фоновые знания адресата, и если их не хватает – дополнять.

• Понимать, какую роль играет отправитель – от этого могут различаться значение слов. Например, «аннулирование документа» у них в разных отделах означает разное.

• Понимать, что ему не хватает каких-то фоновых знаний о контексте, чтобы понять смысл – это очень сложная задача.

Адресат бывает: реальный и усредненный. О нем надо знать следующее.

• Языковая компетенция

• Предметная компетенция

• Ценностные и культурные ожидания (как сказать: «златокудрая дева трепещет» или «рыжая девка трясется»)

• Коммуникативный эффект

• Природа канала

• Направленность, степень официальности

• Особенности ситуации использования

Ценностные ожидания важны, например, некоторые сотрудники трепетно относятся к переходу на «ты» и несанкционированный переход несет побочку во взаимодействии.

Итого: Что, Кому, Зачем, В какой ситуации. В презентации – чек-лист. Она не прогоняет по нему каждый свой текст, но при работе с младшими аналитиками – очень полезно понимать, что просело.

Как проходит перевод? Выделяют единицу перевода, и подыскивают эквивалент. Есть постоянные эквиваленты, вариативные и трансформация – добавление.

Эквивалент – Москва всегда будет Москвой. А soldier – солдат, рядовой, военный. Маленький – little, small. Drugstore – аптека, но там может продаваться еда, а у нас – нет. Санкции – негатив, но «с санкции руководителя» – позитив.

И она составляет словарь эквивалентности по командам, и снаружи. Внутри может быть схема, снаружи – операция или процесс.

Способы трансформации.

• Конкретизация. Пояснение понятий, которых нет у нас. underdog – участник соревнований, у которых нет шансов на победу. «Нужно доработать План-А» добавляем, о чем идет речь.

• Генерализация: закон об отмене повешения реально отменял любую смертную казнь, и это указываем. «Мы доработаем API-метод так-то и так -то» – сократить в изменение API или даже бэк.

• Антонимический перевод. Не «не умирал до», а «жил до». Не пречислять все статусы, а «все кроме двух». Или знаешь конкретные параметры – свернуть, что три параметра, а не 20+.

• Смысловое развитие. Не отдал лошади голову (I gave the horse his head), а «отпустил поводья».

Если помощь в поиске решения – причины, а менеджеру – результат. Решили автоматизировать Д – есть причина про время, есть результат – оптимизация, есть для разработчика – что делаем.

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

Итоги. Ложные договоренности и иллюзия понимания сопровождают нас всегда. Приемы переводчиков помогут нам это улучшить.

Очень сложно – когда многосмысловые слова, которые ты понял неверно. Слово «продукт» все понимают по-своему. «Нарисуйте дом» – каждый представит свое.

Выравнивание языка – могу делать в своей команде. С соседними командами – не реально, и аналитик несет ответственность по передаче смысла при коммуникации.

Тут я согласен. Отмечу, что DDD говорит о том, что в рамках проекта надо вырабатывать единый язык, понятный всем участникам, но это выравнивание – внутри своего ограниченного контекста. А вот со смежными командами, работающими в других контекстах, надо устанавливать соответствие, и предлагает для этого использовать набор методов, аналогичных методам интеграции в ООП. Понятие ограниченного контекста – очень мощный подход в DDD, до этого теоретики говорили про «единую и непротиворечивую модель предметной области», достижение которой на практике не реально.

Альбина Бикбулатова. Аналитик-Хамелеон: Как выжить и прокачаться в сложных кросс-командных коммуникациях

Основная идея доклада: разные люди требуют разного взаимодействия, и аналитик должен, во-первых, понимать с кем он имеет дело, а во-вторых – подстраиваться под человека для эффективного взаимодействия. Альбина использует образ хамелеона, чтобы подчеркнуть это. Понятно, что у подстройки могут быть ограничения, и не всегда руководитель должен подстраиваться сам, более того, в ряде ситуаций это мешает, и тогда лучше вести такое взаимодействия через подходящих подчиненных.

А теперь подробнее. В 1/3 случаев проекты проваливаются из-за неэффективной коммуникации: заказчик, команда, смежники. Если после созвона идет раздражение и аргументы – у вас проблемы. Что делать?

Есть книга «Разговоры с монстрами», там под монстрами имеют ввиду тех, кто выше по статусу, или у кого мы просим. Две основных рекомендации оттуда: (1) когда идете на звонок, имейте вариант Б и Ц на случай неудачи, а (2) если вышли из себя – берите паузу.

Как понять, с кем именно вы имеет дело? Для этого есть модели.

DISC – оценка поведения людей. Результат любой ценой или созраняем отношения; адаптируемся или меняем под себя. Книга «Кругом одни идиоты».

• Доминанты (D) – жестко, вплоть до ненормативной лексика. Пожар – встречный пал. Мы не фигню предлагаем, а для результата и быстро.

• Инфлюенсеры (I) – зажигают, они ориентированы на людей. А вот будет исполнено ли – вопрос.

• Устойчивые (S) – постоянные, надежные, стабильные. Если сложное – будет игнорить и уходить в себя. Уловить и действовать через личные отношения.

• Соответствующие (С) – критики, логики, разработчики, для них надо все четко.

PAEI – модель Адизеса описывает руководителей: P – тушение пожаров и локальные решения, A – там все по регламентам, задачам и правилам, I – заходить через людей, E – заходить от инноваций.

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

Дальше были кейсы и шаблоны.

• Привилегированный тиран в смежной системе, нарушает договоренности, не приходит на встречи и так далее. Он родственник большого руководителя, поэтому нельзя эскалировать. Нашла аналитика-хамелеона, купила два билета на codefest, тот позвал этого тирана в компанию, они съездили вместе и подружились. И теперь работа идет по схеме плохой и хороший полицейский.

• Были сложные взаимодействия с командой DataScience. Она отправила аналитика на курсы data science вместе с ними с задачей подружиться. Получилось, и теперь взаимодействие на личных связях.

• Объединение внутри команды или даже с другой командой: хамелеон сплачивает, создает общие угрозы, поддерживает неформальное общение и так далее.

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

• Антикоррупционный слой (это паттерн из DDD для сопряжения контекстов) – когда к вам проникает чужая бизнес-логика, надо стать куполом.

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

Аналитик-хамелеон – эмоциональная стабильность, адаптивный коммуникационный стиль и опыт построения неформальных связей.

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

Команда на удаленке. Зовет всех 4 раза в год в офис, идет на обед. Чтобы строить отношения, надо знать, чем интересуются сотрудники, подписаться на их соцсети и так далее.

В заключении этого конспекта я хочу дать комментарий про модели Адизеса и DISC, о которых говорила Альбина. Надо понимать, что обе типологии отражают не кластеры, на которые люди делятся по их психологическим характеристикам, а соответствие людей определенным функциональным позициям на работе.

Адизес рассматривает жизненный цикл компании и говорит: «На конкретных стадиях развития от руководителя требуется решение определенных типов задач. Чтобы их решать хорошо, он должен владеть конкретным стилем руководства», и выписывает характеристики, которые нужны для такого этого. При этом один человек может владеть более, чем одним стилем, но не может владеть всеми четырьмя, поскольку сильные стороны для одного из них являются слабостью для других. Впрочем, соответствие с психологическими типами у типологии Адизеса все-таки есть, поскольку каждый из стилей связан со своим нейрофизиологическим механизмом мотивации Хелен Фишер, основанным на одном из гормонов (дофамин, тестостерон, окситоцин и серотонин). У каждого человека есть все четыре системы мотивации, но сила их различается, что обусловлено разным жизненным опытом и динамиками развития. Но, как легко догадаться, смена мотивации вовсе не означает, что ты вдруг овладеваешь иным способом руководства, нужна тренировка и навыки, так что связь – косвенная.

С DISC история следующая. Уильям Марстон сформулировал четыре типовые позиции в организации своего времени, это было в 1928 годы: руководитель-лидер, способный вырабатывать стратегию и вести по ней людей; руководитель-переговорщик, достигающий целей в рамках заданной стратегии и ограничений; автономный исполнитель, решающий задачи; исполнитель, требующий управления. И дальше выписал соответствующие этим позициям психологические характеристики, которые в то время полагали врожденными. Если мы применяем это сейчас, то актуальный вопрос: насколько эти позиции соответствуют позициям в современной организации. Вероятно, соответствуют слабо, особенно в ИТ. Общество изменилось, и авторитарный лидер сейчас воспринимается не как идеал, достойный уважения, а как босс-самодур, на первое место выходит переговорщик. А от автономных исполнителей требуют не соблюдение правил, а инициативы в решении задач. И так далее. Не случайно в статьях по психологии говорят, что DISC устарел, а лучше использовать Big Five. Которой тоже, впрочем, не описывает реальные кластеры, а является образом соответствия западному корпоративному идеалу 1980-х, так что к его уместности тоже есть вопросы.

В этом смысле гораздо перспективнее модель Белбина – ее роли были выявлены из наблюдения за самоорганизацией команд равных участников. Они отражают реальные кластеры психологических предпочтений в деятельности, потому что люди сами их занимали. При этом, хотя модель первоначально была сформулирована для команд менеджеров, позднее ее перенесли на ИТ-команды. И она является гораздо более богатой, чем DISC, включая не только типы руководителей и исполнителей, но и способы работы с идеями, что для ИТ принципиально важно.

Подробнее про эти и другие можно почитать в моей книге «Инженерная модель личности: Меняя себя и других — понимай устройство», а также отдельных статьях и выступлениях на моем сайте.

Юлия Литвинюк. Как мы подружили 250+ аналитиков и разработчиков без административного влияния

Очень интересный кейс. Большая продуктовая система интенсивно развивается. Более 250 аналитиков и разработчиков, динамическая структура команд – они переменные и собираются под проект, включают от 3 до 20 человек, хотя стараются делать устойчивые пары ведущий аналитик-тимлид.

Систему используют много заказчиков на большом масштабе. И год назад у ряда крупных заказчиков начались критические инциденты – система деградировала под нагрузкой, целиком или в отдельных функциональных блоках. Устранение инцидентов приводило к авралам и работе ночами, поэтому руководство компании поставило отдельную цель в OKR – снижение количества таких инцидентов.

Анализ показал, что инциденты связаны с архитектурными паттернами, которые не рассчитаны на масштабы, которые проявляются у некоторых заказчиков. Например, когда возникает акт приемки работ на 800 страниц – все-таки, у большинства размер акта на полтора порядка меньше. Или когда в большой торговой сети всеми сотрудниками 7000 магазинов идет подписание документов при поступлении, а потом – переподписание, например, инструкции по безопасности, которая обновлена за счет смены нормативки. И вообще, система оказалась плохо рассчитана на кейс, когда у одного документа десятки тысяч электронных подписей. И так далее.

Как видно из анализа, это проявление не архитектуры в крупном, проблема может вылезти в рамках проектирования конкретной фичи. То есть надо не просто исправить конкретную проблему, а поменять методологию проектирования и разработки, при проработке архитектуры думали об этих вопросах. Сложность в том, что для такого решения нужна совместная работа аналитика и разработчика над проектом, а не последовательная, когда аналитик пишет постановку, а разработчик ее реализует. И изменить подход надо на масштабе команды в 250 человек.

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

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

Проблема – в последовательном процессе. Аналитик и разработчик говорят на разных языках. Аналитик может спроектировать, но не знают технические ограничения. А разработчик, который знает их – не понимает бизнес-контекст, из которого следуют количественные требования. И вместо решения – конфликты «кто виноват?» на разборе инцидентов.

Она поехала на Teamlead Conf – увидели workshop по внедрению изменений – модель влияния Джозефа Гренни, системный подход для изменения поведения, который масштабируется от личных привычек для изменения компании.

Таблица 2x3, две колонки (сферы): (1) мотивация – хочу ли измениться, зачем мне это и (2) способности – могу ли измениться, работать иначе. И три категории по строкам: личная, социальная, структурная. И для каждой ячейки – свой набор факторов: создать новую мотивацию, привлечь лидеров мнений, изменить систему вознаграждений и так далее. В презентации все это есть, смотрите.

И они применили эту систему для своего кейса.

Личная мотивация – чтобы сам хотел изменится. Надо поставить себя на место человека, и соединить новое с его ценностями. Не навязывать и критиковать, а завоевать доверие.

Связали антипаттерны с фактическими инцидентами – как люди их решали. Провели гильдии с разбором, и не в залоге «делали плохо, хорошо по-другому», а с точки зрения профессионального роста: «обычно делают так, но есть альтернативы».

Личная способность. Фокус по развитию навыка.

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

• Ошибки в безопасной среде.

• Насмотренность лучших практик.

• Чек-листы проектирования: сколько подписей на документе, сколько версий у документа (бывало до 1000), типовые НФТ.

• Освоение антипаттернов и сдача аттестации

• Практикум по парному проектированию – был рассказ на ЛАФ год назад. Ключевая конструкция: аналитик выясняет требования, а разработчик учитывает технические ограничения, пройти можно только вместе.

• Клуб обсуждений.

Социальная мотивация. У групп есть лидеры мнений, явные или неявные, и их надо увлечь. Надо различать лидеров и первопроходцев: первопроходцы побегут использовать, но за ними – не пойдут. Надо заручиться именно поддержкой лидеров. Для этого ведущих аналитиков и тимлидов обучили первыми. После обучения многие приносили в команду, становились лидером изменением. А у руководства это было в OKR – они поддерживали. И обсуждение антипаттернов стала нормой в коммьюнити, появилось убеждение «профи так делают».

Социальная способность. Объединиться вокруг общей цели (OKR), поощрять помощь, выделить время. Ролевые инструкции парного проектирования – по интеграции типовое оглавление и кто пишет разделы. Тимлиды и рецензенты в командах – приземления на реалии. И в систему менторинга включить.

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

Знание антипаттернов включили в оценку компетенций. Обсуждение прогресса на 1:1, передача менторам. И косвенное влияние: ты знаешь – делаешь правильные решения – квалификация выше – растешь. Фокус на OKR компании -снижение критических инцидентов.

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

В результате сейчас не все 250 сотрудников используют, но 70% – да. И новые – используют. Количество критических инцидентов снизилось сильно. Сработало потому, что отталкивались от реальных болей, а не теории. Не меняли роли, поменяли среду и немного сменили процесс. И дали инструменты, не навязывали, а показали выгоду. Использовали все 6 способов влияния.

Затраты – значительные, но не чрезмерные, потому что встроили в существующее: компетенции, 1:1, гильдии, онбординг и так далее – туда добавилась новая тема. А сделали антипаттерны, чек-листы, аттестации, практикумы парного проектирования (создание – человеко-месяц, дальше затраты на проведение) и шаблоны кода.

Как повторить?

1. Одно жизненно-важное изменение

2. Начните с боли, а не теории

3. Минимальный набор изменений

4. Микропрактикум

5. Найдите лидера мнений и привлеките его

6. Встройте в процессы

7. Свяжите с профессиональной ценностью.

Изменения пошли по мере накопления критической массы – в практиках. А началось все в OKR – снизить количество критических инцидентов, антипаттерны – лишь средство достижения.

Круглый стол по ИИ

Круглый стол был структурирован на отдельный такты по вопросам. На нем обменивались мнениями и делились практиками, не было цели выработать мнение и придти к общему решению. На мой взгляд, основная функция – как раз показать, что LLM уже мощно работает, и может не только решать задачи вайбкодинга, но и, например, обучать новичков.

Дальше – тезисное изложение содержания, которое я успел пунктиром записать. Реплики – от разных авторов, и я это не фиксировал. Кроме того, при записи неизбежна интерпретация, а когда я дорабатывал в текст для публикации, интерпретировал еще раз. Съемки не было, но была запись на диктофон, обещали транскрибировать и выложить.

1.     Что можно делегировать ИИ

Два принципиальных подхода: аналитик пишет, ИИ проверяет, или наоборот. Пока вырулить в то, что ИИ пишет, удается плохо. Аналитик ведет интервью, задает контекст, базовые вопросы. И это сильно зависит от опыта, есть кейсы, когда у сеньора получается прояснить ситуацию, а миддл – запутался. Дальше человек пишет документ. Они сравнивали, человек обгоняет Claude, потому что тот опирается на усредненное знание, а человек – на конкретный контекст, а передать в Claude контекст – это как создать документ с результатом. А вот дальше ИИ проверяет результат, это он делает хорошо.

Но это – работа в существующем процессе, а он будет перестраиваться. Так уже было: первые сайты делали из каталогов документов, а первые мобильные приложения – на основе веб, подобно сайтам – и они были ужасны, но постепенно новые практики нарабатывали. Сейчас создают ИИ-натив, новое. Как именно перестроится процесс – неясно, крутимся как умеем и подстраиваемся на ходу.

Я тут отмечу, что и в существующем процессе много точек включения ИИ. Да, начальные интервью – человек. А транскрибация – ИИ. Заготовка концептуального документа – оглавление, тезисы, основное содержание тоже человек. А вот проверить, соотнести с записью интервью, зафиксировать, что упущено и предложить доработки вполне может ИИ. А если помимо 2-3 основных интервью планируется широкий опрос, чтобы увидеть разнообразие практических кейсов, то ИИ может помочь и в подготовке списка вопросов и в обработке результатов.

Когда-то была история: приложение для диспетчеров такси. На входе был ад – громадное количество информации, которая показывала все заказы, и диспетчера плохо успевали в них увидеть те точки, куда надо вмешаться. Сделали чистый экран, где только инциденты. Казалось бы, хорошо, но диспетчеры говорят: нет ощущения, что система работает, не видно динамики. Так и с ИИ: если агенты делают все сами, все равно нужна наблюдаемость. Я с этим согласен, но это не значит, что нужны все детали, наблюдаемость умеют делать через мониторинг – графана и прочее. Правда не все умеют работать через показатели, а не доску задач, но это – старая проблема, ИИ тут интенсифицирует процесс.

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

Генерировать технические решения – можно, но это – длинный текст, который человек не дочитывает, хотя он – хороший. Надо перестраивать процесс.

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

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

И к скорингу резюме это тоже относится, я еще год назад на Merge слушал доклад про ИИ-рекрутера полного цикла – от интервью с руководителем о требованиях и создания описания вакансии до первичного взаимодействия с каждым кандидатом в переписке, а затем скоринга для отбора на собеседование. Так там люди подбирали три разных способа оценки кандидата, и на их основе – итоговую оценку, так – работало. И да, это думать надо.

Вся административная и техническая рутина уходит на ИИ: транскрибирование и резюме интервью и совещаний, выделение решений и формирование задач.

Когда человек начинает работать с ИИ, то есть две проблемы: (а) восприятие конкурента, и в самом вопросе «что могу делегировать» – про конкурента, (б) восприятие как автомата, а там нет автомата. С этим надо работать.

ИИ работает. Два дискавери за две недели, каждое по-старому требовало 160 часов. А в феврале мобильное приложение разработали и вывели в store за 60 часов. Коэффициент ускорения 2-4 раза.

Разобраться с легаси ИИ тоже хорошо помогает. Отмечу, что на Merge я слышал интересный кейс. У человека наработан навык погружения в проект с помощью ИИ. Человек пришел на работу в компанию, где позволен только GigaChat (по безопасности), но тот разборки с проектом не потянул. Зато научил, как развернуть себе на рабочую машину локальный DeepSeek – и тот смог разораться, хотя думал над ответом по 40 минут, в отличие от сетевого. Но в результате за вечер погрузиться получилось, в то время как погружение без ИИ по оценкам из прошлого опыта требовало бы неделю.

2.     Как образовываться, работать с ИИ мидлам и сеньорам.

Хотя новый вопрос был объявлен, часть тезисов относится к предыдущему.

Кейс. Спросили ИИ, чтобы разобраться с легаси. Первый ответ был хороший, по делу. Потом пошли вглубь – и он начал фантазировать, на третьей итерации – стоп. Это – опыт. А как опыт тренировать у новичков? Неясно. Я бы сказал, что так же как раньше: наступаем на грабли, ревью с объяснениями, наставничество, помощь старших. В принципе, ничего не изменилось.

Про работу – метафора. Есть лето, простор. Мы огородили площадку, собираем грибы, пять человек. Вдруг новая технология сбора, теперь это двое делают. Остальные идут вокруг – лес большой, мы раньше просто не могли столько собрать. Так и тут – задач много, хотелки безграничны.

Если говорить про легаси, то ИИ может обвязать легаси тестами, и будет безопасно менять. Раньше обвязка тестами была сильно дороже.

Про сеньорность. Хороший лыжник с некоторой вероятностью станешь биатлонистом- освоение смежных. И теперь ИИ позволяет быть сеньором в большом количестве областей. Развивайтесь, осваивайте их с помощью ИИ. У него сотрудник был миддл-минус, а с за счет ИИ он стал сеньор-минус – он может отвечать за задачу. Но это не само происходит – надо освоить ИИ.

Концентрация на инструменте – вредит, а обучение – вечный вопрос. Есть задача, выписал инструменты, в их числе ИИ, который нужен не всегда. И делаешь. И open claude – можно скилы под себя настраивать и это – мейнстрим. Инструмент свежий, и появляются короткие курсы.

Эксперт – тот, кто продолжает спорить ИИ. Надо подняться. Захватить контекст и процесс. Управление – на себя, а реализация – на LLM. B надо расширять рамки, перенастраивать.

Ольга Подолина. ИИ в сельском хозяйстве ставят на тракторы – автоводители, Россия тут впереди многих стран. И надо придумывать новое.

Ирина Гертовская. В 60-х такие машины работали на горнорудных фабриках. И это не новое. ИТ сейчас везде. И его становится больше, надо быть на фронтире.

Не надо учиться писать доку. Аналитик был спецом, который видел общую картинку, и с ней работал. Прокачка – умение видеть картинку, спроектировать новое, джобами и смыслами. Профессия становится сложной. Нужны софты. Задачу плохо ставят, ее надо переварить.

Есть разные сеньоры. Бывают, что человек 5 лет на одном проекте, набрает опыт, который с ним связан, и дают сеньора, потому что надо поднимать зарплату. Или ты успешно освоил процессы компании. И это не значит, что в другой компании или другом проекте ты тоже будешь сеньором. Надо взглянуть на себя, свои компетенции, и переоценить – это может быть больно. С другой стороны, мидлы бывают недооцененные, у них перспективы.

3.     Обучение джунов.

Татьяна Половинкина. Потребность в джунах уменьшается, хотят мидлов с ИИ, которые на следующий день станут сеньорами. Но это – в короткую. Мы берем джунов с дальним прицелом, и у них наставничество для джунов, и они его активно переводят на ИИ. У них есть DWH-ментор. Но некоторые менти говорят: ваш ментор сюсюкает, я его переделал, мне жесткий нужен. Ннужны джуны, которые смогут управлять системой. Есть процесс, который выковыривает таких людей и учит их.

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

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

Реплика. Вы говорите об идеальном джуне. А как обучить, чтобы он мог это сделать? Ответы. Как начинал я: мне дали проект и отправили делать. И сделал. А еще наши дети сами обучались пользоваться мобилками. И сами научатся ИИ.

Реплика. Компетенции меняются, через пять лет будет нейроинтерфейс.

Делать обучение надо самим, университеты не смогут обучать, они на такую быструю смену программ не ориентированы.

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

Реплика. Черчение в университете руками, а не в автокаде – чтобы развить пространственное мышление. Ответ. А Демокрит думал, что письменность убьет мышление – они не будут запоминать, а будут читать.

Татьяна Половинкина. Уже сейчас ИИ учит джунов. Не когда-нибудь. Виртуальный DWH-ментор.

Есть разные джуны. Есть талантливые, которые за несколько месяцев становятся как архитекторы. А он не хочет – надо погрузиться.

Вопрос. Про HR. Мы меняем навыки компетенций. А потом они сталкиваются с нашими HR – и что? А это проблемы HR.

Новые позиции: архитектор контекста, управляющим процессом devops.

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

Осознанность надо иметь. Но еще кругозор – он не всегда есть. И бывает ребята после ВУЗа – не понимают область. И выстраивание процесса, чтобы они могли расти и выстраиваться.

Татьяна Половинкина. DMBOK-рулетка: Архитектура данных на выживание

Это был очень интересный workshop чтобы почувствовать, как работает pipeline DWH. D оригинале он в электронной форме, но на второй день на площадках не было интернета (только через WiFi в основном здании). Поэтому был собран процесс из людей и движущихся бумажек.

(CRM, ERP, Log) → Streaming → Raw → ODS → DDS → (Mart → User)xN

• ODS – трансформация

• DDS – хранение данных со всей историей изменений и версий

• Mart – витрина

• MDM – отдельно встроен, он делает золотую запись. И она пополняется отдельно от основного потока, а в потоке она фильтрует и идет соответствие.

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

На этом я завершаю свой отчет.