Просмотр исходного текста страницы Блог:Максима Цепкова/2026-07-09: Saint Teamlead-2026: ИИ-агенты меняют индустрию разработки

{{Conf-Ref}}
На хабре опубликован мой [https://habr.com/ru/companies/oleg-bunin/articles/1057164/ '''отчет с Teamlead в Питере'''].  Как я писал по горячим следам, на конференции было крутое визионерское выступление Авенира Воронова, и еще ряд интересных выступлений с конкретными кейсами ИИ. Как я писал, на мой взгляд трек ИИ на Teamlead оказался круче, чем на Highload. Так что ловите отчет с конспектами!

----
 Дублирую статью на свой сайт

Сразу после Saint Highload прошла [https://teamleadconf.ru/spb/2026/schedule '''Saint Teamlead Conf'''] – четыре трека, из них один – мастер-классы, а на других помимо выступлений было несколько круглых столов. И основной темой тоже было применение ИИ. При этом, на мой взгляд, в выступлениях по ИИ было больше конкретики и меньше анонсов светлого будущего, когда разработку в больших корпорациях будет вести исключительно ИИ. А еще второй день принес прекрасное визионерское выступление '''Авенира Воронова''', собственно, оно заставило меня сразу после окончания, по свежим следам опубликовать пост, в котором я фиксировал общие впечатления о конференции. С него я и начну этот отчет, а затем – перейду к конспектам отдельных выступлений. Начну я с выступлений про ИИ, а затем будет остальное. Сразу отмечу, что часть слотов я пропустил, занимаясь нетворкингом, да и в целом на конференции было четыре трека, а я мог быть только на одном, так что конспект не полон.

== Общие впечатления ==

Второй день #Teamlead принес крутое визионерское выступление '''Авенира Воронова'''. Два тезиса. '''Первое''': ускорение разработки в 10 раз обнуляет нынешнюю систему планирования и управления через задачи. Потому что, когда проверка гипотезы теперь занимает день-два, вместо двух месяцев, то традиционный бэклог на квартал или год исчезает: ведь каждая гипотеза приносит новую информацию, и там получается точка ветвления. Вместо списков задач управление будет идти через стримы активностей с целевыми векторами и оперативным маневром внутри. Как следствие, это обнуляет существующую систему метрик. Зато вайбкодинг позволяет сделать специальные метрики под каждую гипотезу, что ранее было недоступно. Но в целом управление гибридной командой людей и ИИ-агентов нужно строить совершенно иначе, чем мы привыкли.

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

'''И это – реальность, которая уже пришла''', компания Авенира делает тулы, которые это все обеспечивают.

Замечу, что это перекликается с совершенно неожиданным выступлением '''Юлдуз Фаттаховой''' и '''Андрея Березина''' из Сбера об изменении ответственности продукта и техлида с приходом ИИ. Юлдуз говорила, что вайбкодинг позволяет продуктам быстро проверить гипотезы, не обращаясь к команде разработке и запускать только перспективные. Но команда разработки при этом вместо привычных задач получает на вход результаты этого вайбкодинга. А еще в их выступлении был разобран кейс встройки ИИ в продукты: создание в существующем продукте анализа данных ИИ-помощника, чтобы вести анализ могли не только технари, разбирающиеся в запросах, но и другие пользователи. Такая встройка порождает совершенно новые задачи по подбору моделей, обеспечению и тестированию качества и времени ответа от такого помощника и так далее.

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

В целом трек ИИ на Teamlead был, на мой взгляд, сильнее, чем на Highload. Больше конкретики, сделанных проектов, и меньше рассуждений о том, как «космические корабли будут бороздить просторы Большого театра». Я тут хочу отметить выступление '''Марка Быстрова''' из ЦИАН о ИИ-конвейере, который обеспечивает гарантированное переписывание сервисов на другой техстек – с pyhton на C# или обратно. На первом такте там анализ сервиса и его тестов, проверка достаточности описания контракта и покрытия тестами, затем – написание дополнительных тестов на тонкие места, чувствительные к смене стеков, поэтапный перенос и тестирование. Люди – есть, они анализируют проблемы и дорабатывают настройки конвейера. Через конвейер они успешно пропустили несколько сервисов, и не получили ни одного отката на проде. ИИ за несколько месяцев с присмотром пары инженеров с неполной занятостью в этом проекте успешно сделал работы, которые по оценкам требовали пары лет работы команды.

Смене мышления, которое влечет ИИ, был посвящено и выступление '''Александра Зизы''', но его фокусом было следующая из прихода ИИ необходимость самоопределения. Еще были интересные выступления '''Алексея Пронского''' про использование ИИ-агентов для работы с архитектурой, '''Андрея Сотника и Родиона Лунева''' из X5 про эксперимент по разработке нового проекта на ИИ с реальными метриками, '''Владимира Гриненко''', '''Дарины Коршуновой''', Екатерины Боголеповой и других – я слушал не все выступления про ИИ.

Естественно, на конференции были выступления не только про ИИ. Я хочу отметить выступление '''Александра Алазиди''' о том, как сделать, чтобы платформенная команда была ускорителем, а не барьером.

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

== Авенир Воронов. AI-копилоты управления разработкой ==

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

'''Текущая ситуация'''. Генерация кода и документации превышает предыдущие скорости. Постановка задач стала бутылочном горлом. Метрики старого поколения – запаздывают. Тулинг – громоздкий: jira, project и другое планирование проектов – не успевают. И скорость реагирования бизнеса возросла.

Jira. Она передает задачу исполнителю, что там внутри – знают те, кто рядом, например, ревьюер. У исполнителя еще дискавери и многое другое, и все это – внутри тикета и скрыто. '''Сейчас можно заглянуть и посмотреть, что делают люди внутри'''.

'''Эпоха smart заканчивается'''. То, что меряли раньше – преобразуется. Вайбкодинг не только ускоряет разработку, но и ведет нас к вселенной, где для задачи можно сделать ad hoc-инструмент.

Smart-тикеты канут в лету. У нас был годовой план, кварталы, есть проекты, все это разбивают на задачи, дальше эпики, стори, таски и так далее. В тикетах acceptance, дедлайны, майлстоуны. И все это работало медленно, поэтому в таком планировании был смысл.

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

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

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

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

Новый способ постановки задач.

# Цель – бизнеса или техническая
# Контекст – не сузить задачу, а передать все необходимое для решения.
# Ограничения – что менять нельзя: безопасность, юристы, бизнес, code style…
# Критерий готовности – как понять, что задача выполнена? Авторизация – значит логин прошел и что-то дальше открылось, а не просто вылезло окно логина и приняло ввод.
# Артефакт результата, он может быть разным: код, PR, тесты, отчеты, план, список рисков.
# Риски и зависимости – что может помешать. Амазон обвалил облако в Аргентине, потому что пустил агента на прод.
# Приемка – кто и по каким признакам принимает результат.

SMART не дает агентам рамки поведения, а у агентов нет здравого смысла, нет формализации критериев приемки, задачи ставятся по-другому, через цели и ограничения.

'''Как контролировать задачи?''' Была работа на тестировщиках через чат-окно, мы закладывали туда скилы и вынимали чат-логи, смотрели на мониторинге, дальше они на основе этого делали видение или задачи. Особенно безопасники – закидывают агентов-проверяльщиков. Правила, скиллы и прочее, например, правила безопасности или 152-ФЗ, культурный код компании и так далее. Коммуникации и контроль через чаты.

Когда процесс ускорился в 10 раз – управлять надо по-другому. Но теперь вы много знаете про работу разработчика, чем он реально занимается, стиль коммуникации, потенциальную совместимость с другими командами.

'''Как мерить?''' Анализ логов, когнитивная нагрузка, sentiment (психологические скачки) в реальном времени, ROI по ИИ доказуемо.

ROI по ИИ – 9 метрик: частота использования, качество решений ИИ, выполнение по задачам. Если человек запустил 10 агентов – это что в часах? Это можно переводить в деньги. NPS, реальное распределение времени, выявление чемпионов и реальные компетенции.

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

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

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

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

Вопросы, на которые нет ответов.

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

Они уже предлагают миксовать команды.

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

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

Таски – в прошлом, метрики – новые, и тулы тоже на лету. B это – только начало, уже сейчас LLM запекают в железо от google – есть окно, софт рождается мгновенно.

'''Вопрос'''. Смарт-тикеты – способ систематизировать мыли, а что дальше? '''Ответ'''. Когда только заходили в управление, то цели-результаты были по-другому – работа через стримы, это не конечные цепочки – по продажам, по масштабированию, по клиентскому успеху – они измеримы. Надо систематизировать иначе. Все, кто пользуется агентами, пытаются загнать в pmbok, разработчики – по архитектуре, и это не работает, идет разрушение.

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

'''Вопрос'''. А метрики психологического состояния и подобные – насколько объективны? Модели выдают приятное. '''Ответ'''. У модели есть разные характеры, у LLM-судей выбирают, как они должны общаться, они выдают разный скоринг, мы их сопоставляем, и разделяем объективность модели и метрики.

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

== Марк Быстров из ЦИАН. 28 промптов спустя: как claude code довел миграцию до прода ==

Замечательный рассказ о том, как была построен ИИ-конвейер для переноса сервисов между разными техстеками. Перенос проводили для выравнивания стеков внутри функциональных областей, поддерживаемых одной командой, поэтому одни сервисы переносили с python на C#, а другие – в противоположном направлении. И это все – '''в критичной области''', Марк работает в юните монетизации, где 125 команд обеспечивают разработку биллинга и платных механик.

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

Что входит в процесс? Первый шаг – '''оценка возможности переноса: не всякий сервис годится.''' Этот выполняется с участием людей. Вот критерии.

* Бизнес-логика не размазана по 10+ интеграций. Проводится анализ связей по монитору.
* Команда должна выигрывать по миграции – экспертиза, онбординг
* Должно быть покрытие функциональными тестами. Если его нет – то сначала надо сделать. '''Без тестов миграция – не ускорение, а перенос багов'''. При этом у них тесты изолированы от сервиса, так что они могут проверять сервис на любом стеке.<br />

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

Если сервис не прошел фильтр, то его можно привести к мигрируемому виду: покрыть тестами, разнести данные и так далее, это – отдельная работа. А мервисы на монолитной БД ждут завершения распила монолита.

Маленькие сервисы переписывают врйчную, у конвейера есть стоимость входа: если в сервисе 64 end point, то она размазывается, а на 2-3 end point лучше вручную, но примерно по тому же процессу.

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

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

Агенту нельзя сказать «перепиши на C#», надо задать архитектурные шаблоны, соответствующие стеку. Иначе агент просто возьмет шаблоны исходного стека, и получится код на C# в стиле python. Поэтому агент берет пустой шаблон для нового стека, и переносит в него конфиги и структуру БД.

Опыт дал им важный принцип: '''улучшаем код, а не промпты'''! Рядом с проектом лежит папка с хорошим кодом и SDK – агент лучше вычленяет образцы из кода, а не слов.

Покрытие тестами. Их покрывали тем, что важно для функцинала, а вот тонкие различия поведения, связанные с типами данных обычно не тестировали. Поэтому агенты дописывают тесты на те моменты, которые различаются в стеках: типы данных, различие null-none и так далее.

Тесты проверяют функционал сервиса изолировано, а при переносе надо сложнее. Есть различия с именами локальных очередей – разная у C# и Python, и это препятствует раскатке и совместной работе, поэтому тут отдельная проверка для агента. Могут измениться имена метрик, и тогда ты не узнаешь проблемы с нефункциональными требвоаниями по алертам. Был кейс, когда агент не перенес кэш – ведь и так все работает, на это тоже добавили чек-лист.

Детерминированные правила для кода – оформление SQL и тому подобное выносим в linter, и агент гоняет код через него. Потому что правила в LLM он может игнорировать, а сообщения linter – нет.

В результате получился набор skills – инструкций под разные задачи.

* '''Prepare''' – инвентаризация end point: оценивает сложности, трассирует цепочки вызовов, смотрит покрытие тестов и достраивает тесты, там, где не хватает.
* '''Translate''' – микросервисы на целевом стеке по шаблонам. Для начала копирует функциональные тесты, потом переводит endpoint по одному, от простого к сложному, простые дают работающий скелет. '''Каждый endpoint – отдельная ветка'''. Идет контроль что тесты работают правильно: проходит по тем end point, которые перенесли и падают на тех, что не перенесли.
* '''Review''' – проверка новой реализации, сопоставление со старым исходником – это те ошибки, которые не нашли тесты. Там 2-3 прохода, одного мало. Правила ревью двух видов: детерминированные и требующие суждения. Детерминированное выносим в linter, а не в skill: не отдавай агенту то, что инструмент сделает надежнее.

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

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

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

Один инцидент на проде все-таки поймали, но быстро исправили без отката. Перенесли сервис и iOS приложение начало падать на одной из ручек. Проверяют контракт, выяснилось, что iOS отсылало не int, а строку, при этом С# неявно приводил к целому, а python падал с ошибкой. Контракт формально одинаковый, а чека в run-time не было. А корневая проблема в том, что клиент iOS был не сгенерирован, а написан вручную. Теперь это в чек-листе.

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

Без инструмента миграция заняла бы годы – это обоснование. Использовали Claude, но если будут проблемы – перейдут на Codex или локальных агентов, тут они проблемы не видят. Да, стоимость токенов может расти, сейчас в подписки за 200$ ты получаешь токенов на 2000$ и более. Именно поэтому сейчас локальный Qwen не окупается, но он становится лучше, а если подорожает, то будут его использовать.

== Алексей Пронский из Билайн. Выводим Architecture as Code на новый уровень с помощью Claude Code ==

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

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

ИИ может делать '''дизайн-документ''', который может называться по-разному: архитектурное решение, Solution Architecture Document и так далее, и который согласуется с ИБ и смежниками. Содержание: архитектурные схемы, бизнес-контекст, инфопотоки, ФТ и НФТ, безопасность. Это уже внедрено в БКС в 5 команд, у каждой из которых свой solution architect, обычно техлид или системный архитектор.

Как было: на входе BPMN на 60 шагов, по ним делаем требования, пишем документ, отправляем согласовывать – и прилетает 60 замечаний о том, что неверно заполнены поля. Они сменили подход: Architecture as Code – описываем архитектуру формально, и проверяем, а диаграммы порождаются автоматом. Инструмент – '''Structurizr''', его развивает создатель '''C4-model'''. Там описание системы и связи, схема создается по dsl-коду, дальше можно вручную двигать элементы, если надо, но часто хороший вариант из коробки.

'''Получили единый источник правды'''. Было у каждого решения свои диаграммы и диаграмма ландшафта, все устаревало. Они описывают, и архитектура ландшафта – автоматом. Все описание – в git.

В описании – системная диаграмма и диаграмма потоков, отличающаяся стрелочками, и надо уметь помечать старое-новое. В Structurizr ты помечаешь связи тегами и выводить несколько диаграмм из одного кода. Structurizr может закинуть в любое приложение – miro и другие.

Подход обеспечивает валидацию, экспорт диаграмм, аналитику, проверки ИБ (например, что все – через proxy), алерты архитектору по дрифту архитектуры, проверки по инфраструктуре.

Есть проблема: в draw.io нарисовать модель на 10 систем – 20 минут, а написать в dsl – около часа. При этом архитектор мыслит визуально, а ему приходится писать код. Но LLM понимает картинки, можно нарисовать, обсудить и согласовать эскиз, закинуть в LLM и получить описание. LLM пишет на любых языках, включая Structurizr – для нее это упрощение, по сравнению с диаграммами.

Автоматизация работы с архитектурой раньше была скриптами. А теперь на уровне смыслов и целей. Например, речевая аналитика – анализ диалогов поддержки. И так же в архитектуре: проверь соответствие ИБ, сравни с бизнес-требованиям и так далее. '''Написали 65 скилов''': ревью документов, merge, экспорт в SVG и т.д.

'''Основной процесс''': на входе md требований и BPMN процесса, на выходе – Structurizr svg диаграмм и черновик решения. Фазы процесса. (1) Контекст – требования и BPMN добавляет текущие файлы. (2) Уточняющие вопросы – куда встроить сервис, где БД, протоколы интеграции – в контексте этого часто не хватает. (3) Генерация документа. (4) Валидация и экспорт в SVG – без нее треть dsl получается не валидным, поэтому агент поднимает в докере structurizr lite и добивается устранения ошибок. (5) Результат – черновик архитектуры.

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

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

Есть технические проблемы. Workspace.json – хрупкий артефакт, возникают конфликты по merge. Написали скилд, но помогает не всегда.

В результате анализ требований сократился с трех дней до двух, создание диаграмм и решения – от нескольких дней до нескольких часов, а согласование правок – с 5-8 дней до 3-4. Итого полный цикл с 2-3 недель уменьшился до недели.

Он перешел несколько месяцев назад в Билайн – и туда принес этот подход. Там Acritecture As Code сейчас внедряется. В Билайн Bi Atlas и публикация архитектуры через пайплайн, в нем проверки: фитнес функции, паттерны и антипаттерны и техрадар, и дальше комплексные проверки. '''И вместо архитектурного комитета получается автомат'''. Но заполнение dsl усложняется – много обязательных полей. И есть плугин для vscode для заполнения – он открытый. И LLM все равно полезно – порождать DSL-код, и выполнять проверки И не все требования влазят в архитектурный пайплайн, часть – в локальных инструкциях, их можно превратить в скилы.

И все это залито на github, в презентации есть QR-код – '''можно использовать'''. Но надо согласовать с безопасниками. Три варианта: локальные модели, ручная очистка Structurizr, очистка Structurizr на прокси.

Из вопросов.

* В БКС пробовали в dochub. Если большая картинка – mcp чтобы вытягивать контекст в LLM.
* Codex пробовали в последнее время, можно доработать. OnPrem – хуже, особенно слабые.
* Для сокращения токенов – заранее описывали типовые ошибки, это сразу направляет агента по правильному пути.
* Если описания еще нет – сделать Structurizr, LLM – поможет.
* У безопасников – свои LLM-агенты, которые первично проверяют то, что прислали на согласование.

== Владимир Гриненко. От хайпа к культуре: нанимаем ИИ в компанию ==

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

Вот шаги.

* Первое – '''дружим нейронку с ИБ''', объясняем: нейронки неизбежны, данных к проду разработка не имеет, мы сделаем прокси наружу со всеми логами – вы сможете вести анализ и мониторинг, для закрытых данных будут репозитории с локальными нейронками и так далее.
* '''Продать лидам!''' Обнаружить их, и починить скепсис там, где он есть.
* Найти или сделать ИИ-лида, который разбирается в ИИ, знает SDD, делает агентский пайплайн и инструкции по нему, готов посмотреть качество и починить его, готов помочь командам. Это все – компетенции руководителя, просто ИИ-лид применяет их не к людям, а к агентам.
* '''Принесите командам токенов''', если не безлимит, то квоты, например, внутренний безлимит и внешние.
* Полезен бюджет на премии тем, кто уже повнедрял – только надо смотреть на результат, а не на сожженные токены.
* Встройте в онбординг. Тем попробовал – очевидно, что нейронку можно спросить про взаимодействие с ней, а новых надо научить, что так можно.
* Регулярные встречи по достижениям и проблемам, и парное программирование с публикацией логов.<br />

* Важно не только порождать код, но и обустраивать другие процессы: ревью кода, тестирование, выкатка. Там много рутинных работ, которые можно превратить скилы. Это не сложно, но люди привыкли делать руками. '''Садимся рядом с человеком, спрашиваем, как он работает, пробуем сделать скил, не работает, докручиваем'''.
* '''DoD'''. Если команда сработалась, то часто небольшой заголовок в задаче – и всем понятно, что должно быть в результате. Нейронке этого недостаточно, нужен DoD. Но, неожиданно, если его написать, то и люди лучше работают, делают что нужно.
* У них в нейронки побежали все команды, в результате получили mcp ко всем сервисам и логам, и агенты помогают по инцидентам.
* Метрики. Нельзя вычленить вклад нейронок на фоне параллельных изменений. Но скорость производства, покрытия тестами, скорость влития в команды, инциденты на продакшн и скорость их устранения и так далее – надо за ними смотреть, что не стало хуже.

'''Изменения в культуре'''.

* Команды – меньше
* Коммуникации – короче
* Контекст – прозрачнее.
* Все договоренности – зафиксированы – чтобы нейронки их читали. Нейронки могут помочь слушать и транскрибировать
* Циклы – быстрее
* Ответственность – на разработчиках

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

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

AI product engineer – понимает бизнес и продукт и управляет агентами. На мой взгляд, это старый IT-any-key, только с нейронками.

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

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

== Дарина Коршунова. Гибридный интеллект: эволюция команды для выживания в эпоху ИИ ==

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

Дарина – владелец продукта «Центр управления магазинами» в Magnit Tech. Команда крепких мидлов с одним сеньором внедряли ИИ. И странное происходит: забыл, когда спорили об архитектуре за чашкой кофе. Еще недавно – спорили, а тут – перестали, даже если дичь предлагаешь (она пробовала) – кивают или молчат. '''Команда перестает быть командой, становится просто исполнителями'''. Причина – когда внедрили ИИ в работу – внедрили еще одного участника: молчаливого, услужливого и быстрого. И это изменило отношения.

Три симптома, которые разрушают команду больше, чем неудачный релиз.

* Сеньор-разработчик, 15 лет опыта, гордится чистым кодом и реальный спец. Но сегодня он полдня проверяет код за ИИ. Кто он теперь? '''Кризис идентичности''': кто я теперь, какова у меня роль?
* ИИ предложил решение, разработчик поддержал, принял решение, вывел в прод, прод упал – кто виноват? Команда существует там, где есть ответственность каждого участника. '''Кризис ответственности''': что я решаю, за что отвечаю?
* Джуны учатся у сеньора писать код. А сейчас сеньор пишет с ИИ. И у кого учиться джуну? '''Кризис развития''' – теряем цепочку профессионального развития: как джуну расти, как и у кого учиться?

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

Фильм Матрица – красная и синяя таблетки. Красная – человеческий интеллект: контент, этика, ответственность. Синяя: скорость, память, паттерны. На пересечении – фиолетовая таблетка.

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

Матрица 2x2 гибридного интеллекта. Делегирование от ручного контроля к автономии ИИ против взаимодействия от изоляции к синергии (с ИИ?). Изоляция с ручным контролем – ручное управление. Изоляция с автономным ИИ – конвейер. Синергия и ручной контроль ИИ – параллельные миры, команда выгорит по одиночке. Высокая автономия ИИ и синергия с ним – гибридный интеллект. У меня к такой схеме есть вопросы к осям, надо аккуратнее посмотреть на их содержание, основной вопрос – ось взаимодействия про членов команды или взаимодействие сотрудника с ИИ, мне кажется, это напутано. Но идея понятна.

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

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

'''Новые ритуалы''': промпт-ревью, сессия синтеза, контекст-чекинг.

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

Роли задают фокус, ритуалы – процесс, а распределение функций даст содержание работы.

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

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

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

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

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

Дальше – вопросы.

* '''Вопрос'''. А если ИИ часть команды – то не сбросят ответственность? '''Ответ''': нет, наоборот, это как джун.
* '''Вопрос'''. А ИИ генерит много кода – там будет громадная проверка, время сеньора. '''Ответ'''. Надо сеньора разгрузить, надо ротировать роли, пусть джуны учатся. Ошибки – опыт, мы не стали лучше, мы стали быстрее – есть помощник. Нагрузка на сеньора будет меньше, а сейчас – больше, генерит и проверяем. А мы выделяем функцию, и ее передаем, и тогда меньше. Налаживание процесса.
* '''Вопрос'''. А если сеньору нравится писать код? '''Ответ'''. Он может продолжать писать код, а лет через пять встретимся, посмотрим.
* '''Вопрос'''. А вдруг сеньоры деградируют. '''Ответ'''. У нас много легаси, сеньоры – хранители, надо выводить в контекст.
* '''Вопрос'''. Раньше 15 коммитов – молодец, придумал архитектуру – красавчег. А сейчас claude – быстрее. Он сменил парадигму: мы красавчики, когда докатываем фичи до кода, и люди это мотивирует, и бизнес рад. И нет цели обязательно писать с помощью ИИ. Не думали ли в эту сторону? '''Ответ'''. Хорошее предложение. И да, надо приземлять на процесс. И мы должны предлагать бизнесу решения, а не просто исполнять.

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

== Юлдуз Фаттахова и Андрей Березин из Сбер. О дивный новый мир: как PO и TL переопределяют зоны ответственности в эпоху ИИ ==

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

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

Интересно, что Юлдуз и Андрей – из Сбера, от которого на Highload было выступление про административное внедрение тотального использования ИИ для полного автомата исполнения (смотри [https://habr.com/ru/companies/oleg-bunin/articles/1053550/ мой отчет]). А в этом выступлении – совершенно иной залог, рассказ про эволюционные изменения, которые ведут к практическим результатам.

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

CPO руководит продуктами, а CTO – техлидами. Продукты внутренние и технические – обработка данных, аналитика и так далее. Есть проблема к входными коммуникациями: дай доступ на S3 – технический вопрос, но реально мы пускаем. Request – нужно техническое мнение, фича против техдолга. Стоимость системы и тарифы – кто управляет, есть внутренние цены. И кто берет обязательство перед внешними контрагентами. А еще – оценка вклада продукта и техлида.

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

Как было до ИИ? Они создали матрицу компетенций (по сути – разделения ответственности).

* За все внешнее отвечают продукты, техлиды – отвечают за технических вопросы, поэтому внешний запрос идет продукту, а дальше есть фильтр техлида.
* Планы развития – продукт, и он же делает дорожные карты, техлид согласует.
* Финансы, тарифы и юнит – продукт, но техлид требует резурсы – gpu, cpu.
* Целеполагание и DoD (критерии приемки) – продукт.

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

Кейс: ИИ-помощник для BI. Есть платформа, которая анализирует диалоги с пользователями, 30 млн первичных событий, из них собирают витрины с метриками. Порог входа, чтобы делать свои запросы и витрины – большой, появилась идея: снизить порог входа за счет помощника.

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

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

Приняли, что AI-first-native надо делать. Порог входа должен быть ниже: мы спрашиваем ИИ, а не ищем в инете, и ожидаем того же от продуктов.

* '''Продукт отвечает за UX-эффект''' – как пользователь взаимодействует с ИИ-ассистентом. Измерение успеха – хорошо ли он отвечает, какой порог входа, и это нетривиально, так как результат – график. Критерии успешности пилота, готовность к бете, к публичному показу, бюджет.
* '''Техлид'''. Какую модель используем, какой latency от модели. Если внешняя – то ее источники. И взаимодействие – RAG или Lora. Кто готовит данные? Как мониторить и трейсить?
* '''Совместно''': сколько будет стоить, хотя бы на полгода, сопутствующие риски – вендор-лок, джейлбрейки, baseline качества релиза и раскатки, баланс развития продукта и стоимости разработки, инфраструктуры и поддержки: продукт не должен стать убыточным из-за добавления ИИ.

'''Принцип'''. Минимальные инвестиции в прототип, используем время, зарезервированное для экспериментов, и ресурсы и модели с других задач. Дальше – пилот на малую группу и при успехе, что пользователи начали пользоваться, а не поиграли – раскатываем.

Появилась задача: научиться управлять не детерминированными системами: модели дают непредсказуемость. Впрочем, отмечу, что такие задачи уже были, например, обеспечить производительность БД или системы в целом под нагрузкой или с ростом объема данных.

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

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

Для продуктов – новые вызовы и возможности. '''Не надо идти к инженерам делать прототип – можно сделать самим и придти к команде с проверенной гипотезой'''. Исследования сильно ускорились, легче отделять важное от шума за счет прототипов. Но продуктов надо этому научить, они становятся командой технических продуктов. Метрики, оценка качества модели – это все вопросы продуктов. И важно держать баланс между маркетингом (используем ИИ) и реальным бизнес-эффектом. И понимать риски – персональные данные, зависимость от модели и так далее.

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

К ответственности добавили жизненный цикл фич – мониторинг произвдительности модели и тестирование. Требование к данным для ИИ – риски, ограничения и value, ETL-процессы и так далее. Безопасность – что нельзя в публичные и реализация изоляции модели и хранилища данных. И метрики.

'''С чего начать, если вы решите пойти по этому пути?'''

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

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

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

Как запланировать фичу, если окно возможностей короткое? Переприоритизируем.

Добавление фич ведет к инцидентам и CTO должен планировать решения. Решением может быть ИИ-агент разбора инцидентов.

'''Стоимость входа – небольшая''', можно развернуть Qwen на одном GPU 10к рублей аренды, и делать прототипы. Так что прототипы можно делать дешево. А дальше уже считаешь экономику, она может быть разной.

== Надежда Погина. От хаоса к системе: как Блок СТО за полгода построил AI-first команду на ошибках и времени ==

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

Блок CTO – инфраструктура 300+ человек, внутренние информационные технологии cloud.ru. Задача – не просто начать использовать ИИ, а построить ai-first. Боли с ИИ – как везде: сотрудники порождают десятки идей, до реализации – единицы; сотрудники хотят попробовать, но нет времени; есть скепсис к ИИ: ошибки и низкое качество отклика.

Методы решения: диагностика-мониторинг, скоринг идей, внутреннее обучение и фабрика экспертов (внешнее – дорого), сообщество и культура – создание среды.

'''Регулярные встречи по ИИ каждые 2 недели''' (86% участвовали), разбор удачных и неудачных кейсов, приглашение внешних экспертов, самостоятельная разработка курсов для обучения, сделанная ошибка – топливо роста.

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

'''1. Диагностика и замеры – опросы.'''

Уровень самооценки, регулярность использования ИИ, барьеры (знания, время, безопасность, качество), желаемые формат обучения, примеры неудач (анонимно). В презентации QR-код с опросом и реальными результатами до и после. Изменения: использование 72 → 84, я-новичков 39 → 15 (люди стали оценивать себя как более опытных), уровень знаний 2 → 3, эффективность 67% → 84% (оценка сотрудников по опросу).

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

'''2. Скоринг проектов''': техническая реализуемость, бизнес-ценность, риски (безопасность и зависимостьот api), сроки.

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

'''Проекты, которыми гордятся''': анализатор CQR (анализ плана работ для согласования), Help desk ассистент, Гипович (ИИ для инженера), и еще пара.

Модель может давать результат 6/10 на старте, это нормально. Дальше доводим, валидация и ручной аудит. Нужны входные данные – им потребовалось около 4 месяцев для описания процессов на приемлемом модели уровня.

'''3. Сообщество и среда'''.

* Регулярные встречи без записей: хотите быть в курсе – приходите.
* Прозрачность: публичный блок проектов, классификатор.
* Безопасная среда – чтобы авторы не боялись обсуждения идей, приносили их.
* Карьерный трек.
* Готовые рецепты – шаблоны, промпты, чек-листы как база для агентов.

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

'''4. Информация''': Дайджест AI inside СТО – там набор рубрик, это достаточно трудоемко, но стоит того.

'''5. Чек-лист типовых ошибок''': на следуйте трендовым новинкам, оценивайте качество данных, не ожидайте 100% надежности с первого дня.

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

'''Все начинается с людей'''. Недостаточно дать инструмент и понукать «переходим на ИИ». '''Нужна среда и сообщество, чтобы любопытство их вело'''.

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

'''Вовлечение – на энтузиазме''', только после виртуальной команды пошло организационное оформление. Но СТО, у которого большой авторитет в компании – драйвил тему.

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

== Андрей Сотник и Родион Лунев из X5-tech. AI-помощник. Как эксперимент вышел из-под контроля ==

'''Это рассказ про quick success использования ИИ: люди взяли новый проект и быстро его сделали'''. Успешно по скорости: за две недели закончились задачи, которые брали на три месяца, ускорение на новых проектах оцениваются '''в 5-20 раз'''. По качеству тоже неплохо, но этот фактор они недооценили: надо было больше вкладываться в качество тестов, а не просто в покрытие ими. В следующий раз учтут. Конечно, из-за высокого темпа срезали углы, но после исчерпания задач они с помощью ИИ восстановили контекст проекта и разгребли технический долг. В результате '''новые проекты запускают только с помощью ИИ'''. В существующих – сложнее, там много контекста и легаси-кода, но '''команды вдохновлены на использование ИИ'''. Собственно, в этом и есть смысл quick success, который является важной частью методологии внедрения новых технологий.

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

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

Как идет исполнение? Агент оценивает сложность задачи, в зависимости от нее выбирается способ решения: simple делают в одно окно, medium – агенты в цепочке, complex решают много агентов. Оркестратор делает план, показывает, спрашивает «выполнять?». . Когда база готова – идет генерация фичи, и параллельно тесты. До 4 агентов параллельно, если больше – оркестратор может захлебнуться.

Дальше – quality gate в хуках. Когда агент пытается завершить – линтеры, форматеры и так далее. Ошибки – назад оркестратору и дальше обратываются. Ревью – несколько агентов со своими правилами.

Потом smoky end-2-end тесты. Специальный агент проверяет тесты – но это если были изменения верстки. Если были баги, которые не исправили – отдельный агент разбирается и документирует багу. Важно не откладывать баги на потом, иначе плохой код послужит образцом для нового кода.

Цикл зеленый – фича готова к ревью.

За две недели эксперимента кончились задачи, которые брали на три месяца.

Проблемы, в основном технические – обход блокировок. А еще смежные команды не успевали.

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

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

Результат: 99% кода ИИ, высокое покрытие тестов и высокий брак. Они выбрали скорость, а не качество – не оценили ресурс QA, не проработали генерацию качественных тестов, агенты создавали тесты, но качество их оказалось недостаточным.

А вот безопасный пайплайн – сборка, проверка тестами, статический и динамический анализатор на уязвимости был сделан.

Получено явное ускорение, на слайде были конкретные цифры.

Выводы из эксперимента.

* Человек без опыта разработки сможет сделать прототип, а дальше будет стена – тесты, интеграция, мониторинг – ИИ не закрывает. А разработчик, понимающий инструменты – пойдет дальше, он может сломать эту стену.
* Максимальное ускорение – на системе с нуля, когда жертвуем анализом, '''ускорение 5-20 раз'''. Остальное – понятное. Внешние модели требуют изолированного поднятия бэка и фронта на ноуте разработчика.
* На потоке существующих проектов – '''в 2-3 раза быстрее'''. Другие команды тоже подключаются.
* ИИ часто ошибается, '''надо делать harness, но он устаревает''': оркестрация требовалась 2-3 месяца назад, а сейчас не нужна – агенты из коробки работают.
* Фронт 2-3 раза дороже бэка по токенам.

В презентации есть шпаргалка, как действовать.

== Александр Зиза. Что ты от меня хочешь? ==

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

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

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

Сейчас все корпорации побежали к ИИ-агентам, и Гартнер предсказывает, что к 2030 более 60% внедрений первой волны внедрения ИИ провалятся – не оправдаются ожидания по производительности и стоимости. Причиной станет недооценка квалификации кадров.

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

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

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

Но проблема именно с обеих сторон. Люди не умеют делать «задачу без ТЗ», александр проводил тренинг по самоопределению, 52% перепутали проблему, цель и инструмент. Отмечу, что это – типично, когда корпораты ставят цель «внедрить ИИ-агентов», как 10 лет назад ставили цель «внедрить Agile».

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

Но будущее всегда абстрактно, оно еще не создано. Что конкретно можно отдать ИИ?

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

Доклад от MIT: 95% компаний не видят отдачи от ИИ. Причина – не модели, а неумение встроить ИИ в реальную работу. Я тут согласен, впечатления от Highload, где крупные корпораты рассказывали про их видение работы с ИИ это подтверждают. А у мелких как раз получается, и в крупных островки инициативы тоже живут.

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

Психологическая кривая персональных изменений Фишера: тревога – счастье – страх – угроза – вина – постепенное принятие – движение вперед. И по пути – развилки. 25-30% сотрудников не хотят признавать agentic AI трендов. Идет размытие понятий, чтобы избежать изменений. Впрочем, отмечу, что с Agile было то же самое.

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

Есть два привычных хода, которые сейчас не работают. Тимлид: «Распишу задачу детальнее и дам инженеру». HR: «Ребят надо пожалеть, а то выгорят». Ломается старая лестница компетенций джун → мидл → сеньор → тимлид. Как создать крутого сеньора, если работу джуна и мидла делает ИИ?

Дальше – развитие темы. Лестница Нормированная работа (задачи по ТЗ) – Бизнес-цели (Middle/TL) – Доля рынка (C-level) – Рынок (Предприниматель) – Индустрия – Экономика – Мироустройство – Космос. Как думать с уровня, на котором не был? Илон Маск умеет думать на уровне Космоса. А технологии приходят с уровня индустрии, и ИИ – оттуда. Я тут скажу, что ответ один – просто начинать думать на большем масштабе, строить цепочку самоопределения, разбираться в логике событий. Тем более, что лестница – ложная, многие продуктовые разработчики, создавая фичи мыслят не просто проблемами пользователей, но и долей рынка, которое принесет решение этих проблем, а в стартапах – теми изменениями, которые принесет в мир успех стартапа.

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

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

TeamLead несколько лет назад был про средства. А теперь – про Субъекта. Как сподвигнуть на самоопределение, чтобы человек взял задачу, а не сидел в домике эксперта?

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

Партнер, а не начальник. Три уровня разговора.

* Я – что хочу, позиция, цели, ценности
* Команда – место, где мы осуществляем замысел
* Польза миру

Впрочем я бы тут рекомендовал не брать старую схему Выготского, а использовать современную технологию карты гипотез Александра Бындю, которая гораздо лучше прописывает связи. За подробностями отсылаю к его книгам, или, для начала, на [https://mtsepkov.org/ByndyuHypo-2 мой отзыв]. Теперь конкретно про ИИ. Когда мы работаем с данными, то у нас есть оценка достоверности: свое руками проверенное – доверенный источник – требует проверки – поток сетей, когда общаемся с ИИ, то он не различает ценное и мусор, ему надо знать контекст. Это – проблема, но не повод опускать руки и жаловаться. Смените модель поведения: вместо «все плохо с ИИ» – конкретный тезис, предложение.

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

Границы и масштаб метода. Есть мировая статистика: 72% не готовы меняться, 27% меняется по контексту, 1% меняются всегда, в росссии – аналогично. Вопрос: выбирай с кем работать. Я тут не согласен. Во-первых 90-е показали, что люди в СССР хотят меняться, хотя получалось у всех по-разному. А во-вторых, это вообще корпоративный миф: люди не хотят меняться, когда подозревают, что их хотят заставить работать больше и тяжелее, а платить меньше. Почему-то компании очень часто хотят именно таких изменений и наивно удивляются, почему люди их не хотят. Иногда бывают не так, но это ж объяснить надо, преодолев еще барьер недоверия.

Как надо измениться?

* Перестать расписывать задачу, дать средство или сопроектировать
* Перестать говорить «подумай» без средства, дать способ думать
* Кидать задачу «сделай X», сначала вместе описать задачу как действие
* Мерджить непроверенный ИИ-вывод, стать пилотом, а не пассажиром: править и проверять результат.
* Не снимать с людей все трудное, а оставлять там, где растишь людей.
* Не тушить пожары и тянуть одеяло на себя, а строить систему, где все работает без тебя.

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

== Александр Алазиди. Платформенная команда – это ускоритель или узкое место ==

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

После выступления была реплика из зала – по теме есть хорошая книга Platform as strategy. Однако, насколько я посмотрел, это про другой тип платформ – для взаимодействия потребителей и поставщиков, типа маркетплейсов, Яндекс-такси и так далее, платформа – многозначное слово.

Итак, тезисы выступления.

* Платформа – не набор технологий и логотипов. Важна упаковка в понятный используемый сервис.
* Есть сервисы, которые нужны всем – авторизация или логирование, и часто платформы собирают из них. Это – не слишком хороший кейс, там не получается целостности.
* Часто узкое горло использования – занятость экспертов заняты. Или для разворачивания надо дать инструкцию админу-исполнителю, которую сложно сделать.
* Сейчас часто ИИ-команду представляют как платформу, и получается неудачно. Потому что кто-то пошел бы вайбкодить, но разворачивать у себя запрещено, а инфраструктура работает как стоп.
* Аналогичная проблема с платформой данных – вместо каталога данных и легкого доступа ты упираешься в административные процедуры, чтобы их получить.
* Есть психология: все быстрое делаем мы, а тормозят нас смежники. Поскольку от платформы все зависят, то начинаются повсеместные разборки, кто виноват. Однако, в любом случае '''платформа должна сокращать время разработки''', а не наоборот.
* Есть и другая крайность, когда платформа превращается в «подай-принеси». Настроить хранение, ИИ, еще какие-то сервисы. Команда не применяет продуктового мышления, не думает о платформе как о продукте с понятными границами. Каждый проект просит уникальное для себя, получается просто набор всего на свете.
* Еще антипаттерн – слияние с командой-заказчиком, когда в платформу просачивается бизнес-логика конкретных решений. Героическая платформа – разгребаем чужой бэклог. Так быть не должно, но быть барьером для выполнения бизнес-задач тоже не надо, надо совместно искать решения, чтобы команды могли сделать требуемую бизнес-логику.

Если это обобщить, видны такие проблемы.

* '''Размытые границы''': команда не знает чем заняться и делает все, что просят.
* Отсутствие продуктового мышления.
* Команды продавливают расширение границ. Был кейс, договрились, что платформа поддерживает набор сервисов для стеков dotnet, java, python. , но не php. Потом пришел кайфный подрядчик с php – и платформу продавили, чтобы php тоже был для единственного проекта.<br />

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

'''Главный вопрос: какие решения (decision) платформа должна снять с потребителя?'''

'''Team Topologies'''. Архитектурные подходы к проектированию команд – организация как архитектурная схема, с типовыми шаблонами и способами взаимодействия. Не все команды должны быть одинаковыми, в книге выделено 4 типа команд. stream-align – ценность, и для поддержки: команда учит, команда сеньоров для сложных задач, команда платформы. И тип взаимодействия может быть разный: сервис, фасилитация, совместная работа (самый дорогой).

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

Контракт команды – '''team api''': что мы делаем, и что мы не делаем. И метрики вместо «постараемся быстрее». Четыре дорожки потребителя платформы: типовые запросы, запросы на помощь, запросы на экспертное решение и запрос на создание исключения. И нужен понятный путь, как команда через api запрашивает решение, и как получает ответ.

Минимальный сервис Thin Platform Viable (TVP) – это не MVP, а минимальная упаковка сложности. Иногда это просто wiki, где лежит guide со скриншотами и один хорошо описанный сервис.

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

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

Метрики: effort (наши усилия) – output (наши результат) – outcome (ценность – снижение нагрузки заказчика) – impact (деньги). Просто мерить первые две, но реальная полезность – в последних.

'''Не стройте платформу целиком'''. Возьмите типовые обращения, посмотрите, что болит часто – и упакуйте это через team api, а потом – померяйте результат.

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

== Алеся Бикбулатова. Когда хочется все бросить: как найти внутренние ресурсы для движения вперед ==

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

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

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

Есть не очевидный эффект: первый симптом выгорания – ярко выраженный энтузиазм и героический порыв «все возьму и сделаю», а результат – не успеваю, подавленность, негатив.

Много мифов.

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

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

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

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

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

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

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

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

Впрочем, отмечу, что тут есть тонкий момент. Если ситуация зависит от внешних обстоятельств, ты рассказываешь – люди начинают тревожиться, а влиять все равно не могут. Важно, как рассказывать. Алеся об этом говорила, но ее предложение: «есть 3 сценария, и хороший 80%, хотя такой уверенности нет», на мой взгляд, большая манипуляция, которая дает формальную отмазку руководителю: «я тебя предупреждал».

SCARF-модель. Status, Certainly, Autonomy, Relatedness (принадлежность сообществу), Fairness (справедливость). '''Статус – сложный фактор, его каждый человек определяет по-разному''', и с этим надо разбираться и для себя и для других. Autonomy тоже не однозначно: есть те, кому кайф жить в хаосе, без контроля. Надо знать доминирующие факторы для себя и для членов команды и закрывать их. Я тут отмечу, что с такими оговорками – вполне рабочая модель. А без них – не очень, потому что содержание этих факторов Дэвид Рок (книга «Мозг. Инструкция по применению») собрал на культурном контексте американских менеджеров, а он сильно отличается от культуры российского ИТ. Именно поэтому статус получается сложным, у Рока там достаточно однозначно.

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

'''Вопросы для изменения ситуации'''.

* Что забирает больше энергии и можно ли это изменить?
* Что я делаю из страха, а не из выбора?
* Кому я мог бы доверять больше – и что этому мешает?
* Есть ли в команде кто-то, кто видит меня как человека, а не руководителя
* Что я точно хочу сохранить в своей жизни, не зависимо от изменений в бизнесе?

Эти вопросы надо себе задать, и получить ответы, лучше письменно.

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

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

'''Восстановление, микро и макро'''.

* 5-минутные паузы без телефона между встречами
* Прогулка без подкаста и других звуков, даже без музыки
* Завершение рабочего дня – ритуал «стоп»
* Лдин прием пищи без экрана
* Отпуск без доступности – реальный, а не формальный
* Еженедельный день без совещаний
* регулярные встречи с ментором и коучем – если сами не вывозите, то переложите ответственность
* физическая активность как приоритет, а не бонус

'''Энергетические запасы лидера''' – как их восполнять.

* Журнал успехов – что сделали классного.
* Карта тревог – выписать что беспокоит, разделить на могу влиять/не могу влиять. Такое признание снимает тревогу.
* Личная аптечка – 5 действий, которые точно восстанавливают на 10 – 30 – 60 минут. Написать заранее, использовать по факту – потому что в кризис мозг не вспомнит, нужен список. Универсальных нет, кроме дыхания – там физиология. Есть кого заряжают кошки и собаки, кто-то любит природу, кто-то чай, кто-то музыку и так далее.

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

К корпоративным психологам отношение скептическое: один на 1000 – бесполезно. Полезно просвещение – обучение практикам.

'''Вопрос'''. Как заслужить право на ошибку? Что делать, если на неделе 2-3 критичных ошибки? '''Ответ'''. Внутренняя установка «заслужить право на ошибку» настораживает. Просто правильных решений должно быть больше ошибочных. Плюс проговаривать с командой: решение сейчас принимаем быстро, поэтому ошибок будет больше.


[[Категория:ИИ-агенты]]
{{wl-publish: 2026-07-09 21:00:26 +0300 | MaksTsepkov }}