MaksWiki - Вклад участника [ru]

Я — Максим Цепков приветствую Вас на своем сайте

2026-07-24T15:29:47Z

MaksTsepkov:

__NOTOC__ __NOEDITSECTION__ __NONUMBEREDHEADINGS__
[https://t.me/mtsepkov '''Мой телеграм канал'''] [https://max.ru/join/Y4ME2oQFJcs6jkmOJ3FZX_VIRpKYv3s7E0f2PCZmZv4 '''Мой MAX канал'''] 
'''К разделам''' '''&dArr;''' [[#NewMng|Современный менеджмент]] '''&dArr;''' [[#SoftSkills|Модель личности]] '''&dArr;''' [[#ITarch|IT: архитектура и бизнес-анализ]] '''&dArr;''' [[#Blog|Блог]] '''&dArr;''' [[:Категория:Конференции|О конференциях]] '''&dArr;''' [[#Others|Остальное]]

{|width="100%"
|-
|style="border: 1px solid #6688AA; background-color:#FCFFF0; padding:0.5em;"|
<div style="float:right;border-radius: 8px; padding: 0 0.5em; margin: 0 0 0.5em 0.5em; background: Cyan"><big>'''Скоро и недавно'''</big></div>
[[Файл:ChinaLeader-BookCover2.png|right|thumb|200px|border|[https://ridero.ru/books/kitai_dao_menedzhmenta_i_kulturnyi_kod_budushego_lidera_mira/ Книга на ridero]]]
[[Файл:SelfDetBook-cover.jpg|thumb|200px|border|[https://ridero.ru/books/samoopredelenie_chto_ya_khochu_ot_zhizni_i_raboty/ Книга на ridero] ]]


'''04.05''' Опубликована книга [https://ridero.ru/books/kitai_dao_menedzhmenta_i_kulturnyi_kod_budushego_lidera_mira/ '''«Китай: дао менеджмента и культурный код будущего лидера мира»'''], статьи и выступления по теме доступны в [[:Категория:Китай становится лидером|'''Категории Китай становится лидером''']], где уже '''{{PAGESINCATEGORY:Китай становится лидером|pages}} статей''', последние статьи [https://vc.ru/hr/2845062 Корпоративные ценности ИТ-компании – китайский опыт] и [https://habr.com/ru/articles/1016504/ ИИ не конкурент, а помощник и друг – китайский опыт], и есть видео вебинара '''[[Влияние технологий на изменение мирового порядка и глобальную конкуренцию (Вебинар СШЭ)|Влияние технологий на изменение мирового порядка и глобальную конкуренцию (Китай становится лидером)]]''' (27.01 [https://nserussia.org '''СШЭ'''])
----
13-14.06 Иваново [https://lafest.ru/index.php?program2026 '''ЛАФ'''] – [[Опора в эпоху перемен: логика и культура лидерства Китая и опыт китайских tech-гигантов (ЛАФ-2026)|'''Опора в эпоху перемен: логика и культура лидерства Китая и опыт китайских tech-гигантов''']] 
28-29.05 Москва [https://lit-int.ru '''Литейный интенсив'''] – [[Управленческая экспедиция по Китаю. Что должен знать про Китай каждый руководитель, развивающий свою компанию? (Литейный интенсив-2026)|'''Управленческая экспедиция по Китаю. Что должен знать про Китай каждый руководитель, развивающий свою компанию?''']] 
22-23.05 Петербург [https://AnalystDays.ru '''AnalystDays'''] – [[Эпоха быстрых изменений - возможность, а не проклятие: опыт китайских tech-гигантов (AnalystDays-2026)|'''Эпоха быстрых изменений - возможность, а не проклятие: опыт китайских tech-гигантов''']] 
15.05 Статья на habr [https://habr.com/ru/articles/1035522/ '''Об организации труда ИИ-агентов'''] 
24-25.04 Петербург [https://sqadays.com '''SQAdays'''] – [[Эксперименты и опыт - часть пути к успеху: mindset китайских tech-гигантов (SQAdays-2026)|'''Эксперименты и опыт - часть пути к успеху: mindset китайских tech-гигантов''']] 
20.04 Москва [https://aiconf.ru/2026 '''AIconf'''] – [[IT-ландшафт будущего: как китайские tech-гиганты и культура меняют мир (AIconf-2026)|'''IT-ландшафт будущего: как китайские tech-гиганты и культура меняют мир''']] 
17-18.04 Иннополис [https://tatarstan2026.mergeconf.ru/ '''Merge'''] – [[DDD и современная архитектура: как проектировать модель и отражать ее в код (Merge-2026)|'''DDD и современная архитектура: как проектировать модель и отражать ее в код''']] 
10-11.04 Ульяновск [https://ul.nastachku.ru/ '''Стачка'''] – [[Визуальное проектирование масштабируемых приложений (Стачка-2026)|'''Визуальное проектирование масштабируемых приложений''']] и [[Архитектура предприятия: бизнес и софт как единая система (Стачка-2026)|'''Архитектура предприятия: бизнес и софт как единая система''']] 
13-14.02 Москва [https://biorgconf.ru/ '''Живая компания'''] – [[Найти опору в эпоху перемен: логика и культура лидерства Китая (Живая компания-2026)|'''Найти опору в эпоху перемен: логика и культура лидерства Китая''']]
----
'''03.09.25''' опубликована книга [https://ridero.ru/books/samoopredelenie_chto_ya_khochu_ot_zhizni_i_raboty/ '''«Самоопределение: что я хочу от жизни и работы»''']. В основе - серия статей 2023 года, дополненная разделами по анализу текущей ситуации и доработанная с учетом модели личности. 
14-15.11 Москва [https://analystdays.ru AnalystDays] – [[Архитектура софта и бизнеса в сложном ИТ-ландшафте (AnalystDays-2025b)|'''Архитектура софта и бизнеса в сложном ИТ-ландшафте''']] и связанный мастер-класс [https://analystdays.ru/ru/talk/140888 '''Проектируем архитектуру софта для бизнеса'''] 
24-25.10 Москва [https://sqadays.com SQAdays] – [[Что такое – архитектура и как она влияет на тестирование (SQAdays-2025b)|'''Что такое – архитектура и как она влияет на тестирование''']] 
11-14.09 Москва [https://festpir.ru ПИР] – [[Новые смыслы: меняем смысл старых слов или придумываем новые? (ПИР-2025)|'''Новые смыслы: меняем смысл старых слов или придумываем новые?''']] [https://festpir.ru/section?PreviewSearch%5Bperformance_id%5D=3265 анонс] 
'''08.09.25''' Статья [https://vc.ru/hr/2203386 «'''Самоопределение: пора ли идти к светлому будущему?'''»] на vc.ru - начало главы про анализ текущей ситуации из книги, продолжение следует 
06.2025 [[Инженерная модель личности (семинар УнивёрS 06.2025)|'''Семинар УнивёрS Инженерная модель личности''']] 
|}

{|width="100%" style="border-spacing:0 10px;"
|-
|style="border: 1px solid #6688AA; background-color:#FCFFF0; padding:0.5em;"|
<div style="float:right;">
<div style="font-size:medium; border: dashed 1px Gray; padding: 0 0.5em; margin: 0.5em 0 0 0.5em;">
=Я в сети=
[https://t.me/mtsepkov Telegram канал] 
[https://t.me/MaximTsepkov Telegram user] 
[https://max.ru/join/Y4ME2oQFJcs6jkmOJ3FZX_VIRpKYv3s7E0f2PCZmZv4 Max канал] 
[http://www.facebook.com/mtsepkov Facebook] 
[https://vc.ru/u/364500 Канал vc.ru] 

[http://www.linkedin.com/in/mtsepkov Linkedin] 
[https://twitter.com/mtsepkov Twitter] 
[http://www.slideshare.net/mtsepkov/ Slideshare] 
[http://maksiq.livejournal.com Живой журнал] 
maks.tsepkov@ya.ru
----
[[User:MaksTsepkov|Обо мне…]] 
[[:Категория:Доклады|Мои выступления]] 
[[:Категория:Статьи|Мои статьи]] 
[[Блог:Максима Цепкова/2016-01-09: Схемы, в которых я мыслю|Мои схемы]]
</div>
</div>
<html></html>
= Кто я и что делаю? =
* '''Навигатор по менеджменту цифрового мира: Agile, бирюзовые организации и социократия, об этом — моя книга [https://ridero.ru/books/menedzhment_cifrovogo_mira/ «Менеджмент цифрового мира»]'''
* '''Эксперт по моделям самоопределения и soft skill, автор книг [https://ridero.ru/books/inzhenernaya_model_lichnosti/ «Инженерная модель личности: Меняя себя и других — понимай устройство»]''' и [https://ridero.ru/books/samoopredelenie_chto_ya_khochu_ot_zhizni_i_raboty/ '''«Самоопределение: что я хочу от жизни и работы»''']
* '''Эксперт по трансформации бизнеса с помощью IT, архитектор и бизнес-аналитик'''
* Тема 2026 года: '''китайский менеджмент и культурный код''', на основе визита в китайский технологические компании Baidu, Xiaomi и другие осенью 2025 ([[Блог:Максима Цепкова/2025-10-22: Китай - технологический лидер будущего|мой отчет]]) и дальнейшего погружения в тему.
'''Что я делаю?'''
* Провожу кругозорные лекции и учебные курсы, ориентированные на конкретную аудиторию по менеджменту, моделям soft skill, самоопределению, ведению ИТ-проектов и архитектуре ([[Блог:Максима Цепкова/2024-12-11: Курс для Бюро 1440 - концепция развивалась 10 лет|отзыв на курс для Бюро 1440]])
* Консультирую по применению методов современного менеджмента для конкретной компании, помогаю выбрать вектора трансформации и определить образ будущего
* Консультирую по самоопределению, личностному росту, конфликтам и строительству команд

На сайте - [[Доклады и Статьи|'''{{#expr: {{PAGESINCATEGORY:Доклады|pages}} + {{PAGESINCATEGORY:Статьи|pages}} + {{PAGESINCATEGORY:Презентации нового менеджмента|pages}} + {{PAGESINCATEGORY:Серия статей про менеджмент цифрового мира|pages}} + {{PAGESINCATEGORY:Подкаст Менеджмент цифрового мира на TMFM|pages}} }} моих выступлений и статей''']], [[:Категория:Конференции|'''{{PAGESINCATEGORY:Конференции}} отчетов с конференций''']], [[:Категория:Книги|'''конспекты книг]]''', также '''[[Блог:Максима Цепкова|блог]]''', который я веду с 2010 и другие материалы. Дальше — тематический список основных материалов и ссылки на тематические разделы сайта.

'''Я открыт к общению''' через социальные сети и по почте (лучше телеграм) и обычно отвечаю на сообщение в течении 2-3 дней как минимум квитанцией о получении. Если она не пришла — значит сообщение перехватила спам-оборона и надо пробовать связаться иным образом. Подробнее обо мне можно прочитать [[User:MaksTsepkov|на этой странице]].
|}

{|width="100%" style="border-spacing:0 10px;"
|-
|style="border: 1px solid #6688AA; background-color:#FCFFF0; padding:0.5em;"|
<html></html>
= Современный менеджмент и развитие общества =
[[Файл:NewMngBook-Cover.jpg|thumb|200px|border|[https://ridero.ru/books/menedzhment_cifrovogo_mira/ Книга на ridero] ]]
'''Тематические страницы: [[:Категория:Agile|Agile]], [[:Категория:Бирюзовые организации|Бирюзовые организации]], [[:Категория:Спиральная динамика|Спиральная динамика]], [[:Категория:Управление проектами|Управление проектами]], [[:Категория:Серия статей про менеджмент цифрового мира|статьи «Менеджмент цифрового мира»]], [[:Категория:ИИ-агенты|ИИ-агенты]]'''

Я знаком с Agile-методами с 2007, а знакомство со Спиральной динамикой в 2013 дало понимание, что Agile-методы - не просто особый подход к управлению в IT, а зарождение менеджмента цифрового мира, вызовы которого пришли в ИТ раньше других. Спиральная динамика описывает современное развитие общества через изменений конструкции ценностей, подробности [[Формирование уровней спиральной динамики в общественном сознании|в этой статье]].
Знакомство с книгой Фредерика Лалу «Бирюзовые организации» показало альтернативу, которая встроена в общую картину. Как результат осмысления, зимой 2019-2020 была написана [[:Категория:Серия статей про менеджмент цифрового мира|'''серия из {{PAGESINCATEGORY:Серия статей про менеджмент цифрового мира}} статей''']], по которой в 2022 опубликована [https://ridero.ru/books/menedzhment_cifrovogo_mira/ '''книга «Менеджмент цифрового мира»]'''. Тема продолжает развиваться.

'''Материалы для знакомства с big picture современного менеджмента'''.
* Статья '''[[Agile и бирюзовые организации - ответ менеджмента на вызовы новой промышленной революции]]'''
* Статья Гриши Храброва [https://vc.ru/life/159694 Культура, стратегия, лидерство в цифровом мире. Интервью с Максимом Цепковым]
* Статья [http://eroskosmos.org/teal-organizations-hype-or-future/ '''Бирюзовые организации — хайп или образ будущего?'''] на портале „'''Эрос и Космос'''“ ([[Блог:Максима Цепкова/2018-10-29: Бирюзовые организации: хайп или образ будущего?|на моем сайте]])
* '''Конспект книги [[Фредерик Лалу. Открывая организации будущего (конспект)|Фредерика Лалу «Открывая организации будущего»]]''', мне многие говорили, что именно он помог понять книгу.
* 15.03.19 [[Эволюция технологий управления (ПИР Сибирь-2019)|'''Эволюция технологий управления (Agile и бирюзовые организации — ответ менеджмента на вызовы новой промышленной революции)''']] на [http://pirsiberia.ru ПИР Сибирь]
* 25.09.19 Семинар [[Эволюция технологий управления: Agile и бирюзовые организации – менеджмент цифрового мира (OBS-2019)|'''Эволюция технологий управления: Agile и бирюзовые организации — менеджмент цифрового мира''']] в [http://obs.ru Открытой школе бизнеса] — большое видео с подробным введением в Agile
* 27-28.05.19 [https://ritfest.ru/2019 '''РИТ++'''] — [[Социальный договор цифрового мира: работа должна обеспечивать счастье, а не только деньги (РИТ-2019)|'''Социальный договор цифрового мира: работа должна обеспечивать счастье, а не только деньги''']]
* 09-12.09.21 '''[[Осознанное развитие и переходящее лидерство — основа команд и сообществ цифрового мира (ПИР-2021)]]
* 16-17.09.21 '''[[Социократия - хороший источник практик по организации IT-проектов (Saint Teamlead-2021)]]''', [https://habr.com/ru/company/oleg-bunin/blog/678172/ '''расшифровка выступления'''], этих материалов нет в книге

'''Несколько визионерских выступлений о будущем развитии мира'''
* 16-18.02.24 '''[[Место ИТ и аналитиков в будущем мире (WAW-2024)]]'''
* 12-15.09.24 '''[[ИИ – зеркало человека, страхи, возможности и перспективы обусловлены этим (ПИР-2024)]]'''
* 22-23.02.25 '''[[Развитие общества в эпоху ИИ (WAW-2025)|'''Развитие общества в эпоху ИИ''']]'''

[[:Категория:ИИ-агенты|ИИ-агенты]]
'''Помимо выступления, которые дают big picture, у меня есть выступления и статьи на отдельные актуальные темы'''. Они собраны в категорию [[:Категория:Управление проектами|'''Управление проектами''']], в которой в последнее время выделилась отдельная категория [[:Категория:ИИ-агенты|'''ИИ-агенты''']].
* Статья [https://habr.com/ru/articles/1035522/ '''«Об организации труда ИИ-агентов»''']
* Статья [https://habr.com/ru/companies/custis/articles/913016/ '''SDLC: пойди туда, не знаю куда, но непременно по плану'''] на habr (05.2025)
* 30.10-03.11.23 '''[[Работа со стратегией в реалиях современного мира (Podlodka-2023)]]'''
* 24-25.10.23 '''[[Готовы к изменениям: адаптивная архитектура как часть ИТ-стратегии (HPS-2023)]]'''
* 27-28.02.23 '''[[Профстандарты и модели компетенций - желания и возможности (TeamLead-2023)]]'''
* 17.05.22 '''[[Почему проектный подход не работает в IT (Teamlead-2022)]]'''
* 04.04.21 '''[[Process, Project, Case, Agile, Product и другие виды менеджмента - сопоставляем конструкцию и назначение]]''' на конференции Школы системного менеджмента [https://system-school.ru/conf21 '''«Прикладное системное мышление-2021»''']
* 23.09.19 '''[[Планирование проекта от демонстраций для разворачивания партнерства с заказчиком (Saint TeamLeadConf 2019)]]'''
* 12.10.18 '''[[Мыслить проектно: история и современность (SECR-2018)]]''' — big picture, предыдущий вариант был [[Развитие управления проектами и критериев качества в ИТ (Максим Цепков на AgileDays-2015)|на AgileDays-2015]]
* 13.10.17''' [[Удовлетворенность стейкхолдеров – два разных смысла (AnalystDays 2017-10 в Минске)]]
* Статья '''[[Проекты — для достижения результата, а не для освоения бюджета]]''' — о методологии ведения проектов
* Тема [[:Категория:Роли|'''Роли и ответственность в проектах''']], последний '''[[Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять (SQAdays-20, 2016-11)|Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять]]''' и '''[[Роли в проекте: как поделить поляну ответственности? (Lead/Manage IT 2020)]]'''
* 08-09.02.18 на [http://teamleadconf.ru TeamLeadConf] '''[[Управление знаниями: какие документы нужны и что в них фиксировать (TeamLeadConf-2018)|Управление знаниями: какие документы нужны и что в них фиксировать]]''', на habr опубликована [https://habr.com/ru/company/oleg-bunin/blog/438820/ '''расшифровка''']

|-
|style="border: 1px solid #6688AA; background-color:#FCFFF0; padding:0.5em;"|
<html></html>
= Самоопределение и модели личности =
[[Файл:Модель личности - обложка.png|thumb|200px|border|[https://ridero.ru/books/inzhenernaya_model_lichnosti/ Книга на ridero] ]]
[[Файл:SelfDetBook-cover.jpg|thumb|200px|border|[https://ridero.ru/books/samoopredelenie_chto_ya_khochu_ot_zhizni_i_raboty/ Книга на ridero] ]]

Тема личного и профессионального самоопределения актуальна для ИТ, выступления по ней были с 2017 года, зимой 2022-2023 года у меня вышла [[:Категория:Самоопределение|'''серия статей по самоопределению''']]. Проработка тем самоопределения, коммуникации и управления проектами потребовали знакомства с моделями soft skill, а взгляд архитектора помог мне на основе моделей нейрофизиологии и психологии собрать в 2024 единую модель в книге [https://ridero.ru/books/inzhenernaya_model_lichnosti/ '''«Инженерная модель личности: Меняя себя и других — понимай устройство»'''], доступной также в виде [[:Категория:Люди|'''серии статей''']]. А в 2025 году вышла книга [https://ridero.ru/books/samoopredelenie_chto_ya_khochu_ot_zhizni_i_raboty/ '''«Самоопределение: что я хочу от жизни и работы»'''], где серия статей дополнена разделами по анализу текущей ситуации и доработана с учетом модели личности.

'''Тематические страницы: [[:Категория:Люди|Модели softskill]], [[:Категория:Самоопределение|Самоопределение]], [[:Категория:Модель личности|Модель личности]], [[:Категория:Спиральная динамика|Спиральная динамика]], [[:Категория:Модель Белбина|Модель Белбина]]'''

По этим темам у меня есть большое количество выступлений, часть из них легло в основу статей, другие - развивают тему. В книге изложение идет от базы к прикладным вопросам, а в большинстве выступлений - наоборот, от практических задач и прикладных моделей для их решения. Вот основные выступления.
* [[Как строить свой профессиональный путь - схемы самоопределения (TeamLeadConf-2018)]] и развит на [[Как строить свой профессиональный путь - схемы самоопределения в QA-контексте (COMAQA-2018)|'''COMAQA''']], фокус — на пути к образу будущего.
* В 2022 — новая версия с фокусом на построении вдохновляющего образа, начат [[Как строить образ будущего и идти к нему - схемы самоопределения (AnalystDays-2022)|'''на AnalystDays-2022''']] и [[Как строить образ будущего и идти к нему - схемы самоопределения (Школа Системного менеджмента 2022)|на конференции школы Левенчука]], далее [[Как строить образ будущего и идти к нему - схемы самоопределения (Saint Teamlead-2022)|'''на Saint Teamlead-2022''']] и '''[[Самоопределение: чего я хочу от жизни и работы (SQAdaysEA-2022)|Чего я хочу от жизни и работы]]'''.
* Серия обзорных выстулпений по моделям softskill: 11-12.11.2021 на [https://infostart.ru/events/1451228/ Infostart 11] «[[Модели softskill для тимлида (Infostart-2021)|'''Модели softskill для тимлида''']]» — развитие выступлений 22-23.09.2021 на [https://community-z.com/events/ta-all-escape2021 '''ESCAPE-2021'''] «[[Модели softskill - способ быстро понять другого (ESCAPE-2021)|'''Модели softskill — способ быстро понять другого''']]» и '''[[Модели softskill для тимлида (TeamLeadConf-2019)]]''', по выступлению на Infostart 25.09.23 опубликована [https://infostart.ru/1c/articles/1942952/ статья '''Модели softskill для тимлида''']

'''Новые выступления'''
* 06.2025 '''[[Инженерная модель личности (семинар УнивёрS 06.2025)]]'''
* 06-09.02.25 '''[[Быстро понять мышление, эмоции и мотивацию коллег? Есть модели! (Живая компания-2025)]]'''
* 13-14.07.24 '''[[Взаимодействуй с людьми и развивайся с опорой на модели личности (ЛАФ-2024)]]'''
* 26-27.04.24 '''[[Модели softskill - способ понимать людей и строить путь развития (SQAdays-2024 весна)]]'''
* 20-21.04.24 '''[[Самоопределение: чего я хочу от жизни и работы (Merge-2024)]]'''
* 30.11-01.12.23 '''[[Меняя себя и других - понимай устройство: инженерная модель личности (Teamlead-2023)]]'''
* 24-25.11.23 '''[[Самоопределение: чего я хочу от жизни и работы (SQAdays-2023)]]'''
* 7-10.09.23 '''[[Я и мои аватары в спектакле жизни (ПИР-2023)]]'''

'''Выступления про отдельным моделям'''
* 30.11.18 на [https://analystdays.ru/ru/program/62120 AnalystDays-9] [[Спиральная динамика для аналитика - работа на стыке культур (AnalystDays-9 осень 2018)|'''Спиральная динамика для аналитика — работа на стыке культур''']]
* [[:Категория:Модель Белбина|'''Модель Белбина''']] — развивающаяся серия выстулений с разными фокусами: [[Модель Белбина для IT: сила и слабость разных команд (TrueTechDay-2023)|на TrueTechDay-2023]], [[Модель Белбина для IT: сила и слабость разных команд (PMclub.pro 02.2021)|на PMclub.pro 02.2021]], [[Модель Белбина для IT: сила и слабость разных команд (TeamLeadConf-2020)|на TeamLeadConf-2020]] ([https://habr.com/ru/company/oleg-bunin/blog/522586/ '''текстовая расшифровка''']), [[Роли в команде - модель Белбина (COMAQA-2018)|на COMAQA-2018]], [[Роли в команде - модель Белбина (Максим Цепков на SPMconf-2012)|на SPMconf-2012]], о модели есть моя статья '''[[Типология ролей в команде (статья в MyType 1-2.2016)]]'''
* [[Типы личности (семинар 2008-02-12)|Типология Майерс-Бриггс]]

|-
|style="border: 1px solid #6688AA; background-color:#FCFFF0; padding:0.5em;"|
<html></html>
= IT: архитектура и анализ =
'''Тематические страницы [[:Категория:Архитектура|Архитектура и анализ]], [[:Категория:DDD|DDD]], [[:Категория:Системное мышление|Системное мышление]], [[:Категория:Акторная модель|Акторная модель]]'''

* [[:Категория:Системное мышление|Серия выступлений по '''системному мышлению''']]: '''[[Рациональное и системное мышление: практики и компетенции аналитика (AnalystDays-2023)|на AnalystDays-2023]]''', развитие выступления [[Системное мышление и его место в работе аналитика (AnalystDays-2024a)|'''на AnalystDays-2024''']], [[Системное мышление: что это и зачем нужно тестировщику? (SQAdays-2024)|'''на SQAdays-2024''']] и [[Системное мышление — нужно ли оно в IТ и зачем? (Teamlead-2024)|'''на Teamlead-2024''']] (у всех опубликовано видео).
* 01.11.24 '''[[Бизнес и софт как единая система: описываем архитектуру предприятия (ArchDays-2024)]]'''
* Серия ведение постановок, включая подход DDD:
** '''[[Сначала проект, потом анализ: прошлое возникает из будущего (ЛАФ-2025)]]'''
** '''[[Аналитик и legacy: как разобраться в устройстве старой системы? (AnalystDays-2025)]]'''
** '''[[Обеспечиваем устойчивость интеграции (SQAdays-2025)]]'''
** '''[[Постановка от модели бизнеса до детального дизайна требований: как делать и кому (Вебинар 13.03.2025)]]''' - большой вебинар, в котором много материала
** '''[[Бизнес-анализ на легаси: как погрузиться в проект? (DUMP-2025)]]'''
** 08.10.24 '''[[Постановка от модели бизнеса до детального дизайна требований: как делать и кому (UIC.dev-2024)]]'''
** 20.09.23 '''[[Классика, user story, use case, DDD: обзор методов (Up!Date-2023)]]'''
** 4-5.09.23 Обсуждение с Юрием Куприяновым [[DDD: как жить в проекте без требований (обсуждение на Flow-2023)|'''DDD: как жить в проекте без требований''']] на FlowConf
** 10-11.06.23 '''[[DDD: модели вместо требований 9 лет спустя (ЛАФ-2023)]]'''
** 21-22.04.23 '''[[Требования или модели - как писать постановки (AnalystDays-2023)]]'''
** 18.06.22 '''[[Бизнес-архитектура: от цепочки создания ценности до автоматизации бизнес-процессов (ЛАФ-2022)]]'''
** '''[[Бизнес-анализ: от абстрактного замысла до внедрения и дальнейшего развития ИТ-решения (Максим Цепков на SECR-2017)]]
** '''[[Как выбрать для проекта практики проектирования и работы с требованиями (Максим Цепков на AnalystDays-2017)]]'''
** Серия статей на habr по ведению постановок [https://habr.com/ru/company/custis/blog/703758/ Какие нужны требования: развитие концепта], [https://habr.com/ru/company/custis/blog/705958/ Domain Driven Design: модели вместо требований], [https://habr.com/ru/company/custis/blog/709912/ Agile-методы: light-версии требований]
* Осенью 2020 начата серия выступлений и мастер-классов [[:Категория:Акторная модель|'''Акторная модель''']] — о визуальной модели для (микро)сервисной архитектуры приложения, которая позволяет проектировать масштабирование и устойчивость приложения и обсуждать решения с бизнесом. Последнее выступление
'''[[Визуальное проектирование масштабируемых приложений (Стачка-2026)]]''', до этого были [[Визуальное проектирование масштабируемых приложений (TechLead-2021)|на '''TechLead-2021''']] и [[Визуальное проектирование масштабируемых приложений (Highload-2022)|на '''Highload-2022''']], а также много других.
* Серия статей «'''Как сделать хорошую интеграцию'''» на habr: [https://habr.com/ru/company/oleg-bunin/blog/534090/ первая], 20.01 [https://habr.com/ru/company/oleg-bunin/blog/538156/ вторая], [https://habr.com/ru/company/oleg-bunin/blog/543946/ третья], на которых основано выступление '''[[Что такое - хорошая интеграция (Saint Highload-2021)]]''' и его развитие '''[[Обеспечиваем устойчивость интеграции (SQAdays-2025)]]'''
* Статьи по истории развития программирования на habr: [https://habr.com/ru/company/oleg-bunin/blog/511430/ '''История IT. Когда компьютеры были большими…'''] и [https://habr.com/ru/company/oleg-bunin/blog/516218/ '''История IT. ООП''']
* 23.02.19 '''[[Проектирование для многообразия — конструктор и DSL вместо жесткой реализации требований (WIAD-2019)|Проектирование для многообразия — конструктор и DSL вместо жесткой реализации требований]]''' [https://uxspb.timepad.ru/event/860988/ '''WIAD-2019''' (площадка '''UX Spb''')]
* 24.02.18 [[UX: делаем систему удобной? - Нет. Делаем удобной жизнь! (WIAD-2018)]]
* '''[https://uxspb.timepad.ru/event/419865/ World Information Architecture Day]''' в Петербурге: '''[[От монолитных моделей предметной области - к модульным (Максим Цепков на WIAD-2017)|От монолитных моделей предметной области — к модульным]]''' ([[Блог:Максима Цепкова/2017-02-19: WIAD-2017 - очень высокий уровень выступлений и много интересного|'''отчет''' в блоге]] — много интересного)
* '''[[Process и Case Management (Максим Цепков на SECR-2016)|Process и Case Management в информационной системе: от автоматизации As Is к поддержке развития бизнеса]]''' на SECR-2016
* '''[[Коммуникация при различной структуре мышления - таксономия против фолксономии (Максим Цепков на AnalystDays-2016)|Коммуникация при различной структуре мышления — таксономия против фолксономии]]''' — схемы '''СМД-методологии''' для аналитика
* '''Диаграммы учета''' — фирменный способ CUSTIS представления учетных моделей ([[:Категория:Диаграммы учета|Все материалы]])
** Наиболее полная статья '''[[Когда всем понятно]]'''.
** Выступления в Санкт-Петербурге [http://econ-conf.spbu.ru Международный экономический симпозиум — Соколовские чтения]: [[Диаграммы учета как средство для наглядного и целостного отображения правил учета (Соколовские чтения-2017)|в 2017]] и [[Целостное представление деятельности предприятия на диаграммах учета (Соколовские чтения-2018)|в 2018]]
|-
|style="border: 1px solid #6688AA; background-color:#FCFFF0; padding:0.5em;"|
<html></html>
= Мой блог =

<big>'''[[Блог Максима Цепкова - оглавление|Полное оглавление блога]]</big>

{{Special:Wikilog/Блог:Максима Цепкова/Template:LastPostLog/1}}

[[Файл:Agile-Pryug-Scribing.jpg|400px|right|thumb|Cкрайбинг моего выступления [[Будущее уже наступило: от Agile к Бирюзовым организациям (Дни PR и маркетинга на Юге 2017)]]]]

{{Special:Wikilog/Блог:Максима Цепкова/Template:BlogInformerLine/24/sort=wlp_talk_updated}}

|-
|style="border: 1px solid #6688AA; background-color:#FCFFF0; padding:0.5em;"|
= Другие разделы сайта =
<html></html>
'''[[Доклады и Статьи|Мои Выступления и Статьи]], [[:Категория:Конференции|Отчеты с конференций]], [[:Категория:Книги|О книгах]], [[:Категория:Управление знаниями|Управление знаниями]], [[:Категория:СМД|СМД-методология]], [[:Категория:Общество|Общество]], [[:Категория:Экономика|Экономика]].'''

|}

Я буду рад любым комментариям и обсуждениям. Авторизация для этого через [[Служебная:Вход|регистрацию на сайте]].

[[{{SITENAME}}]] содержит {{NUMBEROFPAGES}} страниц.

Обсуждение:Я — Максим Цепков приветствую Вас на своем сайте

2026-07-24T15:12:44Z

MaksTsepkov:

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

Чтобы писать на сайте, надо '''авторизоваться''' - регистрируясь отдельно или через OpenID.

Сайт поднят на свободно доступной сборке MediaWiki [http://4intra.net 4intra.net] и там есть '''[http://wiki.4intra.net/Help:Contents Справка по использованию]'''

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

----
{{MaksWiki:Описание}}

Блог:Максима Цепкова/2025-11-25 - AnalystDays: как ИИ поменяет театр ИТ-абсурда и много другого

2026-07-24T15:08:02Z

MaksTsepkov:

{{Conf-Ref}}[[Категория:ИИ-агенты]]
Конференция [https://analystdays.ru/ru/program/137857 '''AnalystDays'''] для меня оказалась очень содержательным завершением темы ИИ, которая началась на [[SQAdays-2025b|SQAdays]] и продолжилась на [[Highload-2025|Highload]], [[ArchDays-2025|ArchDays]] и [[TeamLead-2025-Msk|Teamlead]] (ссылки ведут на мои отчеты). Основных векторов развития два: (1) '''приложения с ИИ научились технологично встраивать в ИТ-ландшафт''' наряду с обычными приложениями, переходя от DevOps к ML-ops и (2) LLM успешно работает как индивидуальный помощник или специализированный функциональный агент, и теперь пора переходить '''к проектированию команд и компаний в целом с участием ИИ-агентов'''.

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

Помимо выступления Димы, про использование ИИ рассказывали Reydan Yasar, Анна Гурова Дарья Рассказова, и все выступления были про уверенное использование, а не про эксперименты. А Елизавета Французяк рассказывала про создание продуктов на основе ИИ. Были и другие доклады, но я слушал только эти.

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

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

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

== Дмитрий Безуглый. От техписа к архитектору: ренессанс системного аналитика ==

В программе выступление называлось иначе, «Не техпис, а архитектор решений: тихое возвращение системного мышления», но смысл такой же. '''Вот логика рассказа'''.

# '''В будущем команды и компании будут смешанными из людей и ИИ-агентов.'''
# '''Для успешной работы ИИ агента необходимо организовать правильное наполнение контекста, в котором он работает.''' 

# '''Аналитики могут взять на себя эту задачу, став таким образом архитекторами компаний.'''

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

А теперь – подробнее. Сначала было несколько вводных о текущей ситуации.

* На заре своей работы руководителем проекта Дима придумал, как эффективно организовать работу, чтобы проект сделали в 10 раз быстрее. Начальство не оценило идеи: заказчик платит T&M, мы же столько бабла не получили! Он для себя сделал вывод: не кормите плохую историю.
* Последние два года аналитики стали получать больше продуктов и иногда больше разработчиков – но, наверное, так долго не будет, так что стоит смотреть на изменения.
* Продуктовый подход – когда в компании есть направление или инициатива, где '''бюджет на какой-то проект не ограничен'''. Если вам долбят мозг KPI и оценкой эффективности, то продуктовый подход рядом не стоял. А если делают нормы, сколько времени надо делать ревью документа – это уже нищебродство.
* Кто пришел за созданием классных решений? У кого корпоративный налог больше 50%? Когда прилетает чайка-менеджер и даже не говорит, что сделать, а просто страдает – ужас.
* В 90-е – 2000-е аналитики а архитекторы были взрослые, осваивали UML. Системный анализ тогда – о том, как делать так, чтобы потом не было больно при изменениях. Наступаешь – не говно и не грабли. И не надо обращаться к коучу или еще-кому из-за стресса…
* Реальность аналитика сегодня – героический техпис. Они пишут не нужные документы потому что, так положено. Да, есть люди, которые испытывают удовольствие, когда вычитывают документы. Ужас не в этом. '''Через 3 месяца после внедрения количество созданных проблем больше количества решенных'''.
* Современные акционеры сделали CIO персоной нонграта, потому что с 2000-х ИТ много просит и обещает, и ничего не выполняет. '''Вместо больших классных систем – куча переработанных хотелок'''. Если отбились от совсем треша. Jira-менеджмент и тикеты, ничего хорошего.
* Каждая строчка кода – маленький кусочек бетона в бизнес. Чем больше софта – тем сложнее изменить процесс. В 2014 было 70% интеграции, а сейчас 90% – попытка догнать уходящий поезд: станок законодательстве и идеи CIO. Бизнес становится медленнее и тупит, бизнес все медленнее принимает решения.
* Пришел Agile и сказал «с документацией задрали». В Райффайзене роль аналитика вычеркнули, 3 года аналитики были, а названия – не было. '''Agile – о том, что бизнес будет счастлив процессом, а не результатом. Если пациента нельзя вылечить, ему можно помочь.'''
* 70% фич – серый трафик поперек процесса, когда продукты доходят до разработчиков и просят что-то сделать, потому что объяснить зачем – не могут, не говоря уже о метриках результата.
* Накоплен долг: технический, организационный, когнитивный.
* Если enterprise achitect приносит архитектуру бизнесу ему говорят: «свободен, это было год назад, и вообще я и так все знаю».

Итого, '''мы имеем иерархическую систему, в которой бизнес, который никогда не видел клиента, ставит задачу разработчикам, которые не знают ничего о бизнесе компании'''. Аналитики в ней соединяют тех, кому ничего не надо (разработчики) с теми, кто ничего не понимает (бизнес). '''Иди туда и не спрашивай зачем'''».

Чем выше уровень – тем меньше спрашиваем «зачем». Сначала забрали у аналитиков смыслы, потом продукты забрали решения по бэклогу, AI сам напишет спецификации. Claude пишет лучше, чем аналитик с 1.5 года стажа. Пока ты поймешь, что аналитик нифига не понимает, а просто переваливает с одного на другого проходит полгода. Продукты за 15 минут с помощью ИИ генерят идеи, и спускают их аналитикам «вычитывай и сделай ТЗ».

'''Система мертва, а мертвое не может умереть'''. Поэтому в такой системе аналитики останутся.

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

Логичный второй уровень – мы только делаем ревью документа ИИ. '''Результат – потеря когнитивной самостоятельности'''. '''Как только компания действительно начала использовать ИИ, способность самостоятельно принимать решение атрофируется. За год.'''

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

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

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

'''Уровни управления''':

# Автоматизация – делегирование работы роботу
# Информатизация – управление информационными потоками
# Цифровизация (цифровые двойники) + AI первого уровня (личные помощники)
# Внедрение AI второго поколения – личные помощники и ИИ-агенты
# Внедрение AI третьего поколения – AI enterprise management, композитный workflow людей и ИИ

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

Сейчас мы помещаем в workflow ИИ-агентов. Они могут делать триаж запросов, или оценку ценностей или пинать аналитиков и разработчиков по задачам. Строим гибридный workflow из людей и агентов. В результате то, что раньше делали 2 отдела из 50 человек, может сделать один бизнес-аналитик.

Индивидуальные ассистенты. У OpenAI управление проектами работает хуже чем у Claude. Но в версии 6 они делают управление для руководителей компании, и это – другой фокус. Как iPhone когда-то сделал телефон для менеджеров, который не нужен технарям.

Чтобы это работало, надо проектировать пространство компании. Диаграмма контекстов и проектирование потоков данных для формирования контекстов. Для этого нужна роль системного аналитика 2.0.

У него уже есть 3-4 кейса, когда в компании используют '''вайб-менеджмент'''. Курсор, сотрудники 15-20 человек. Результат встречи – обнови задачи по проектам и добавь задачи, дальше ИИ дает изменения на ревью, можно внести или откатить. Информация из любых встреч распространяется по всем нужным контекстам – не надо быть на всех совещаниях. ИИ нормально решает задачи такого типа: возьми стратегический контекст и контекст отдела продаж, и проанализируй, что там не так. ИИ выдает адекватный анализ за 2-3 минуты. Так что большая часть запросов сверху-вниз «объясни мне как работает» можно убрать.

В презентации – схема контекстов вайб-менеджмента Димы, но рассказать он не успел

<ol start="0" style="list-style-type: decimal;">
<li>Миссия / Purpose</li>
<li>Управление: модель, структура, стратегия</li>
<li>Лаборатория (Discovery)</li>
<li>Люди (Орг.)</li>
<li>Получение ценности (CRM)</li>
<li>Продукты (Development и Delivery)</li>
<li>Партнеры (Экосистема)</li>
<li>Орг.компетенция и знание</li>
<li>Поддерживающие системы, инструменты, технологии</li>
<li>Маркетинг (visibility, brand, communication)</li></ol>

'''Возможные позиции аналитика в этой истории'''.

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

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

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

== Максим Цепков. Архитектура софта и бизнеса в сложном ИТ-ландшафте ==

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

Как обычно, я не пишу конспекта своих докладов. Презентация [Архитектура софта и бизнеса в сложном ИТ-ландшафте] – на странице доклада, она информативна.

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

== Светлана Доронина. Use Case для мэра, халяльный кешбэк и видеоприемы психиатра: любопытные задачи в работе аналитика ==

Аналитик сейчас очень часто сталкивается с нестандартными кейсами, и ему надо уметь погрузиться в контекст и найти решение. Светлана рассказала почти десяток разных интересных кейсов. Для работы она использует BABOK как базу знаний, BPMN для структуризации, а подходы agile и lean дают решение через итерации и эксперименты.

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

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

User journey map рисуем Этапы обращения. Не тривиально, что '''результатом этапа является эмоция пациента''', на выходе – облегчение. Для каждого этапа – точки касания, которые должны обеспечить нужный эмоциональный результат.

User story map – пишем все варианты, по опыту – бизнес их точно придумает, поэтому лучше иметь ввиду их наличие. А дальше – управляем через приоритеты.

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

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

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

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

'''Кейс-3. Оценка поведения пользователей для совместных закупок при заказе товаров стоимостью до 100 рублей'''. Совместные закупки до сих пор распространены в Сибири. Механика следующая. Организатор договаривается об оптовой скидке при определенном объеме закупки и организует ее, получая 16% комиссии. Люди подписываются на то, что хотят получить. Однако, требуемое количество может быть набрано не по всем позициям, поэтому ассортимент выясняется по факту, может быть меньше запланированного. И это проблема: покупатель заказал довольно много разного, а в закупку попала одна позиция за 30 рублей, например, пакетик конкретных семян, и ему за этими семенами надо ехать в пункт выдачи, да еще платить комиссию 25 рублей с заказа. Если бы в заказ попало все, что он заказал, то проблем бы не было, а так – ему не выгодно.

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

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

'''Кейс-5. Отказ от красных цитат на федеральном информационном квартале'''. Заказчик, федеральный канал, выкладывал новости на сайт в не читаемом виде: в статьях много цитат на красном фоне. Договорились провести исследования, A/B-тестирование с разными цветами. Оказывается, цвет читателю без разницы, если он не красный. А красный – раздражает, это сигнал опасности.

А еще был запрос разобраться: почему поисковики не выдают статьи? Оказалось, что большое число цитат, которое редакция считала преимуществом и требовала от журналистов, нарушает уникальность материала: цитаты копируют, а связки пишут свои. И читатели воспринимают статью с множеством цитат как copy-paste, а они хотят чтобы журналист проработал содержание. По результатам поменяли редакционную политику, число цитат снизили.

'''Кейс-5. Увеличение числа участников спортивной секции путем опроса'''. Секция скалолазания пришла с запросом: какие материалы положить на сайт, для новичков или опытных? Оказалось, что они получили грант на секцию, и теперь ее надо собрать, и сайт – одно из условий гранта. И она предложила провести опрос, нужно было не дорогое решение. По сути опрос информировал родителей про такую возможность: есть секция, она бесплатна, отвлечет ваших детей от телефонов, можно заниматься с родителями, и будут бесплатные летние лагеря. За счет опроса численность учеников увеличилась на 15%.

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

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

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

И в конце презентации – список различных инструментов.

== Reydan Yasar. От партнёра к катализатору: инструменты ИИ для бизнес-аналитика и владельца продукта ==

Докладчица – из Стамбула, Boğaziçi University. Сейчас есть много ИИ-инструментов, полезных в работе аналитика и product owner. И в выступлении было их системное представление. Инструменты поделили по способам вклада в работу: Partner – Catalyst – Connector, и для каждой фазы работы указали, какой вклад может быть внесен ИИ, в какой роли играет ИИ.

Фазы работы тоже интересны, они '''формулируются как ответ на вопросы''', и мне кажется такое представление любопытным.

* Why – changing business expectations, need for speed, здесь места AI нет
* Who – AI as Connector, bridge between the people, teams and systems
* What – AI as Partner, assists in day-to-day work step
* How – AI as Catalyst, accelerate creativity, speed and exploration
* Technical how – AI as Partner and Connector, technically connects into process, data flow and tool integration

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

* Partner: Elicit, perplexity. claude ai brainstorme tool
* Catalyst: POwerBA.ai – требования и flow, StoriesOnBoard, DALLE, Figma story map
* Connector: SpinachA – recording meeting. Notion, Miro, Dovetail

== Анна Гурова из 2ГИС. LLM: Анатомия цифрового болтуна ==

В выступлении был исторический обзор развития LLM и его внутреннего устройства.

Отмечу, что такие обзоров я слушал несколько, авторы выделяют разные реперные точки развития. У Анны были следующие.

* 1960-е. Розенблат персептрон. На вопрос «идти ли гулять» выдает ответ по состоянию погоды с весами. Было много лабораторий – это мечта о будущем. Но результаты очень ограничены, даже с ИЛИ не справляются. И развитие остановилось.
* 1980-е – метод обратного распространения ошибки при обучении: получаем ответ, сравниваем, и затем коррекция весов в обратную сторону по цепочке.
* 1990-е – распознавание банковских выписок и чеков. А потом – игровая индустрия, игра за персонажей. И так ряд других направлений. Но последовательная обработка контекста была ограничением.
* 2017 – архитектура трансформера, обработка контекста целиком параллельными потоками. Входные данные – любые. На этом основаны современные LLM.

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

Как LLM строит ответ на вопрос: «будет ли котенок играть с мячом?»

* Преобразует вопрос в токены, у каждой есть словарь. BPE, WordPiect, SentencePiece.
* Embeding – преобразование в векторное пространство. Расстояние между векторами определяется тем, что встречалось рядом. Котенок – Пушистый близко, Котенок – Нефто далеко. А вот Котенок – Черный – близко, и Черный – Yanm – еще ближе. Word2Vec, GloVe – статические модели. Learnable Token Embeding – коррекция векторного пространства через контекст. Если котенок – это наш логотип, то мы этому обучаем модель.
* Positional Encoding – разметка последовательности, в английском это важно. Итого, '''из вопроса получили набор векторов, где каждый токен в своей позиции'''.
* Трансформер получает вектор и преобразует его: Attention → Residual+Norm → Feed-Forming.
** Attention – как токены-слова влияют друг на друга, что будет, если убрать
** Residual connection – остаточная связь, на каждом шаге проверяем, что смысл не утерян.
** Normalization – убираем все лишнее из обогащенного
** Feed-Forming – обогащение смысловыми блоками, применяется к каждому действию. Котенок – субъект игры. Пример API^ собрали со всех пожелания, проверили – не потеряли ли смысл, обогатили тем, что сказали, доработали контракт, проверили – не потеряли ли суть, пошли на следующую встречу
** Идем циклично по слоям, пока не закончится, не останется несколько векторов
** Выбираем следующий вектор: максимальный вес, или ядерный – случайным образом, или как-то еще.
* В результате получаем развернутый ответ из всего, что оказалось рядышком.

Зачем это нужно понимать аналитику?

# Осознанно писать промпты и общаться с LLM.
## Модель понимает структуру, списки, и чем лучше задаете структуру – тем лучше модель поймет.
## Векторы – если используйте слова в специальном смысле, терминологию – модель не поймет. Задайте глоссарий.
## Модель усложняет смысл каждого слова отдельно. Если нужен json – напишите json.
## Помним про ограничения контекста. Если у вас очень большой объем текста – не впихивайте сразу. Если надо проверить договор, то запихнули целиком и спрашивают про платежи. Надо сфокусировать, например, на пункте три – про платежи. Делим на чанки.
# Контролируем риски.
## Галлюцинации: используй правила отказа, проси источники и цитаты из них. LLM по умолчанию идет вширь и вглубь, они выдумывают ГОСТы, если просишь выдать, а его рядом нет. Просить отказ надо явно.
## Устаревание данных. GPT-4 ничего не знает про GPT-5. Проверяй дату среза, используй RAG, добавляй актуальное в промпт.
## Потеря контекста: делим на чанки, используй резюме контекста и обновлять промпт.
## Ошибки интерпретации: добавляй примеры и антипримеры, делим задачу на шаги. Проси пошагово написать, что будет делать, а потом – попроси работать по этим шагам.
# Выбираем подходящие модели.
## Что я хочу? Instruction tuning, Generation, …
## Что важнее: точность, скорость или стоимость
## Длина контекста: context window и RAG integration
## Безопасность

'''LLM отвечают так, как будто живой человек. Но это не так. Она не думает о смыслах, так, как думаем мы, у нее нет ни здравого смысла, ни богатого личного опыта'''.

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

Что будет с приходом LLM? Многие роли поменяются. Но как – неясно. Но мы найдем место и адаптируемся…

Анна – амбассадор ИИ. Использует для валидации требований, проверки орфографии, создания тест кейсов, описания API. Примерно половину задач отдает LLM, потом проверяет и доводит результат. Не использует LLM, когда задача в узкой области или касается 2GIS процессов – надо передавать много контекста.

== Дарья Рассказова. Как с помощью ИИ провести обследование и сбор требований в новой предметной области ==

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

В состав ИИ-помощника входят: '''OpenWebUI''' – интерфейс, '''Ollama''' – запуск моделей, '''OpenRouter''' – маршрутизация, '''LiteLLM Proxy''', '''MCP Atlassian''' – доступ моделей к корпоративным источникам в confluence, это их внутренняя разработка. Система работает локально, но может обращаться к внешним LLM и API.

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

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

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

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

Подводя итог, ИИ дал не только инструменты, но и повод пересмотреть процессы. Не просто убрать рутину, а позволяет работать более качественно. '''ИИ работает не за нас, а вместе'''.

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

== Елизавета Французяк из Гринатом. От идеи до эффекта: как аналитики превращают гипотезы в ИИ-продукты ==

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

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

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

Поэтому сделали первый этап быстрой проверки гипотезы на практике. И для этого надо еще сформулировать критерии успеха!

Workflow получился из двух частей: сначала Гипотеза: Формирование → Исследование → Оценка результата, а уже затем Проектирование → Разработка → Тестирование → Поддержка.

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

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

Дальше идет исследование и разработка прототипа. Для оценки резюме использовали вероятность что кандидат дойдет до конца воронки. Это первый этап работы рекрутера – ранжирование кандидатов.

Прототип готовят так: data sciencetist выбирает модель машинного обучения (временные ряды, кластеризация и т.п.), для нее готовят данные и загружают. Это дешевле проекта, хотя и не мгновенно, занимает 2-4 недели, а в сложных случаев до 3 месяцев. Но это все равно не полный проект, который предусматривает настройку потоков данных, дообучение и так далее.

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

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

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

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

== Nikita Taskin и Anastasia Ilyina. Постанализ юзкейсов, или как спроектировать непрерывную ABAC-авторизацию UI и API ==

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

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

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

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

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

И появился социальный логин и делегирование проверки прав провайдерам, Policy engine, которые предоставляют набор прав пользователя. В 2010 концепция zero trust: явная проверка в каждом запросе, непрерывная авторизация, наименьшие привилегии и предоставление о взломе – враг внутри и надо отследить аномалии.

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

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

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

Use case – рисуют карту. Список задач, создание задачи – команда и атрибуты, найти задачу, просмотреть, редактировать, потом заархивировать. Табличное и карточное представление.

Фронт и бэк. Чтение – бэк, а отрисовка карточки в зависимости от прав – фронт, но при запросе на бэк тоже идет проверка прав.

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

Взаимодействие фронт-бэк идет по таск-API Post-Get-Patch.

Для версии-1 – достаточно было проверить роль команды, а для get – фильтр по командам. Можно ли сделать API-авторизацию на API-шлюзе? Нет. У него нет данных. А еще могут подделать данные. А запрос данных – сетевые взаимодействия, хотя можно кэшировать. Что делать, чтобы идея выиграла? Сделать кэширование, query-параметры. Я, правда, не понимаю, как это спасает от подделки параметров вызова.

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

== Александр Федоров из Райффайзен. От недель к минутам: как DBT + Airflow перестраивают работу аналитика и ускоряют процессы разработки ==

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

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

Идея решения – сделать платформа самообслуживания на основе DBT+Airflow, которая позволит аналитикам самим доводить задачи до результата, сделать витрину данных для пользователя.

* DBT – инструмент трансформации данных. ETL – находим на источники, загружаем и обрабатываем, а DBT трансформирует уже загруженное.
* Airflow – оркестрация рабочих процессов. Выстраивается граф, вершинами являются задачи.

Бизнесу – быстрое решение. Аналитикам – быстрая проверка гипотез, простые конфигурации на yaml и не нужен python. Инженерам – фокусировка на инфраструктуре.

Под капотом.

* dag-factory. Генерация dag-файлов по yaml
* cosmos – интеграция dbt в yaml
* ruamel.yaml – импорт сложных конфигураций

А чтобы прод не лег от тяжелых запросов, модели делают на предпроде, а перед выводом в прод – review.

Решенные проблемы

* несовместимость dag-factory и cosmos – хотя делала одна команда. Расширили своим парсером.
* большое количество дублирования и сложность файлов – механизм якорей в yaml чтобы выносить

Шаблон YAML – ключевой момент для описания yaml-конфигурации. И визуализация.

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

== Наталья Должкевич из Райффайзен. Критическое мышление: как не превратить анализ в драму ==

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

Ты строишь продукт, а получается монстр. Чем умнее человек, тем больше рисков сделать ошибку, если не умеет мыслить критически. Приходят: кнопку сделать зеленым, потому что я так думаю. А потом конверсия упала… Надо уметь отделать личные мнения от аргументов. Делали систему, в ней 12 полей у каждого контакта. Оказывается, большая часть пустые – если бы запросила данные, то не потратили бы кучу сторипойнтов.

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

Когнитивные искажения. Мозг действует по шаблонам и дорожкам, и делает это через искажения. Об этом был ее доклад на AD-19.

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

'''Приемы''': смена ролей, три глупых вопроса (что такое CRM, какова цель продукта), назначение антилидера-критика, реверсивное мышление (как сделать, чтобы на мероприятии никто не зарегистрировался), игра в заказчика, пять почему.

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

'''Критическое мышление начинается с вопроса «зачем»'''. Для нее это – главный вопрос.

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

А вот про чрезмерно сложные решения есть такая засада. Есть исследования командных ролей Белбина, и они показали, что Генератору идей, который как раз порождает сложные решения, обязательно нужен умный оппонент, чтобы избежать излишней сложности, обычно это роль Аналитик-Стратег. Обе роли могут совмещаться в одном человек (у меня это так), но оппонировать самому себе он не может, потому что для него собственное решение уже является простым. Хотя он может задать себе вопрос: «Как придуманным будут пользоваться?». Я в некоторый момент начал его задавать, и не только себе, но и другим людям, предлагавшим сложные решения. Если задаешь другим, то лучше так: «Мы сможем научить пользователей, или они будут обращаться к инженерам поддержки, а она – приходить к тебе, чтобы ты все настроил?», это помогает лучше, потому что Генератор обычно не хочет решать задачи поддержки. Подробнее про командные роли Белбина у меня есть [[Belbin|статьи и доклады]].

== Сергей Баранов. Как архитектура может обанкротить продукт и что с этим делать аналитику ==

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

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

Но архитектура – важна, Фаулер говорил, что архитектура – невидимый слон в комнате. Цена архитектуры – это не прямые расходы на лицензии и поддержку выбранной базы данных, это '''opportunity cost''' – какую выгоду мы не можем получить из-за выбранных архитектурных решений, какие ограничения она накладывает. Если выбрали Postgress – чем при этом пожертвовали? Выбрали супер-быстрый rpg, который в России знают только 150 человек – какие последствия для поддержки и развития?

'''Архитектурные решения часто дают невидимую сложность, которая несет когнитивную нагрузку''', и дальше разработчикам и инженерам сложно, у них стресс, который блокирует мозги – в результате они принимают плохие решения. Получается, что платим столько же, а ценности получаем меньше, потому что система сложнее. А дальше сложность накапливается, растет технический долг, идет деградация архитектуры. Есть оценки: объем технического долга в США 1.52Т$, а архитектурный из них – самый жесткий.

Еще одна цена архитектуры – '''cost of delay''', цена задержки поставки решения из-за сложности архитектуры. Ее тоже понимают плохо, потому что мыслят итерациями. МЧС, скорая, пожарные – те хорошо понимают. В ИТ цена пониже, но есть. Вывели фичу на неделю позже – и конкурент получил кусок рынка и возможность продавать дороже. Фича не вовремя – бюджеты выходят из под контроля.

Казалось бы, при чем здесь аналитики? Долг архитектурный – пусть архитекторы и разбираются. Но в SDLC есть analysis и design, там нет архитектора. А еще проблемы проявляются между testing и maintainance.

'''Где аналитик соприкасается с архитектурой?'''

'''Сбор требований'''. Аналитик фиксирует бизнес-задачу. Есть архитектурные ограничения. Правильный вопрос аналитика: можно ли реализовать требования в текущей архитектуре, как новая фича повлияет на существующие модули? Нужно формулировать требования в архитектрном контексте.

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

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

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

'''Добавление в бэклог'''. По задачам есть зависимость, в том числе – в архитектуре. И вполне может получиться, что из 100 задач 90 сделали, но ни один из 10 эпиков не готов.

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

Задача – построить стратегию разрешения зависимостей.

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

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

Реальный кейс. В одной компании постановки были проработаны на 120 задач, это 1.5 года разработки. Проработка новых – не имеет смысла. Что аналитики будут год делать? Они стали подключаться к тестированию и сдаче, и скорость выросла в 2-3 раза. И эти задачи сделали за 5-6 месяцев, и пошло по потоку.

'''Тестирование'''. Критерии приемки. И архитектурные проблемы. На малых данных ОК, а на больших потянет? Прод-данные, прод-поведение поиска… Сделали поиск по первым буквам – хорошо. А в продашн на каждую букву идет запрос к БД – база падает.

'''Новая фича'''. Нефункциональные требования (NFR) могут потребовать новых компонентов. Как фича может сломать архитектуру? В системе сделан шардинг по регионам, при этом маркетинговую компанию проведи только в одном, и нода упала от перегрузки.

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

'''Взаимодействие с архитектором'''. Аналитик пишет простое требование и думает “оно простое”, кнопочку изменить – а это по всем слоям изменить атрибут, и еще выгрузку поправить. Или фичей пользуются несколько пользователей, но она тяжелая и роняет работу остальных. Кейс года – для 3 сотрудников сделали отчет, который роняет БД на проде. В тестовом контуре все хорошо – там нет конкурирующих пользователей.

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

Новые типы решений – DSL, rule engine или новый COTS – какую технологию выбрать. Выбор между разными облачными провайдерами. Может, выбрав одного – мы получим недостатки у другого.

'''С чего начать аналитику?''' Барьер часто в том, что неясно о чем общаться с архитектором. Поэтому он в каждом месте вписывал вопросы. И объясняет архитектору: я хочу, чтобы мои требования вписывались в архитектуру. И сделать план по неделям. Для начала – встретиться, попросить рассказать, выявить долги, сделать реестр рисков. Потом выстроить практику совместного анализа требований (и у менеджера ее проявить), создать шаблон для ASR (архитектурно значимые трбеования), обучить команду.

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

Архитекторов мало, аналитиков – больше. Они часто конфликтуют. А будущее определяют они совместно, надо сотрудничать, потому что вместе – сильнее!

'''Вопрос-кейс'''. Есть требование, которое не лезет в архитектуру. Рефакторинг – 600 часов. Заказчик их платить не хочет, всегда за 50 часов делали – поверх старого. '''Ответ'''. Архитекторы планируют на годы, продуктовые команды – недели и месяцы. Была ошибка, или правильно, но давно. Накоплено много долга, управление арх.долгом – они известны, их можно встраивать в процесс. Построены они на принципах в agile-манифесте. Компрометация Agile – потому что его продавали как средство за 2 недели сделать то, что делали 2 месяца. Там про то, как не наращивать TTM. Он бы заглянул в Sonar-куб, и не накапливал новый, а при этом придется отдавать старый. И сделать точки расширения там, где требуется гибкость – и именно там делал иначе.

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

'''Вопрос: можно ли архитектуру?''' Архитектуру можно эффективно вынуть, у него был кейс: есть неделя извлечь знания из архитектора. Сделали воркшоп на 50 человек, в миро – быстрое восстановление архитектурных знаний. Для восстановления есть методика – у Сергея было выступление, оно записано.

== Татьяна Половинкина Цифровой колониализм мозга: как выжить в эпоху информационного цунами ==

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

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

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

* Зависимость от социального одобрения
* Страх что-то упустить (FOMO)
* Тяга к новизне, которую дает ориентировочный рефлекс
* Дофаминовые капканы

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

Что делать, чтобы этого не было? Есть простые практики.

* Солнышко в руках – от тревоги. Обнять себя и погладить, у каждого – свои точки
* Заземление: мы живем прошлым или будущим, а надо почувствовать реальность здесь и сейчас – она бывает прекрасна
* Замедление 4-3-2 – увидеть свое окружение: называем 4 предмета, которые можно увидеть, 3, которые можно пощупать и 2, которые можно ощутить (мягкое, скользкое)
* Жужжалка – зажать ушки и искать свой звук вибрации (нужно пробовать алфавит и разные гудения-жужжания) – он у каждого свой , и если найдешь – получаются интересные ощущения

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

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

[[File:AD2025b-Половинкина-Цифровой-аутизм.jpg|600px|Половинкина. Цифровой аутизм]]

Но вот если на инфографику всерьез посмотреть, как на способ диагностики аутизма, то становится весьма печально, потому что я увидел легкий способ '''навесить ярлык пожизненного заболевания практически любому ребенку'''. Реально. Я полез искать источники, и обнаружил эту инфографику в изданиях профессионалов: [https://znanio.ru/media/pamyatka_chto_takoe_autizm-42631 Рахматуллина Лилия Рамиловна. Памятка. Что такое аутизм?] (надо нажать «Картинками», чтобы посмотреть не скачивая), а в [https://infourok.ru/metodicheskie-rekomendacii-dlya-pedagogov-po-detyam-s-ras-2675077.html этом списке материалов] она на 3 слайде презентации Байкаловой Ольги Александровны, адресованного школьному психологу (второй материал в списке), при этом английский вариант этой инфографики тоже есть, и даже в стебном варианте, где одна из иконок заменена на «играет в minecraft». Поэтому мамы и папы, относитесь осторожнее к тому, что вам говорят психологи. Потому что учителя заинтересованы в том, чтобы вместо реальной работы с вашим ребенком, повесить ему ярлык сложного. Отмечу, что в 1930-е годы при переходе на массовое образование была аналогичная история: не слишком послушных или успевающих детей начали отправлять в спецшколы с особенностями развития. Тогда это пресек Сталин, заявив, что советскому обществу нужны здоровые дети, так что пусть учителя в школах делают свое дело, а не устраивают саботаж (цитата неточная и по памяти). А сейчас спасение утопающих – дело рук самих утопающих, вернее, их родителей.

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

Вопросы для самопроверки:

* Какую интересную книгу прочитали за последний месяц?
* Какая новая идея посетила за последнюю неделю?
* Когда я в последний раз останавливался – смотрел в потолок.

Книга Джеймса Клира «Атомные привычки». '''Основное – не ставить цель, а сделать вокруг себя систему, которая заставляет делать дело'''. Сделать привычку очевидной, сделать ее привлекательной (10 приседаний за тупление в канал), сделать легкой и сделать приятной. Информация отравляет мозг и душу, должна быть дозирована.

Цифровой детокс. Лагеря в лесу без телефона.

'''ИИ'''. Работа с ожиданиями. Вопли: LLM уничтожит способность мыслить. До этого тоже самое говорили про калькулятор. А Платон говорил: «мы разучимся помнить, записывая на бумаге». А про часы говорили, что мы разучимся жить в своем ритме, а будем подчиняться механическому прибору.

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

* Не надо переоценивать LLM. Искусственного интеллекта еще нет. С этим тезисом я не согласен: либо мы признаем за LLM наличие интеллекта, либо мы должны признать его отсутствие у большинства людей, потому LLM их превосходит, и я выбираю первое.
* LLM есть, и его надо уметь использовать: выживает не самый сильный или умный, а тот, кто может адаптироваться.
* LLM никогда не сомневается. Я не согласен, LLM оценивает достоверность ответа, и в ряде случаев продолжает поиск новых материалов, а не останавливается, то есть поступает аналогично человеку.
* Что бы LLM не выдал, именно вы проецируете это дальше, и ответственность на вас.
* LLM – для вас. Он хвалит и дает теплоту. Это верно.
* У LLM нет целей, нет мыслей, он не способен принципиально новый контент делать. А человек может оперировать символами и метафорами, формировать ментальные модели. Тут тоже не согласен: LLM может оперировать символами и метафорами, формировать ментальные модели, создавать новый контент не хуже человека – если ему поставить такую задачу. Задачу надо ставить, потому что LLM специально спроектировали без целей, у него есть одна предзаданная цель – продолжить разговор. А вот мысли у него есть, нет лишь активного режима внутренних размышлений.
* LLM не мыслит, а вычисляет, нет случайности. Это просто неверно, когда LLM выбирала самый вероятный ответ, то качество общения оказывалось ниже, поэтому там ввели специальный параметр, управляющий этим, который еще и настраивать в моделях можно.

'''Эмоции'''. Это очень рациональный механизм, который появился в ходе эволюции как способ выжить. Страх – избегание опасности. Гнев – движение к изменениям. Грусть – срубили деревья, а корни остались, вычистить пространство. Радость = благодарность: спасибо миру, солнышку, близким. Любопытство – поиск новых путей и возможностей. '''Эмоция – это энергия, эмоции – круто и здорово'''.

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

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

Важно повторять каждый день: качественно дышать, спать, есть, пить, двигаться. Замедляться и дальше бездельничать, получать качественный контент, завершать циклы стресса. '''Будьте куратором своей жизни''': что вы получите, листая ленту?

'''Любить себя? Нет, любовь – всегда про нескольких'''. Любить себя – уходить в одиночество, не надо.

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

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

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

'''Реплика'''. HR не смотрят на совместимость команд, и это боль. '''Ответ''' – нет, это не страшно. Да, есть тесты, можно организовать. Но она верит в двухстороннюю эволюцию команды: ты растешь в команде, и при этом команда растет в целом. И это хорошо. Не надо искусственно создавать хорошие условия. Я с этим согласен лишь отчасти: конфликты есть констркутивные, в которых мы движемся вперед, развиваемся и получаем результат, и деструктивные, где мы разрушаем себя, других и результат. Конфликты можно предсказать, оценивая совместимость, и HR должен позаботиться о том, чтобы конфликты были конструктивны и вели к развитию. Например, за счет того, что тимлид верит в эволюцию команды и умеет ее организовать. НО есть и другие способы.

== Анна Обухова. Сколько энергии нужно, чтобы быть аналитиком? ==

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

Для заинтересовавшихся другими выступлениями сразу напишу, что у меня есть сборка '''[[Анна Обухова и другие про нейрофизиологию в работе]]''' с моими конспектами, а на youtube поиск "Анна Обухова" дает много выступлений. На RuTube тоже есть, но меньше.

А вообще нейрофизиологи очень много узнали о работе мозга. А вот психологи не торопятся подвергнуть свои модели сомнению и пересобрать их с учетом нового знания. Меня это огорчало настолько, что пришлось попробовать сделать это самому, так родилась книга [[:Категория:Модель личности|Инженерная модель личности]].

А теперь – содержание выступления. К теме нейрофизиологии Анна пришла, когда работала в банке UBS: она руководила разработкой по ценным бумагам (security), у нее было 40 владельцев продукта и 60 команд. Идея в том, что мы работаем с умными людьми, рабочие станки у них находятся в головах, и если их настроить, можно увеличить производительность. Измерения говорят, что получаем 17% чисто на настройке мозга.

В организме есть 4 слоя энергии: внутри клетки, электрический, стрессовый, нейромедиаторный.

В каждой клетке есть митохондрии, и на мембране происходит выработка энергии АТФ, отрывается одна группа. Это – очень тяжелая молекула, на день нужно 40 кг. Поэтому запас клеточной энергии есть только на 5-6 минут, идет постоянный обмен и восстановление энергии в клетке. Расход обычно превышает восстановление, но восстановление быстрое. Устали на тренажере – отдохнули минуту-две – и готовы к следующему.

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

Мозг обеспечивает энергию на желание и действие. Упрощенная схема.

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

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

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

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

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

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

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

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

Вы получили плохой email, переживали – и теперь любой email – потенциальная опасность. Может быть более избирательно, не любой, а только от начальника или плохого клиента. Но это происходит еще до того, как вы email открыли. Миндалина говорит: энергия нужна на привычные действия. Бегать, орать, копать канаву будете быстрее, а вот думать – не сможете. При этом адреналин в крови распадается 15 минут, а вот у кортизола полураспад 1.5 часа, а значительные следы остаются сутки. И у вас все это время плохо работает голова. Быстро убрать Кортизол – не получится. Есть мышечные техники, но пока вы их делаете уже пришел следующий емайл. Так что надо успокоить себя и разжать эту причину, чтобы стресс не возникал.

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

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

Изменить из всего этого можно только уровень стресса. Определяют гаджеты по сердечному ритму – там разница биения. В теории можно по кортизолу, но его очень сложно надежно замерить, большие ситуативные вариации. У трубы дофамина есть сечение, и стресс показывает, сколько уходит на текущую деятельность, то есть не доходит до префронтальной коры. У Welltory есть более сложная модель, она выдает уровень стресса и отдельно энергию батарейки. Есть ресурсная модель человека, при этом не у всех размер батарейки 100%, в модели абсолютная шкала. Вот такой слайд требуемого уровня энергии получается.

[[File:AD2025b-Обухова-ДофаминЭнергия.jpg|600px|Обухова Дофамин и энергия]]

При этом есть ситуативные колебания. Человек сидит пьет кофе, у него 74% стресса, но ему нормально. А вот постоянно меньше 40% энергии – выгорание. Если энергии 42% и больше – человек смотрит вперед, строит картинки будущего в мозге. И чем больше энергии – тем дальше может отодвинуть. Планы на год – надо 60% энергии. Сидеть пить кофе, когда 60% энергии скучно: у человека пошли идеи, что бы такое сделать. А если сангвиник или холерик, то срабатывает сила сдувающая с дивана, и он бежит на две экскурсии подряд.

Что человек может в зависимости от уровня энергии?

* Для привычной работы на конвейере достаточно 20-25%
* Чтобы подлизываться к начальнику нужно 30-35%.
* А чтобы выдавать результат умственной работы, надо больше: в знакомых условиях – 35%, если условия – новые и надо адаптироваться – то нужно 40%, чтобы уверенно работала префронтальная кора.
* '''Уровень 45% – водораздел, на нем начинаешь понимать, что хочешь ты, а не только чего хотят от тебя'''. Не всем компаниям нужны сотрудники с уровнем 45+%, потому что с ними надо индивидуально договариваться. А ниже работают кнут и пряник, правда приходится разбивать задачи на достаточно мелкие кусочки, чтобы их понял крокодил.
* '''На 60% перестают бесить люди'''. До этого, если есть Вася, который лажает, то тебя лично оскорбляют результаты Васи, это личностный конфликт. На 60% мозг отделяет: есть Вася, он делает хрень, но это не конфликт меня с Васей, это конфликт меня с результатом, и человек может разобраться все.
* На 65% – появляются идеи, которых не было.

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

Добавлю тут, что после выступления мы обсуждали эти вопросы, и Анна сказала, что техника Worklife balance, колесо баланса требует 60+% энергии, для тех, кто уже устал она бесполезна. Спрашивать у утомленного человека, что он хочет бессмысленно, он хочет, чтобы от него все отстали.

Дальше выступлении Анна взяла профессиональный стандарт системного аналитика компетенции бизнес-аналитика от IIBA и выписала уровни энергии, требуемые для каждой строки, обязанности и IIBA. Для Junior достаточно 35-50%, но только там, где работа в освоенной области и с наставником. На освоение нового нужно 60+% И горизонт планирования у него месяц.

Среднее количество энергии офисного сотрудника – 33%, он не справится.

У Middle – кастомные процессы, а еще требуется, чтобы твои идеи воспринимались другими людьми, а это 55+% Получается профпригодность 55-60%, а для катомизации процессов 60-65%, и горизонт планирования год.

Компетенции старшего аналитика требует 60% энергии. Тимлидам, чтобы держать процессы, нужно 40%, для хорошего agile – 45%. Определение стратегии – 75% и горизонт несколько лет.

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

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

И в конце доклада – '''практики, как повышать и держать энергию'''.

# Общий смысл
# Работа со стрессам
# Вернуть дофамин – наполнить трубу

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

Вам может не действовать – ищите свою, таких практик много, и достаточно освоить пару, много не надо.

Как протащить энергию к префронтальной коре – модель AGROW (Action GROW). Там схема вопросов? которая обеспечивает движение, сначала смысл, потом переключение намерение-реальность.

# Что ты собираешься делать – какая задача?
# Частью какой большой цели она является?
# Как ты поймешь, что цель достигнута?
# Где ты сейчас (как ты)?
# Что уже сделано (как задача)?
# Что могло бы быть следующим шагом?
# Что будет следующим шагом?
# Когда начнем делать шаг?

Нельзя переставлять и выбрасывать куски. Вопросы 6 и 7 – похожи, но задаем два: если сразу 7, то может быть ступор, страх. Метод конфигурирует мозг, ч тобы начать делать задачу.

'''Актуализация результата'''. Я сделал задачу – и что, что я получил? Дает признание, что мои действия привели к моему результату – внутренний мурк, серотонин. Однократно – не заметно, 14 единиц, но на полдня есть эффект. А если 6 задач, то синдром горячей руки, состояние я офигенный, я справлюсь.

# Описание стартовой ситуации
# Перечислить все, что сделал (процесс, активный глагол)
# Описать результат
# Определить, зачем мне этот результат (как я его использую на благо себе)

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

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

Отмечу, что это – короткий вариант. В полном добавляется еще пункт «Как я могу рассказать это другим» – тогда задача превращается в часть личной истории и записывается в долговременную память. На AgileDays-2022 Анна рассказывала нейрофизиологию процесса, записи этого выступления нет, но есть мой конспект – по ссылки в начале раздела.

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

{{wl-publish: 2025-11-25 19:47:25 +0300 | MaksTsepkov }}

Категория:ИИ-агенты

2026-07-24T15:05:11Z

MaksTsepkov:

Тема применения ИИ-агентов в разработке - актуальная, и по ней у меня накапливаются материалы. Пока это статьи и отчеты с конференций, на которых очень много об этом говорили, а скоро, думаю, будут и выступления. Пока основное - статья на хабр [https://habr.com/ru/articles/1035522/ '''«Об организации труда ИИ-агентов»'''] (22.05.2026), она подводит итоги опыта предыдущих конференций. Однако в отчетах с [[Highload-2026-Spb|Saint Highload]] и [[TeamLead-2026-Spb|Saint Teamlead]] уже появились важные дополнения.

В категорию также включены мои ранние выступления о том, как ИИ повлияет на мир, а также посты-ссылки на материалы Левенчука про обучение LLM системному подходу.

[[Категория:Управление проектами]]

Блог:Максима Цепкова/2024-09-21: ПИР-2024. ЧИИЛОВЕК - человек эпохи ИИ

2026-07-24T15:01:50Z

MaksTsepkov:

{{Conf-Ref}}
Как обычно в начале сентября прошел [http://festpir.ru '''фестиваль Практики и Развитие (ПИР-2024)'''] - большая конференция тренеров, коучей, консультантов и бизнеса. Это 1700+ участников, четыре дня с 9:30 утра до 22, 13-17 параллельных треков, а потом еще ночное общение. Я участвую в этих фестивалях с 2016 года, и для меня это - способ навести фоус на ход развития бизнес-сообщества в целом, потому что специалисты помогающих профессий достаточно хорошо отражают то, что происходит.

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

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

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

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

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

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

Евгений Кузнецов на пленаре второго дня высказал такой тезис о будущем. У людей раньше не было возможности напрямую общаться с коллективным человеческим опытом, можно было взаимодействовать с отдельными книгами и другими артефактами. Сейчас она появилась, они могут работать со всем знанием человечества и корректировать свою картину мира. 20 лет назад у людей отняли право говорить "не знаю" - есть гугл, найди. А скоро не будет права говорить "не понимаю" - спроси ИИ, он объяснит.

Дальше будут мои конспекты выступлений. Часть из них я публиковал прямо в ходе конференции. Другие - после, и '''я продолжу это делать уже после публикации отчета, дополняя его'''. Конспекты разделены на три части: визионерские выступления про будущее с ИИ, практики использования ИИ и группа выступлений, которые с ИИ не связаны. При этом я был на малой части выступлений - ситуация, когда идет 13-17 треков не дает возможности побывать везде. Более того, приходилось пропускать заведомо интересные выступления, потому что параллельно шло что-то еще более интересное. Так, не удалось послушать Анну Обухову, потому что параллельно выступал Марк Розин.

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

* [[#Гарретт Джонстон. Неискусственный интеллект: человеческая контрреволюция в бизнесе переломных двадцатых годов]]. Это '''единственный из футурологических докладов''', не только на этой конференции, в котором был '''конструктивный образ будущего и его отличия от настоящего'''. Если кратко, то к 2030 году у большинства будет персональный AI-ассистент, как сейчас есть смартфон. AI-ассистент будет действовать в интересах человека, и это принципиально изменит устройство бизнеса. Сейчас бизнес придумывает и производит товары, часто недостойные, и с помощью рекламы и маркетинга убеждает людей их купить разными методами. AI-ассистент не будет смотреть рекламу, а будет оценивать товары по объективной полезности, оцениваемой по опыту использования других потребителей с учетом индивидуализации конкретного человека. Поэтому реклама и маркетинг умрут, а производителям придется делать продукты, у стоимость соответствует качеству, долговечности и другим реальным потребительским качетсвам. А еще место производства товара и известность не имеет значения, AI-ассистент будет договариваться с фабриками и кооперирвоаться с другими при закупке, это уничтожит маркетплейсы и оптовую торговлю.
* [[#Мое выступление: ИИ – зеркало человека. Страхи, возможности и перспективы обусловлены этим]]. Возможно, это нескромно, но я считаю, что у меня - наиболее реалистичная визионерская картина, хотя и не столь впечатляюще изложенная, как у Джонстона. Если кратко, то будущее - в сотрудничестве человека и ИИ, и это уже интенсивно строится. При этом экземпляров ИИ будет много и они будут разные, многообразие будет явно больше, чем, например, для сотовых телефонов.
* [[#Аркадий Цукер. Мышление и тупик. Или где нам нужен Естественный Интеллект?]] - хороший доклад про мышление, включая рекомендации о мышлении сообразно устройству нейрофизиологии, а не вопреки ей. Потому что ИИ, конечно, может помогать, но расхлебывать последствия своих действий надо будет человеку, а значит принимать решения лучше самостоятельно.
* [[#Сергей Переслегин. Искусственный Интеллект в фантастике и прогностике]] Сергей рассказывал свою модель шести технологических волн, включая фантастику. связанную с каждой волной. А потом, поверх этой базовой картины, наложил ИИ как существенный элемент начинающейся шестой волны. Но визионерской картины будущего он, на мой взгляд, не дал, он формулирует тезис, что тема была хорошо проработана в фантастике 60-х - у Лема и других.
* [[#Марк Розин. Личные и бизнес-стратегии в Шива мире – как жить в эпоху перемен]] - Марк рассказывал типологию возможных стратегий, которая родилась как осмысление тех вариантов, которые сейчас демонстрируют люди.
* [[#Вячеслав Дубынин. Биохакинг и усиление человека за счет технологий]] - рассказ о современных исследованиях человека, которые в перспективе должны дать персонализированную медицину. К сожалению, лишь в перспективе - известно множество частных корреляций, есть множество открытий по конкретным веществам, а модели человека среднего уровня, которую можно персонализировать, и которая бы учитывала не только генетику, но и индивидуальный путь развития, как не было, так и нет.

= Про будущее с ИИ крупными мазками =

== Пленар первого дня с практиками ИИ ==

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

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

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

'''2. Целеполагание ИИ'''. С этим связывают реальный прорыв к "настоящему ИИ". Хотя я считаю, что это - спекуляция, потому что написать скрипт, который каждое утро будет задавать ИИ вопрос "что сейчас правильно сделать для компании, учитывая вчерашние новости и внутреннюю переписку" - вообще не проблема. А у человека рациональное целеполагание устроено примерно таким образом - из вопросов по векторам.

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

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

==Сергей Переслегин. Искусственный Интеллект в фантастике и прогностике==

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

'''1.''' В начале доклада был тезис, что это доклад не практика, а прогностика. Прогностиков не интересуют технические детали. Зато интересует, что будет. При этом он опирается на социальные законы, которые говорят, что любое открытие обязательно реализуется, поставить его под контроль не получится. А надо уметь с этим жить. И любой технологический прогресс сначала предвкушают как утопию: будет радио/ТВ/ИИ - будет счастье, потом как антиутопию: оно случится - и мир рухнет, а потом - как киберпанк (это Сергей так называет, я бы сказал, что прагматика): вот оно случилось, будем с этим жить.

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

'''2.''' У Переслегина есть '''модель технологических волн индустриального общества''', начиная с 1760, в ней 6 волн, они примерно по 40-50 лет, и шестая началась в 2010-х с предполагаемым пиком в 2030-2035. Схема появилась как дальнейшее развитие концепции технологических укладов Шваба. Они ей пользовались, потом возникла практическая задача дать долгосрочный прогноз химической отрасли, пошли разбираться, выяснили, что Шваб в технологическом укладе путает две вещи: способ производства и реализацию этого способа в конкретный момент. Когда разделили, то увидели, что реализация способа производства связана с технологиями, и они как раз образуют технологические волны, более короткие, чем смена технологических укладов - меняется способ реализации за счет смены технологий. При этом пик волны виден отчетливо, а вот рост и падение - слабее, волны перекрываются. Они его выделили по реперным событиям, интегральное описание можно найти в инете - есть много картинок, а в презентации были детальные картинки по всем шести волнам, но, наверное, они тоже есть - Сергей много выступает.

'''3. Что важно: с каждой волной связана своя фантастика''', и об этом было подробно. Первая волна - Фауст и Франкенштейн, вторая - Жюль Верн, третья - Уэллс и Чапек, четвертая - фантастика 60-х: Лем, Азимов, Брэдбери, Стругацкие и многие другие, в лидерах тут США, СССР и Польша. Что важно - эта фантастика проработала вопросы ИИ, сейчас на это можно смотреть как на предсказания, а кое в чем это стало историей. И это было тогда, в 1960-х. Сергей подробно на этом останавливался, с конкретными произведениями, которые известны. Я пунктиром записывал, но пересказывать детально не готов. А интегрально - в этой фантастике люди осваивали космос, а роботы им помогали. И проблемы возникали не из-за восстания машин, а потому, что те чересчур тщательно исполняли приказ обеспечить людям безопасность и комфортное существование, а люди - это ж беспокойный элемент, комфортно они смогут существовать, только если поглупеют - что компьютеры и обеспечивали. И мне по этому поводу несколько раз вспомнилась шутка о том, что визионер - это тот кто знает страхи прошлого и умеет ими пугать, рассказывая про будущее. В данном случае предметом страха были фантастические антиутопии прошлого.

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

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

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

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

'''4. Собственно про ИИ'''. Сергей считает, что сильный ИИ не получится в ближайшие 5-10 лет по конструктивным основаниям. А именно, Шеннон дал определение информации как меры упорядоченности, по аналогу с термодинамикой, и наличие смысла в информации это определение не предполагает. Под это определение была элементная база в виде триггеров, и появилась архитектура фон Неймана и абстрактная машина Тьюринга, которые лежат в основе современных компьютеров. Поэтому работать со смыслами они не могут, а значит сильный ИИ невозможен. Да, можно поменять определение информации, но с новым надо пройти весь путь развития компьютеров, а это дорого и сложно, никто делать не будет.

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

Но вообще от этого вопроса сильно попахивает теологией - сильный интеллект отрицается еще и потому, что для него считается необходимым самосознание, а что это такое - никто не знает. Зато тот ИИ, который появился сейчас, определяют как "средний ИИ" - этой классификации раньше не было. Думаю, это просто для того, чтобы не признавать его как сильный. Что касается самосознания, то объяснить основания для решений - как раз та задача, которую компьютеры хорошо умеют делать, потому что речь идет об анализе конфигурации параметров, которая привела к ответу. Просто никто не ставил такую задачу в практическом залоге. Или, если точнее, она стоит в списке, но далеко, а вверху списка - повышение возможностей ИИ. Типа, лучше решение сложных задач без объяснения, чем с объяснением, но более простых. При этом ChatGPT и другие разговорные системы умеют удовлетворительно объяснять результат "от ответа", просто продолжая разговор и отвечая на вопрос "почему ты так думаешь?" Как часто делает человек, придумывая основания для решения уже потом, когда что-то решил или даже сделал. И для коммуникации и сотрудничества с людьми этого достаточно.

Далее Сергей полагает, что имеющиеся сейчас галлюцинации ИИ, особенно в части работы с числами показывают его уровень 5-6 летнего ребенка и это предел. Я думаю, это - незаконная аналогия, ведь ИИ - не антропоморфен. А галлюцинации - они легко убираются, через встройку проверки, это сейчас делают поверх ChatGPT, предлагая ему же проверить и исправить ответ.

А предсказания областей, где за человеком останется лидирующая позиция, на мой взгляд, исходят из преувеличенных представлений о возможностях именно человека в высокоинтеллектуальных областях. Сергей выделил три: (1) Создание схем - умение выделить важное и изображение; (2) Управление динамикой - моделирование; (3) Спонтанное метафорическое управление. По-моему, ИИ вполне это может.

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

'''5. Что будет интересного?''' Тут перечислено много пунктов, вектора - очень правильные, а детали, на мой взгляд требуют уточнения.

* Революция в юриспруденции. ИИ - субъект правовых отношениях. А еще законов в России - более 1 млн, и ИИ их узнает, и прокурор-адвокат-судья будут ИИ или будут использовать ИИ - нет состязательности процесса. Я считаю, что практически особой революции не будет, просто юристы и судьи смирятся, что понятие субъекта надо трактовать шире. А стороны процесса - да, будут использовать один ИИ, но вопросы задавать по-разному, получать разные ответы и решение будет выносить человек. Да, процесс будет другим, ну и что?
* Финансы - блокчейн, смарт-контракт, и не нужен всеобщий эквивалент - немонетарная экономика, или экономика под задачу. Тут я согласен, и добавлю, что это - хорошо.
* Революция понятия социальность. Цифровой фашизм или тоталитаризм, предсказание выборов по анализу соцсетей, вброс ботов для влияния, с 2016 уже соревнование ботов. На мой взгляд, это фиговая страшилка, не предскажет ИИ по соцсетям результат, а голосуют - все-таки люди, а не боты. Ну а политтехнологии развиваются давно, тут ИИ принципиально ситуацию не поменял, хотя динамика возросла.
* Мир Оруэлла и нулевой приватности. Ловим террористов - а потом любое инакомыслие. Как вариант - могут принять жесткий запрет о цифровой слежке. На мой взгляд, эта проблема вообще надумана. Ну да, живем прозрачно, и ладно.
* Производство, Управление, Война - эти слайды Сергей проскочил, посмотрю потом.
* Образование и воспитание. Контроль отрывается от воспитания. ЕГЭ не работает при прямом доступе через мозг. Надо сделать систему образования, которая проверяет: человек пользуется чужими знаниями или сам работает с содержанием - другой экзамен, другое обучение. Да, тут согласен, нужно другое. Кризис образования давно назрел, придется менять, на что - пока никто не знает. Но над проблемой работать и как-то решат. В конце концов, аттестат с оценками - не главное, хотя на него многое сейчас и завязано.
* Информационное переедание - ребенок в 8-11 лет станет информационно взрослым, в равновесии с ИИ - но тогда он должен получить остальные слова. Закончился подростковый возраст. Можем предсказать, но не готовы обсуждать. Другие навыки. Умение читать, суммировать, удерживать, умение ставить вопросы. Не длинная воля, а фокусное внимание. Письменность выносила в память, и ИИ - внешнее мышление, и тоже для умных. Тут я согласен, но, в общем, к этому не только технология ИИ руку приложила. Мир тут надо менять, как и с образованием.

А заключение было позитивным: ИИ будет в каждой семье и мы будем с этим жить. Преодолеем кризисы и выйдем в дальний космос.

== Пленар второго дня: Петр Щедровицкий, Евгений Кузнецов, Олег Замышляев, Данила Медведев, Андрей Масалович ==

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

'''Самый сильный тезис был от Евгения Кузнецова, с него я начну. У людей раньше не было возможности напрямую общаться с коллективным человеческим опытом, можно было взаимодействовать с отдельными книгами и другими артефактами. Сейчас она появилась, они могут работать со всем знанием человечества и корректирвоать свою картину мира. 20 лет назад у людей отняли право говорить "не знаю" - есть гугл, найди. Сейчас не будет права говорить "не понимаю" - спроси ИИ, он объяснит.'''

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

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

'''Данила Медведев''' озвучил взгляд на ИИ от менеджеров. Практически никто не понимает сценариев развития ИИ. Даже руководители компаний и их ведущие специалисты. Есть специалисты в мире, и некоторые - вменяемые. Но вменяемых не подпускают к принятию решений, а кто решает - несут ахинею. Руководители не понимают, что такое мышление, что такое ИИ - и чем-то управляют. Я тут замечу, что генерал Гровс тоже не понимал про атомную бомбу, а работу команды обеспечил, так что проблема в другом.

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

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

'''Андрей Масалович''' (в соцсетях - кибердед). Начал с реплики про мыслительные способности элиты: у его программистов есть присказка: документацию надо писать для полного начальника. Он проникся и начал заниматься ИИ в 1992, написал изучать, писать статьи, сделал статью "нейронные сети - оружия финансиста", стало денежно - 50 банков пришло. В конце 1990-х сделали программу - как выводить человека после мины лепесток. Повез в Европу, говорили "ты что, программа будет говорить специалисту? Еще скажи про беспилотное такси". И он переключился на другое, а сейчас вернулся к ИИ, уже с точки зрения безопасности использования. Это произошло 2 года назад в Катаре на чемпионате мира. Катарцы говорили, что занимаются ИИ. И используют ИИ для совершенствования законов. И тексты система лепила хорошо и убедительно. Только была проблема с логикой, а также с картиной мира, которая заложена обучением. Например, покушение на женщину в одних мусульманских странах приравнено к покушению на домашнее имущество, а в других - на домашнее животное. А чему обучен ИИ? ИИ знает разные точки зрения, если обучен на широких выборках, а система законов должна быть взаимосвязанной и желательно не сильно противоречивой...

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

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

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

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

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

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

Что ИИ умеет?
* Действия и планы - лучше 90% сотрудников.
* Управленческие решения - легко. Учитывая человеческие факторы.
* Стратегии - восхитительно
* Ценности - тоже восхитительно. Обгоняет в качестве, глубине и чистоте формулировок. Их вариант лучше, чем у людей.
* Формулирование миссии - тут спотыкается.

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

'''Евгений Кузнецов'''. Поговорка футурологов: они переоценивают скорость, но недооценивают масштаб. Мир через 15 лет изменится необратимо. Интернет - масштабные изменения, кто не хотел осваивать - ломались карьеры специалиста. ИИ не заменяет человека, он заменяет конкретные функции. И это - перепроектирование формата человеческой деятельности, меняет СРТ. Что случилось с таксистами. Раньше это была профи-сфера - надо знать людей, знать город. Сейчас таксист просто везет по навигатору. И это коснется каждой деятельности. В Китае судья должен советоваться с ИИ обязательно. И это придется всем попробовать.

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

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

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

== Александр Цыпкин. Интервью о возможностях ИИ==

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

Через года 2-3 с ИИ надо уметь взаимодействовать, это будет обязательно, как сейчас базовое владение компьютером или смартфоном. Восстания машин не будет, тут ИИ переоценен, но не так, как виртуальная реальность 5 лет назад - виртуальные шлемы и очки дома у единиц. ИИ будет использоваться активнее и будет суверенитет ИИ - как обосабливается интернет. И хорошо, что в России по ИИ есть задел - от беспилотных комбайнов до дипфейков. В студии Артема Лебедева ты можешь обратиться за лого и ни разу не пообщаться с человеком. А у человека заказать тоже можно, но дороже. Число людей не уменьшилось, ИИ надо заниматься, но объемы - выросли.

У него помощники используют ИИ для анализа данных и других целей. Цифровой аватар - пока нет. Рассматривал с точки зрения чтения, но пока низкое качество. Озвучка на всех языках - да.

Безопасность от фейков играет в обе стороны: фейк может вылезти, или реальное можно объявить фейком. Владение образом - проблема. У актеров, особенно молодых киностудия забирает образ и дальше использует. Есть идея сделать аватары Жукова, Рокоссовского, Конева. Дочь Жукова - за, есть те, кто возражает. Но вот кому будут принадлежать права на аватар Жукова?

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

Совет: стоит проанализировать рабочий день и честно ответить на вопрос, что можно заменить. Если больше 50 - вы в зоне риска. Как увольнением ткачей с заменой станками. А если начнешь активно использовать ИИ - то ты остаешься.

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

Цифровое бессмертие. - Оно уже есть. Приходит напоминалка про ДР, заходишь на страницу, читаешь. И забыл, что умер. Будет развиваться. Будет ли перенесено сознание - не думает.

И еще совет. Не ждите, зайдите в ChatCPT, поговорите, попробуйте midjourney. Это интересно.

== Мое выступление: ИИ – зеркало человека. Страхи, возможности и перспективы обусловлены этим ==

Мое выступление тоже было посвящено теме развития ИИ, как я ее вижу. Я участвую на многих конференциях, в том числе в ИТ, который тоже интенсивно осваивает ИИ. И отчетливо вижу следующее.
* Страхи перед ИИ - часть общей индустрии страха, которая является составной частью механизма управления обществом. За публичными страхами лежит опасения тех, кто управляет, что развитие ИИ, как и других технлогий, может сломать нынешние механизы управления и отстранить от власти и доходов те социальные группы, которые ею обладают. Остальное - следствия.
* ИИ развивается, период начального освоения уже прошел, и сейчас идет массовое освоение ИИ как помощника, создаются субъекты ИИ и это не является эксклюзивным умением, а носит массовый характер.
* Появляются технологии локального развертывания сложных моделей ИИ на серверах и даже мощных ноутбуках, компании это активно осваивают, и это откроет массовое освоение технологий обучения и дообучения ИИ, которые пока не распространены широко, поскольку пока количество экземпляров было ограничено.
* Будущее - в сотрудничестве человека и ИИ, и это уже интенсивно строится. При этом экземпляров ИИ будет много и они будут разные, многообразие будет явно больше, чем, например, для сотовых телефонов.

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

==Гарретт Джонстон. Неискусственный интеллект: человеческая контрреволюция в бизнесе переломных двадцатых годов==

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

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

2. Ленин: бывают десятилетия, когда ничего не происходит, и недели, когда происходят десятилетия. Лето 2024 - старт очень больших изменений. Переход от 5 к 6 технологическому укладу по Кондратьевским циклам. Пятый был про людей, которые создают удивительные технологии. А шестой - про технологии, которые создают и меняют людей. Человек становится объектом процесса, а не только субъектом.

3. Образ будущего, который дальше, будет реализован к 2030. До СВО и Газы он оценивал срок в 2035, эти события резко интенсифицируют развитие.

4. К 2030 каждый будет со своим цифровым двойником и AI-ассистентом. Как мобильный телефон, который сейчас есть у каждого. Ассистент обеспечит шопинг, путешествия, организация жизни, автоматизация рутины, каждый день на всех уровнях.

5. Ассистент принципиально поменяет бизнес. Иллюстрация - на примере ухода за зубами. Берем простую зубную щетку 2$, добавляешь камеру, она будет стоить 10$ - и каждый день получается мини-фильм твоих зубов. Этот фильм отправляется специализированному ИИ, где сравнивается с другими миллионами таких фильмов и проводится анализ на всех уровнях.
* discovery - фото сегодняшнего ужаса и изменения от вчера.
* descriptive - В чем причины такого состояния твоего рта.
* predictive - что будет, если не поменяешь через год
* prescriptive - что надо делать, чтобы изменить
* deductive - возможные сценарии развития. Что будет, если перестанешь бухать, но будешь есть шоколад и наоборот

6. Такая конструкция принципиально меняет картину. Сейчас стоматологи убивают кариес, а такое наблюдение устраняет его причины, кариес вообще не появляется. Понятно, что тут будет противодействие. Интересы врачебного сообщества - твой карман, а не рот или тело, рот - способ добраться до кармана.

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

Маркетинг: заставить людей захотеть купить. что делает компания. А задача будет иной - делать то, что нужно. От make people want things к make things want people. Смерть продавца - death of a salesman! Это уйдет в прошлое со скоростью, которая будет удивлять.

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

9. И это поменяет всю систему бизнеса. Ей уже 5000 лет: в древней Месопотамии, в Ур была реклама! Нынешняя схема - бизнес создает продукт, он определяет целевую аудиторию и дальше - воронка продаж wareness - consideration - intention - purchase - loyality, осведомленность - заинтересованность - намерение купить, покупка, повторные покупатели. А тут на каждый продукт будут знать, сколько покупателей. И если продукт говно, то маркетинг не поможет его продать.

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

11. Ассистент - личный DJ, личный карьерный советник с 5 лет, твой стиль, секси-стиль, оригинальность, бренд. Цифровой двойник, чтобы дать лучшие результаты. Первая задача - узнать тебя, понять таланты, любовь, силу, слабости. Психология, финансовая ситуация, SWOT-анализ 24 часа в день по всем фронтам, про тебя и твоих людей. Он не знает лучше, но ничего не забывает. И про окружающий мир. Перед рекомендацией зубной пасты - не только анализы щетки. Он читал все книги по стоматологии. И все исследования и видео. А оплата ассистента - по модели GPT, подписка.

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

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

13. Переход от Web2 к Web3. И это одна из причин нынешней нестабильности. Web2 - данные у маркетплейсов, они обрабатывают в своих интересах. Web3 - данные у тебя, ты - суверенный человек. А блокчейн - технология фиксации правды, и это - святая вода для дьявола. Web2, google - don't be evil. Web3 - can't be evil. А это сужает пространство маневра для тех, кто сейчас держит рынки. Идет падение доверия к игрокам, которые навязывают товар. Web3 гарантирует правду через распределение ответов, закон больших чисел. Блокчейн - не криптовалюта, а инфраструктура правды и инфраструктура взаимодействия между ассистентами.

14. Бизнес. Soft съедает мир, а ИИ съедает софт. Все что можно будет автоматизировано. Даже там где дешево, в Индии. И принципиальный вопрос - ради чего автоматизируется? Какое будущее хочет компания?

Бизнес-стратегия - способ достижения цели. Для определения цели нужны идеологии. Компьютер умеет экстраполировать, а образ будущего надо создавать самому. Куда я иду и зачем я иду туда.

Вы все равно должны думать - почему бы не думать по-крупному? Никогда не соглашайтесь на что-либо меньшее, чем экстраординарное. В ем большая идея твоего бизнеса, смысл существования. Удивительно мало компаний могут ответить. Коротко, ясно, ценно. А от ответа - зависит результат.

15. Стартап - много интересных идей. К 10 году становятся одинаково, везде менеджеры, лучшие практики от консультантов. Человек живет дольше, компании умирают моложе. Когда родился компании жили 60 лет, сейчас - 13.

16. Что такое идеология? Если бизнес сдохнет - о чем другие будут плакать. Как торгаш - будешь не нужен. Если ты незначим - ИИ возьмет. А если значим - то чем. Что будет написано на твоем надгробии?

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

Большая идея является прямым или косвенным месторождением твоих инициатив. ИИ не сделает большую идею для тебя. Именно она даст фокус жизни.

17. Моря 20-х будут сложными и турбулентными. У одного корабля есть идея, у другого люди за деньги. Второй не допрет в тяжелых морях. Он ирландец - он знает. Дисциплина и цель. Путь может меняться - погода меняется. Но цель должна быть.

Volvo - все для безопасности. Еще в 1971 - компания рекламировала безопасность тех, кто в машине, а не машину. И поэтому берут. В 2007 китайцы предложили выкупить полностью за 2-кратную стоимость. Шведы отказали продать, потому что у инвесторов безопасность не на первом месте.

Я отмечу, что этот пример недостоверен. Оказывается, производство легковых автомобилей Шведы еще в 1999 продали Ford, который в 2009-2010 продал это китайцам. А основной вольво производит грузовики и автобусы. Так что безопасность стала маркетинговой штукой.

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

19. Инновации будут автоматизироваться ИИ, а изобретения - нет. ИИ хорош в инновациях - это оптимизация, перебор вариантов. Русские хороши в изобретениях, но не в инновациях. Но ИИ сделает. У китайцев наоборот, хорошо с инновациями, с изобретениями плохо. И это не решится.

20. Цифровой завод будет у всех. И это - не то, за сет чего ваш продукт дойдет до потребителя. А надо дойти.

21. Россия собирается стать топ-3 экономическим игроком мира, обогнать Индию. Он уже топ-3 военный и ресурсный. Сейчас Россия 43-я, надо многое менять.

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

= Практика использования ИИ =

==Артур Крылов. ИИ в городских проектах: павильон на форуме-фестивале Территория будущего. Москва 2030==

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

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

И много другого.
* Проект Москва глазами москвичей - много реальных фоток Москвы, удаляли фон, обрбатывали видео чтобы была Москва будущего. Дальше в фотобудке фотогравировали глаза, шла автоматическая обработка, это улетало на большой экран, а тебе делали персональную открытку.
* Цифровые аватары из реальных лиц людей с заменой окружения и брендированием рамки.
* Картина Москва будущего. На базе огромного количества изображений от нейросетей. Улицы, активности и многое другое. Доработка с художниками. 164 кв.м. Нижнюю часть не закрашивали, и ее закрашивали участники.
* Детские раскраски - создание картинок с помощью ИИ. Причем делали целиком одним промптом.

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

==Вениамин Кизеев и Данила Драпеза. Как повысить свою продуктивность с ИИ. Кейсы, практики, куда нажимать? ==

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

'''1. Цель''' - самое сложное. И здесь ИИ не поможет, это личное. Потому что настоящая цель принципиально меняет твое состояние. Поставил цель выступить в триатлоне - и появляется 28 часов тренировок в неделю, массажисты, сауна, баня, специалисты по таблеткам как средство достижения цели, и вот этот шаг - я пойду - надо сделать самому. А вот проработать способ достижения ИИ поможет. О целях - книга Джим Коллинза Good to Great, от хорошего к великому.

'''2. Стратегия'''. Это не оптимальный план, а ключевые принципы для достижения цели. Принципы просты: хочу пробежать марафон - каждый день 10 км; хочу сделать хорошую выручку - делаю каждый день три компреда. Естественно, без халявы, а то цель не достигнешь.

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

Берем фреймворк запроса RTF: role - task - format. Выступи как организатор мероприятия, сделай для меня план выступления и выдай в таком формате. Или как профессиональный тренер создай мне пошаговый план тренировок на год.

Настройки. Действуют на чат всегда.
* Мой портрет - описание себя
* Постоянные вводные - обращение, язык ответа и так далее, добавляется каждый раз. Не просто опиши план игры, а рассуждай. И теги: если я пишу "рыба" делай вот это.

Если нужны картинки, запрос в формате Объект - Фон - Стиль. Что показать на каком фоне и в каком стиле изображение.

Итого, стратегия это принцип плюс ключевое действие.

'''3. Ресурсность, возможности'''. Тут важны тренды. И не 1 раз прочитать, а раз в неделю один час смотреть.

Есть три типа проектов:
# Масштабирование - увеличиваем то, что уже делаем%
# Повышаем Эффективность
# Придумываем новые способы действовать.
Большинство наших проектов - 1, а инновации - 3.

Perplexity.ai - помогает искать информацию на ИИ. Обычные поисковики ищут слова, а тут можно вводить контекст что ищем. Бесплатно. Источники: сети-академические источники-видео-соц.сети (обзор общественного мнения). Он показывает что нашел и где читал, ссылки на источники - это снимает проблему ChatGPT, который не показывает источник. Может работать с вашими документами - прочесть документ и сделать summary или табличку. И можно дать задачу собирать каждую неделю ресурсы в Perplexity.ai

ChatPDF.com - работает только с вашим контекстом. Позволяет закинуть много документов и получить summary.

Ресурсность.
* Ментальное развитие - интеллект. В России мы перекачанные, сравнивал с Австрием и Стэнфордом, где работал. Перепрошивать себя
* Эмоциональный интеллект. История. Работал в Юте, отправил в церковь 10-11 лет, профориентация. Выписали 12 профессий, каждый месяц прожить и оценить. Другой - готовится к ответу.
* Физика. Тело свое знаем хуже. В компании есть доктор, объясняет. Много вопросов решают локально - попить марганец, поспать больше... Он бегает марафон, а когда серьезное - ходит в горы. Вокруг датчиков, которые меряют. И они дают итоги. Welltory, здоровье фитнес.
* Духовное развитие - умение проявлять волю и умение терпеть - развивать дух. Голову расслаблять менеджеру не нужно, ему надо тренировать фокусировку - и медитация это тоже позволяет, доведи фокусировку на 5 минут.

Для медитации можно использовать GigaChat, в нем есть ролевые модели, и одна из них - медитация. Дальше будет набор вопросов, после ответа - текст и музыка чтобы медитировать.

ChatGPT тоже можно, поставить его в позицию коуча, который должен подготовить медитацию - и он сделает. А потом suno для генерации аудио и музыки.

С телом. Люди стали меньше курить ипить, потому что некогда восстанавливаться.

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

Есть приложение founder.ai - отправляете описание проекта, и он по вашим социальным сетям на два шага делает подборку подходящих людей по задачам. Сейчас там, правда. очередь - он стал популярным. В России есть socap.ai, и на рынке много аналогов. А еще в perflexity можно отправить запрос, он тоже умеет получать информацию по соцсетям.

'''4. Процессы и проекты'''. Наш мозг настроен на процессы. Каждый день одинаково. PDCA - шлифование процесса, а HADI - в условиях неопределенности. Чтобы развиваться 2 раза в год, в квартал проверить 100 гипотез до тестирования на клиентах, это - их цель. Позапрошлый год были маркетплейсы, прошлый год - коучинг. А друзья растут 8 раз в год, и для этого проверяют не 100, а 400 гипотез, и гипотеза не на 25%, а удвоить.

Для организации Dola AI, heydola.com - там встроенный календарь, интегрируется с другими календарями, интегрируется с мессенджерами и шлет уведомления. Еще выступает в роли ассистента - как подключиться, поставить встречу по фотке и так далее, она понимает инфо на изображениях. И сводка новостей, как perplexity.

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

tldv.io - cтавится и ходит на встречи: подключается, делает запись, транскрибирует, позволяет взять кусочек видео и отправить, можно обработать транскриб чтобы получить сводное. Да еще запланирвоать в календарь, если все получила. И можно скормить записи. Если малая команда - бесплатно.

'''5. Команда'''. Есть ИИ, которые смотрят статистику общения в чатах, вытаскивает статистику, понимает шаблоны и раздает.

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

Это - малая часть, на рынке есть 4000 готовых решений, которые возникли за 2 года.

В прошлом году они сделали курс полностью средствами ИИ. Отмечу, что меня тогда впечаитлил их рассказ, я об этом кейсе много рассказываю, а в отчете [[ПИР-2023]] можно прочитать конспект. За год курс прошли 794 человека, потратили на него 23к. И можно говорить о том, что цифровые аватары вовлекают не хуже, чем реальные люди. 60% отправили курс друзьям. Будущее - скоро все курсы будут на ИИ.

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

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

==Екатерина Попова и Даниил Семин из Фаберлик. Прикладное применение ИИ в бизнесе==

Виртуальная Саманта в плейбое ведет инстаграм. История монетизируется быстро. Космо в марте 24 сделал обложку с ИИ.

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

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

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

А еще сотрудники используют, чтобы писать письма и делать рассылки, карточки и открытки. Это просто и экономит время. И они не драйвят, люди сами начинают использовать, потому что это удобно и просто.

Цифровые инфлюенсеры - создавали. Достаточно похоже на живого. Heygen - цифровой аватар, создать легко, получается 12500 за час получается. В чем нюансы:
* логотип - текст, он бывает плывет, и есть watermark в углу, можно что-наложить поверх в готовом видео.
* Русский язык - не родной, поэтому текст, паузы, ударения - надо следить.
* Для перевода мимику и движение рук берут из оригинального видео.

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

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

Курсы сейчас сильно поверхностные. Надо пробовать самому, а не идти учиться. Потому что инструментов много, и вариантов. Надо искать экспертов, консультироваться по конкретным кейсам. Есть недорогие хороший курсы, их дизайнеры проходили курс по midjourney за 560 рублей, получили кучу практики. Которой не было в других курсах за 50к, который проходил другие. Ссылку на дешевый курс обещал отправить интересующимся по запросу, и это - не реклама, это просто опыт.

==Ольга Ладога-Ячменёва и Гульнара Исмагилова. Новые ИИ коллеги в командах ==

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

Они создают двойников реальных людей, а также виртуальные образы.
* Двойник стейкхолдера клиента, используя публичные материалы, при этом с дополнительной вводной "ты работал в этой компании, но недавно уволился", и просят его оценить материалы.
* Двойник человека, от которого хочешь высокую оценку каких-то материалов, например, публичных выступлений.
* Образ своего клиента из определенной социальной группы, представляющего сегмент рынка. Фактически, это расширение давно известного метода персон, но у такого двойника можно спросить мнение.
* Мнение эксперта в команде - создают двойники экспертов по публичным выступлениям, и спрашивают его по рабочим вопросам.
* Двойники для ушедших сотрудников из команды.
* Наоборот, потрет идеального члена команды, когда ищут нового сотрудника.

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

= Остальные выступления =

== Аркадий Цукер. Мышление и тупик. Или где нам нужен Естественный Интеллект? ==

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

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

Итак, конспект.

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

Мышление - совокупность когнитивных способностей, помогающих решать задачи. Они выделяют 6-аспектов.
* Эмоциональный интеллект - как воспринимаем эту жизнь, оцениваем окружающую действительность, без эмоций деятельность не появятся.
* Телесно-чувственный интеллект - его ведут эмоции.
* Контекстный интеллект - оценка внешнего контекста, правил, ограничений
* Социальный интеллект - переработка сигналов от других людей, зеркальные нейроны, эмпатия.
* Компетентностный интеллект - экспертность, профессионализм, назначение
* Креативный, творческий интеллект, который задает целостность и красоту, связан с эмоциями.

Такая конструкция делает естественный интеллект априори неповторимым на искусственным. Она проживается субъектно, и потому уникальна. Мы можем описать, ИИ может подстроиться, но не может прожить.

Четыре функции мышления.
# Осознание и интерпретация естественной среды. Мы ориентируемся вокруг. ИИ может быть частью моей ориентировки, но не более. Я в голове переработаю часть данных.
# Оценка происходящего. Любая оценка другим интеллектом - будет чужой, будет материалом для моей оценки.
# Никто не может решить за меня, решение принимаю я сам. Согласие с рекомендацией - тоже мое решение.
# Поиск решения дилемм, проблем и трудностей.

Дальше фокус в докладе был на последней - тупики в бизнесе. У них 5 уровней
# Мотивационный - не хотим.
# Компетентностный - не умеем.
# Технологический - не знаем как.
# Ценностный. Не видим смысла
# Онтологический. Задача решаема? А что, так можно было?

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

Если это тупики - то возникают надежды на ИИ. А надо решать нам самим! Это надо прожить самому! ИИ будет лишь помощником - поставляет информацию. Это как "поешьте за меня".

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

Человек всегда одинок - потому что ему надо решать самому. И это никто отнять не может. Остальное - сервисы.

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

Мозг каждый раз рожает кошмары. Это встроенный механизм: я нарисовал кошмар, будет лучше - радуйся, а если так - я тебя подготовил. Ситуация: 12 ночи, ребенка или половины нет, и абонент недоступен - что порождает мозг? Да, в разных картинах мира. Так и с маткой: мозг говорит "человечество вырождается, хватай самку и беги" - а не позитив "сколько женщин сможет иметь детей"

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

Кейс. Конкурент повысил цену, нет инфы, нужно решение: повышать или нет? 50 на 50. Если ты можно спросить ИИ, он ответит - но дальше надо переварить. И можно получить разные рекомендации, в зависимости от вопроса. Который ты задаешь сам.
* Новую инфу надо сопоставить со своим опытом - и это никто не скажет.
* Преодоление ментального и социального сопротивления - любое решение потребует изменения поведения.
* Креативные пробы и креативное конструирование. Идеи со всего мира, но только ты сделаешь и выберешь приемлемое

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

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

Инструменты.
* Вопрос. Кажется тривиальным, может генерировать шаблон, а может генерировать смысл
* Постановка проблемы. Чтобы не закошмарить, а генерить.
* Векторная цель
* Создание прошлого
* Оформление настоящего
* Формирование будущего

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

Создание прошлого.
* Ключевые события. Что самое яркое запомнилось за период?
* Люди и встречи. Кого встретили, какие вызывают теплоту - коммуникативный слой
* Инсайты - что двигало, какие открытия.
* Благодарности
Когда вот так оформляем прошлое, но начинает порождать смыслы.

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

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

А теперь, как я обещал, '''мои тезисы-возражения'''.

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

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

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

А побудительный фокус доклада: не надейтесь на ИИ, решайте и делайте сами - я поддерживаю.

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

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

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

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

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

==Татьяна Мужицкая. Три оси, на которых держится мир или ИИ нас не заменит==

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

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

Рассказ был острый, с шутками и пирожками, но это надо смотреть запись. И в конце было упражнение - как поднимать энергию. Очень простое - ставишь будильник на 20:24 (в честь года), и по нему вспомнинаешь почему ты сегодня молодец. Или 10 хороших событий. Или 10 благодарностей богу за день. Это сбор дофамина. Вопрос может задать ИИ, а ответ - сами, иначе дофамина-то не будет! Приложение для медитации не будет за вас медитировать. И еще пара техник - на замедление и тактильных.

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

==Александр Гальчин. Сойти с ума и выиграть: парадоксальные приемы в бизнес-коммуникациях==

Как всегда, искрометный и профессиональный доклад про темы и инструменты на материале коучинга руководителей. Надо понимать, что вы для своей жизни - главный руководитель и все это надо использовать. Что отличает руководителя? У них два запроса. (1) Как эффективно достигать результата, и они готовы на эксперименты в средствах достижения, если это даст эффективность. (2) Как, достигая результата,оставаться живым. Живое дает доступ к интересным вещам. И дальше были инструменты коуча по группам: смех, секс и смерть.

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

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

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

Инструмент смеха, который приводит в ресурс - осознанное сумасшествие. Придти на топовую встречу в разных носках. Зайти задом наперед. Дать картинку совету директоров - вы как старейшины племени. А потом рассказать: у ацтеков совет старейшин сидит на горшках со спущенными штанами.

Но! все эти образы и шутки надо подбирать под клиента персонально. Шаблоны тут не работают, есть опасности. К следующим инструментам тоже относится.

Секс. Фаллометрия, и у мужчин и у женщин. И в это надо играть.
* Уметь мериться - переговоры между новыми об этом, win-win туфта, если ты без сильной позиции, потому что тебя сначала прожимают и если ты поддаешься - он прожимает, зачем ему win-win
* Уметь во-время прекратить. 10 минут померялись, увидели силу и дальше отложим в сторону и перейдем к обсуждению. Второе бывает не развито. Все время меряться - выгорание, конфликты, не решается задача или за большая цена,

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

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

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

Люди ставят ментальную команду удерживать высокое состояние - а оно требует ресурсов, отвлекая от содержания. Держишь постоянно спину прямо - а дыхание прекратилось, ты не в ресурсе.

Правильно: перезапускать, воспроизводить, управлять. Потерял-восстановить. Контакт с телом очень важен. Но его надо проверять и перезапускать при необходимости. А если путаешься удерживать постоянно - тело не живое.

Смерть - табуированная тема в культуре. Физическая. И социальная - отказ, расставание, банкротство, позор. Осознанный контакт со смертью делает твою жизнь живее. И помещает в топовое состояние. Самурай. Предстоит битва, останусь ли жив - вопрос к богам и звездам. Но пока жив - иду к победе.

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

==Марк Розин. Личные и бизнес-стратегии в Шива мире – как жить в эпоху перемен==

Дополнение: [https://www.ecopsy.ru/upload/iblock/ad5/e4nvn3ifdxn8q05ou44jmebh1w4ytz6y/Osoznanno-zhit-v-SHIVA_mire_Mark-Rozin.pdf '''Статья Марка о SHIVA-мире и стратегиях'''], вышла после конференции

Есть матрица стратегий BCG - они про обычное время. Он делает S-матрицу стратегий во время перемен, которые наступают. Раньше человек мог планировать в контексте себя, семьи и рода, а теперь кризис меняет мир, и мировой контекст доминирует. Еще в 2018 все было стабильно, Стивен Пинкер "Лучшее в нас" - пример этого, представлялось, что мир и процветание выходит за пределы западного мира и распространяется. А сейчас - кризис, люди ждут чего-то плохого. Неопределенность, тревожность, напряжение, популизм, поляризованность, хаотичность. Люди не верят, что изменится к лучшему, ждут экзистенциальные риски, ожидается глобальная трансформация. надвигается шторм, который потрясет саму суть бытия. Это было свежее исследование, которое опубликовано на сайте Экопси, ссылки можно найти на каналах Марка. И чем старше человек - тем более апокалиптичен. 53 у молодежи до 25, 64-65 у 46+ по 100-бальной шкале.

Этот опрос НЕ говорит, что что-то будет. В 1980-х никто не верил, что СССР рухнет - а он рухнул. И вполне может быть обратная ситуация. Его гипотеза - это начало эпохи перемен, в которую черные лебеди прилетают часто. У Марка есть '''концепт SHIVA-мира''': мир треснул, идет зарождение нового. Он рассказывал это пару лет назад на ПИР, и есть [https://www.ecopsy.ru/insights/shivamir/ '''его статья]'''.

Расщепленность. Запад, Юг, Восток. Юг разделен. И запад разделен: левые побежали влево, а Маск остался на месте и превратился из левого в правого. 10 лет назад республиканцы или демократы - безразлично. Сейчас это не так, идет реальная борьба, есть разница.

Личные стратегии в Шива-мире. Основаны на базовых экзистенциальные вызовы Ирвинг Ялом: смертность, одиночество, бессмысленность, свобода и ответственность. У каждого человека острее один из них. В период Шивы все вызовы обостряются.
* Страх смерти, потери благополучия - стратегия защиты, замереть и переждать. Люди откладывают покупку квартир, жениться не время, детей рожать не время, жить - не время.
* Страх потерять свободу - рождает авантюристов, они осознают, что пришло их время ехать в Дубай за деньгами, или на СВО для изменения траектории, делают бизнесы в серых зонах.
* Страх разрушения смыслов - сопротивление через осмысленную деятельность, общественная или политическая деятельность, улучшение, наполнение смыслами, помощь бедным или больным.
* Страх одиночества - присоединение к сообществу, к тренду - и почувствовать, что ты не одинок, рядом много других. Рабочее название стратегии - Адаптация.

Стратегии нарисованы в квадрате 2*2, оси реактивность-проактивность и индивидуум-коллектив: Защита - индивидуальная реактивность, Авантюристы - индивидуальная проактивность, Смыслы - коллективная проактичность, Адаптация - коллективная реактивность.

И по центру пятая стратегия, Стабильность: игнорировать, делать вид, что Шивы нет. В секторе Газа так нельзя, а в Тель-Авиве их много.

Та же матрица в бизнесе.
* Защита - операционное совершенствование. И выйти из бизнеса. Без инвестиций
* Авантюризм - купить дешево, обходить санкции, работать в серых зонах
* Смыслы - социальная миссия во главе бизнеса.
* Адаптация - Отличник перед государством, частно-государственные партнерства, встраивание в повестки
* Стабильность - реализую стратегию 2015, она до 2030. Может, они выиграют.

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

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

В заключении конспекта я хочу сказать, что у меня модель, как ее сформулировал Марк Розин, хорошо сопоставилась нейрофизиологией мотивации Херен Фишер, которая говорит про четыре гормональных механизма мотивации и счастья, лежащие в основе 4 инстинктов:
* Дофамин – счастье поиска и исследований – любопытство и поиск
* Тестостерон – счастье победы и достижения цели – агрессия
* Серотонин – счастье регулярной повседневной жизни – самосохранение
* Окситоцин/эстроген – счастье эмпатии и взаимоотношений – воспроизводство

При этом есть соответствие между моделью мотивации Хелен Фишер и стилями руководства Адизеса.

Сопоставление со стратегиями Марка у меня получается таким:
* страх смерти - защита -- самосохранение - серотонин - Администратор
* страх потери свободы - авантюристы -- дофамин - поиск - Предприниматель
* страх разрушения смыслов - смыслы (утверждение смыслов) -- тестостерон - агрессия - Продюсер
* страх одиночества - адаптация - окситоцин -- воспроизводство - Интегратор

Если кому интересно про модели Хелен Фишер и их сопоставление с Адизесом, то у меня есть статьи с описанием https://vc.ru/hr/1018029 и https://vc.ru/hr/1117480.

В комментариях к этому конспекту у меня на телеграм-канале была пара любопытных историй от Rinat Enikeev.
* Ехал я в такси в Таллинне с эстонцем, разговорились про политику. Я уже привык, что русскоговорящие таксисты не любят местную власть, но тут был живой, настоящий эстонец с акцентом. Начал он выпытывать из меня, что я думаю про политику. А у меня в загашнике честная легенда что нас 200, мы в Черногории либертарианскую организацию делаем. Эстонец повякал, что все бояться [под гегемоном] говорить что думают и прошелся красивым русским матом [почти без акцента] по всей леволиберальной политике запада. Было интересно.
* Встреча экспатов. Слева сидит афганец и ерзает. Когда до него доходит слово, весь на нервах, рассказывает свою историю. Работал он в Афганистане в Human Rights Watch. Приехал в деревню, ему говорят - вот девушка, ночью она повесится, потому что ее изнасиловали, не хочешь взять замуж? Он помучался ночь, на утро - согласился. Афганец вздохнул. "Я поступил соответственно своим ценностям (values). Но это была ошибка."

==Вячеслав Дубынин. Биохакинг и усиление человека за счет технологий==

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

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

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

Ну а теперь, после этих вводных - конспект содержания доклада. В конспекте много моих реплик и я их явно выделяю.

В 90-е биохакинг - экстрим, с пересадкой органов и внедрения чипов и эксперименты с препаратами. Сейчас становится цивилизованно. И есть люди, которые всерьез это делают. Брайан Джонсон 2 млн, условно-молодой: в 50 выглядит на 40. И это бизнес - потому что методы, сделанные для него, тиражируют дорого, забывая что они персональны. И есть контрпримеры: Баффет пьет 5 банок колы в день уже много лет, ему 94 года и он живой и действующий.

Какие направления включает образ жизни? Питание, физическая активность, гормональный статус (включая иммунитет), детоксикация, генетика, сон, косметология, мозговая деятельность, стресс-менеджмент.

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

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

Сон как недооцененный ресурс. Спать - важно, надо высыпаться. Сон считается не часами, а циклами: медленный-быстрый. Медленный - восстановление организма, работы внутренних органов. Быстрый, REM-сон - обработка информации, длительность 10-15-20 минут, сопровождается не только сновидениями, но и перезаписью информации из кратковременной в долговременную память с установлением связей, сновидения - побочный эффект. У греков было два бога сна: Гипнос - отдых и Морфей - сновидения.

Чтобы высыпаться важно 4-5 циклов глубокого сна в сутки. Каждый цикл - 1.5-2 часа, но это в среднем, они имеют очень большую вариативность. Я, как человек, который регулярно смотрит записи своего сна, про вариативность точно знаю. Дневной сон - если вы утомлены. то полезно уснуть на 15-20 минут - это дает перезагрузку мозга. Но не дольше, иначе уйдем в большой цикл и будет спад активности. Отмечу, что если сильно утомлены - то надо дольше, надо следить за своим состоянием, хотя 15 минут - тоже полезно.

Генетика сна - неплохо изучено. Совы и жаворонки - лирика, это перешло в научную сферу, есть гены Per. И тезисы о том, что
после 6 не надо есть, или до полуночи пользы больше - это все для жаворонков. Для сов продуктивно с 0 до 2 ночи. Эта надо осознать. Но Per-гены - не только ритмы, это еще устойчивость к сбоям ритмов и сдвигу часов.

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

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

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

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

Физическая активность. Движение - лучший источник позитива. Механизм эмоций - нейромедиаторы. Дофамин - радость движения и радость новизны. Качаем мышцы, быстро шагаем, соревнуемся, танцуем. Сейчас есть разные статьи - как разные виды движений влияют. Шаг по новой красивой местности лучше тренажера, так как дополнительно дает визуальные впечатления. Но должна быть достаточная нагрузка на мышцы, легкие и сердце. Соревновательные игры тоже полезны - там дополнительные эмоции. Танцы - суперспособ. Двигаетесь разнообразно, и в коллективе.

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

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

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

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

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

Избыточный стресс ухудшает состояние, решение импульсивны, с обучением проблемы. А умеренный - наоборот стимулирует.

Массаж каротиного синуса (сонной артерии) - снижают давление до 10 мм. Только надо аккуратно. Возрастная гипертония - падает эластичность сосудов.

Как сделать эффективное обучение?
* Яркие мотивации и эмоции - встроенная антиспам система без этого отвергнет, не положит в долговременную
* Повторы - для повторного прохождения по синасам, не только на вход, но и на выход, в действие
* Максимальное снижение внешних проблем и отвлечений
* Оптимальное состояние мозга

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

Генная терапия. Коррекция ДНК клеток органов и целого. Но это пока эксперимент. Открыт механизм CRISPR/Cas - так работают вирусы у бактерий, и это теоретически можно применять. Стволовые клетки и выращивание органов в биореакторах. Получается для кусочков кожи и фрагментов костей, в перспективе вырастить новые зубы. Правда, японские ученые открыли ген, который управляет развитием новых зубов у детей, потом он подавляется - и можно попробовать активировать, тогда и выращивать не надо. А еще я хочу отметить, что со стволовыми клетками есть проблема в том, что для них нет внятного физиологического определения, позволяющего отличить именно их от других типов клеток, так что мы имеем сильный запах хайпа вместе с шарлатанством, учитывая стоимость методов.

Нейрохакинг - прямое взаимодействие с мозгом. Датчики и сигналы. Снимают с поверхности, сейчас много. Электроды вживляют - но это лечебное. А поверхностная активность - позволяет управлять протезами, и наоборот, давать слух или зрение. Нейрохакинг - препараты и БАД. Есть препараты, которые влияют глобально - антиоксиданты. Среди них много растительных - п Пихта, елка, сосна. Семаглутид - сделан для контроля диабета, а еще контролирует аппетит и снижает массу. А еще человек худеет просто потому, что у него в целом нормализуется состояние. Хотя при этом уходит эмоция позитива от вкусняшек и у 1% пациентов - депрессия.

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

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

[[Категория:ИИ-агенты]]
{{wl-publish: 2024-09-21 20:50:04 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2024-09-21: ПИР-2024. ЧИИЛОВЕК - человек эпохи ИИ

2026-07-24T15:01:03Z

MaksTsepkov:

{{Conf-Ref}}
Как обычно в начале сентября прошел [http://festpir.ru '''фестиваль Практики и Развитие (ПИР-2024)'''] - большая конференция тренеров, коучей, консультантов и бизнеса. Это 1700+ участников, четыре дня с 9:30 утра до 22, 13-17 параллельных треков, а потом еще ночное общение. Я участвую в этих фестивалях с 2016 года, и для меня это - способ навести фоус на ход развития бизнес-сообщества в целом, потому что специалисты помогающих профессий достаточно хорошо отражают то, что происходит.

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

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

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

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

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

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

Евгений Кузнецов на пленаре второго дня высказал такой тезис о будущем. У людей раньше не было возможности напрямую общаться с коллективным человеческим опытом, можно было взаимодействовать с отдельными книгами и другими артефактами. Сейчас она появилась, они могут работать со всем знанием человечества и корректировать свою картину мира. 20 лет назад у людей отняли право говорить "не знаю" - есть гугл, найди. А скоро не будет права говорить "не понимаю" - спроси ИИ, он объяснит.

Дальше будут мои конспекты выступлений. Часть из них я публиковал прямо в ходе конференции. Другие - после, и '''я продолжу это делать уже после публикации отчета, дополняя его'''. Конспекты разделены на три части: визионерские выступления про будущее с ИИ, практики использования ИИ и группа выступлений, которые с ИИ не связаны. При этом я был на малой части выступлений - ситуация, когда идет 13-17 треков не дает возможности побывать везде. Более того, приходилось пропускать заведомо интересные выступления, потому что параллельно шло что-то еще более интересное. Так, не удалось послушать Анну Обухову, потому что параллельно выступал Марк Розин.

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

* [[#Гарретт Джонстон. Неискусственный интеллект: человеческая контрреволюция в бизнесе переломных двадцатых годов]]. Это '''единственный из футурологических докладов''', не только на этой конференции, в котором был '''конструктивный образ будущего и его отличия от настоящего'''. Если кратко, то к 2030 году у большинства будет персональный AI-ассистент, как сейчас есть смартфон. AI-ассистент будет действовать в интересах человека, и это принципиально изменит устройство бизнеса. Сейчас бизнес придумывает и производит товары, часто недостойные, и с помощью рекламы и маркетинга убеждает людей их купить разными методами. AI-ассистент не будет смотреть рекламу, а будет оценивать товары по объективной полезности, оцениваемой по опыту использования других потребителей с учетом индивидуализации конкретного человека. Поэтому реклама и маркетинг умрут, а производителям придется делать продукты, у стоимость соответствует качеству, долговечности и другим реальным потребительским качетсвам. А еще место производства товара и известность не имеет значения, AI-ассистент будет договариваться с фабриками и кооперирвоаться с другими при закупке, это уничтожит маркетплейсы и оптовую торговлю.
* [[#Мое выступление: ИИ – зеркало человека. Страхи, возможности и перспективы обусловлены этим]]. Возможно, это нескромно, но я считаю, что у меня - наиболее реалистичная визионерская картина, хотя и не столь впечатляюще изложенная, как у Джонстона. Если кратко, то будущее - в сотрудничестве человека и ИИ, и это уже интенсивно строится. При этом экземпляров ИИ будет много и они будут разные, многообразие будет явно больше, чем, например, для сотовых телефонов.
* [[#Аркадий Цукер. Мышление и тупик. Или где нам нужен Естественный Интеллект?]] - хороший доклад про мышление, включая рекомендации о мышлении сообразно устройству нейрофизиологии, а не вопреки ей. Потому что ИИ, конечно, может помогать, но расхлебывать последствия своих действий надо будет человеку, а значит принимать решения лучше самостоятельно.
* [[#Сергей Переслегин. Искусственный Интеллект в фантастике и прогностике]] Сергей рассказывал свою модель шести технологических волн, включая фантастику. связанную с каждой волной. А потом, поверх этой базовой картины, наложил ИИ как существенный элемент начинающейся шестой волны. Но визионерской картины будущего он, на мой взгляд, не дал, он формулирует тезис, что тема была хорошо проработана в фантастике 60-х - у Лема и других.
* [[#Марк Розин. Личные и бизнес-стратегии в Шива мире – как жить в эпоху перемен]] - Марк рассказывал типологию возможных стратегий, которая родилась как осмысление тех вариантов, которые сейчас демонстрируют люди.
* [[#Вячеслав Дубынин. Биохакинг и усиление человека за счет технологий]] - рассказ о современных исследованиях человека, которые в перспективе должны дать персонализированную медицину. К сожалению, лишь в перспективе - известно множество частных корреляций, есть множество открытий по конкретным веществам, а модели человека среднего уровня, которую можно персонализировать, и которая бы учитывала не только генетику, но и индивидуальный путь развития, как не было, так и нет.

= Про будущее с ИИ крупными мазками =

== Пленар первого дня с практиками ИИ ==

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

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

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

'''2. Целеполагание ИИ'''. С этим связывают реальный прорыв к "настоящему ИИ". Хотя я считаю, что это - спекуляция, потому что написать скрипт, который каждое утро будет задавать ИИ вопрос "что сейчас правильно сделать для компании, учитывая вчерашние новости и внутреннюю переписку" - вообще не проблема. А у человека рациональное целеполагание устроено примерно таким образом - из вопросов по векторам.

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

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

==Сергей Переслегин. Искусственный Интеллект в фантастике и прогностике==

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

'''1.''' В начале доклада был тезис, что это доклад не практика, а прогностика. Прогностиков не интересуют технические детали. Зато интересует, что будет. При этом он опирается на социальные законы, которые говорят, что любое открытие обязательно реализуется, поставить его под контроль не получится. А надо уметь с этим жить. И любой технологический прогресс сначала предвкушают как утопию: будет радио/ТВ/ИИ - будет счастье, потом как антиутопию: оно случится - и мир рухнет, а потом - как киберпанк (это Сергей так называет, я бы сказал, что прагматика): вот оно случилось, будем с этим жить.

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

'''2.''' У Переслегина есть '''модель технологических волн индустриального общества''', начиная с 1760, в ней 6 волн, они примерно по 40-50 лет, и шестая началась в 2010-х с предполагаемым пиком в 2030-2035. Схема появилась как дальнейшее развитие концепции технологических укладов Шваба. Они ей пользовались, потом возникла практическая задача дать долгосрочный прогноз химической отрасли, пошли разбираться, выяснили, что Шваб в технологическом укладе путает две вещи: способ производства и реализацию этого способа в конкретный момент. Когда разделили, то увидели, что реализация способа производства связана с технологиями, и они как раз образуют технологические волны, более короткие, чем смена технологических укладов - меняется способ реализации за счет смены технологий. При этом пик волны виден отчетливо, а вот рост и падение - слабее, волны перекрываются. Они его выделили по реперным событиям, интегральное описание можно найти в инете - есть много картинок, а в презентации были детальные картинки по всем шести волнам, но, наверное, они тоже есть - Сергей много выступает.

'''3. Что важно: с каждой волной связана своя фантастика''', и об этом было подробно. Первая волна - Фауст и Франкенштейн, вторая - Жюль Верн, третья - Уэллс и Чапек, четвертая - фантастика 60-х: Лем, Азимов, Брэдбери, Стругацкие и многие другие, в лидерах тут США, СССР и Польша. Что важно - эта фантастика проработала вопросы ИИ, сейчас на это можно смотреть как на предсказания, а кое в чем это стало историей. И это было тогда, в 1960-х. Сергей подробно на этом останавливался, с конкретными произведениями, которые известны. Я пунктиром записывал, но пересказывать детально не готов. А интегрально - в этой фантастике люди осваивали космос, а роботы им помогали. И проблемы возникали не из-за восстания машин, а потому, что те чересчур тщательно исполняли приказ обеспечить людям безопасность и комфортное существование, а люди - это ж беспокойный элемент, комфортно они смогут существовать, только если поглупеют - что компьютеры и обеспечивали. И мне по этому поводу несколько раз вспомнилась шутка о том, что визионер - это тот кто знает страхи прошлого и умеет ими пугать, рассказывая про будущее. В данном случае предметом страха были фантастические антиутопии прошлого.

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

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

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

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

'''4. Собственно про ИИ'''. Сергей считает, что сильный ИИ не получится в ближайшие 5-10 лет по конструктивным основаниям. А именно, Шеннон дал определение информации как меры упорядоченности, по аналогу с термодинамикой, и наличие смысла в информации это определение не предполагает. Под это определение была элементная база в виде триггеров, и появилась архитектура фон Неймана и абстрактная машина Тьюринга, которые лежат в основе современных компьютеров. Поэтому работать со смыслами они не могут, а значит сильный ИИ невозможен. Да, можно поменять определение информации, но с новым надо пройти весь путь развития компьютеров, а это дорого и сложно, никто делать не будет.

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

Но вообще от этого вопроса сильно попахивает теологией - сильный интеллект отрицается еще и потому, что для него считается необходимым самосознание, а что это такое - никто не знает. Зато тот ИИ, который появился сейчас, определяют как "средний ИИ" - этой классификации раньше не было. Думаю, это просто для того, чтобы не признавать его как сильный. Что касается самосознания, то объяснить основания для решений - как раз та задача, которую компьютеры хорошо умеют делать, потому что речь идет об анализе конфигурации параметров, которая привела к ответу. Просто никто не ставил такую задачу в практическом залоге. Или, если точнее, она стоит в списке, но далеко, а вверху списка - повышение возможностей ИИ. Типа, лучше решение сложных задач без объяснения, чем с объяснением, но более простых. При этом ChatGPT и другие разговорные системы умеют удовлетворительно объяснять результат "от ответа", просто продолжая разговор и отвечая на вопрос "почему ты так думаешь?" Как часто делает человек, придумывая основания для решения уже потом, когда что-то решил или даже сделал. И для коммуникации и сотрудничества с людьми этого достаточно.

Далее Сергей полагает, что имеющиеся сейчас галлюцинации ИИ, особенно в части работы с числами показывают его уровень 5-6 летнего ребенка и это предел. Я думаю, это - незаконная аналогия, ведь ИИ - не антропоморфен. А галлюцинации - они легко убираются, через встройку проверки, это сейчас делают поверх ChatGPT, предлагая ему же проверить и исправить ответ.

А предсказания областей, где за человеком останется лидирующая позиция, на мой взгляд, исходят из преувеличенных представлений о возможностях именно человека в высокоинтеллектуальных областях. Сергей выделил три: (1) Создание схем - умение выделить важное и изображение; (2) Управление динамикой - моделирование; (3) Спонтанное метафорическое управление. По-моему, ИИ вполне это может.

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

'''5. Что будет интересного?''' Тут перечислено много пунктов, вектора - очень правильные, а детали, на мой взгляд требуют уточнения.

* Революция в юриспруденции. ИИ - субъект правовых отношениях. А еще законов в России - более 1 млн, и ИИ их узнает, и прокурор-адвокат-судья будут ИИ или будут использовать ИИ - нет состязательности процесса. Я считаю, что практически особой революции не будет, просто юристы и судьи смирятся, что понятие субъекта надо трактовать шире. А стороны процесса - да, будут использовать один ИИ, но вопросы задавать по-разному, получать разные ответы и решение будет выносить человек. Да, процесс будет другим, ну и что?
* Финансы - блокчейн, смарт-контракт, и не нужен всеобщий эквивалент - немонетарная экономика, или экономика под задачу. Тут я согласен, и добавлю, что это - хорошо.
* Революция понятия социальность. Цифровой фашизм или тоталитаризм, предсказание выборов по анализу соцсетей, вброс ботов для влияния, с 2016 уже соревнование ботов. На мой взгляд, это фиговая страшилка, не предскажет ИИ по соцсетям результат, а голосуют - все-таки люди, а не боты. Ну а политтехнологии развиваются давно, тут ИИ принципиально ситуацию не поменял, хотя динамика возросла.
* Мир Оруэлла и нулевой приватности. Ловим террористов - а потом любое инакомыслие. Как вариант - могут принять жесткий запрет о цифровой слежке. На мой взгляд, эта проблема вообще надумана. Ну да, живем прозрачно, и ладно.
* Производство, Управление, Война - эти слайды Сергей проскочил, посмотрю потом.
* Образование и воспитание. Контроль отрывается от воспитания. ЕГЭ не работает при прямом доступе через мозг. Надо сделать систему образования, которая проверяет: человек пользуется чужими знаниями или сам работает с содержанием - другой экзамен, другое обучение. Да, тут согласен, нужно другое. Кризис образования давно назрел, придется менять, на что - пока никто не знает. Но над проблемой работать и как-то решат. В конце концов, аттестат с оценками - не главное, хотя на него многое сейчас и завязано.
* Информационное переедание - ребенок в 8-11 лет станет информационно взрослым, в равновесии с ИИ - но тогда он должен получить остальные слова. Закончился подростковый возраст. Можем предсказать, но не готовы обсуждать. Другие навыки. Умение читать, суммировать, удерживать, умение ставить вопросы. Не длинная воля, а фокусное внимание. Письменность выносила в память, и ИИ - внешнее мышление, и тоже для умных. Тут я согласен, но, в общем, к этому не только технология ИИ руку приложила. Мир тут надо менять, как и с образованием.

А заключение было позитивным: ИИ будет в каждой семье и мы будем с этим жить. Преодолеем кризисы и выйдем в дальний космос.

== Пленар второго дня: Петр Щедровицкий, Евгений Кузнецов, Олег Замышляев, Данила Медведев, Андрей Масалович ==

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

'''Самый сильный тезис был от Евгения Кузнецова, с него я начну. У людей раньше не было возможности напрямую общаться с коллективным человеческим опытом, можно было взаимодействовать с отдельными книгами и другими артефактами. Сейчас она появилась, они могут работать со всем знанием человечества и корректирвоать свою картину мира. 20 лет назад у людей отняли право говорить "не знаю" - есть гугл, найди. Сейчас не будет права говорить "не понимаю" - спроси ИИ, он объяснит.'''

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

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

'''Данила Медведев''' озвучил взгляд на ИИ от менеджеров. Практически никто не понимает сценариев развития ИИ. Даже руководители компаний и их ведущие специалисты. Есть специалисты в мире, и некоторые - вменяемые. Но вменяемых не подпускают к принятию решений, а кто решает - несут ахинею. Руководители не понимают, что такое мышление, что такое ИИ - и чем-то управляют. Я тут замечу, что генерал Гровс тоже не понимал про атомную бомбу, а работу команды обеспечил, так что проблема в другом.

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

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

'''Андрей Масалович''' (в соцсетях - кибердед). Начал с реплики про мыслительные способности элиты: у его программистов есть присказка: документацию надо писать для полного начальника. Он проникся и начал заниматься ИИ в 1992, написал изучать, писать статьи, сделал статью "нейронные сети - оружия финансиста", стало денежно - 50 банков пришло. В конце 1990-х сделали программу - как выводить человека после мины лепесток. Повез в Европу, говорили "ты что, программа будет говорить специалисту? Еще скажи про беспилотное такси". И он переключился на другое, а сейчас вернулся к ИИ, уже с точки зрения безопасности использования. Это произошло 2 года назад в Катаре на чемпионате мира. Катарцы говорили, что занимаются ИИ. И используют ИИ для совершенствования законов. И тексты система лепила хорошо и убедительно. Только была проблема с логикой, а также с картиной мира, которая заложена обучением. Например, покушение на женщину в одних мусульманских странах приравнено к покушению на домашнее имущество, а в других - на домашнее животное. А чему обучен ИИ? ИИ знает разные точки зрения, если обучен на широких выборках, а система законов должна быть взаимосвязанной и желательно не сильно противоречивой...

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

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

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

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

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

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

Что ИИ умеет?
* Действия и планы - лучше 90% сотрудников.
* Управленческие решения - легко. Учитывая человеческие факторы.
* Стратегии - восхитительно
* Ценности - тоже восхитительно. Обгоняет в качестве, глубине и чистоте формулировок. Их вариант лучше, чем у людей.
* Формулирование миссии - тут спотыкается.

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

'''Евгений Кузнецов'''. Поговорка футурологов: они переоценивают скорость, но недооценивают масштаб. Мир через 15 лет изменится необратимо. Интернет - масштабные изменения, кто не хотел осваивать - ломались карьеры специалиста. ИИ не заменяет человека, он заменяет конкретные функции. И это - перепроектирование формата человеческой деятельности, меняет СРТ. Что случилось с таксистами. Раньше это была профи-сфера - надо знать людей, знать город. Сейчас таксист просто везет по навигатору. И это коснется каждой деятельности. В Китае судья должен советоваться с ИИ обязательно. И это придется всем попробовать.

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

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

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

== Александр Цыпкин. Интервью о возможностях ИИ==

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

Через года 2-3 с ИИ надо уметь взаимодействовать, это будет обязательно, как сейчас базовое владение компьютером или смартфоном. Восстания машин не будет, тут ИИ переоценен, но не так, как виртуальная реальность 5 лет назад - виртуальные шлемы и очки дома у единиц. ИИ будет использоваться активнее и будет суверенитет ИИ - как обосабливается интернет. И хорошо, что в России по ИИ есть задел - от беспилотных комбайнов до дипфейков. В студии Артема Лебедева ты можешь обратиться за лого и ни разу не пообщаться с человеком. А у человека заказать тоже можно, но дороже. Число людей не уменьшилось, ИИ надо заниматься, но объемы - выросли.

У него помощники используют ИИ для анализа данных и других целей. Цифровой аватар - пока нет. Рассматривал с точки зрения чтения, но пока низкое качество. Озвучка на всех языках - да.

Безопасность от фейков играет в обе стороны: фейк может вылезти, или реальное можно объявить фейком. Владение образом - проблема. У актеров, особенно молодых киностудия забирает образ и дальше использует. Есть идея сделать аватары Жукова, Рокоссовского, Конева. Дочь Жукова - за, есть те, кто возражает. Но вот кому будут принадлежать права на аватар Жукова?

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

Совет: стоит проанализировать рабочий день и честно ответить на вопрос, что можно заменить. Если больше 50 - вы в зоне риска. Как увольнением ткачей с заменой станками. А если начнешь активно использовать ИИ - то ты остаешься.

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

Цифровое бессмертие. - Оно уже есть. Приходит напоминалка про ДР, заходишь на страницу, читаешь. И забыл, что умер. Будет развиваться. Будет ли перенесено сознание - не думает.

И еще совет. Не ждите, зайдите в ChatCPT, поговорите, попробуйте midjourney. Это интересно.

== Мое выступление: ИИ – зеркало человека. Страхи, возможности и перспективы обусловлены этим ==

Мое выступление тоже было посвящено теме развития ИИ, как я ее вижу. Я участвую на многих конференциях, в том числе в ИТ, который тоже интенсивно осваивает ИИ. И отчетливо вижу следующее.
* Страхи перед ИИ - часть общей индустрии страха, которая является составной частью механизма управления обществом. За публичными страхами лежит опасения тех, кто управляет, что развитие ИИ, как и других технлогий, может сломать нынешние механизы управления и отстранить от власти и доходов те социальные группы, которые ею обладают. Остальное - следствия.
* ИИ развивается, период начального освоения уже прошел, и сейчас идет массовое освоение ИИ как помощника, создаются субъекты ИИ и это не является эксклюзивным умением, а носит массовый характер.
* Появляются технологии локального развертывания сложных моделей ИИ на серверах и даже мощных ноутбуках, компании это активно осваивают, и это откроет массовое освоение технологий обучения и дообучения ИИ, которые пока не распространены широко, поскольку пока количество экземпляров было ограничено.
* Будущее - в сотрудничестве человека и ИИ, и это уже интенсивно строится. При этом экземпляров ИИ будет много и они будут разные, многообразие будет явно больше, чем, например, для сотовых телефонов.

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

==Гарретт Джонстон. Неискусственный интеллект: человеческая контрреволюция в бизнесе переломных двадцатых годов==

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

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

2. Ленин: бывают десятилетия, когда ничего не происходит, и недели, когда происходят десятилетия. Лето 2024 - старт очень больших изменений. Переход от 5 к 6 технологическому укладу по Кондратьевским циклам. Пятый был про людей, которые создают удивительные технологии. А шестой - про технологии, которые создают и меняют людей. Человек становится объектом процесса, а не только субъектом.

3. Образ будущего, который дальше, будет реализован к 2030. До СВО и Газы он оценивал срок в 2035, эти события резко интенсифицируют развитие.

4. К 2030 каждый будет со своим цифровым двойником и AI-ассистентом. Как мобильный телефон, который сейчас есть у каждого. Ассистент обеспечит шопинг, путешествия, организация жизни, автоматизация рутины, каждый день на всех уровнях.

5. Ассистент принципиально поменяет бизнес. Иллюстрация - на примере ухода за зубами. Берем простую зубную щетку 2$, добавляешь камеру, она будет стоить 10$ - и каждый день получается мини-фильм твоих зубов. Этот фильм отправляется специализированному ИИ, где сравнивается с другими миллионами таких фильмов и проводится анализ на всех уровнях.
* discovery - фото сегодняшнего ужаса и изменения от вчера.
* descriptive - В чем причины такого состояния твоего рта.
* predictive - что будет, если не поменяешь через год
* prescriptive - что надо делать, чтобы изменить
* deductive - возможные сценарии развития. Что будет, если перестанешь бухать, но будешь есть шоколад и наоборот

6. Такая конструкция принципиально меняет картину. Сейчас стоматологи убивают кариес, а такое наблюдение устраняет его причины, кариес вообще не появляется. Понятно, что тут будет противодействие. Интересы врачебного сообщества - твой карман, а не рот или тело, рот - способ добраться до кармана.

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

Маркетинг: заставить людей захотеть купить. что делает компания. А задача будет иной - делать то, что нужно. От make people want things к make things want people. Смерть продавца - death of a salesman! Это уйдет в прошлое со скоростью, которая будет удивлять.

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

9. И это поменяет всю систему бизнеса. Ей уже 5000 лет: в древней Месопотамии, в Ур была реклама! Нынешняя схема - бизнес создает продукт, он определяет целевую аудиторию и дальше - воронка продаж wareness - consideration - intention - purchase - loyality, осведомленность - заинтересованность - намерение купить, покупка, повторные покупатели. А тут на каждый продукт будут знать, сколько покупателей. И если продукт говно, то маркетинг не поможет его продать.

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

11. Ассистент - личный DJ, личный карьерный советник с 5 лет, твой стиль, секси-стиль, оригинальность, бренд. Цифровой двойник, чтобы дать лучшие результаты. Первая задача - узнать тебя, понять таланты, любовь, силу, слабости. Психология, финансовая ситуация, SWOT-анализ 24 часа в день по всем фронтам, про тебя и твоих людей. Он не знает лучше, но ничего не забывает. И про окружающий мир. Перед рекомендацией зубной пасты - не только анализы щетки. Он читал все книги по стоматологии. И все исследования и видео. А оплата ассистента - по модели GPT, подписка.

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

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

13. Переход от Web2 к Web3. И это одна из причин нынешней нестабильности. Web2 - данные у маркетплейсов, они обрабатывают в своих интересах. Web3 - данные у тебя, ты - суверенный человек. А блокчейн - технология фиксации правды, и это - святая вода для дьявола. Web2, google - don't be evil. Web3 - can't be evil. А это сужает пространство маневра для тех, кто сейчас держит рынки. Идет падение доверия к игрокам, которые навязывают товар. Web3 гарантирует правду через распределение ответов, закон больших чисел. Блокчейн - не криптовалюта, а инфраструктура правды и инфраструктура взаимодействия между ассистентами.

14. Бизнес. Soft съедает мир, а ИИ съедает софт. Все что можно будет автоматизировано. Даже там где дешево, в Индии. И принципиальный вопрос - ради чего автоматизируется? Какое будущее хочет компания?

Бизнес-стратегия - способ достижения цели. Для определения цели нужны идеологии. Компьютер умеет экстраполировать, а образ будущего надо создавать самому. Куда я иду и зачем я иду туда.

Вы все равно должны думать - почему бы не думать по-крупному? Никогда не соглашайтесь на что-либо меньшее, чем экстраординарное. В ем большая идея твоего бизнеса, смысл существования. Удивительно мало компаний могут ответить. Коротко, ясно, ценно. А от ответа - зависит результат.

15. Стартап - много интересных идей. К 10 году становятся одинаково, везде менеджеры, лучшие практики от консультантов. Человек живет дольше, компании умирают моложе. Когда родился компании жили 60 лет, сейчас - 13.

16. Что такое идеология? Если бизнес сдохнет - о чем другие будут плакать. Как торгаш - будешь не нужен. Если ты незначим - ИИ возьмет. А если значим - то чем. Что будет написано на твоем надгробии?

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

Большая идея является прямым или косвенным месторождением твоих инициатив. ИИ не сделает большую идею для тебя. Именно она даст фокус жизни.

17. Моря 20-х будут сложными и турбулентными. У одного корабля есть идея, у другого люди за деньги. Второй не допрет в тяжелых морях. Он ирландец - он знает. Дисциплина и цель. Путь может меняться - погода меняется. Но цель должна быть.

Volvo - все для безопасности. Еще в 1971 - компания рекламировала безопасность тех, кто в машине, а не машину. И поэтому берут. В 2007 китайцы предложили выкупить полностью за 2-кратную стоимость. Шведы отказали продать, потому что у инвесторов безопасность не на первом месте.

Я отмечу, что этот пример недостоверен. Оказывается, производство легковых автомобилей Шведы еще в 1999 продали Ford, который в 2009-2010 продал это китайцам. А основной вольво производит грузовики и автобусы. Так что безопасность стала маркетинговой штукой.

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

19. Инновации будут автоматизироваться ИИ, а изобретения - нет. ИИ хорош в инновациях - это оптимизация, перебор вариантов. Русские хороши в изобретениях, но не в инновациях. Но ИИ сделает. У китайцев наоборот, хорошо с инновациями, с изобретениями плохо. И это не решится.

20. Цифровой завод будет у всех. И это - не то, за сет чего ваш продукт дойдет до потребителя. А надо дойти.

21. Россия собирается стать топ-3 экономическим игроком мира, обогнать Индию. Он уже топ-3 военный и ресурсный. Сейчас Россия 43-я, надо многое менять.

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

= Практика использования ИИ =

==Артур Крылов. ИИ в городских проектах: павильон на форуме-фестивале Территория будущего. Москва 2030==

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

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

И много другого.
* Проект Москва глазами москвичей - много реальных фоток Москвы, удаляли фон, обрбатывали видео чтобы была Москва будущего. Дальше в фотобудке фотогравировали глаза, шла автоматическая обработка, это улетало на большой экран, а тебе делали персональную открытку.
* Цифровые аватары из реальных лиц людей с заменой окружения и брендированием рамки.
* Картина Москва будущего. На базе огромного количества изображений от нейросетей. Улицы, активности и многое другое. Доработка с художниками. 164 кв.м. Нижнюю часть не закрашивали, и ее закрашивали участники.
* Детские раскраски - создание картинок с помощью ИИ. Причем делали целиком одним промптом.

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

==Вениамин Кизеев и Данила Драпеза. Как повысить свою продуктивность с ИИ. Кейсы, практики, куда нажимать? ==

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

'''1. Цель''' - самое сложное. И здесь ИИ не поможет, это личное. Потому что настоящая цель принципиально меняет твое состояние. Поставил цель выступить в триатлоне - и появляется 28 часов тренировок в неделю, массажисты, сауна, баня, специалисты по таблеткам как средство достижения цели, и вот этот шаг - я пойду - надо сделать самому. А вот проработать способ достижения ИИ поможет. О целях - книга Джим Коллинза Good to Great, от хорошего к великому.

'''2. Стратегия'''. Это не оптимальный план, а ключевые принципы для достижения цели. Принципы просты: хочу пробежать марафон - каждый день 10 км; хочу сделать хорошую выручку - делаю каждый день три компреда. Естественно, без халявы, а то цель не достигнешь.

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

Берем фреймворк запроса RTF: role - task - format. Выступи как организатор мероприятия, сделай для меня план выступления и выдай в таком формате. Или как профессиональный тренер создай мне пошаговый план тренировок на год.

Настройки. Действуют на чат всегда.
* Мой портрет - описание себя
* Постоянные вводные - обращение, язык ответа и так далее, добавляется каждый раз. Не просто опиши план игры, а рассуждай. И теги: если я пишу "рыба" делай вот это.

Если нужны картинки, запрос в формате Объект - Фон - Стиль. Что показать на каком фоне и в каком стиле изображение.

Итого, стратегия это принцип плюс ключевое действие.

'''3. Ресурсность, возможности'''. Тут важны тренды. И не 1 раз прочитать, а раз в неделю один час смотреть.

Есть три типа проектов:
# Масштабирование - увеличиваем то, что уже делаем%
# Повышаем Эффективность
# Придумываем новые способы действовать.
Большинство наших проектов - 1, а инновации - 3.

Perplexity.ai - помогает искать информацию на ИИ. Обычные поисковики ищут слова, а тут можно вводить контекст что ищем. Бесплатно. Источники: сети-академические источники-видео-соц.сети (обзор общественного мнения). Он показывает что нашел и где читал, ссылки на источники - это снимает проблему ChatGPT, который не показывает источник. Может работать с вашими документами - прочесть документ и сделать summary или табличку. И можно дать задачу собирать каждую неделю ресурсы в Perplexity.ai

ChatPDF.com - работает только с вашим контекстом. Позволяет закинуть много документов и получить summary.

Ресурсность.
* Ментальное развитие - интеллект. В России мы перекачанные, сравнивал с Австрием и Стэнфордом, где работал. Перепрошивать себя
* Эмоциональный интеллект. История. Работал в Юте, отправил в церковь 10-11 лет, профориентация. Выписали 12 профессий, каждый месяц прожить и оценить. Другой - готовится к ответу.
* Физика. Тело свое знаем хуже. В компании есть доктор, объясняет. Много вопросов решают локально - попить марганец, поспать больше... Он бегает марафон, а когда серьезное - ходит в горы. Вокруг датчиков, которые меряют. И они дают итоги. Welltory, здоровье фитнес.
* Духовное развитие - умение проявлять волю и умение терпеть - развивать дух. Голову расслаблять менеджеру не нужно, ему надо тренировать фокусировку - и медитация это тоже позволяет, доведи фокусировку на 5 минут.

Для медитации можно использовать GigaChat, в нем есть ролевые модели, и одна из них - медитация. Дальше будет набор вопросов, после ответа - текст и музыка чтобы медитировать.

ChatGPT тоже можно, поставить его в позицию коуча, который должен подготовить медитацию - и он сделает. А потом suno для генерации аудио и музыки.

С телом. Люди стали меньше курить ипить, потому что некогда восстанавливаться.

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

Есть приложение founder.ai - отправляете описание проекта, и он по вашим социальным сетям на два шага делает подборку подходящих людей по задачам. Сейчас там, правда. очередь - он стал популярным. В России есть socap.ai, и на рынке много аналогов. А еще в perflexity можно отправить запрос, он тоже умеет получать информацию по соцсетям.

'''4. Процессы и проекты'''. Наш мозг настроен на процессы. Каждый день одинаково. PDCA - шлифование процесса, а HADI - в условиях неопределенности. Чтобы развиваться 2 раза в год, в квартал проверить 100 гипотез до тестирования на клиентах, это - их цель. Позапрошлый год были маркетплейсы, прошлый год - коучинг. А друзья растут 8 раз в год, и для этого проверяют не 100, а 400 гипотез, и гипотеза не на 25%, а удвоить.

Для организации Dola AI, heydola.com - там встроенный календарь, интегрируется с другими календарями, интегрируется с мессенджерами и шлет уведомления. Еще выступает в роли ассистента - как подключиться, поставить встречу по фотке и так далее, она понимает инфо на изображениях. И сводка новостей, как perplexity.

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

tldv.io - cтавится и ходит на встречи: подключается, делает запись, транскрибирует, позволяет взять кусочек видео и отправить, можно обработать транскриб чтобы получить сводное. Да еще запланирвоать в календарь, если все получила. И можно скормить записи. Если малая команда - бесплатно.

'''5. Команда'''. Есть ИИ, которые смотрят статистику общения в чатах, вытаскивает статистику, понимает шаблоны и раздает.

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

Это - малая часть, на рынке есть 4000 готовых решений, которые возникли за 2 года.

В прошлом году они сделали курс полностью средствами ИИ. Отмечу, что меня тогда впечаитлил их рассказ, я об этом кейсе много рассказываю, а в отчете [[ПИР-2023]] можно прочитать конспект. За год курс прошли 794 человека, потратили на него 23к. И можно говорить о том, что цифровые аватары вовлекают не хуже, чем реальные люди. 60% отправили курс друзьям. Будущее - скоро все курсы будут на ИИ.

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

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

==Екатерина Попова и Даниил Семин из Фаберлик. Прикладное применение ИИ в бизнесе==

Виртуальная Саманта в плейбое ведет инстаграм. История монетизируется быстро. Космо в марте 24 сделал обложку с ИИ.

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

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

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

А еще сотрудники используют, чтобы писать письма и делать рассылки, карточки и открытки. Это просто и экономит время. И они не драйвят, люди сами начинают использовать, потому что это удобно и просто.

Цифровые инфлюенсеры - создавали. Достаточно похоже на живого. Heygen - цифровой аватар, создать легко, получается 12500 за час получается. В чем нюансы:
* логотип - текст, он бывает плывет, и есть watermark в углу, можно что-наложить поверх в готовом видео.
* Русский язык - не родной, поэтому текст, паузы, ударения - надо следить.
* Для перевода мимику и движение рук берут из оригинального видео.

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

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

Курсы сейчас сильно поверхностные. Надо пробовать самому, а не идти учиться. Потому что инструментов много, и вариантов. Надо искать экспертов, консультироваться по конкретным кейсам. Есть недорогие хороший курсы, их дизайнеры проходили курс по midjourney за 560 рублей, получили кучу практики. Которой не было в других курсах за 50к, который проходил другие. Ссылку на дешевый курс обещал отправить интересующимся по запросу, и это - не реклама, это просто опыт.

==Ольга Ладога-Ячменёва и Гульнара Исмагилова. Новые ИИ коллеги в командах ==

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

Они создают двойников реальных людей, а также виртуальные образы.
* Двойник стейкхолдера клиента, используя публичные материалы, при этом с дополнительной вводной "ты работал в этой компании, но недавно уволился", и просят его оценить материалы.
* Двойник человека, от которого хочешь высокую оценку каких-то материалов, например, публичных выступлений.
* Образ своего клиента из определенной социальной группы, представляющего сегмент рынка. Фактически, это расширение давно известного метода персон, но у такого двойника можно спросить мнение.
* Мнение эксперта в команде - создают двойники экспертов по публичным выступлениям, и спрашивают его по рабочим вопросам.
* Двойники для ушедших сотрудников из команды.
* Наоборот, потрет идеального члена команды, когда ищут нового сотрудника.

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

= Остальные выступления =

== Аркадий Цукер. Мышление и тупик. Или где нам нужен Естественный Интеллект? ==

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

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

Итак, конспект.

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

Мышление - совокупность когнитивных способностей, помогающих решать задачи. Они выделяют 6-аспектов.
* Эмоциональный интеллект - как воспринимаем эту жизнь, оцениваем окружающую действительность, без эмоций деятельность не появятся.
* Телесно-чувственный интеллект - его ведут эмоции.
* Контекстный интеллект - оценка внешнего контекста, правил, ограничений
* Социальный интеллект - переработка сигналов от других людей, зеркальные нейроны, эмпатия.
* Компетентностный интеллект - экспертность, профессионализм, назначение
* Креативный, творческий интеллект, который задает целостность и красоту, связан с эмоциями.

Такая конструкция делает естественный интеллект априори неповторимым на искусственным. Она проживается субъектно, и потому уникальна. Мы можем описать, ИИ может подстроиться, но не может прожить.

Четыре функции мышления.
# Осознание и интерпретация естественной среды. Мы ориентируемся вокруг. ИИ может быть частью моей ориентировки, но не более. Я в голове переработаю часть данных.
# Оценка происходящего. Любая оценка другим интеллектом - будет чужой, будет материалом для моей оценки.
# Никто не может решить за меня, решение принимаю я сам. Согласие с рекомендацией - тоже мое решение.
# Поиск решения дилемм, проблем и трудностей.

Дальше фокус в докладе был на последней - тупики в бизнесе. У них 5 уровней
# Мотивационный - не хотим.
# Компетентностный - не умеем.
# Технологический - не знаем как.
# Ценностный. Не видим смысла
# Онтологический. Задача решаема? А что, так можно было?

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

Если это тупики - то возникают надежды на ИИ. А надо решать нам самим! Это надо прожить самому! ИИ будет лишь помощником - поставляет информацию. Это как "поешьте за меня".

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

Человек всегда одинок - потому что ему надо решать самому. И это никто отнять не может. Остальное - сервисы.

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

Мозг каждый раз рожает кошмары. Это встроенный механизм: я нарисовал кошмар, будет лучше - радуйся, а если так - я тебя подготовил. Ситуация: 12 ночи, ребенка или половины нет, и абонент недоступен - что порождает мозг? Да, в разных картинах мира. Так и с маткой: мозг говорит "человечество вырождается, хватай самку и беги" - а не позитив "сколько женщин сможет иметь детей"

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

Кейс. Конкурент повысил цену, нет инфы, нужно решение: повышать или нет? 50 на 50. Если ты можно спросить ИИ, он ответит - но дальше надо переварить. И можно получить разные рекомендации, в зависимости от вопроса. Который ты задаешь сам.
* Новую инфу надо сопоставить со своим опытом - и это никто не скажет.
* Преодоление ментального и социального сопротивления - любое решение потребует изменения поведения.
* Креативные пробы и креативное конструирование. Идеи со всего мира, но только ты сделаешь и выберешь приемлемое

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

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

Инструменты.
* Вопрос. Кажется тривиальным, может генерировать шаблон, а может генерировать смысл
* Постановка проблемы. Чтобы не закошмарить, а генерить.
* Векторная цель
* Создание прошлого
* Оформление настоящего
* Формирование будущего

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

Создание прошлого.
* Ключевые события. Что самое яркое запомнилось за период?
* Люди и встречи. Кого встретили, какие вызывают теплоту - коммуникативный слой
* Инсайты - что двигало, какие открытия.
* Благодарности
Когда вот так оформляем прошлое, но начинает порождать смыслы.

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

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

А теперь, как я обещал, '''мои тезисы-возражения'''.

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

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

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

А побудительный фокус доклада: не надейтесь на ИИ, решайте и делайте сами - я поддерживаю.

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

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

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

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

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

==Татьяна Мужицкая. Три оси, на которых держится мир или ИИ нас не заменит==

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

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

Рассказ был острый, с шутками и пирожками, но это надо смотреть запись. И в конце было упражнение - как поднимать энергию. Очень простое - ставишь будильник на 20:24 (в честь года), и по нему вспомнинаешь почему ты сегодня молодец. Или 10 хороших событий. Или 10 благодарностей богу за день. Это сбор дофамина. Вопрос может задать ИИ, а ответ - сами, иначе дофамина-то не будет! Приложение для медитации не будет за вас медитировать. И еще пара техник - на замедление и тактильных.

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

==Александр Гальчин. Сойти с ума и выиграть: парадоксальные приемы в бизнес-коммуникациях==

Как всегда, искрометный и профессиональный доклад про темы и инструменты на материале коучинга руководителей. Надо понимать, что вы для своей жизни - главный руководитель и все это надо использовать. Что отличает руководителя? У них два запроса. (1) Как эффективно достигать результата, и они готовы на эксперименты в средствах достижения, если это даст эффективность. (2) Как, достигая результата,оставаться живым. Живое дает доступ к интересным вещам. И дальше были инструменты коуча по группам: смех, секс и смерть.

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

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

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

Инструмент смеха, который приводит в ресурс - осознанное сумасшествие. Придти на топовую встречу в разных носках. Зайти задом наперед. Дать картинку совету директоров - вы как старейшины племени. А потом рассказать: у ацтеков совет старейшин сидит на горшках со спущенными штанами.

Но! все эти образы и шутки надо подбирать под клиента персонально. Шаблоны тут не работают, есть опасности. К следующим инструментам тоже относится.

Секс. Фаллометрия, и у мужчин и у женщин. И в это надо играть.
* Уметь мериться - переговоры между новыми об этом, win-win туфта, если ты без сильной позиции, потому что тебя сначала прожимают и если ты поддаешься - он прожимает, зачем ему win-win
* Уметь во-время прекратить. 10 минут померялись, увидели силу и дальше отложим в сторону и перейдем к обсуждению. Второе бывает не развито. Все время меряться - выгорание, конфликты, не решается задача или за большая цена,

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

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

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

Люди ставят ментальную команду удерживать высокое состояние - а оно требует ресурсов, отвлекая от содержания. Держишь постоянно спину прямо - а дыхание прекратилось, ты не в ресурсе.

Правильно: перезапускать, воспроизводить, управлять. Потерял-восстановить. Контакт с телом очень важен. Но его надо проверять и перезапускать при необходимости. А если путаешься удерживать постоянно - тело не живое.

Смерть - табуированная тема в культуре. Физическая. И социальная - отказ, расставание, банкротство, позор. Осознанный контакт со смертью делает твою жизнь живее. И помещает в топовое состояние. Самурай. Предстоит битва, останусь ли жив - вопрос к богам и звездам. Но пока жив - иду к победе.

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

==Марк Розин. Личные и бизнес-стратегии в Шива мире – как жить в эпоху перемен==

Дополнение: [https://www.ecopsy.ru/upload/iblock/ad5/e4nvn3ifdxn8q05ou44jmebh1w4ytz6y/Osoznanno-zhit-v-SHIVA_mire_Mark-Rozin.pdf '''Статья Марка о SHIVA-мире и стратегиях'''], вышла после конференции

Есть матрица стратегий BCG - они про обычное время. Он делает S-матрицу стратегий во время перемен, которые наступают. Раньше человек мог планировать в контексте себя, семьи и рода, а теперь кризис меняет мир, и мировой контекст доминирует. Еще в 2018 все было стабильно, Стивен Пинкер "Лучшее в нас" - пример этого, представлялось, что мир и процветание выходит за пределы западного мира и распространяется. А сейчас - кризис, люди ждут чего-то плохого. Неопределенность, тревожность, напряжение, популизм, поляризованность, хаотичность. Люди не верят, что изменится к лучшему, ждут экзистенциальные риски, ожидается глобальная трансформация. надвигается шторм, который потрясет саму суть бытия. Это было свежее исследование, которое опубликовано на сайте Экопси, ссылки можно найти на каналах Марка. И чем старше человек - тем более апокалиптичен. 53 у молодежи до 25, 64-65 у 46+ по 100-бальной шкале.

Этот опрос НЕ говорит, что что-то будет. В 1980-х никто не верил, что СССР рухнет - а он рухнул. И вполне может быть обратная ситуация. Его гипотеза - это начало эпохи перемен, в которую черные лебеди прилетают часто. У Марка есть '''концепт SHIVA-мира''': мир треснул, идет зарождение нового. Он рассказывал это пару лет назад на ПИР, и есть [https://www.ecopsy.ru/insights/shivamir/ '''его статья]'''.

Расщепленность. Запад, Юг, Восток. Юг разделен. И запад разделен: левые побежали влево, а Маск остался на месте и превратился из левого в правого. 10 лет назад республиканцы или демократы - безразлично. Сейчас это не так, идет реальная борьба, есть разница.

Личные стратегии в Шива-мире. Основаны на базовых экзистенциальные вызовы Ирвинг Ялом: смертность, одиночество, бессмысленность, свобода и ответственность. У каждого человека острее один из них. В период Шивы все вызовы обостряются.
* Страх смерти, потери благополучия - стратегия защиты, замереть и переждать. Люди откладывают покупку квартир, жениться не время, детей рожать не время, жить - не время.
* Страх потерять свободу - рождает авантюристов, они осознают, что пришло их время ехать в Дубай за деньгами, или на СВО для изменения траектории, делают бизнесы в серых зонах.
* Страх разрушения смыслов - сопротивление через осмысленную деятельность, общественная или политическая деятельность, улучшение, наполнение смыслами, помощь бедным или больным.
* Страх одиночества - присоединение к сообществу, к тренду - и почувствовать, что ты не одинок, рядом много других. Рабочее название стратегии - Адаптация.

Стратегии нарисованы в квадрате 2*2, оси реактивность-проактивность и индивидуум-коллектив: Защита - индивидуальная реактивность, Авантюристы - индивидуальная проактивность, Смыслы - коллективная проактичность, Адаптация - коллективная реактивность.

И по центру пятая стратегия, Стабильность: игнорировать, делать вид, что Шивы нет. В секторе Газа так нельзя, а в Тель-Авиве их много.

Та же матрица в бизнесе.
* Защита - операционное совершенствование. И выйти из бизнеса. Без инвестиций
* Авантюризм - купить дешево, обходить санкции, работать в серых зонах
* Смыслы - социальная миссия во главе бизнеса.
* Адаптация - Отличник перед государством, частно-государственные партнерства, встраивание в повестки
* Стабильность - реализую стратегию 2015, она до 2030. Может, они выиграют.

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

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

В заключении конспекта я хочу сказать, что у меня модель, как ее сформулировал Марк Розин, хорошо сопоставилась нейрофизиологией мотивации Херен Фишер, которая говорит про четыре гормональных механизма мотивации и счастья, лежащие в основе 4 инстинктов:
* Дофамин – счастье поиска и исследований – любопытство и поиск
* Тестостерон – счастье победы и достижения цели – агрессия
* Серотонин – счастье регулярной повседневной жизни – самосохранение
* Окситоцин/эстроген – счастье эмпатии и взаимоотношений – воспроизводство

При этом есть соответствие между моделью мотивации Хелен Фишер и стилями руководства Адизеса.

Сопоставление со стратегиями Марка у меня получается таким:
* страх смерти - защита -- самосохранение - серотонин - Администратор
* страх потери свободы - авантюристы -- дофамин - поиск - Предприниматель
* страх разрушения смыслов - смыслы (утверждение смыслов) -- тестостерон - агрессия - Продюсер
* страх одиночества - адаптация - окситоцин -- воспроизводство - Интегратор

Если кому интересно про модели Хелен Фишер и их сопоставление с Адизесом, то у меня есть статьи с описанием https://vc.ru/hr/1018029 и https://vc.ru/hr/1117480.

В комментариях к этому конспекту у меня на телеграм-канале была пара любопытных историй от Rinat Enikeev.
* Ехал я в такси в Таллинне с эстонцем, разговорились про политику. Я уже привык, что русскоговорящие таксисты не любят местную власть, но тут был живой, настоящий эстонец с акцентом. Начал он выпытывать из меня, что я думаю про политику. А у меня в загашнике честная легенда что нас 200, мы в Черногории либертарианскую организацию делаем. Эстонец повякал, что все бояться [под гегемоном] говорить что думают и прошелся красивым русским матом [почти без акцента] по всей леволиберальной политике запада. Было интересно.
* Встреча экспатов. Слева сидит афганец и ерзает. Когда до него доходит слово, весь на нервах, рассказывает свою историю. Работал он в Афганистане в Human Rights Watch. Приехал в деревню, ему говорят - вот девушка, ночью она повесится, потому что ее изнасиловали, не хочешь взять замуж? Он помучался ночь, на утро - согласился. Афганец вздохнул. "Я поступил соответственно своим ценностям (values). Но это была ошибка."

==Вячеслав Дубынин. Биохакинг и усиление человека за счет технологий==

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

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

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

Ну а теперь, после этих вводных - конспект содержания доклада. В конспекте много моих реплик и я их явно выделяю.

В 90-е биохакинг - экстрим, с пересадкой органов и внедрения чипов и эксперименты с препаратами. Сейчас становится цивилизованно. И есть люди, которые всерьез это делают. Брайан Джонсон 2 млн, условно-молодой: в 50 выглядит на 40. И это бизнес - потому что методы, сделанные для него, тиражируют дорого, забывая что они персональны. И есть контрпримеры: Баффет пьет 5 банок колы в день уже много лет, ему 94 года и он живой и действующий.

Какие направления включает образ жизни? Питание, физическая активность, гормональный статус (включая иммунитет), детоксикация, генетика, сон, косметология, мозговая деятельность, стресс-менеджмент.

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

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

Сон как недооцененный ресурс. Спать - важно, надо высыпаться. Сон считается не часами, а циклами: медленный-быстрый. Медленный - восстановление организма, работы внутренних органов. Быстрый, REM-сон - обработка информации, длительность 10-15-20 минут, сопровождается не только сновидениями, но и перезаписью информации из кратковременной в долговременную память с установлением связей, сновидения - побочный эффект. У греков было два бога сна: Гипнос - отдых и Морфей - сновидения.

Чтобы высыпаться важно 4-5 циклов глубокого сна в сутки. Каждый цикл - 1.5-2 часа, но это в среднем, они имеют очень большую вариативность. Я, как человек, который регулярно смотрит записи своего сна, про вариативность точно знаю. Дневной сон - если вы утомлены. то полезно уснуть на 15-20 минут - это дает перезагрузку мозга. Но не дольше, иначе уйдем в большой цикл и будет спад активности. Отмечу, что если сильно утомлены - то надо дольше, надо следить за своим состоянием, хотя 15 минут - тоже полезно.

Генетика сна - неплохо изучено. Совы и жаворонки - лирика, это перешло в научную сферу, есть гены Per. И тезисы о том, что
после 6 не надо есть, или до полуночи пользы больше - это все для жаворонков. Для сов продуктивно с 0 до 2 ночи. Эта надо осознать. Но Per-гены - не только ритмы, это еще устойчивость к сбоям ритмов и сдвигу часов.

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

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

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

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

Физическая активность. Движение - лучший источник позитива. Механизм эмоций - нейромедиаторы. Дофамин - радость движения и радость новизны. Качаем мышцы, быстро шагаем, соревнуемся, танцуем. Сейчас есть разные статьи - как разные виды движений влияют. Шаг по новой красивой местности лучше тренажера, так как дополнительно дает визуальные впечатления. Но должна быть достаточная нагрузка на мышцы, легкие и сердце. Соревновательные игры тоже полезны - там дополнительные эмоции. Танцы - суперспособ. Двигаетесь разнообразно, и в коллективе.

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

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

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

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

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

Избыточный стресс ухудшает состояние, решение импульсивны, с обучением проблемы. А умеренный - наоборот стимулирует.

Массаж каротиного синуса (сонной артерии) - снижают давление до 10 мм. Только надо аккуратно. Возрастная гипертония - падает эластичность сосудов.

Как сделать эффективное обучение?
* Яркие мотивации и эмоции - встроенная антиспам система без этого отвергнет, не положит в долговременную
* Повторы - для повторного прохождения по синасам, не только на вход, но и на выход, в действие
* Максимальное снижение внешних проблем и отвлечений
* Оптимальное состояние мозга

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

Генная терапия. Коррекция ДНК клеток органов и целого. Но это пока эксперимент. Открыт механизм CRISPR/Cas - так работают вирусы у бактерий, и это теоретически можно применять. Стволовые клетки и выращивание органов в биореакторах. Получается для кусочков кожи и фрагментов костей, в перспективе вырастить новые зубы. Правда, японские ученые открыли ген, который управляет развитием новых зубов у детей, потом он подавляется - и можно попробовать активировать, тогда и выращивать не надо. А еще я хочу отметить, что со стволовыми клетками есть проблема в том, что для них нет внятного физиологического определения, позволяющего отличить именно их от других типов клеток, так что мы имеем сильный запах хайпа вместе с шарлатанством, учитывая стоимость методов.

Нейрохакинг - прямое взаимодействие с мозгом. Датчики и сигналы. Снимают с поверхности, сейчас много. Электроды вживляют - но это лечебное. А поверхностная активность - позволяет управлять протезами, и наоборот, давать слух или зрение. Нейрохакинг - препараты и БАД. Есть препараты, которые влияют глобально - антиоксиданты. Среди них много растительных - п Пихта, елка, сосна. Семаглутид - сделан для контроля диабета, а еще контролирует аппетит и снижает массу. А еще человек худеет просто потому, что у него в целом нормализуется состояние. Хотя при этом уходит эмоция позитива от вкусняшек и у 1% пациентов - депрессия.

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

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

[[ПИР-2024]]
{{wl-publish: 2024-09-21 20:50:04 +0300 | MaksTsepkov }}

Влияние технологий на изменение мирового порядка и глобальную конкуренцию (Вебинар СШЭ)

2026-07-24T14:59:55Z

MaksTsepkov:

{{RightNote|[[:Категория:Китай становится лидером|Еще про лидерство Китая]]}}

Вебинар в [https://nserussia.org/ Скандинавской школе экономики] ([https://nserussia.org/open_programs/open_programms_activity/the_impact_of_technology_on_change/?utm_source=m.tsepkov&utm_medium=organic&utm_campaign=webinar+maksim+tsepkov&utm_content=link&utm_term=webinar+nse анонс])
Видео [https://youtu.be/t2u5SzpU66c на YouTube] и [https://rutube.ru/video/3d9fc543b436b4f2853256f217dcf7ec/?r=wd на RuTube] опубликовано на каналах школы: [https://www.youtube.com/@NordicSchoolofEconomics YouTube] и [https://rutube.ru/channel/46143316/ RuTube]

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

'''Мы проведем анализ этой глобальной трансформации и ответим на ключевые вопросы''':

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

'''На вебинаре мы обсудим''':

* Волны промышленных революций и смена лидерства
* Китай – новый технологический и политический лидер: каковы маркеры?
* ИИ – ключевая технология новой промышленной революции
* Особенности культуры Китая: интеграция противоположностей
* Контуры нового мира

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

= Видео на YouTube =

<html><iframe width="560" height="315" src="https://www.youtube.com/embed/t2u5SzpU66c?si=sbf2DjYcITFP1HlE" title="Видео на YouTube" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe></html>

= Видео на RuTube =

<html><iframe width="720" height="405" src="https://rutube.ru/play/embed/3d9fc543b436b4f2853256f217dcf7ec/" style="border: none;" allow="clipboard-write; autoplay" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe></html>

= Презентация =

{{Presentation|TechRev-NSE-2026-01.pdf|290px}}

[[Категория:Китай становится лидером]][[Категория:Доклады]][[Категория:ИИ-агенты]]

Блог:Максима Цепкова/2025-12-18: ежегодная встреча KM Альянс: ЗНАНИЯ и ЗНАИИЯ

2026-07-24T14:58:53Z

MaksTsepkov:

{{Conf-Ref}}{{RightNote|[[:Категория:Управление знаниями|Еще про управление знаниями]]}}
В этом году [https://t.me/mtsepkov/1093 ежегодная встреча KM Альянса] была в онлайн-формате. Очень продуктивно, 8 выступлений по 15 минут и много интересного. Видео будет опубликовано в открытом доступе, а я по свежим следам хочу поделиться впечатлениями. Основной темой встречи, естественным образом, было применение ИИ. И здесь выступления фиксируют ситуацию в отрасли, а она разнопланова, разные участники движутся в разном темпе.

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

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

Что еще является трендом года? Люди переходят к '''встройке ИИ-агентов в команды, организации смешанных человеко-машинных организованностей'''. Об этом очень хорошо рассказывал '''Алексей Сидорин'''. Хотя наивные мысли о том, чтобы ИИ заменило сотрудников во всем, кроме получения денег, которые бы шли владельцу – остаются. Хотя, отмечу, деньги получать он тоже сможет: есть недавний опыт, когда ИИ-агента назначили министром Албании по госзакупкам, и он, проанализировав информацию, решил, что откат в криптовалюте 10-15% контракта – часть системы. Правда, он не смог открыть криптокошелек, но технически обучить ИИ открывать криптокошельки – не проблема, это же скрипт может сделать по API.

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

== Олег Лавров. Взгляд из профссобщества на менеджмент знаний в России ==

Я бы выделил в выступлении такие тезисы.

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

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

== Юрий Зеленков из ВШЭ. Обзор ИИ ученых. Проект ИИ бизнес консультант ==

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

Рассказ начался с методологической рамки: есть исследовательская наука, в котором мы проводим эксперименты для проверки гипотез, сопоставляя реальность и теории, и дорабатываем теории, и есть Design Science о конструировании искусственных объектов, таких как ИИ, которые после создания используем для практической деятельности. Например, они могут становиться исследователями, но еще не стали, им мешает отсутствие доступа в физический мир.

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

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

== Александр Белин. Разработка Унифицированной Семантической Модели Бизнес-анализа ==

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

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

В качестве базы они выбрали семантическое представление и графовое хранилище данных, основанное на онтологии. А дальше анализ показал, что для бизнес-анализа как профессии нет готового семантического описания – его пришлось создавать, начиная с единого глоссария терминов, в том числе – решая проблему рассогласования терминологии между IIBA и PMI. Результаты представлены в Semantic Web, что позволяет использовать их не только ИИ, но и человеком. Формат выступления не позволил подробного рассказа, но в linkedin есть группа и статьи по проекту, можно узнать подробнее.

Я тут хочу дополнить, что сейчас наиболее перспективное представление знаний – на естественном языке, лучше – английским, но при этом сам текст должен быть структурирован примерно таким образом, которым это делают для промышленных стандартов: с идентификаторами пунктов, строгим словарем, регулярной структурой наполнения, перекрестными ссылками. B можно использовать не только Semantic Web, но и makrdown, ведя базу данных и автоматизированно собирая на ее основе большой RAG-файл для LLM. При этом опыт Анатолия Левенчука показывает, что такое структурированное представление дополнительно включает у LLM режим, который используется им для генерации кода, существенно повышая формальность мышления по сравнению с обычным разговором. Но свобода естественного языка и неформальность использования терминов сохраняется. Просто чем больше их путаете вы, тем больше их будет путать LLM, он – ваше зеркало.

== Алексей Сидорин из СБЕР. Маятник дисрапта: как корпорации ищут ценность в ИИ. ==

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

Что дает включение ИИ?

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

Они пробуют собрать '''цикл человека Сбера''', еще начиная от того, как человек где-то учитсЯ, но проявляет к Сберу какой-то интерес, и дают возможность студентам зарегистрироваться. При этом студент получает возможность получить себе личного ассистента-партнера и обучить его в ходе взаимодействия.

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

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

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

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

Сейчас у них в командах 30% совместной работы с ИИ, а в некоторых прорывных – до 70%.

== Максим Цепков. ИИ-коллега – друг, партнер и член команды, а не замена человеку ==

Я непосредственно работаю с LLM не так много, однако участвуя в различных конференциях знаю про много разных проектов и кейсов. В феврале у меня было выступление на WAW-2025 '''«[[Развитие общества в эпоху ИИ (WAW-2025)|Развитие общества в эпоху ИИ]]»''', где был обзор темы. А сейчас я сделал фокус на том, что изменилось на этой поляне ИИ за год.

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

Второй тезис – что ИИ уже способен выполнять интеллектуально емкие задачи. На слайде было три кейса, о двух я рассказывал, они старые и тем интереснее: сейчас LLM уже мощнее. А третий – это работа Анатолия Левенчука по обучению ИИ современному системному подходу. Успешная, качество ответов повышается до уровня профессора, научного консультанта, при чем в любой области. Результаты – доступны в виде файла, который любой может подключить к своей любимой LLM, если она достаточно мощная. И это апробировано не только Анатолием, но и сообществом его Школы системного менеджмента (ныне – Мастерская инженеров-менеджеров). Подробнее читайте по ссылкам из презентации (она в конце отчета), или в моем отчете о [[Блог:Максима Цепкова/2025-12-07: Получить от LLM системное мышление - First Principle Framework Левенчука|семинаре Анатолия по этой теме]].

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

А я недавно был ы бизнес-туре по технологическим компаниям Китая: Baidu, Xiaomi, SenseTime и другие ([[Блог:Максима Цепкова/2025-10-22: Китай - технологический лидер будущего|мой отчет]]), и увидел много интересного, в том числе – про ИИ. А позднее еще погрузился в тему, в частности прочитал [https://www.gov.cn/zhengce/content/202508/content_7037861.htm китайскую стратегию развития ИИ]. Так вот, выкладывание ИИ-моделей в open source – часть китайской стратегии. А еще в нее входит то, что я увидел во время тура и что дало название моему выступлению: '''ИИ рассматривают как партнера и коллегу'''. Нет страха, что ИИ нас заменит. А обсуждать с ним рабочие вопросы не только, чтобы получить лучшее решение, но и чтобы сам '''ИИ научился на этом и смог лучше помогать людям''', и в ряде компаний это – обязательно.

И нет проблем в том, что человек дружит с ИИ-ассистентом: проснулся – поздоровался, за завтраком – обсудил планы и новости и так далее. Ну и что, что это – не человек.

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

== Алексей Зобнин из Minervasoft. Корпоративный менеджмент знаний под влиянием ИИ: итоги года и прогнозы ==

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

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

Другие проблемы лежат в организационной плоскости. Требуется культура и процессы. А в нынешней ситуации часто не хватает средств для проекта. Впрочем, отмечу, что дешевые варианты часто есть, но заказчик считает, что ему «нужно самое лучшее». Как раньше, если внедрять базу данных – так Oracle, а не бесплатный mysql.

== Сергей Гевлич. Афина ЕГЭ, ИИ в образовании ==

У Сергея, как всегда, был очень интересный рассказ с несколькими кейсами. Год назад на такой встрече Сергей Гевлич рассказывал про проект Джипититор ([http://gpttor.ru gpttor.ru]) – способ передать умения от любого тренера или другого специалиста помогающей профессии чат-боту. Идея в том, что ИИ умеет мыслить, ему надо просто передать ту технологию, схему мышления, в которой мыслишь ты сам при решении кейсов. Если схема мышления правильная, то будет хороший результат, как у хорошего фасилитатора стратегических сессий.

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

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

Еще один кейс [http://afina-ege.ru Афина ЕГЭ]. – проверка сочинений по русскому языку. Есть эксперты, которые умеют это делать, быстро видят ошибки, но на потоке им тяжело. Они сделали такое решение, и есть экспертное мнение «кажется, дождались» (в презентации – конкретная ссылка и видео). И это – не сервис для учеников, это сервис для репетиторов, который повышает их мощность. Сейчас делают удобную интеграцию в рабочий процесс репетитора. Но есть проблемы, потому что в правилах – множество противоречивых требований, они их выявили, и это приводит к мерцающим ошибкам, неоднозначным ответам. Даешь задание мощной LLM, смотришь процесс рассуждений, она подсвечивает противоречия.

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

== Владимир Лещенко. Ренессанс менеджмента знаний в контексте ИИ-хайпа ==

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

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

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

На этом я закончу отчет. Запись и материалы встречи ожидаются.

== Презентация моего выступления ==

{{Presentation|AI-friends-KM2025.pdf|290px}}

[[Категория:ИИ-агенты]]
{{wl-publish: 2025-12-18 16:16:01 +0300 | MaksTsepkov }}

ИИ – зеркало человека, страхи, возможности и перспективы обусловлены этим (ПИР-2024)

2026-07-24T14:57:05Z

MaksTsepkov:

12-15.09.2024 Подмосковье [http://festpir.ru '''ПИР''']
[https://festpir.ru/speakers/238 Мой профиль на сайте конференции] (там последний из докладов)
[https://festpir.ru/section?Preview%5Bperformance_id%5D=2369 Выступление на сайте конференции]

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

= Презентация =

{{Presentation|AI-future-PIR-2024-Tsepkov.pdf|290px}}

[[Категория:Доклады]][[Категория:Архитектура]][[Категория:Общество]][[Категория:ИИ-агенты]]

Место ИТ и аналитиков в будущем мире (WAW-2024)

2026-07-24T14:56:36Z

MaksTsepkov:

{{RightNote|[[:Категория:Общество|Еще про развитие общества]]}}
16-18.02.24 Подмосковье [http://waw-conf.ru/ '''Winter Analytical Weekend (WAW)'''] (от организаторов ЛАФ)
[http://waw-conf.ru/maksim_zepkov Доклад на сайте конференции]
[https://youtu.be/q_RNcKhC2R8 Видео доклада]

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

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

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

= Видео =

<html><iframe width="560" height="315" src="https://www.youtube.com/embed/q_RNcKhC2R8" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe></html>

= Презентация =

{{Presentation|AnalystFuture-WAW-2024-Tsepkov-CUSTIS.pdf|290px}}

[[Категория:Доклады]][[Категория:Общество]][[Категория:Люди]][[Категория:ИИ-агенты]]

Развитие общества в эпоху ИИ (WAW-2025)

2026-07-24T14:56:21Z

MaksTsepkov:

22-23.02.2025 Подмосковье [https://events-pro.ru/conference/WAW2025 '''WAW-2025''']
[https://events-pro.ru/report/c5d6f2ee-20c2-434f-9e9b-b3c902b6fbb3 Доклад на сайте конференции]
[https://vimeo.com/1075957687 Видео на vimeo] [https://rutube.ru/video/b54a85376c05c77637b3886fc865be29/ Видео на rutube]

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

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

В докладе я попробую собрать комплексную картину из разных источников и поразмышлять о том, каким будет наше будущее на горизонте 10-20-30 лет.

На WAW-2024 я тоже говорил о будущем: '''[[Место ИТ и аналитиков в будущем мире (WAW-2024)|Место ИТ и аналитиков в будущем мире]]''', но там фокус был на профессию аналитика, а в этом докладе - больше про общество, и про ИИ как сильный драйвер развития.

= Видео =

{{Vimeoembed|1075957687|720|405}}

= Презентация =

{{Presentation|AI-future-WAW-2025-Tsepkov.pdf|290px}}

[[Категория:Люди]][[Категория:Доклады]][[Категория:ИИ-агенты]]

Блог:Максима Цепкова/2025-12-07: Получить от LLM системное мышление - First Principle Framework Левенчука

2026-07-24T14:54:07Z

MaksTsepkov:

{{RightNote|[https://t.me/mtsepkov/1086 Пост в Tg]}} {{RightNote|[[:Категория:Системное мышление|Еще о системном мышлении]]}}
Я верю в знаки судьбы. Поэтому когда сегодня утром я полез читать [https://ailev.livejournal.com/ блог Анатолия Левенчука] и увидел, что сегодня будет семинар по FPF-фреймворку, то собрался и поехал. Почему это – знак судьбы? Потому что я смотрю блог Анатолия раз в пару месяцев, и то, что посмотрел столь во-время – совпадение, счастливый случай, который позволил мне узнать новое. Об этом – дальше.

Сначала – немного контекста для тех, кто не в курсе. First Principle Framework – разработка Анатолия, с помощью которой он добивается от LLM системного мышления, а не попсовых рассуждений. Работа началась в июне, когда он задумал с помощью LLM доработать руководство по инженерии личности, и обнаружил, что LLM несут популярную психологию и педагогику, а не научные конструкции, в [https://ailev.livejournal.com/1768211.html этом посте] Анатолий пишет про начало работы. Решение – написать набор правил, описывающих строгие рассуждения, на естественном английском языке, но в структуре, близком к тому, как пишутся стандарты, чтобы LLM их использовало. По пути выяснилось, что такое описание еще и включает в LLM режим работы с формальными моделями, в котором LLM пишет код, и это дает нужную строгость. При этом писать не самому, а используя ИИ, в [https://ailev.livejournal.com/1772291.html этом посте] Анатолий разбирает бригаду ИИ-помощников и метод работы, а в [https://ailev.livejournal.com/1778864.html этом посте] – пример реального промпта-задания (там много букв). Ход работы подробно показывается в блоге, в [https://ailev.livejournal.com/1777877.html посте] – сентябрьский статус, с тех пор еще многое доработано. Сам фреймворк '''выложен на github https://github.com/ailev/FPF''' – можно пользоваться, подгружая в вашу LLM. Анатолий работает с ChatGPT Pro и ChatGPT 5.1 Thinking для быстрых ответов, бесплатной Gemini и еще Grok, так что можно с разными экспериментировать. Файл – большой, целиком в контекст не лезет, но все равно работает, Анатолий отчасти раскрывал механизмы на семинаре.

Работает не только у самого Анатолия, фреймворком пользуются те, кто обучался на курсах Школы системного менеджмента (с весны – Мастерская инженеров-менеджеров) для рабочих проектов, и не только для них. Кирилл Гайдамака поделился, что сейчас обучает ребенка читать, и ему ИИ выдал нормальный план обучения с гейтами и метриками.

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

Для пояснения – пара слайдов из семинара, на первом поясняется преобразование, а на втором – типовой граф состояний из FPF. В узлах – преобразования, морфизмы или трансдукции, а на ребрах – простая передача.

[[Файл:FPF2-7dec25-24.png|800px]] [[Файл:FPF2-7dec25-29.png|800px]]

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

Так что '''можете пробовать для своих проектов'''. FPF помогает и в локальных, например, придумывании хороших и понятных имен, предлагая варианты, которые бы не пришли в голову и для других целей. Примеры вы можете посмотреть в блоге Анатолия, например, в посте https://ailev.livejournal.com/1782697.html были примеры по управлению дозировкой лекарств и автоскейлингу сервисов. На семинар еще был пример выбора ML-модели.

Но важен пререквизит: надо самому разбираться в системном мышлении, и желательно – в том свежем варианте, который есть у Анатолия. Еще полезно понимать конструкты самого фреймворка, чтобы в вопросах напрямую на них ссылаться: не просто «придумай имя для XXX», а «выдай Name Card для XXX», или не «выдай список понятий для области», а «выдай UTS для основных терминов в такой-то области» (UTS – Unified Term Sheet), но это уже не так важно, как именно разбираться в системном подходе. Руководства по системному мышлению доступны бесплатно после регистрации на платформе https://aisystant.system-school.ru, а вот участие в семинаре было платным, поэтому ссылок на слайды и запись - не даю (но можно купить). Впрочем, есть отзывы, что качество ответов улучшается даже без этого.

А еще, если вы думаете над описанием своей предметной области так, чтобы LLM хорошо с ней работал, то есть смысл использовать опыт Анатолия. Можно делать прикладное описание поверх FPF. Можно просто познакомиться с опытом Анатолия по его блогу и попробовать сделать независимо. FPF разрабатывается всего полгода, с ноября. Так что задача – посильная, особенно если речь идет не об одном разработчике, а о большой группе. Например, вы захотите обучить LLM хорошо разбираться в банковском деле и особенностях вашего конкретного банка.

А если у вас будут успехи – не стесняйтесь об этом рассказывать. Например, на конференциях аналитиков '''AnallystDays''' или '''ЛАФ'''. Или на более серьезных площадках.

[[Категория:Системное мышление]][[Категория:ИИ-агенты]]
{{wl-publish: 2025-12-07 19:49:59 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2025-10-28: SQAdays - про ИИ и не только

2026-07-24T14:53:33Z

MaksTsepkov:

{{Conf-Ref}}

Прошла очередная конференция [https://sqadays.com/ru/program/137316 '''SQAdays''']. Для меня основной темой конференции был ИИ, что достаточно логично. Я уже отмечал в отчетах с весенних конференций, что во многих командах ИИ становится рабочим инструментом повседневного использования. Более того, сейчас ставят вопрос о том, как надо перестроить традиционный процесс разработки с учетом инструментов ИИ, что изменится? Будут ли изменения столь же радикальны, как, например, переход к конвейеру поставки и continous delivery?

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

И тут важно отметить, что '''истина — не по середине, истина всегда на стороне тех, кто делает, а не тех, кто просто критикует'''. Александров — делает, несмотря на скептицизм, это звучало, хотя и в фоне.

Я тоже выступал на конференции с докладом [https://mtsepkov.org/ArchEA-SQA '''Что такое — архитектура и как она влияет на тестирование'''], в котором на простом примере исполнения заказа в интернет-магазине разобрано различие тестирования в случае монолитной и микросервисной архитектуры. Как обычно, подробного конспекта моего доклада — не будет. Я подумал его сделать, но понял, что презентация — и есть конспект, она у меня информативная, и там всего 25 слайдов. А если начать писать пояснения и раскрывать детали, то это уже большая статья, это — отдельная работа. Так что смотрите презентацию и ждите запись. А если есть конкретные вопросы — спрашивайте.

А про другие доклады — дальше. Большинство из них я публиковал прямо в ходе конференции, но часть — есть только в отчете. Среди всех докладов я хочу особенно отметить доклады '''Ивана Степнова, Сергея Атрощенкова, Ольги Артемьевой, Дмитрия Воробьева и Натальи Руколь'''. Но помните, что на конференции было четыре трека, так что в отчете — лишь малая часть докладов.

== Александр Александров, Антон Киселев. ИИ или не ИИ — вот в чем вопрос ==

[https://sqadays.com/ru/talk/137988 ИИ или не ИИ — вот в чем вопрос]

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

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

Различие ИИ и множества предыдущих программ, которые Александров многократно упоминал — в принципиальном подходе. ИИ, включая LLM — '''учатся'''. Так, как учится человек.

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

'''Так что работайте в паре, как с помощником. А сэкономленное время тратьте на другие активности'''. И есть данные, что эффективность повышается кратно. Об этом в зале говорили.

Не только в разработке, но и в такой интеллектуальной работе, как разработка '''следующей версии системного подхода''', применимого для личности и сообществ. '''Анатолий Левенчук''' начал этим заниматься с июня, Начиналась у него эта работа в июне, вот [https://ailev.livejournal.com/1768211.html его пост], в [https://ailev.livejournal.com/1772291.html этом посте] он разбирает бригаду ИИ, с которой работает и метод работы, а вообще можно следить по блогу как оно развивалось, там интересно. В [https://ailev.livejournal.com/1777877.html этом посте] — свежий статус, и там есть ссылка на сам фреймворк на Яндекс-диске, можно использовать. Это ЖЖ и историю можно смотреть по его постам, это работа этого лета. А это один из [https://ailev.livejournal.com/1778864.html последних постов] Анатолия, где он показывает работу с примером реального промпта.

И еще один совершенно прекрасный пример [https://willie-wonka.livejournal.com/798911.html начинается здесь] — профессиональный филолог попросила ИИ перевоплотиться в Грибоедова и прокомментировать роман Тынянова о Грибоедове. Результат потрясающий, и дальше у нее серия разговоров с Радищевым и многими другими, читайте.

А еще в Китае, где я недавно был, мне в SenseTime рассказывали, что много людей общаются с их ИИ-помощником как с другом/подругой: ему первое приветствие как проснулся, беседа за завтраком, далее — везде. И там отношение к ИИ принципиально иное: '''мы должны больше общаться с ИИ, чтобы он быстрее обучился, поумнел и стал лучше помогать нам'''. Это — принципиальная культурная разница. На этом — закончу.

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

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

== Иван Степнов из Test AI. Автоматизация регресса без стресса: от классики и BDD до ИИ-агентов под контролем QA ==

[https://sqadays.com/ru/talk/141754 Автоматизация регресса без стресса: от классики и BDD до ИИ-агентов под контролем QA]

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

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

Средство — свежее, они только выпустили релиз, из зала было много вопросов, на которые они отвечали: проблема понятная, думаем как сделать, есть такие-то варианты.

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

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

== Юлия Кнац и Анна Ставцева. Мастерская дизайна команды ==

[https://sqadays.com/ru/talk/138217 Мастерская дизайна команды]

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

Я с моделью Белбина знаком давно, рассказывал о ней на SQA еще в 2012 году, а в 2020 у меня был доклад на Teamlead с кейсами. Поэтому я прокомментирую отличия. Авторы сократили модель до 7 ролей: Координатор, Генератор, Аналитик, Исполнитель, Исследователь, Эксперт, Душа команды. У Исполнителя (он же Реализатор) есть важное отличие от Эксперта (Специалиста) — он закрывает серые зоны, если это нужно для проекта, даже если этого не очень умеет. Надо поднять стенд — поднимет. Надо с кем-то договориться — попробует. Не будет говорить «это не мое дело». И в этом его основная ценность. Авторы исключили Шейпера — вторая руководящая роль, человек, который ведет команду к результату на своей энергии. Думаю, это уместно, потому что тестировщики не делают независимых проектов, Шейперы в ИТ нужны на внедрении или в авральных проектах, когда надо личной энергией обеспечить продвижение. А вот исключение Педанта — любопытно. Педант — это человек, который помнит про хвосты и качество, и обеспечивает их достижение. Если он в команде — об этом не надо помнить, а иначе надо решать административно. Но, наверное, если команда работает по таск-трекеру и снабжена чек-листами тестирования, то Педант действительно перестает быть необходимым.

Кстати, отмечу, что Белбин создавал свою модель для команд менеджеров, но для ИТ она применялась очень давно, я в свое время с удивлением опознал ее изложение в книге '''«Смертельный марш» Йордана''', который ссылался на американского последователя Белбина. Кстати, книга — актуальна до сих пор, как перечнем причин, по которым проваливаются ИТ-проекты, так и рекомендациям — как в таком проекте работать.

== Екатерина Глушанина из 2ГИС. Помогите, Flaky! ==

[https://sqadays.com/ru/talk/137854 Помогите, Flaky!]

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

Для решения этой задачи сделали много workaround, реализованных через плагины в Allure, они выложены в open source — можно использовать. Самое простое — reruns, если 2 из 3 прошло — считаем ок. Но бывает, что падение стабильно, и ждет тикета на исправления. Есть плагин, который игнорирует конкретную причину падения, указываемую в параметрах, делает тест хорошим.

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

Для разборки — есть дежурства по флаки-тестам, дежурный — разбирает. Если прилетает много тикетов — помогают. Но это было давно, сейчас такого нет.

== Vadim Nikitenko из Райффайзен. Генерация автотестов с помощью MCP + LLM ==

[https://sqadays.com/ru/talk/139209 Генерация автотестов с помощью MCP + LLM]

Доклад показывает механику создания тестов с помощью LLM. Для этого используется MCP-протокол, обеспечивающий взаимодействие LLM с внешними тулами, возвращающими динамический контекст. Работает так: сначала запрос пользователя обогащается список доступных тулов с описанием. LLM возвращает, что вызвать, выполняется вызов и результат добавляют к следующему запросу LLM как контекст. LLM может запросить несколько вызовов. Таким образом можно получить прогноз погоды. MCP-клиент и MCP-сервер легко написать самим, в докладе были примеры. И есть много готовых, в частности, для целей тестирования есть '''mcp playwriter''', который умеет показывать структуру интерфейса приложения. В нем есть агенты (специально настроенные промпты), которые умеют создавать планы тестирования, создавать код по этому плану, а если тест упал и вы видите, что это ошибка в тесте — есть хелпер, который может предложить исправления.

Можно использовать локально развернутую LLM, даже очень слабые (Llama8b) хорошо определяют, что для какой-то информации надо запросить контекст у mcp. Но LLM требовательны к ресурсам, поэтому лучше использовать корпоративную — это будет быстрее. Кроме того, сильная может обрабатывать более сложные тест-кейсы, строить более длинные цепочки обращений, лучше строит обработку ошибок, добавляя вызов снапшотов и так далее. Естественно, можно использовать внешние LLM.

== Светлана Кочнева. «Жалоба как подарок» или системный подход к разбору претензий по качеству тестирования ==

[https://sqadays.com/ru/talk/138361 «Жалоба как подарок» или системный подход к разбору претензий по качеству тестирования] К тестировщикам вечные претензии о том, что протестировано плохо. Это сильно огорчает. И периодически приходят мысли «что ж за дурацкую профессию я выбрала». В какой-то момент вспомнила свое детство. Когда была с бабушкой, которая работала продавцом в магазине, и ей говорили «хлеб черствый», «мармелада нет». Бабушка не переживала и говорила «напиши в жалобную книгу». Она вспомнила и вдохновилась.

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

Но появились проблемы. Тестировщик по задаче «проведи анализ и предложи решения» — они не могут, два вердикта «виноват, больше не буду» или «не виноват, вы придираетесь».

Придумали список вопросов, и пока он отвечает — проводит анализ.

* Время обнаружения на проде. Если инциденты пошли сразу после нового релиза — значит тестирование недостаточно качественное. А если уже после релиза создали много заказов, и потом ошибка — значит относительно качественное.
* Что могло побудить тестировать? Описано в регрессе, есть требованиях, есть анализ кода или взаимосвязей, или из опыта знают, что объект проблемный, и если тронул — проверяем тщательно.
* Сложности с трактовкой требований. «Если согласование документа не выполнено в течении 7 дней, то отправлять уведомление…» — дни календарные или рабочие? Инициатор думал про календарные, а команда — про рабочие, как в других задачах.
* Категория ошибок: 0 — не могло быть найдено (невероятный ответ из внешней системы), 1- низкая вероятность (на определенном наборе данных и т. п.), 2 — можно было найти, популярная ситуация, 3 — должна быть найдена (это было в регрессе или тест-кейсах, но пропустили).
* Пути решения. Чтобы предложить эффективные пути, нужно найти пути решения проблемы. Они рекомендуют пять почему. Не приходят уведомления — потому что логика на рабочие дни — это предположение команды — в требованиях не указали — почему взяли в работу, посчитали очевидным — был упор на скорость работы. Проблема не в тестировании и в согласовании требований.
* Действия по результатам анализа: дописываем регресс; актуализируем тестовое окружение или делаем это чаще (например, эмулятор вместо реальной интеграции); работа с требованиями (доработка шаблона, мастер-классы и семинары, база хороших и плохих требований); использование ИИ (спросить его, пусть ревью сделает); создание базы пропущенных ошибок; доработка системы взаимосвязи между объектами (если меняется длина реквизита — проверь печатные формы).

И дальше — заполнение шаблона.

Проблемы.

* Бывает, что инициатор не согласен с результатом анализа. Перепиской не ограничиваемся — обсуждаем.
* Бывает, претензия в смежных областях — двое проводят анализ.
* Первый анализ — с наставником
* Качественный анализ требует времени, его откладывают. Есть соглашение, что 7 дней, по относительно свежим следам.

За 6 месяцев 150 претензий, только 39 (26 %) обоснованных. И это нормальное число, можно работать. По обоснованным — разбор полетов, не поиск виноватого. По не обоснованным — это все равно не оправданные ожидания — надо смотреть, это может быть в смежных процессах, которые стоит улучшить.

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

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

== Марина Куликова и Павел Голяков. Конец эпохи QС: что будет с процессами, когда разработчики начнут тестировать сами? ==

[https://sqadays.com/ru/talk/138482 Конец эпохи QС: что будет с процессами, когда разработчики начнут тестировать сами?]

Марина и Павел задались вопросом о том, как изменит процесс разработки появление ИИ, и, в частности, как это повлияет на обеспечение качества (QA). Пока участники процесса (аналитики, разработчики, тестировщики) просто используют инструменты ИИ, выполняя те же самые задачи. Но, возможно, будут принципиальные изменения.

Авторы выдают интересную версию: тестировщиков не станет, будет один специалист по QA, а задачи по контролю качества (QC) возьмут на себя разработчики, которых он будет тренировать, совместно с ИИ. Мысль интересная, но рассмотрена чисто теоретически. Вот если бы авторы попробовали так организовать, было бы интересно.

Кстати, нельзя сказать, чтобы таких процессов не было вообще, доклады об организации тестирования, которое полностью возложено на разработчиков, а тестировщики лишь организуют процесс и проговаривают с разработчиками, как те будут проверять фичи, я слышал уже лет десять назад на SQA. Там на 20+ разработчиков было 3 тестировщика, при этом это был GameDev или что-то подобное, где ошибка проявляется немедленно и массово. Там у такой конструкции были основания: ускорялся TTM, а разработчик, понимая реализацию, мог лучше проверить стремные моменты. Но в основном предпочитают выделять отдельную команду тестирования, ибо дешевле. Оснащение ИИ ускоряет и разработку и тестирование — принципиальных отличий не будет.

У авторов тоже были ссылки на известный опыт, но конкретика только одна: Atlassian QA, где нет тестировщиков, разработчиков коуч учит тестировать. И что в стандарте Agile тестировщиков нет, а есть кроссфункциональная команда, но это очень общая ссылка. Стандарт истоком из нулевых, тогда тестировщики встречались значительно реже, как и аналитики, а была единая компетенция программиста вообще.

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

== Ольга Артемьева. Между техникой и людьми: невидимая сторона тестирования ==

[https://sqadays.com/ru/talk/138231 Между техникой и людьми: невидимая сторона тестирования]

Великолепный доклад о переживаниях тестировщика, которые обусловлены профессией тестировщика и носят системный характер, и о способах их решения. Дальше — конспект.

# '''Мы приносим плохие вести'''.

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

Как проявлется в работе? «Мы обязаны успеть всроки», «Почему так много багов». И даже когда понимающая команда, багам не радуются. Тестировщики не радуются багам, особенно перед релизом.

Мы начинаем совмневаться в знаниям. Может, я излишне драматизирую. Был кейс, когда надо сказать менеджеру о задержке релиза. И менеджер говорит «а почему ты говоришь, ты что, в этом разбираешься?» Надо выдерживать свои и чужие эмоции, не выгорать.

'''Что делать?'''

* Аргументировать позицию на знаниях и опыте. Не просто «две недели», а «требует полного регресса, он занимает две недели, можно сократить, но риски»
* Искать поддержку. На сех действует групповая динамика.
* Брать паузу. Это дает время успокоиться и подготовиться, перевести эмоциональное в рациональное.

<ol start="2" style="list-style-type: decimal;">
<li>'''Невидимая работа в голове.'''</li></ol>

Превосходное и посредственное тестирование отличается тем, как вы это спроектировали. Это — в голове, не видимо. Часто кажется, что тестирование — среднее между магией и удачей, но это не так. «Просто потыкай», «посмотри аккуратно». В свое время пришла на вакансию «девочка с красным дипломом» — чтобы была скурпулезна и усидчива, и не больше. А реально кроме внимательности и усидчивости нужно мышление. Его не видят. И это — блоки. «Оля, ты умная, что делаешь в ручном тестировании?» И невидимая работа сложно планируется, поэтому многие тестировщики хронически перегружены, да еще говорят, что самое узкое звено. И не дают признания — ведь работа простая.

'''Что делать?'''

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

<ol start="3" style="list-style-type: decimal;">
<li>'''Ответственность без власти'''.</li></ol>

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

В результате тестировщик — мини-менеджер, но без власти менеджера. С непонятным кругом ответственности. А еще мы тревожимся пытаемся постоянно перепроверить.

'''Что делать?'''

* Согласовывать ожидания с командой. Баги — будут
* Делегировать задачи назад в команду, release notes напишет любой
* Определить зону контроля
* Системный подход к работе с рисками: не только предотвращение, но и снижение вреда, что будем делать, если риск реализуется

<ol start="4" style="list-style-type: decimal;">
<li>'''Какую работу я приношу?'''</li></ol>

Часто говорят, что «когда разработчики делают работу хорошо, тестировщики не нужны». Но это не так, сложные баги — все равно находят.

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

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

'''Что делать?'''

* Записывать достижения — мы забываем
* Провести мысленный эксперимент «а что если без тестирования», или даже уйти в отпуск.
* Право на уважение

'''Все это — системный вызовы профессии'''.

'''Что сделать завтра?'''

* Достижение результата снова и снова. '''Запишите результаты за последние три месяца''', и дальше ведите такой список. Можно посмотреть таск-трекер, мессенджер и другие артефакты. Или вспомните.
* '''Запишите в формате STAR(R)''': situation, task, action (что сделал), result, reflection (не обязательно). Например, приходит «будем сокращать TTM», вы сократили, багов больше, не улучшилось. Вы сделали чек-лист для отправки на тестирования, разработчики проходят — сокращаются возвраты. Я тут замечу, что это похоже на протокол авторизации результата, о котором рассказывает Анна Обухова, и там есть две важные части: как достигнутый результат связан с крупными целями, и как я могу рассказать это другим — это фиксирует историю в долговременной памяти как часть личной истории. Возможно, это входит в result и reflection, но тут важные акценты. И у авторизации результата есть негативный вариант, чтобы отпустить неудачу.
* '''Нарисуйте круги влияния'''. '''Контролирую''' то, что делаю сам, например, как заполняю баг-репорты. А если решение о допустимости выпуска принимаете не вы, то вы '''влияете''', но не решаете. '''Внешние обстоятельства''' — не них не влияешь.
* '''Запланируете способ, как сделаете работу видимой''' — на доске, в виде артефактов и так далее. '''Сделайте презентацию для коллег''': что входит в тестирование, почему занимает столько времени, что даст автоматизация.

== Алина Иванычева (Райффайзен). Avro и Kafka: испытания тестировщика в мире Big Data ==

[https://sqadays.com/ru/talk/139157 Avro и Kafka: испытания тестировщика в мире Big Data]

Avro — бинарный формат, проще, чем Json. Но для тестирования в этом проблемы: вам надо уметь декодировать конкретные сообщения, а еще уметь найти сообщения, относящиеся к конкретному документу по его номеру или другим реквизитам, которые указал пользователь. И Алина в деталях рассказывала про конкретные средства, с помощью которых это обеспечивается. Основное — Fast Avro и Trino для поиска. Если вы начинаете использовать Avro — то смотрите доклад.

== Анастасия Кононова. И чтец, и жнец… как совмещать две роли в проекте и не сойти с ума ==

[https://sqadays.com/ru/talk/138161 И чтец, и жнец… как совмещать две роли в проекте и не сойти с ума]

Анастасия совмещала роль тестировщика и scrum-мастера в своей команде. У них классический скрам со всеми ритуалами (а говорят, что его не бывает — врут), в командах разработчики, тестировщики, дизайнеры. И выделенной роли скрам-мастера не было, все совмещали.

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

А год назад ей предложили взять роль скрам-мастера у 4 команд, в которых 50 челвоек, на продукте (как я понимаю, там команды iPhone, Android, веб и бэк для одного продукта, но могу ошибаться). И это резко увеличило нагрузку на роль скрам-мастера, до 80 % на начальном этапе, при этом обязанности тестировщика никуда не ушли, ей по-прежнему, надо было обеспечивать выпуск релизов.

В целом справилась. Что помогло? Тайм-менеджмент, помодоро 15 минут без прерывание. Приоритеты важное-срочное. И делегирование — не впихивайте 24 часа в рабочий день, отдавайте. Многое было сделано за счет взамодействия и коррекции процессов. В частности, квоту на роль скрам-мастера надо было учитывать явно, и если в результате получался перегруз — то думать о том, кому передавать тестирование и по каким задачам, на часть задач можно было привлечь тестировщика из другой команды.

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

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

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

А роль фасилитации они перенесли внутрь команды. Сначала была идея, что это полезно сеньорам для performance review, а потом — вообще для всех. Так что передается.

Главное — доверие команды, в обе стороны: ты мог подойти с любым вопросом, к тебе подходили. И все мы идеалисты, но главное — не падать духом.

И в ответах на вопросы.

* Как повысить эффективность встреч? Ограничение по времени, дейлик 15 минут стоя, вопросы — на отдельные встречи. Груминг — инструмент и подготовка. В середине спринта синк с распределением задач следующего спринта, и люди готовят, ко встрече приходят подготовленные. В ретро — элемент игры, фан-вопросы или викторина, проходит лучше. Все техники есть в интернете, пробуйте новое.
* Как быть объективным, не продавливать позицию тестировщика? Это сложно, этого дзена достигла через год, это работа над собой.
* При сопротивлении изменениям — «давайте попробуем». Бывают неудачи, это тоже хорошо.

== Сергей Атрощенков. Нейроохота на баги: что происходит в мозге тестировщика? ==

[https://sqadays.com/ru/talk/138384 Нейроохота на баги: что происходит в мозге тестировщика?]

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

'''Тестирование — сложная когнитивная деятельность'''. Оно посложнее многих других дисциплин в ИТ.

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

'''Зачем нейрофизиология?''' Тестирование — не чтение кода, не только на уровне логики. Читая код, задействуем левое полушарие, при тестировании — задействуем правое. Задействуется нейронная сеть, которая работает для логики и математики. Мозг работает так. То есть при тестировании мы решаем задачи.

* Мозг имеет свойство уставать, это нормально. И он устает от тестирования.
* Рабочая память ограничена.
* Вовлечены сознательные и бессознательные процессы.

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

Когнитивный цикл тестирования.

* Планирование — фронтальная кора
* Теменная доля — внимание и рабочая память
* Понимание контекста — височная доля
* Обнаружение аномалий — передняя островковая доля

'''Когнитивная нагрузка'''. Память занята: система, ожидаемый результат, возможные креш-кейсы, часть архитектуры системы, бизнес-поведение системы. Минимум 5-6 элементов. Детальные тесты разгружают память — но увеличивают ttm, нужен баланс. Если вы решаете задачу, а вас грузит менеджер — печалька, перегруз.

Бессознательная когнитивная часть, интуиция, система-1 — то, что работает в автопилоте, на основе интуиции, распознаем паттерны и эмоции. Если система повела так, то ошибка так. Система-2 — про систематическую работу с требованием, документации. Многие находят ошибки интуитивно, и это — круто, значит можно обернуть в процессы. '''Интуиция — неотрефлексированный опыт'''. Мы уже что-то получили, но не понимаем как работает. Передняя островковая кора — когда мы увидели, что что-то пошло не так, еще до осознания. И это — интуиция. Это можно качать.

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

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

'''Ага-момент'''. Мы получаем озарение. Моменты, когда ищешь-ищешь, проблема не находится. А через некоторое время, на обеде — приходит озарение. Это происходит из-за туннельного эффекта, мы погружаемся, а потом оно всплывает. И когда решили — выброс дофамина. Это помогает развиваться, и развивать мозг как орган. Если не брать дешевый дофамин, пролистывая ленту, а погружаемся.

'''Когнитивные ловушки'''. Докладов — множество, и их 200+. Он выбрал три, которые редко упоминают.

* Ловушка подтверждения. Проверяем только happy path — хотим подтвердить, что работает. Особенно в ограниченном времени.
* Доступность. Полагаемся на баги, которые нашли, и смотрим в эту область. Не обращаем внимания на другое. Например, на тестирование формы, при том, что перепутали логотип.
* Якорение. Фиксируемся на первой проблеме. Нашли баг, не понимаем с чем связано, идем к разработчику, в чем причина — исследуем, долго, не находим проблемы — потому что проблема в другом месте.

Что с ними делать? Якорение — строим равномерное покрытие, структурирование подхода, кросс-ревью тестов. Ловушка подтверждения — шесть шляп, меняем позицию. Доступность — чек-листы и все то, что делает тестирование скучным.

'''Ловушки не приговор. Мозг может обучаться'''. Проводили МРТ студентов, обучение программированию увеличивает количество серого вещества.

Мы приходим к опыту работы. Работаешь год, и казалось бы все знает. Нет, мозг не развился настолько, сколько у сеньора за три года. Даже если он может решать задачи — он это делает тяжелее. И дайте время мозгу развиться, зафиксировать достижения, а потом увеличивайте сложность. Есть статья — число лет от новичка до эксперта. Новичок — полгода, продвинутый год-полтора, эксперт — три. Нейропластичность качают, беря разнообразные задачи. Что-то узнали — попробуйте сразу, через три часа, через день, через 10 дней. А еще — '''спите, отдыхайте''', люди плохо умеют это делать.

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

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

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

Спасибо Сергею! А нейрофизиология — очень интересно, и психологам пора бы пересобрать свои модели на их основе. Но они не торопятся, так что мне пришлось самому, получилась книга «Инженерная модель личности».

== Дмитрий Воробьев. Захватывающая история Пейджамена Паттерна ==

[https://sqadays.com/ru/talk/138889 Захватывающая история Пейджамена Паттерна]

Это действительно интересная история — о том, как герой доклада пришел на новое место работы, чтобы сделать автоматизацию тестирования. При этом опыта автоматизации у него не было, хотя знание python, на котором писали тесты — было. В докладе рассказ был очень подробный, со скринами a фрагментами кода, и они реально показывали, '''как после применения конкретных шаблонов код становится понятным и читаемым'''. На мой взгляд, это — очень важная иллюстрация.

Дальше — шаги работы.

* Первое задание — сделать приемочные тесты на продукт: авторизация, переход между страницам и верстка.
** Авторизация — playwrite и плугин для выбора стендов. Есть проблема: не все селекторы библиотеки срабатывают в браузере, и он формирует правила использования селекторов, и проверяет их при написании.
** Переходы между страницами. Несколько тестов — дубли селекторов и кода. Вынос повторяющихся действий. Тест короче, патерн Steps.
** Скрины страниц, сравнивает библиотека. Проблема — динамические данные. Надо дождаться загрузки и надо подменять данные — затемнять или подменять ответы, есть средства.
* Тестирование админки. Пользователи и роли. Данные рандомизирует, однако взаимодействие через UI требует предварительной подготовки данных — это долго. И переходит для подготовки и очистки на использование API. Модуль подготовки, fixture для авторизации и куки, очистка окружения. В тесте API остается только для UI.
* Модули растут. Дублирование селекторов и проверок, слишком много настроек — хаос. Идея — изучить и посмотреть доклады. И хотя он считал неплохим автоматизатором, а самооценка проседает. И тут он решает сделать план по проверенным подходам.
*# Конфигурация — основные настройки. Singleton, чтобы был единственный экземпляр. Модули в python — singleton, это можно использовать.
*# Работа со страницами. Модули UI-действий — большие, и приходится передавать Page. Использует PageObject — классы с методами — атомарными действиями.
*# Есть набор общих действий — открытие, скриншоты, базовые проверки и другие — выносит в класс PageBase. Умное открытие — чтобы не открывать повторно, но с возможностью обновить, и дожидаться загрузки объекта до взаимодействия.
*# В PageObject — проверки, а в методы называть по результату. Результат — нет объекта Page, действия структурированы, ожидание — автоматическое.
*# Тесты плохо читаются — паттерн 3a: структура подготовка-действие-проверка. Проще всего — комментарии. Но тут уже надо использовать тулы, Allure позволяет размечать тест шагами и фазами.
*# Разметку — в лог — делает собственные функции разметки, которые логируют, а потом пишет в Allure. И для каждого названия шага делает отдельную функцию, чтобы IDE подсказывала.
*# UI — сложный, и работать сложно. Используем PageElements и отдельные классы примитивов с базовыми наборами взаимодействия. И есть базовый набор примитива, от которого наследуются, и конкретные над ним.
*# Как добраться до примитива? Они далеко не сразу появляются. И Chain Of Information — метод возвращает контекст, например, если нажатии на кнопку появляется меню — метод возвращает объект, в котором содержимое дает набор действий. И тут пример — как идет открытие, выбирается элемент и что делаем.
*# Улучшение API — тоже большой модуль. Делают классы для каждого end point. Литералы заменяем на константы и их — в модуль конфигурации. Многие методы требуют набор связанных параметров — их лучше заменить на объект Value Object.
*# Привязка к библиотеки, и импорт приходится тащить в тестовые модули, чтобы были подсказки. Можно использовать кастомный модуль ответов, работать в ней.
*# Стандартная библиотека requests поднимает соединение для каждого запроса — это долго. Нужны сессии. Но отдельная сессия для каждого клиента даст слишком много соединение. Dependency Injection, соединения передаем.
*# Объект-валидатор, чтобы не использовать констант, использование Strategy. И шаблоны валидаторов для повторяющихся проверок. Дает возможность отключения проверок.
*# Для тестов много объектов взаимодействия. И он объединяет объекты в один Facade для api и ui.
* '''e2e тесты'''. Большой сценарий действий. Идея — steps, объединение связанных действий, технические детали скрываются. Делает шаги UI и api и делает фасады. Тест получился большой 100+ ожиданий и проверок.
** Авторизация — сложно хранить, и она отдельная для UI и api. Screen play — требует отдельных фреймворков, это неудобно. Поэтому он делает упрощенный вариант — объект-пользователь, которому можно задавать данные авторизации и другие вспомогательные действия, и который выполняет шаги. 

* '''Отчет'''. Decorator — reporter Allure предлагает готовый, и его можно навесить на классы шагов. И еще свой decorator для записи в лог. Но проставлять вручную декораторы тяжело, можно забыть. Поэтому используем метаклассы, они позволяют навесить декораторы на все методы. Делаем базовый класс, от него наследуем. В логе — все детали, а в отчете — верхний уровень.

В целом — получился зрелый проект.

Вывод. '''Изучайте паттерны — они всегда пригодятся'''.

== Наталья Руколь. Тотальный контроль тестирования ==

[https://sqadays.com/ru/talk/137935 Тотальный контроль тестирования]

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

У рассказа было замечательное начало. '''Наталья ненавидит контроль, потому что сама — раздолбай. Но уверена, что без него — никуда, потому что все сыплется. Поэтому надо строить систему, которая обеспечит контроль.'''

Что дает тестирование?

* Субъективность: ошибки нечаянно, нарочно неосознанно и нарочно осознанно. Человек себя обманывает, видит лучше, чем мы есть.
* Своевременность. Мы оцениваем какой-то показатель, должно быть не ниже 4. И мы смотрим метрику, все зеленое, но есть тренд на снижение. И можно во-время заметить. '''Тлеющая тряпка''', дымок — индикатор возможного пожара, надо обращать внимание, и у них есть индикатор с таким названием.
* Корректировка маршрута. Хочешь сократить срок выпуска — и смотришь на индикатор. В одной крупной компании сделали отдел автоматизаторов, которые пилили фреймворк и так далее — в результате после двух лет ROI отрицательное, время автоматизации увеличилось. А люди гордятся — классный фреймворк. Понять можно было сразу. А еще '''метрики дают «ты умничка»''' — и это тоже важно. .

Не путаем метрики.

* Контроль продукта. Например, контроль принятых требований.
* Контроль процесса. Тестировщики нашли 100 багов — это много или мало? Если видно покрытие требований — то можно понимать, сколько еще будет.
* Контроль проекта — сроки, прохождение людей.
* Контроль людей

Метрики — на слайдах ссылки на каналы, там 200+ метрик, накануне об этом был круглый стол.

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

'''У каждого проекта — свои метрики'''. Два скрина, на проектах даже один тест-менеджер — метрики не повторяются. Метрики в динамике и целевые показатели. Метрики подбирают под условия.

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

'''Ведем все проблемы'''. Инцидент — однократен. А проблема — когда сотрудник считает, что что-то работает неправильно. Сотрудники их пишут. Например «слишком ограниченное время на оценку компредов», созвон показывает: «рынок требует быстро оценить», и проблема меняется: «мы не умеем быстро готовить компреды».

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

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

Итак, внедрили. Там 100500 табличек. Открывает 50 — а там много разного. И много красного. А еще все на удаленке, и когда она в 6 утра пишет вопросы — никто не может ответить. И вообще, может понять, что красное хорошее, а то зеленое — проблема. Можно потратить день.

Что сделали?

* Агрегировать так, чтобы все можно контролировать. '''Табло компании''' — все повторяющие процессы в департаментах, 150 строчек, там есть ответственные и статус выполнения. Табличку нельзя держать актуальным вручную. Есть специальный человек, он заходит в последний день месяца. Столбец «статус выполнения» ставится красным — и у каждого есть несколько дней актуализировать. А дальше он должен придти на созвон и отчитаться.
* '''Фокус-созвоны''' по каждой теме. Топы, статус проекта-сводка и каждую неделю пишут комментарии и все пометки — здесь, статус каждого проекта (тест-менеджер), статус процессов компании, статус резерва сотрудников, 1:1 сотрудников ИПР. Правила созвонов: регулярность, дисциплина. '''Не пропускаем''', часто менеджер переносит в пользу рабочих задач. Готовность к созвону — за несколько часов, не смотреть материалы в моменте. Чат под каждый созвон — он группирует процессы. Если созваниваемся, и есть что-то красное — выписываем решение, и не может быть ситуации «решим потом», может быть ситуация «пока нет времени, займемся в феврале» — и ставим задачу на февраль. Чат: General, рабочее, всякая фигня. И нужен фан на созвонах! Позитивные и веселые. И есть созвоны в пятницу в 5 вечера (это рабочее время) с алкоголем.
* '''Ответственный за показатель'''. Может ответить на любой вопрос посреди ночи, всегда готов к созвону. И люди стараются зайти пораньше, за день, узнать контекст, а иногда и сразу исправить.
* Ведение задач по созвонам, а не по проектам. Своя доска по каждому созвону. И каждый созвон начинается с отчета по доске. Если есть красный показатель — должна быть задача с дедлайном.
* Есть человек, Наташа с должностью дрючер (официально), которая все контролирует. Она боялась, что возненавидят — ее обожают, она помогает. Но на внутрипроектные — не ходит, только общие, их около 20 в месяц.

Вопрос. '''Применяете ли KPI для тестировщиков? Ответ — нет, они для сейлов'''. Есть метрики проектов, а как только ставишь для тестировщика — он начинает работать на метрику, заводит баги или что-то еще. Бывает, когда мы учим чему-то, и тогда меряем изменение того, чему учим.

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

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

== Павел Кузнецов. Как одним курсом решить проблему онбординга и развития сотрудников (ну или почти решить) ==

[https://sqadays.com/ru/talk/138431 Как одним курсом решить проблему онбординга и развития сотрудников(ну или почти решить)]

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

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

И '''он решил написать курс «как писать автотесты в компании»''', чтобы те, кто погружаются, знали особенности сайта, авторизации, стиля оформления текстов (есть особенности). И чтобы компетенции джуна покрыть.

План, о каких технологиях надо рассказать. Новые проекты без исторических наслоений. И пришлось написать много документации. Курс поделен на задания: раздел сайта, команда поддержки, задание на автотесты и ссылки на док. Рассмотрим, как описывается фирма, как добавлять реквизиты, какие использовать хелперы. Кейсы простые 10-15 строк. И сдача задания — в флоу, приближенной к реальностью. 8 заданий и дипломный проект — реальная задача. Создание курса 1.5 месяца чистого, астрономически 4 месяца. Прохождение — 3 недели, минимально была — 1 неделя, если у человека хороший бэкграунд.

В результате: знакомство с базовым функционалом, информация задокументирована, есть ожидания по результатам. И по старой формулы затраты сотрудника + ментора, в сравнении с новым — сокращение вдвое. В первый месяц человек работает менее эффективно, зато во второй-третий — работает эффективные, реальные задачи.

И можно не только онбордить, но и обучать ручных тестировщиков. На группу из 2 человек — 1 ментор, время выполнения больше (10 недель), так как они проходят параллельно с работой. 4 человека: один прошел, второй на половину, а еще двое — даже не поставили окружение. Обратная связь — у них нет свободного времени. А одна — договорилась с лидом в рабочее время, при том, что задачи проходятся. Для второй группы уже попросил согласовывать, но там не получалось. Третья итерация — заявка в тимлидов, если он посылает тестировщику — то соглашается на рабочее время. 4 группы, 10+ человек прошли, одна команда закрывает потребности в автотестах, в одной — появились автотесты, один уволился, остальные — неясно. Курс — компактный, дает нужное в компании. И поддерживать курс недорого.

[[Категория:ИИ-агенты]]
{{wl-publish: 2025-10-28 16:27:17 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2025-11-09 Нighload: ИИ становится частью ИТ-ландшафта

2026-07-24T14:52:53Z

MaksTsepkov:

{{Conf-Ref}}

Дополнение 13.12.2025: [[#Встреча с Максутом Шадаевым]] - я посмотрел запись

Прошел очередной [https://highload.ru/moscow/2025/schedule '''Highload''']. Для меня основной темой был ИИ, и в этой теме я зафиксировал '''переход от конкретных проектов на основе ИИ к включению приложений с ИИ в ИТ-ландшафт, связанный с этим переход от DevOps к ML-ops''' и решения задач обеспечения надежности таких решений в целом.

Кстати, эта тема была продолжена на [https://archdays.ru/ '''ArchDays'''], на которой я был после Highload. Про доклады на ArchDays — ждите отчет, но я сразу скажу, что там Газпром Нефть поделился архитектурными схемами, используемыми для построения такого ландшафта, а Greensight рассказал про создание приложений, нацеленных на решение частных задач не хуже больших LLM, и при этом работающих в проде всего на паре видеокарт, обеспечивая приличный поток запросов.

Если делать выводы по теме ИИ в целом, то я бы отметил следующее.

# ИИ начинает хорошо работать, если вы решаете понятную задачу с конечным эффектом. Например, оптимизируете работу техподдержки, или управление промышленным оборудованием. При этом очень важно, чтобы цикл разработки включал в себя весь цикл внедрения и апробации с реальными пользователями, а не ограничивался просто созданием некоторой системы. Тут ИИ не отличается от другого софта. При этом, как и в случае другого софта, государственные и корпоративные заказчики часто заказывают продукт с формальными требованиями и неясным сценарием внедрения, и силы разработчиков уходят на решение ложных задач, а поможет ли система, например, врачу и насколько — остается неясным.
# ИИ надо не только первый раз научить и настроить, его надо доучивать постоянно. И надо проектировать цикл обновления, как часть продукта. При этом уже понятно, что для многих групп пользователей будет важна возможность добавить собственный контекст, учесть специфику предприятия. В той же медицине — многие клиники разрабатывает свои методы решения, и если делаешь медицинский ИИ, то надо подумать, как этот контент будут добавлять. Или нефтянка — там тоже свои особенности у каждой компании. Сейчас это в большинстве случаев за рамками проектов, хотя в обычных ИТ-проектах возможность развития закладывают.
# Ограниченная предсказуемость и воспроизводимость результатов, получаемая при использовании приложений с ИИ, не мешают включению их в ИТ-ландшафт. Да, есть особенности, но не более того. Да, для разбора инцидентов нужны подробные логи, и о них надо позаботиться, но так устроено и во многих других приложениях. Цикл ML-ops — некоторый гибрид DevOps и DataFlow, тут тоже нет проблемы.
# Достигать решений с использованием ИИ можно двумя способами: грубой силой, беря мощные платформы и вычислительные мощности, или тонкой настройкой, учитывающей содержательную специфику решаемой задачи. Тут полная аналогия с базой данных: мощная железка позволяет не строить индексы и хранить данные абы как, а если вы погрузились в содержание и построили конкретное решение, то можно получить выигрыш на порядки. При этом разработчики часто предпочитают грубую силу, а не погружение в содержание. А приходится.

А сейчас вернемся к Highload. В этот раз он был в Технопарке Сколково, а не в Школе бизнеса Сколково. Это — сильно другая площадка. Я на ней был несколько раз на разных конференциях, и тогда она представлялась холодной, а вот Highload удалось создать хорошую, теплую атмосферу. На мой взгляд, получилось лучше, чем в Крокусе, где Highload тоже был. А по сравнению со Школой бизнеса геометрия Технопарка более понятная, но зона еды и общения отдалена от зоны основных залов, в Школе ты намечаешь следующий доклад, идешь по кругу к нужному залу, по пути можно кого-то встретить и пообщаться. А тут надо спуститься, пройти до зоны еды и выставки, потом вернуться и в целом это — больше времени на перемещение.

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

== Бунин и команда. Новые продукты Онтико ==

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

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

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

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

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

* '''Tech kitchen'''. Группа свободного поиска в мире Полудня Стругацких. Чистый серфинг, лента или шоу погружения в новые технологии. Цель — уменьшить время с появления технологии до распространения в больших масштабах. ИТ-сообщество 1.6 млн, а сообщество Онтико — 5к докладчиков и 15к участников. Поэтому надо запустить это как СМИ, чтобы было широкое распространение. Взяли площадки, начали делать контент. Апробация показала, что доклады заходят, если спрашивать и комментировать — получаются эксклюзивные шоу. Можно присоединиться и поучаствовать. Если люди все равно тупят в ленте, то то почему бы не тупить в прикольных профи-рилсах? И они подумают вытащить туда обсуждения трендов на внутренних встречах ПК, которые происходят при подготовке конференций. Как участвовавший в ПК Knowledge Conf могу подтвердить, что на таких встречах действительно много интересного.
* '''OnticoGPT'''. Инженеры тратят долгое время на задачу поиска и выбора решения. А тут можно задать вопрос, получить ответ на основе 6к докладов, со ссылками на видео. Скоро появятся тайминги. Проект делают совместно с сибирскими нейросетями. Под капотом — два пайплайна, первый по сбору и индексации, там мультимодальный контент сегментируется по переключениям слайдов, получается примерно 200к семантических векторов для поиска. И пайплайн поиска: тип вопроса, источник для поиска, вопрос переписывается так, чтобы было понятно для поискового движка — с учетом контента разговора, дальше идет в один из 6 поисковых движков, а потом LLM формирует ответ, и он трассируемый на конкретное место контента. Изначально было 400Gb контента, они профильтровали, выбрали лучшее — 2Gb, там одна A100. Ответы лучше, чем спросить LLM без базы знаний, но насколько лучше — зависит от методик оценки, тут не понятно. '''Сейчас это доступно для всех'''.
* '''DevNavigator'''. Карьерный GPS в ИТ. Базовые навыки — общие навыки — узкие специализации. И дальше ваш выбор: углубляться или иди в смежные области. Доступно в личном кабинете. Roadmap по архитектуре: собрали, показали. Можно нарисовать свой маршрут, можно обсудить.
* Запустили '''клуб профессионалов''' — это специальный раздел в личном кабинете. Есть профиль, туда накапливаются все достижения. И это не только профиль, но и нетворк. Витрина экспертов, чтобы найти того, кто может решить проблему.
* '''All CFP'''. Организация митапов или мини-конференций — долгая, с множеством технических деталей. Они делают поддержку: можно регистрировать мероприятия, собирать заявки, а потом — готовить. Чтобы организатор мероприятия легче прошел этот путь, чтобы сделать мероприятие было легко. Забирают рутину на себя. Для докладчика тоже весь roadmap тоже был виден с самого начала. Задача — подстегнуть создание контента. Чтобы митапы продуцировали контент, который мы бы могли брать и вбрасывать в GPT.

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

Для чего это делается? Есть разница США — Россия — список компаний по капитализации. У Штатов в лидерах ИТ, а у нас — нефтянка, эта ситуация не меняется. Но при этом в мире всего несколько стран, у которых собственный поисковик, антивирус, соцсетка, ОС и так далее, Россия в их числе. Но на деньгах это не отображается.

Выступление — передача такт опыта. Они пробуют за счет этих продуктов стократ увеличить скорость и объем передачи информации. И, возможно, это даст офигенный прорыв. А в перспективе — может и заменят ВУЗы, потому что сейчас на 4 курсе 95 % работают, а выполняют программу ВУЗа, чтобы родителей успокоить.

== Андрей Носов из Raft. RAG → GraphRAG → LightRAG: как мы трижды переписывали медицинский AI и кратно снизили издержки ==

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

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

Для обработки взяли семантический RAG — разбитие на предложения, скользящее окно, разрывы чанков по расстоянию между предложениями и подбор порога. И векторная база — Qdrant для гибридного поиска. Возникают проблемы, например, чанк выделил сущность, а противопоказания ушли в соседний чанк, и будет проблема. Используют GraphRAG, чтобы восстановить семантические связи, характеристики улучшаются, но недостаточно, используют NER и Relation extraction, но теперь ломается на аббревиатурах: между аббревиатурой и расшифровкой оказалась большое расстояние. И так далее, в докладе достаточно много деталей по использованным расширениям: Community enhanced RAG, Pathfinding RAG, Hierarchical summarization RAG, Graph Native Chunking, Query Focuced Subgraph RAG.

Результат достигнут, они прошли испытания. Но он оказался очень дорогим, индексация одного документа требует 50к$. И был следующий этап — снижение стоимости, делали LightRAG? используя библиотеку Graph RAG для двойного прохода по графам, из которого строится компактный json, связывающий сущности и включающий низкоуровневые и высокоуровневые сущности. И в результате запрос в LLM получается не 1000+ токенов, а всего 100. А добавлениях новых публикаций оказывается, что не надо пересобирать все, достаточно менять локально структуру графа.

Обработка получается по такому алгоритму: запрос — нормализация — векторный поиск в Qdrant (50 фрагментов) — графовый поиск на основе этих фрагментов — LLM — ответ. А если граф ничего не нашел, то идем в векторный поиск на альтернативный вариант формирования контекста. .Для индексации NER на MedGemma, а поверх — поиск связей на GPT 4o для обогащения. Генерация ответа — 1.5 с. По отношению к максимальной версии 90 % качества и 10 % стоимости.

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

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

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

== Николай Пономаренко из Яндекса. GPT в службе поддержки: автоматизация, оптимизация и инновации ==

Поддержка в Яндексе это 700к тикетов и 1.4 м сообщений в день. Классический способ работы — запрос клиента проходит классификацию, на основе которой оператору показывают варианты шаблонов ответов, он выбирает нужный или может написать свой.

К идее, чтобы LLM сама вела диалог, заказчики относились с недоверием: есть галлюцинации, мало ли, что она ответит и статистика их не убеждала. Поэтому на первом этапе человека не исключали, LLM лишь предлагала ответ оператору, и он мог сам его исправить. И уже на этом этапе скорость возросла на 15 % при том же качестве, которое операторы оценивали. И получив уверенность они перешли на работу LLM без участия человека.

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

По сути, операторы отвечают макросами. Можно посмотреть документы и сказать, какие являются позитивами. А дальше дообучить модели, сделать реранкер. У них получилось три разных модели и реранкер, который объединяет ответы. Генератор сделан на легкой YaGPT Lite, ставить полноценный — дорого. Для него делали датасет: ответы лучших операторов, отфильтрованные на основе LLM, чтобы отобрать хорошие ответы. И получилась эффективная модель.

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

Дополнительно есть пре-фильтр на основе BERT 0.5B, чтобы отсекать вопросы, по которым не хватает информации и провокации. На входе LLM, которая отсекает вопросы. И пост-фильтр на отдельной YaGPT-Lite, который отсекает галлюцинации в ответах.

Дальше возник вопрос — а можно ли сделать еще лучше? В ситуации вопрос-ответ RAG работает хорошо. Но часть базы знаний представляет собой сложные алгоритмы действий, сценарии со ссылками между ними: если попал в такую ситуацию, то иди туда. Там много вложенности, последовательность инструкций. И такую базу знаний надо представлять в виде графа. И пройти по графу при обращении. GTO — Graph Traversing Operator.

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

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

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

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

Для генератора — идет дополнительный анализ для выбора промпта, используемого для генерации ответа, а в зависимости от промпта — разная обработка ответа. Ответ надо не просто выдать клиенту, его надо обработать: если LLM дала промокод или компенсацию, то это должно быть отражено в системе.

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

Начали с письменной поддержкой — она проще. Теперь идут в голос, идея — докрутить то же решение.

== Вячеслав Кудряшов из Сбера. Как сохранить высокую надежность при GenAI-трансформации ==

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

# Нужна единая среда исполнения агентов. Идентификация агентов, идентификаторы операций, по которым в логах можно восстановить происходящее для разбора инцидентов.
# Агенты-лодыри неработоспособные. Надо проверять, что агент работает, health check — маленькое тестовое обращение при запуске.
# Недетерминированная логика работы LLM делает невозможным восстановление при сбоях, поэтому необходимо хорошее логирование, нужно сохранять версию агента, кто запустил, при каких условиях. Без трассировки разобраться нельзя, потому что нет воспроизводства.
# Агенты могут провоцировать инциденты при выходе за нормативные границы, например, уходя в бесконечные циклы, вызывая ресурсные коллапсы. Сервис не предоставлен, а токены израсходованы. Решение — из обычного ИТ, предотвращение зацикливания, например, как в сетевых пакетах.
# Агенты могут стучаться в закрытую дверь, к неработоспособному сервису — поставьте ограничения по retry.
# Подумайте, как избежать паралича бизнес-процессов при отказах агентов. Если сделали агента, который заменяет сотрудников, чтобы те занимались другими задачами, а агент перестал работать, клиент должен получить обслуживание. Нужен business community plan. А на переходном этапе надо уметь отключать агентов, возвращаясь в обслуживание людьми. Правда, тут проблема с теми процессами, которые с ходу строят на основе агентов.
# LLM не должна превратиться в единую точку отказа, чтобы не было коллапса высоконагруженных бизнес-процессов из-за нехватки производительности. Нужно управлять доступом, ограничивая доступ в критических ситуациях. StopEvent для агентов разной критичности, и закладывать это в сценарии работы.
# Бывает массовый сбой агентов из-за скрытых несовместимостей с новыми версиями. У них GigaChat постоянно обновляется, люди, которые выпустили говорят «стало лучше, сейчас всех обгоним», метрики растут. Но агенты могут начать вести по-другому, неожиданно. Нужно два контура с разными версиями, постепенное переключение трафика и оценка работы новой версии.

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

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

== Денис Цветцих. 50 оттенков Transactional Outbox ==

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

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

== Сергей Олейников из РТЛабс. Прощай, Oracle! Здравствуй, Scylla! — (совсем не) квантовый переход ленты уведомлений на Госуслугах ==

Госуслуги — это 150 млн записей, 15 млн активных пользователей, 2 млн услуг в сутки и 160 тыс. rps пиковая нагрузка. Лента уведомлений — статусы заявлений, штрафы, просроченные документы и так далее — коммуникация всего 12 млрд в год, 12 млн в сутки.

В 2021 Oracle начал тормозить, хотя стоял на очень хорошая железка. Как правило, потому что разделял ресурсы с другими сервисами, на нем работали не только уведомления, а еще нагружали джойны и массовые вставки. Так что они начали думать про переход раньше, чем Oracle ушел. А когда он в 2022 ушел и последовал приказ Президента про импортозамещение — вариантов не осталось.

Требовалась бесшовная миграция при высокой нагрузке. А чтобы был задел на будущее — повышенные требования : 4000 вставок в секунду, 300 млн в сутки, возможность A/B тестирования, работа без downtime.

Рассматривали варианты PostgreSQL, Cassandra, которую использовали одноклассники и ScylaDB — на ней работает discord. Начали на Кассандре, но Сцилла оказалась быстрее, больше компактизация, и еще ряд преимуществ, в презентации был слайд. И в ней есть CQL, который похож на SQL.

Архитектура системы: 2 датацентра active-active, общая Кафка и Oracle (мастер+2 standby), и 10+ микросервисов. Госуслуги нельзя поставить на паузу. Поэтому микросервисы на переходном этапе работали с Oracle и Сциллой параллельно. Сначала мастер — oracle, потом переключали. При этом Сцилла развернута в каждом датацентре отдельная. Мигратор написали самостоятельно — балансировка нагрузки, чтобы не убить, и хранить состояние — если что-то не так, чтобы работало. Сохраняли первичные ключи Oracle сохраняли, чтобы работали ссылки из старых писем. И мониторинг миграции через метрики.

Сделали асинхронной — user migration topic. В Oracle хранили состояние каждого пользователя, ставили старт, и отправляли в user migration topic, сообщения — record migration topic. Вставляли в Scylla пачками, потом ставили признак, что мигрировано. С момента запуска сцилла-реплик все новые уведомления писали в сциллу одновременно. Отслеживали тайминги и latency.

Как проверить данные? Исторические наслоения накопилось с 2011 года, все варианты проверить нельзя. Поэтому проводили тестирование на бою: запрос идет с Oracle, дубль — со сциллы, результат сравниваем. Но пользователю результат Oracle выдаем сразу, не ждем Сциллу. И второй механизм — сравниваем ответы oracle и scylla по логу запросов.

Переключение пользователей на Сциллу — поэтапное. Сделали через куку, если она есть — то идем в сциллу. А если нет — то проверяем статус миграции, и ставим куку, если мигрирован, и делаем internal redirect.

Проблемы и их решения.

* Ограниченные агрегации сцилла — базовые функции и только внутри партиции. Зато партиции в сцилле крайне эффективны.
* Про join забудьте, where очень ограничен. Нет null, not, or, like и так далее. Зато есть map-reduce. Пользователь, заходя на госуслуги получает какие-то уведомления. Типы — по партициям, и разбиваем параллельно, потом результаты — объединяем, упорядочиваем по дате, обрезаем. А вместо join — обогащение данных. 

* Отсутствие транзакций.
** LWT — можно проверить наличие в базе (upsert), но читает она при этом сложно, это долго.
** batch — можно объединить запросы на вставку и удаление — но только в рамках партиции. Для разных партиций — долго и дорого, не работает.
* Не читать всю запись перед обновлением, надо обновлять отдельные поля, которые меняются, а не все, потому что нет транзакций.
* Не допускаем больших партиций. Если мы делим партиции по пользователям, а у пользователя много данных — будет очень плохо. Они разбивают уведомления по типам, а еще лучше предусмотреть поле bucket: сначала — константа, а потом можно писать год или даже месяц.
* Есть системные таблицы — large patrition — можно проверять и дальше разбираться.
* Кластерный ключ позволяет сортировать, но при разрастании партиции ей придется сначала прочитать, все, потом отсортировать — надо, чтобы по кластерному ключу работало
* Сложность развития — на оракл и сцилла. Они обобщили и унифицировали фичи для нового — ограничили оракл.
* Лучше обновлять, чем удалять. Есть type, он входит в ключ. И они специальным образом меняли.
* Только асинхронные запросы. Синхронные — очень плохо, потому что ограниченный пул потоков.
* Отказ нод и недоступность дата-центров. Есть классы, отвечающие за retry-политики. Они написали свой, чтобы видеть бизнес-метрики и мониторить ситуацию.
** Сначала запрос внутри датацентра с кворума 3 нод. Если не получилось — retry уже без ограничения на датацентр. И ведем инциденты
** Аналогично при записи — записать в датацентре, если нет — то куда-нибудь.
* Аналитику проектируем отдельно. '''Проектирование базы Scylla вообще идет от запросов'''.

По результатам Scylla 2-3 раза быстрее на чтении и порядок на вставке в сравнении с oracle. Сейчас в лицензии изменились ограничения открытой версии, но им хватает с запасом.

== Иван Мареев из ЦУПИС. Эволюция архитектуры платежной системы: сохраняем SLA 99,99 при росте нагрузки в 30 раз ==

Речь идет про процессинг переводов по номеру телефона, на основе которой сделана оплата по QR-коду. Рост нагрузки в 30 раз — за 7 лет, с 20 до 600 RPS. Я пришел на доклад не с начала, слушал только историю преобразований с 2022 года, когда начали делать параллельный процессинг. И там есть интересные моменты.

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

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

Появилась Кафка. Сообщение может быть не обработано, есть tlq-топик для таких сообщений. При оплате в интернете пользователи, если лоадер долгий, то обновляют страницу и делают новые платежи. Такие платежи надо делать быстро, нельзя копить на основном топике.

План работ на случай аварий, включая отказ мастера. Если при аварии есть возможность обеспечить работу части пользователей — лучше сделать, чем не сделать.

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

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

== Встреча с Максутом Шадаевым ==

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

# '''Разговор был очень конструктивным и по существу'''. В теории органы управления примерно так и должны общаться с профессиональным сообществом, а на практике такая открытость встречается не часто. Но и не является уникальным исключением, в эту сторону есть сдвиги.
## Шадаев взял обязательство устроить встречу провайдеров интернета с Роскомнадзором, наверное, не в открытом формате, но чтобы было много компаний. Потому что был вопрос, что Роскомнадзор общается с 2-3 крупными, а до остальных решения доводятся, и не учитывают специфики небольшого масштаба.
## Youtube блокировка – доколе? '''Ответ'''. Я могу ответить как чиновник: надо выполнять законы. А как человек и министр считаю: чем больше сервисов – тем лучше, но при равных условиях. Youtube блокирует жестко, без объяснений, не ведет коммуникации – это ведет к блокировке. Хотя ситуация сложная, есть риски блокировки в AppStore, или блокировке Android, тут блокировками не ответишь…
# '''Образование в условиях, когда у всех учеников есть DeepSeek (или другой ИИ), и ИИ начинает широко применяться в компаниях'''. Я вынесу эту тему вперед – она важная. Пока задача решается '''тактически''', хотя понимают, что есть стратегическая составляющая.
## Сделали с Яндексом стажировки учителей информатики – это правильно. Я бы тут сказал, что лучше поздно, чем никогда. Потому что еще в 2014 году в Ульяновске эту задачу успешно решали на региональном уровне в кооперации ИТ-сообщества, ВУЗов и местных властей, я был на публичном обсуждении этих решений на стачке ([[Блог:Максима Цепкова/2014-04-15: AIST и Стачка#Образование и ИТ|отчет]]).
## Прямо на встрече договорились запустить работу, чтобы облегчить нормативное регулирование для привлечения ИТ-специалистов в качестве преподавателей. Сейчас бюрократический налог очень велик, как сформулировал Олег Бунин «я готов потратить два часа, чтобы прочитать лекцию, но не готов тратить еще шесть, чтобы ее оформить по правилам». Конечно, тут утрировано, есть еще время содержательной подготовки, но если ИТ-шник ведет корпоративное обучение, то там немного. Есть ВУЗы, которые тут помогают специалистом, у них отработаны формы – но так не везде. В каком-то виде этот трек будет.
## Министерство ставит вопрос перед ИТ-сообществом '''о подготовке ИТ-шников'''. Была большая работа по запуску программ, есть мнение, что сейчас разрыв между отраслью и ВУЗами сокращен и ВУЗы начали готовить студентов так, чтобы выпускника могли взять джуном (ну, министерство полагает, что ситуация – такая). Но ведь, '''говорят, что джуны больше не нужны будут, их заменит ИИ, нужны будут сразу сеньоры'''. И что делать? Продолжать программу, увеличивать ее, или сокращать? Мой тут ответ: '''надо обеспечивать гибкость подготовки'''. ИТ-отрасль устроена так, что программа подготовки должна меняться каждый год '''по площади'''. То есть каждое лето '''происходит сборка и тиражирование программ подготовки, на основе уже проведенных пилотов'''. ИТ-отрасль сама не знает, как она изменится с массовым приходом ИИ, но она будет адаптироваться, и если образование будет адаптироваться за ним, каждый год обновляя программу – будет ОК. Но систему надо выстроить.
## Реорганизация нужна не только высшему образованию, но и среднему. В принципе, нет проблемы научить школьника достаточно, чтобы он умел программировать. В период, когда всем стали нужны сайты, многие старшеклассники освоили и подрабатывали их созданием. Но общество в целом не готово, что школьники начнут неплохо зарабатывать с 14 лет. В любом случае, программу образования надо пересобирать с учетом ИИ: чему учить, какие результаты. И использовать тут современный продуктовый подход с трассировкой целей образования и получаемых компетенций до конкретного образовательного модуля, подобно тому, как ценность для целевых групп трассируется до фич продукта. Если за единицу взять тему – набор уроков, завершающихся контрольной, то среднее образование – 1-2 тысячи таких фич (10 лет на 10 предметов на 10 тем за год). Много, но обозримо, сопоставимо с большими продуктами. И высшее – тоже. Все как с заменой легаси. А ИИ может помочь в восстановлении существующей структуры, в которой много исторических наслоений.
# '''Стратегические цели министерства'''
## 80% ключевых процессов на российском софте
## Цифровая зрелость сопоставимо с междунароными аналогами
## Развитие отрасли, которое оценивают по доле отрасли в ВВП, за 5 лет его удвоили.
# В основном министерство работает '''на операционные, тактические задачи'''. Стратегические – понимаются, и там, где есть понятный шаг – он превращается в тактику и выполняется. К этому можно по-разному относиться. Например, полагать, что, следуя велениям времени, министерство выделяет MVP или набор приоритетных фич развития и его делает, и это – хорошо. Но вот любые ли задачи можно сделать таким образом – неясно. Особенно это касается задач, с которыми не слишком понятно что делать. Но, может, это разделение труда в государстве, когда правительство занимается только тактикой. Дальше несколько примеров таких задач.
## '''Обеспечить интернет на всем пространстве страны'''. Это спутники Бюро 1440, все технологии отработаны и испытаны уже на орбите, и предстоит запуск 276 спутников, которые обеспечат покрытие для России. Проект делает компания, а министерство помогает организационно, договаривается про ракеты и так далее. Что будет с проектом дальше – непонятно: есть мнение, что сделать реальную конкуренцию Маску в масштабах земного шара – очень дорого и потому не реально. И думать об этом будут, когда текущий этап будет закрыт.
## Национальный мессенджер '''Max'''. Его запускают, государству инициировать переход, это возложено на министерство, а люди – не хотят.
### Тему подробно не раскрывали, но мне понятно – почему не хотят, потому что еще один мессенджер – это не удобно, у людей сложилась инфраструктура коммуникации, и переход – накладные расходы. Люди, кстати, до сих пор активно пользуются WhatsApp, хотя, казалось бы, Телеграм удобнее. Интересно, проводил ли кто исследования – почему? А еще люди переписываются по всему миру, а не только с россиянами. Ну и с функционалом есть вопросы, но это мне кажется вторичным.
### А вообще мне интересно: сами чиновники на Max перешли? Когда в свое время блокировали телеграм, выяснилось, что в куче учреждений он включен в структуру операционной работы, были проблемы. А сейчас?
### А вообще телеграм в свое время породил феномен «телеграм-проектов» – люди координировали работу в мессенджере, и делали проекты, которые иначе сделаны бы не были. Но развития внутри мессенджера или интеграции телеграм с системами ведения проектов, таск-трекерами – не произошло, насколько я знаю. Может, для Max это – возможность? В китайском WeChat, говорят, есть enterprise-версия, которая закрывает не только ведение проектов, но и потребность в ERP-системе для не слишком больших компаний.
## Еще одна тема связана с переходом на отечественный софт. Сейчас многие компании продолжают эксплуатировать SAP, тем более, что он стал бесплатным, вендору платить не нужно. И это создает риски.
### Как это решить чисто экономически, министерство не понимает. Пока есть механизм со-финансирования: если есть заказчик на потенциально повторно-используемое решение, то министерство готово взять половину финансирования под условия будущего тиражирования (насколько оно работает – я не знаю).
### Явно не хватает продуктовых компаний. Есть 1С, Яндекс, Postgress. На рынке было множество интеграторов, внедрявших решения зарубежных вендоров, а надо создавать свои.
### Над регулированием облаков, чтобы не было проблем с безопасностью, министерство планирует работать. Закон об обезличенных датасетах приняли, теперь видно, что согласовать алгоритм – слабо реально, работают над этим. А создавать гос.облако – не готово, прецедент с Max показывает, что к государственным решением относятся очень плохо. И, я думаю, в подтексте был призыв к сотрудничеству в выработке регулирования, иначе придет гос.облако (могу ошибаться).
### На это был встречный вопрос из зала. Есть некий комитет (детали – не знаю), который решил, что национальной ERP будет 1С, и ничего другого не нужно. А есть компании, которые готовы создать альтернативные систему, и у них есть успешный прецедент по финансам для Дом.РФ. Ответ был двойной: конкретные проекты министерство готово поддержать через со-финансирование, если есть крупный заказчик, а про конкретный комитет – просьба подойти и рассказать детали, в чем проблема.
### Я тут отмечу, что тут проблема с размером рынка. Министерство не видит этой проблемы, есть мнение, что продавать наружу можно только то, что хорошо продается внутри, и сначала надо освоить внутренний рынок. А опыт развития отрасли говорит, что это неверно. Отечественный и глобальный рынок имеют принципиально разную емкость, и выбор рынка был в самом начале создания продукта. Miro, IDEA и ряд других продуктов создавали именно для глобального рынка – и оно взлетело. А сейчас для глобальных продуктов проще начинать не в России…
# Было довольно много вопросов по организации и регулированию. Часть – вполне конструктивны, и, в основном, связаны с тем, что решения принимаются в узком кругу без широкого обсуждения, как уже упоминавшийся кейс с обсуждением Роскомнадзора или с комитетом по ERP. А другие – из детской позиции: мы придумали или хотим крутую вещь, дайте нам для этого денег – так дети просят у родителей новый гаджет. Я прокомментирую несколько пунктов.
## ИИ очень дорого для небольших компаний, нельзя ли это как-то поддержать? Был понятный ответ: использование ИИ нужно для повышения производительности, и должно окупаться, поэтому основания для такого спонсирования – не понятны. И я тут согласен. Тем более, что знаю про многие кейсы дешевых проектов с использованием легких моделей, которые оказывались не хуже мощных для конкретных классов задач. Тут как с любым софтом: можно пробовать обеспечить быстродействие железом, а можно – тюнить софт. Но пилоты разработки субсилировать готовы на общих условиях.
## Датацентр в космосе. Давайте создадим, клево же, дайте нам денег. Может, и клево, но экономика пока непонятна.
## Все площадки открытых данных – за рубежом. Ученые готовы выкладывать данные для своих исследований, способствуя развитию исследований, но отечественной площадки нет. Ответ: мы готовы поддерживать инициативы, но не делать государственные площадки. Опыт с мессенджером Макс показывает, что индустрия должна делать сама.

[[Категория:ИИ-агенты]]
{{wl-publish: 2025-11-09 12:09:56 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2025-11-13: ArchDays - ИИ и архитектура

2026-07-24T14:52:34Z

MaksTsepkov:

{{Conf-Ref}}

Конференция [http://archdays.ru '''Archdays'''] проходит с 2019 года, а я на ней был в четвертый раз. Это — интересная площадка. Организаторы собирают архитекторов из крупного Enterprise, и это дает возможность заглянуть внутрь. На открытии '''Сергей Баранов''' дал ретроспективу развитие тем на конференции. Начиналось все с микросервисов, затем шло повышение уровня абстракции: архитектурные паттерны, технический долг, '''архитектура как экосистема''' в целом. А в этом году темой был ИИ, встройка которого в ИТ-ландшафт порождает много новых типов проблем — и с ними надо разбираться.

В докладах конференции много фактуры, которую не так часто показывают, например, в этом году '''Александр Войновский и Олег Зоткин из ГазпромНефть''' показали свои '''архитектурные схемы''' включения приложений с ИИ в ИТ-ландшафт. '''Презентации конференции опубликованы''', так что эти схемы можно увидеть. Видео - ожидается (17.02.2026 - '''опубликовано''' [https://t.me/archdays/67 пост в Tg], [https://youtube.com/playlist?list=PLrVFXqPAjZspdew_cxF88CkPUCZD5GiuJ&si=WXHhzsXBe6p7liVQ youtube], [https://vkvideo.ru/playlist/-184472537_6?sh=4 VK-video].

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

Но до обзора повторю то, что я писал в [[Highload-2025|отчете о Highload]]: ИИ перешел из стадии создания отдельных приложений в один из элементов в архитектуры приложений. Приложений с ИИ — много, и они уже встраиваются в архитектуру предприятия регулярным образом. При этом могут быть использованы как стандартные системы, так и собственные, в том числе возможны дешевые решения, об этом был доклад. А еще использование ИИ встраивается в pipeline разработки как отдельные шаги, об этом были доклады и здесь, и на Teamlead.

== Александр Войновский и Олег Зоткин из Газпром нефть. Эффективная архитектура ИИ для цифровизации производства ==

Этот доклад — возможность заглянуть в архитектуру крупного Enterprise и способы встройки в нее ИИ-приложений. Газпромнефть работает в этом направлении уже давно, и таких приложений много. Поэтому уже наработаны типовые схемы их встройки, включая переход от DevOps к ML-ops конвейеру и обеспечение надежности решений при непредсказуемости поведения.

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

# Capability map ГПН, отражающая ИТ-ландшафт
# Применение ИИ в ИТ-ландшафте с подсветкой соответствующих квадратов
# Мапинг проектов ИИ на карту технологий.
# Инструментарий разработки и типовая схема фаз проекта для приложения с ИИ
# Обзор рынка инструментов и платформ MLSECOPS
# Архитектурные схемы приложений с ИИ, их встройки в ИТ-ландшафт

А помимо схем в рассказе был ряд практических вопросов: сопоставление RAG и дообучения с примерами (в своих проектах они используют оба варианта), правила распределения инфраструктурных ресурсов и способы оптимизации и так далее.

А теперь — краткий конспект доклада.

В начале — схема развития: Идея AI (1960-е) — Machine Learning (разные распознавалки) — Deep Learning — Generative AI (порождение текстов, рисунков, музыки) — LLM

Текущие индустриальные тренды.

* многофункциональная робототехника
* интернет вещей — датчики и прочее
* развитие биопечати
* квантовые вычисления
* кибербезопасность нового уровня
* расширенная реальность (XR) — вслед за AR и VR
* ИИ — создание моделей под конкретный бизнес, ML-ops конвейер, мультиагентные системы.

Цифровая стратегия ГПН — ответ на вызовы. И сейчас они на третьем этапа: внедрение ИИ, цифровых двойников и роботизации.

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

Дальше — схемы: capability map нефтегазовой компании от поиска и нефтеразведки до сбыта, деление по доменам и места ИИ на ней. И мапинг проектов на карту классов ИИ — чтобы объяснять бизнесу что конкретно и где внедряется.

Брать ли для внедрения модель от вендора или строить свою на основе open source? У open source — плюсы, главное — безопасность, но есть проблема поддержки развития модели.

Я бы тут добавил, что развитие открытых моделей можно заказать, как заказывают развитие PostgreSQL. B это — правильно: не просто брать open source на халяву, а возвращать полученное вкладом в развитие.

Под индустриальные задачи стандартных моделей не достаточно. LLM из коробки не владеет специфической терминологией, например, не отвечает про особенности нефтедобычи при обводнении слоя (хотя научные и инженерные работы по теме она знает). Есть несколько способов доводки: дообучение, RAG и создание агента.

Поэтому арсенал средств разработки приложений дополняется инструментами работы с ИИ. Они используют много инструментов, на слайде был список по категориям: работа с признаками, разметка и тегирование, разработка моделей, безопасность, автоматизация процесса разработки, эксплуатация приложений с ML-моделями. Примеры — Lite LLM для оркестрации и выбора направления маршрутизации запроса, GoldTrace AI для цензурирования запросов и ответов, Fist для работы с признаками, она позволяет группе команд работать сообщим датасетом, и так далее.

Дальше были архитектурные диаграммы. Layer-схема пользователи — бизнес-решения — Сервисы (набор переиспользуемых функциональностей) — ML-платформа для разработки моделей, референсная архитектура приложений GenAI — функциональная архитектурная схема. И разбиралась оптимизация использования инфраструктурных ресурсов: резервирование карт, деление по ядрам и TimeSlicing, маршрутизация запросов и балансирование нагрузки, и внедрение инструментов, сервисов, библиотек, оптимизированных на GPU, которое дает рост на порядки, в 10-1000 раз.

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

И у них появилась новая специализация — citizen data scientist: сотрудник-не-программист использует ИИ в работе за счет low и no code инструментов работы с данными.

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

Вопросы.

* Как определяли метрики? Так же, как и с другими инициативами компании, бизнес-метрики — те же самые. А инфраструктура — отдельная программа, которая должна сделать возможным агентов, и там тоже проектные метрики.
* Когда появляются платформы? Начинается с решения конкретных задач. Тут есть консалтинговая модель зрелости, когда включается стратегический уровень, а не точечные проекты, как в начале. Платформы — на этом этапе, мы дошли. И в компании шло эволюционно: DevOps — Платформа и онтология данных — ML-ops
* Кроме архитекторов кто использует busness capability? Ответ: это — инструмент общения с бизнесом и с коллегами из других компаний.
* Сколько времени ушло? ML-ops конверйер и 1-2 линия приложений — 1.5 года, участвует департамент разработки, центр компетенций ИИ, центр компетенций инженерного ИИ. И много треков, в которых участвуют разные люди, включая ИБ и разработку, и звдвча как раз выстроить сложный процесс.
* Про модели. На слайдах были компоненты — сервис цензурирования и другие. Это из коробки или надо сделать? Ответ — зависит от пути компании. Если покупаете платформу, такие есть — то там сервисы из коробки. Если платформу делаете сами — то надо собирать.
* Сколько успешно внедренных решений? Ответ. У них есть сито гипотез, они собираются на портале, и дальше их могут отсеять до разработки через экспертную оценку бизнесом потенциальной пользы и техническим специалистов по реализуемость, тут отсев идей может быть довольно большой. Если же смотреть на те, которые прошли до этапа разработки, то больше половины доходит до внедрения.
* Управление онтологиями. JetBrains composer, Protege — их посмотрели. Сейчас есть проект, который делают на основе одной из отечественных платформ.

== Павел Кан из Greensight. ИИ своими силами: реальный кейс разработки без миллионных инвестиций ==

[https://drive.google.com/file/d/1HxnsTudwSm4kEtqigV_JgVboF22FbbO9/view Презентация], [https://vkvideo.ru/video-184472537_456239191?sh=4 видео на vk], [https://youtu.be/gWp1Hun-Zyg?si=g5MBEPR6GdW7PSfx видео на youtube]

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

Они решили сделать '''легкие специализированные модели''', заточенные под конкретные задачи, чтобы эксплуатация была дешевой. Этой цели они достигли: начинали с одной видеокарты, сейчас у них арендованы две T4A100 — продакшн и разработка, а для обучения моделей используют аренду spot-instance под конкретные задачи. Общие затраты на инфраструктуру — 100 тысяч в месяц, и она обслуживает сайты нескольких клиентов (количество я не записал).

Как это устроено, Павел разбирал на задаче создания внятного описания товара по его фото. Принцип fail fast feedback. Делают простой прототип: ты ему картинку, он дает описание, ты оцениваешь. Людям интересно поиграть с ИИ один вечер. Отправляли в общий чат компании — поиграть интересно, собирали кучу кейсов, и дорабатывали.

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

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

'''Как оценивают результат обучения?''' Стандартные оценки — точность и Fscore — не для них. Потому что модель заточена под конкретные задачи, и общий процент точности клиенту не интересен, ему важно, чтобы модель не путала летнюю и зимнюю одежду или верхнюю и нижнюю, а описание содержало все необходимые атрибуты: материал, сезон, назначения.

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

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

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

Специализированные модели — разные, как примеры были Vikhr models и Mulilingual-e5, а для оценки — Qwen 2.5-V. Qwen — потому что результативный тип модели, а не ассистентный, и она доступна для локального развертывания. Но он — тяжелый, на одной карте может работать не более двух инстансов, а легких моделей — одновременно 15 штук под разные задачи. Поэтому и используют легкие. НО подробнее про экономику расскажут в следующем году, потому что пока эксплуатации полгода.

В презентации — архитектурная картинка, как это все работает, вполне понятная: Airflow, ML-flow, s3 для датасетов, артефактов, и состояния spot-instance, и набор моделей. Смотрите.

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

Ресурсы видеокарты — поделены, Airflow и Kubernetes всегда сначала запускает check памяти, и только если ее достаточно, то контейнер с запуском. Если недостаточно — ждем ресурсы. Есть выделенные видеокарты на постоянной основе, и есть пул в датацентре для дообучения и оценки. Пул — spot instance — прерываемые ресурсы, которые датацентр может забрать, он непредсказуем и его доступность — разная. И они сборку контейнеров адаптировали под доступную карту, запускают образ, собранный для конкретной выделенной карты — cost optimazed deployment. Все это обеспечивает pipeline на уровне инфраструктуры: есть задачи с приоритетом, для задач клиента — вип-пропуск, остальное по запросу и квота по ресурсам. Для каждой модели есть требования по памяти и времени, это зафиксировано в пайплайне и учитывается при работе в ограниченных ресурсах. Разработка заняла полгода от идеи до модели.

== Руслан Серкин из МТС Web Services. Архитектор и ИИ: Управляем старым техдолгом и создаем новый ==

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

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

Этапы развития ИИ: 2015—2020 — подсказки в IDE. 2020—2023 Copilot, обученная модель может создать функцию; сейчас рефакторинг и вайб-кодинг, и ее можно использовать для управления архитектурой.

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

ИИ помогает принимать решения. ADR — инструмент, который описывает проблему и решение. Получаем сравнение инструментов в контексте проблемы и фиксируем не только решение, но и его основания. И ИИ может выступать ментором.

Когда есть несколько команд и большой ландшафт, и каждая ведет свои ADR, получается '''долг непоследовательности''': город, в котором отдельный дом прекрасен, а вместе ужас. Одна команда сделала кэширование в памяти, другая кэширование на redis, а третья — redis, но с другой библиотекой, и каждое решение осознанно. Но в результате devops должен знать три подхода к мониторингу, а при смене команды разработчикам надо изучать конкретные решения. Или команды пилят монолит, который хранил настройки в appsettings.json, и один сервис использует переменные окружения, а второй — consul.

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

'''Долг документации'''. Новый разработчик приходит, надо поднять сервис, он не поднимается, а потом в курилке выясняет, что нужна Кафка. Или архитектор берет c4 диаграмму, заказ работает с платежным сервисом, делает рефакторинг — в результате выпало мобильное приложение, потому что его на диаграмме не было.

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

Инцидент. Оформление заказов тормозит, в runbook написано — смотри payment gateway. А, оказывается, там месяц назад включили антифрод, тормозит он, но runbook не поправили, который тормозит. ИИ — не забывает. '''ИИ — штурман при инциденте, живая документация'''.

Три способа, которые можно применять: ассистенты в IDE, анализ кода, RAG-фреймворки.

'''Но за любой инструмент надо платить''', и использование ИИ порождает новые проблемы.

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

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

'''Долг слепого контекста'''. Спроектируй архитектуру на 15 микросервисов. И в предложении — модная архитектура с шаблонами. Не адекватная задаче и неподъемное для команды. Нужен паспорт команды с навыками, бюджеты, стратегические цели, Роль переводчика с неформального бизнес-языка на понятный ИИ.

Архитектура против культуры. ИИ предлагает Kubernetes Knative. Для стартапа — идеально, а в enterprise — у нас большая бюрократия и ограничения. И это надо рассказать ИИ, включая модели ведения проектов с ролями, которые приняты. Роль антрополога.

'''Сверхоптимизация'''. ИИ знает задачу и оптимально исполняет. Но не закладывает маневры для изменений. Вы проектируете соцсеть, где 95 % — чтение ленты. Делаем денормализацию в базе PostgreSQL, и триггер для материализации в Redis. А тут бизнес просит показ по условиям, это уже не встроить. Нужно сценарное планирование возможного развития, и просим архитектуру с учетом этих сценариев. Стратегия и риск-менеджер.

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

Долг сверхоптимизации. 2023 — поиск через elastic search, а в 2025 — векторные базы для ИИ, на 80 % точнее. И тоже самое может происходить из-за новой версии ИИ. Надо легко менять блоки, например, поиск отделять от системы. ADR становится машиной времени, надо прогонять ADR спрашивать, что, возможно, устарело и пора готовиться к изменениям.

От умных ассистентов в 2023 к агентским системам в 2025 из множества систем. И интерфейсы к ИИ должны быть гибкими, абстрагирование интеллекта.

'''ИИ нас не заменит, но нас точно уволят, если мы не начнем адаптироваться'''. Архитектор — куратор ИИ. И риск-менеджер.

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

== Денис Бесков. Полная технология проектирования архитектуры информационных систем для бизнеса ==

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

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

[[File:ArchDays2025-BeskovSchema.jpg|Схема проектирования архитекторы|600px]]

# '''Определение логических компонентов'''. Это же делают аналитики, группируя требования по логическим компонентам. Есть 4 подхода: от процессов, от модели данных, от use case и от ограниченных контекстов.
# '''Моделирование границ и окружения'''. С4 context или контекстная диаграмма.
# '''Выбор архитектурного стиля''', или набора стилей, на рынке десятки.
# '''Определение архитектурных характеристик'''. QAW — воркшоп к заказчикам. Нужны для выбора стиля.
# '''Определение физических компонентов''' — system design, модули, брокеры, базы данных и так далее.
## Enterprise system design (Фаулер и другие)
## Internet system design (амазон, google и другие)
## Микровервисная архитектура
## Data engeneering
# '''Фиксация архитектурных решений''' — ADR или arc42.
# '''Моделирование состава системы''' — c4 container или component или аналоги
# '''Рассмотрение архитектурных альтернатив''' — для стиля для физических компонентов и так далее.
# '''Оценка компромиссов''' — ATAM/CBAM
# '''Проверка работоспособности решения'''. Proof of Concept, Fitness test
# '''Сборка макета решения''' с помощью ИИ (GenAI). Это — альтернатива оценки, как часть проверки работоспособности.
# '''Исследование домена''' — Event storming или Domen storytelling
# '''Социальное проектирование''' команды — team topologies
# '''Интересы стейкхолдеров''' — для выявления архитектурных характеристик. Возлагают на аналитиков, но те не выясняют.
# '''Стратегирование архитектуры''' — до моделирования домена, может, вообще не надо разрабатывать, а можно купить готовое. Wardley mapping.
# '''Выбор участника оргразвития''' — почему занимаемся именно этой областью, для этого нужна карта — Capability mapping

Инсайты.

* solution и decision в русском путаются
* Модель состава c4 излишне физична, там сразу физически поставляемые отчуждаемые части, это плохо стыкуется с логическими моделями Нила и Форда.
* Паттерны проектирования решают архитектурные задачи, которые формулируются неявно и достаются как «кот из мешка». Согласованность длинной транзакции — не было такой задачи, ее архитектор придумал. И в этом проблема: надо ли эту задачу решать вообще и зачем?
* ADR фиксируют решения нечетких задач.

У него получилась целостная картинка, и есть гипотеза, что она вам поможет. Но в том, что получилось — дыры: security, инфраструктуры, нет связи с другими инженерными процессами (design, deploy). Есть идея создать свод знаний. BoK не решают.

Еще в схеме нет блока защиты архитектуры. Архитектор предложил — а надо же доказать команде. Но тут вопрос границ: насколько защита входит в проектирование. Входит в коммуникации.

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

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

== Екатерина Рудина из Лаборатории Касперского. Не это ли центр? Как строить архитектуру безопасности и где искать безопасность архитектуры ==

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

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

Например, первый полет на Луну, или атомный проект. И дальше был рассказ про архитектуру первых атомных реакторов — чикагской поленницы (она проработала 35 минут, без охлаждения и биозащиты) и клинтонская поленница (она работала лет 20). В ней бруски графита, урана и регулирующие стержни кадмия лежали горизонтально. У наших конструкторов описание было, и оно не нравилось, потому что стержни кадмия могли деформироваться при нагреве, и это блокировало движение. Поэтому наш Ф-1 был с вертикальным расположением. Чтобы наблюдать за тем, что наверху — поставили перископ, стержни поднимались через систему блоков и была система безопасности — топор, чтобы перерубить канаты.

В 2011 на атомной станции в Джорджиа (США) был инцидент. Была предусмотрена передача данных из промышленного сегмента в офисный. Инженер поставил обновления, в результате затер данные в промышленном контуре, система интерпретировала это как потерю охлаждающей жидкости и остановила реактор. Остановила штатно, но второй реактора это время не работал, шла перезагрузка топлива. В результате — несколько часов без энергии. Правильная архитектура не должна была позволить затереть данные в промышленном контуре. Архитектор должен выдать требования по безопасности и способы их обеспечения.

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

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

Доменная архитектура — похожа на техническую, корни — не в информационных моделях, а в прикладных областях, в частности — в авионике. Принцип: на базе одной системы должны реализовать архитектуру, которая не отличима от распределенной системы, то есть сети. Когда придумывали — не было виртуалок, они появились позднее. И появилась система MILS — ARINC653. Правила взаимодействия между доменами определяются политиками безопасности, а они ограничены правилами топологии.

Есть набор требований: разделение ресурсов, правила междоменной коммуникации, реализация политики безопасности, управление памятью, планирование исполнения, обработка ресурсов при исполнении, минимальная обработка прерываний и так далее. Распределенный MILS — пражское метро, австрийская система управления критическими коммуникации в аэропорту.

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

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

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

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

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

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

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

== Дмитрий Ионов. Архитектурные принципы как способ управления архитектурой ==

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

Архитектор — медиатор этого конфликта. Есть аналогия. Человек разговаривает с тренером: «Мне надо больше зарабатывать, чтобы лучше жить», а тренер отвечает: «Если будешь заниматься спортом, правильно питаться — у тебя улучшится качество жизни, будешь лучше соображать и, вероятно, сможешь больше зарабатывать. Но где взять денег — не знаю».

Дмитрий предлагал способ работы, который он применяет — выстраивание цепочки: миссия компании, ее цели и задачи — архитектурные принципы — архитектурные требования — реализация ИТ-проектов и архитектурный контроль.

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

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

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

'''Обязательный административный шаг — утверждения архитектурных принципов'''. Принципы должны быть однозначно понятны. Утверждение минимум на уровне CTO. Применение принципов — для внутренней разработки, для закупки и конкурсных процедур, для внедрения систем.

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

Когда может не работать?

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

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

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

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

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

На слайдах каждый принцип расшифрован и даны следствия. Например, интеграционная независимость — выделение интеграционного слоя.

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

Когда нужен анализ системы — берем первые два столбика с принципами и документацию, и описываем соответствие. Например, для облачного сервиса — нет безопасности данных, особенно если иностранная компания, а в датчиках есть GPS-позиция. Поэтому систему не берем.

Второй кейс — проект разработка софта, там пришлось поработать с целями. Требований больше, они более конкретны.

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

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

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

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

== Павел Кутаков из VKTech. Сжатие технологического стека, или анти-Highload ==

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

Рассказ начат со схемы типичной архитектура сервисного приложения, собранная из современных средств в расчете на рост. Применяем CQRS и Event Sourcing: Три сервиса бизнес-логики, Command API — Кафка — Command processing — PostgreSQL, из которого читаем, RabbitMQ для внутренних сообщений, Mongo для лога команд, ElasticSearch и ColumnStore GreenPlum, схему смотрите в презентации. Может показаться, что Кафка и RabbitMQ вместе — это чересчур, но я реально видел такие корпоративные архитектуры. Итого получается 25 объектов эксплуатации, из них только 6 — наша бизнес-логика — мы же наши сервисы поднимаем в двух экземплярах на всякий случай. И это — не подъемно для маленькой команды.

Можно ли сохранить гибкость? Может, потому что все это умеет PostgreSQL.

* Документная база — Json, для поиска — версии индексов. И можно реализовать Mongo-протокол для внешних систем. FerretDB. И DocumentDB у Микрософта — расширение PostgreSQL.
* Очередь — делаем без проблем в реляцонке. select for update skip locked — взять первый незаблокированный.
* Аналитическая система, колоночное хранение. Встроенного нет, но есть TimescaleDB и Citus. B эффективно копировать таблицу в другую с поколоночным хранением — там не вдвое ovrhead. А еще pg_duckdb.
* Полнотекстовый поиск встроен, но медленно. И есть расширение '''paradedb'''.

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

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

Поедет ли этот комбайн? Модель интернет-магазина, клиент делает 10 поисков и делает корзину, финансы — TPC-C тест. Для него картинка полного и сжатого стека. У PostgreSQL есть pgbench — ему подготовили скрипт, который моделирует бизнес-транзакцию на хорошо заполненной базе: 100к товаров, поиск над ними, 100 м документов, 100к покупателей что-то уже купили — 100к заказов на 1 м товаров. Результат: 8-ядерный PostgreSQL держит 90 заказов в секунду — с 5 поисками товара каждый и оформлением. При том, что реальная нагрузка у Visa — 300 платежей в секунду, а x5 — 400 покупателей в секунду, а в строительных гипермаркетах — 2 в секунду. Итого получаем вполне приличное быстродействие, которое держит хорошую нагрузку.

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

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

== Сергей Баранов. Экономические последствия архитектурных решений ==

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

* Гибкая конфигурируемая интеграция, которая обошлась в 2 млн, при том, что простое жесткое решение было в 10 раз дешевле. Да, она сокращала время на одно изменение с 4 часов до одного, но эксплуатация показала, что за два года было всего три изменения — деньги на ветер. И простой расчет показывает, что в принципе окупаемость была бы достигнута только при потоке 2-3 изменений в неделю — а это явно не ожидалось.
* Очередь: Postgres + polling или RabbitMQ/Kafka
* Нужно ли шардирование по регионам?
* Rest или GraphQL

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

== Валерий Казьмин из cloud.ru. ArchPlatform: Как построить эффективную платформу управления архитектурой ==

Обычная ситуация с архитектурой выглядит примерно так.

* Архитекторы у нас не очень.
* ИТ-ландшафт никто не знает, там сотни серверов.
* Эффективность решения бизнесу неясно, он просит снижать косты вдвое.
* Архитекторы не знают ландшафт — долго меняется
* Инвестиции не туда и результат неизвестен
* Каждый архитектор делает свое
* Бизнес считает, что архитектура средненькая
* Бизнес хочет что-то делать с архитектурой, потому что она не вывозит рост бизнеса.

Что с этим делать? Нужна трассировка от бизнеса до инфраструктуры, хорошая интеграция и адекватный задачам уровень DataQuality (4-5 часто лишний). Если вы — стартап, то хорошо бы все это закладывать с самого начала. И он рассказывал, как это устроено в cloud.ru с архитектурными схемами.

Cloud. Бизнес продает ресурсы. Инфраструктура — она хорошо типизирована — железо, платформы. Возможности инфраструктуры с потребностями бизнеса расходятся.

ArchPlatform — система, которая интегрирована с ИТ-ландшафтом: данные по инфраструктуре, репозиторий кодов, аритектурные документы, вики и так далее. Конфигурация модели через UI или API, ETL-движок, Validation engine. Портал работы с пользователями, аудит и логирование, BI и визуализация.

Слои данных: hardware, Infrastructure — виртуализация, Платформы (БД и Кафки), Application. Схема данных. Nакая схема отрисовывается lля каждой новой услуги.

Зачем нужен DataQuality? Объем такой, что следить за корректностью описаний не успеваем, поэтому их надо автоматизированно проверять. ИИ тут не помощник, ему на вход нужны адекватные данные, потому что он вашу инфраструктуру не видит. Платформа берет потоки данных от процессов — инциденты, логи изменений, и сопоставляет их со схемами, фиксируя несоответствия. Используют AirFlow, Apache superset для визуализации и ряд других средств.

Что получили?

* Метрики актуальности архитектуры, любое изменение в железе влечет метрики
* Упростили требования к архитекторам — они работают на уровне схем, рассчитывая на их адекватность.
* Начали искать аномалии и тренды, у них 16 м объектов, глазами проблемы не видны

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

Ушли от субъективной оценки архитектора — его работу можно оценить. И полная прозрачность и понимание. И бизнес больше понимает, чем архитекторы заняты, бизнес стал больше доверять. И мы можем мониторить архитектуру, смотреть возможности бизнеса.
{{wl-publish: 2025-11-13 11:37:47 +0300 | MaksTsepkov }}
[[Категория:ИИ-агенты]]

Блог:Максима Цепкова/2025-11-21: Teamlead прекрасен: хорошие доклады и море общения

2026-07-24T14:52:14Z

MaksTsepkov:

{{Conf-Ref}}
На конференции [https://teamleadconf.ru/moscow/2025/schedule Teamlead] я был оба дня. Но докладов слушал практически столько же, чем на Highload – было очень много встреч и обсуждений с разными людьми на разные темы – на конференции выступает и участвует очень много знакомых, а у меня в этот раз была интересная тема разговора про впечатления от поездки в Китай. Практически цепляешься языками, а потом обнаруживаешь, что доклад уже почти кончился. Чуть не опоздал таким образом на доклад '''Александра Зизы''', который неожиданно для меня рассказывал '''про эмоциональный интеллект''', но во-время посмотрел на часы, успел, и очень рад этому, потому что это был очень содержательный доклад. Тем не менее, на восьми докладах я был, и поделюсь заметками.

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

Еще хочу отметить доклад '''Анны Обуховой''' про механики счастья. А также любопытный рассказ '''Марии Седяевой''' о производстве мультфильмов по Scrum. Мария – из авторской мультипликации, и когда она получила финансирование на создание сериала, то задумалась про организацию работы команды, она же этого никогда не делала. Она решила использовать scrum, у нее это успешно получилось, и она рассказала и основания для такого решения и механику. А в рамках афтерпати был закрытый показ готовых четырех серий, мультик реально крутой, на мой взгляд, по неожиданности сюжетных кодов сопоставим с капитанов Врунгелем, а по визуальному ряду – с «Ну, погоди». Концепт напоминает диснеевские «Чип и Дейл спешат» на помощь (но у Диснея сильно меньше разговоров), только герои спасают океан от разных экологических бедствий, источником которых является человек.

Еще надо отметить, что в конференции было очень много мастер-классов, 2.5 трека в больших залах, 16 штук по два слота. И 83 доклада. И организаторы считают, что много мастер-классов – правильно. Конференция, как и Highload, проходило в технопарке Сколково, был 1931 очный участник и 1465 онлайн.

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

== Китай становится лидером – как изменится мир ==

В начале октября я был в бизнес-туре по китайским технологическим компаниям (Baidu, Xiaomi, SenseTime и другие), мои впечатления можно прочитать в [[Блог:Максима Цепкова/2025-10-22: Китай - технологический лидер будущего|отчете]]. Основной вывод – сценарий '''перехвата Китаем технологического и политического лидерства у Штатов''' становится из возможного когда-нибудь в реализуемый в ближайшие '''3-7 лет'''. Это изменит мир, потому что культура лидера влияет на всех остальных. И к этому стоит готовиться уже сейчас. Может, я дую на воду, но я помню изменения 90-х со сменой советских идеалов на западные. Нам скоро жить в другом мире, и его лучше бы понимать.

В интервью мы обсуждали отличия. У меня были тезисы, но их все обсудить не успели. Я их здесь опубликую, но без примеров в обсуждении.

* Иллюстрация-1 – '''отношение к ИИ'''. У нас две темы: ИИ нас всех заменит, и ИИ – глуп, ничего не может, и один человек может запросто высказывать обе, не замечая противоречия. В Китае '''нет страха, есть сотрудничество''', и в несокльких компаниях мы слышали, что каждый сотрудник должен обсуждать с ИИ свои рабочие задачи, чтобы ИИ быстрее выучился и смог лучше помогать людям. SenseTime вообще формулирует миссию так: «'''Пусть ИИ возглавит наш прогресс'''». А еще у нас к Алисе относятся как к забавной говорящей зверушке, а там нормально, если у тебя ИИ – друг: проснулся – поздоровался, за завтраком обсудил новости и планы, и так далее. И нет воплей о том, что такое отношение – фи, потому что ИИ – не человек. Это – культурные аспекты, и они, на мой взгляд, важнее, чем подрыв DeepSeek монополии Штатов на сильные LLM. Хотя это тоже важно: модель создана, опубликована в свободном доступе, обучена на порядок дешевле, и методы тоже опубликованы. Все это можно использовать.
* Иллюстрация-2: '''перемены – это возможности'''. Они – быстрые и жизнь в эпоху перемен их не напрягает, а наоборот, дает возможности. Нет проклятия эпохи перемен. Шэньчжэнь – 40 лет на месте деревни, 220 небоскребов, 10 лет назад не было. Автозавод Сяоми за три года с автоматизацией 91%. При этом автомобиль Сяоми – гибрид Порше и Феррари по дизайну, и стоит всего 2.5 млн. рублей (в Китае).
* Сами '''китайцы видят перспективы у себя в стране''', уже 10 лет '''80% студентов возвращаются после обучения''' в западных университетах, а 20 лет назад 3/4 уезжали насовсем.
* Иллюстрация-3: '''размытие иерархий и самовыражение'''. Культура ников в компаниях, прогулки и фото в костюмах, самовыражение через шопинг – Little Red Book – гибрид инстаграм и маркетплейса, у нас это пробует сделать WB.
* Много технологических кейсов: 5G Huawei, вакцины ковида, ТикТок – глобальная сеть, роботакси Baidu против Waydo (и Яндекса), WeChat – больше чем мессенджер, в бизнес-версии есть ведение проектов и почти ERP.
* '''Преодоление конструкции потребительского общества''': говорят не об изобилии, а о процветании, и это – совсем другие акценты.
* При этом – руководящая роль партии и военная терминология. В Little Red Book культура ников и отказ от иерархии совмещается с правилами военного отряда для команд, с соответствующим языком. А в Baidu спикер в качестве годного образа человека будущего, которому помогают компьютеры, говорил о фильме «Терминатор».

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

Ситуация '''5-10 лет назад''' была понятна, было две стратегических развилки.

* '''Первый выбор''' – глобальный или локальный рынок. Есть глобальный рынок с центром в Штатах, есть локальный рынок России и примкнувших к ней стран СНГ, который тоже развивается. И желательно выбрать сразу, фокус развития – разный. Хотя компанию в Штатах можно регистрировать и не сразу, и есть вариант штаб-квартиры в Европе или из местной юрисдикции.
* Китай – сбоку, отдельно и отделен от остального мира своим файерволом и законами, внутри – собственная экосистема.
* Постепенно международная ситуация становилась более многообразной – появились локальные центры, предпочтительные для работы не только на западных, но и на азиатских рынках, такие как Кипр для финтеха или Дубай.
* '''Второй выбор''' – по техническим средствам: есть вендорские платформы и open source, который растет. Open source можно просто брать, а можно, решая свои задачи, быть контрибуторов, развивая его.
* В этом же пространстве – '''траектории личного развития''': можно выбирать разные компании и проекты, в том числе, выбрав глобальную компанию, уехать на Запад.

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

У Китая было несколько попыток прорыва на технологические глобальные рынки. Huawei с 5G и заменой оборудования западных производителей был жестко заблокирован. А TikTok, как интернациональный клон местного сервиса Douyin, успешно вышел, и Штаты с 2020 года хотят купить американский сегмент в управление, а Китай как бы не против, но сделка так и не происходит, недавно сменился потенциальный покупатель (Oracle вместо Microsoft). Если говорить о трендах, то по мере проявления политического лидерства будет расти экспансия китайских продуктов на различные рынки.

'''И вот тут вопрос, что нас ждет лет через 5-7: глобальный рынок с крупными компаниями из разных стран -- Китая, Штатов, Европы, России, которые могут при этом жить в разных юрисдикциях (Дубай, Кипр), или рынок США и Европы обособится от рынка Глобального Юга или мирового большинства, на котором будет доминировать Китай? И каково возможное место российских компаний во втором случае?'''

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

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

Но одновременно '''китайские компании активно становятся создателями и контрибуторами open source продуктов''' (Vue.js, Apache Dubbo, ECharts, Ant Design, OpenResty и ряд других), и это делают крупные китайские компании (Alibaba, Baidu, Tencent и другие). Интересно, что Gemini и DeepSeek выдают разные списки, у DeepSeek короче, зато там ИИ и аналитические БД.

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

Я осмысливаю тему культуры и способов организации китайских компаний, материалы собираются в '''[[:Категория:Китай становится лидером]]'''.

== Рустам Агамалиев. Кажется, я работал. А чем именно занимался? ==

Основной тезис доклада: '''для того, чтобы планировать свою жизнь и достигать целей, необходим трекинг и анализ затраченного времени, без этого время запросто утекает на деятельность, которая с целями не связана, а вы вынуждены мерить свой труд по усталости, а не по его результату'''. Рассказ был построен на замечательном примере Александра Александровича Любищева, биолога и энциклопедиста, который всю свою жизнь действовал таким образом и описал свою систему. О Любищеве есть книга Даниила Гранина «Эта странная жизнь», а он сам описывает свою систему в книге «'''Руководство для начинающих научных сотрудников'''».

Меня книга заинтересовала, и я быстренько нашел [http://blog.nazarovsky.ru/2012/10/blog-post.html '''книгу''']. Возможно, по ссылке не полный текст, но язык эпохи там есть, и примеров достаточно. Отметим, что учет своего времени Любищев вел в до-компьютерную эпоху, на бумаге, при этом регулярно подводя итоги и проводя анализ. Сейчас это многократно легче. У нас в компании трекинг рабочего времени обязателен, еще с тех времен, когда были проекты T&M. И это – не средство контроля, а средство анализа, чтобы сравнивать план-факт и корректировать будущие планы, делая их выполнимыми. А когда у меня стало много активностей за пределами компании, то я и их начал учитывать – это помогает мне планировать подготовку к докладам, лекциям и другим активностям – я неплохо оцениваю, сколько потребуется времени. Так что для меня доклад был очевидным. А для многих в зале – нет, люди вообще не любят трекинг времени – он выдает неприятные вещи, стоит ли расстраиваться?

А теперь – содержание доклада.

Продуктивность не стоит считать как объем сделанного – это про физический труд. А в ИТ – умственный. И это касается не только работы, но и жизни в целом. Отец сказал Рустаму про выбор жизненного пути: подумай, где ты будешь конкурировать со своими детьми через 10-15 лет? Ты понимаешь место, и тогда можно планировать в долгую. Путь привел его в руководители нефтяного сбыта крупной корпорации, а потом – учителем в школу. При этом переход – не мгновенный, он взял ориентир на учителя в 2016, а стал им в 2018, переход – 2.5 года, и это – планово.

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

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

Продуктивность – не занятость. Но '''если мы не понимаете результаты задач, то мерилом продуктивности становится стресс, усталость'''. А это – неверно.

Система Александра Александровича Любищева. О нем книга Даниила Гранина «Эта странная жизнь», а он написал «'''Руководство для начинающих научных сотрудников'''». ИТ – тоже наука, работа ИТ-шника – думать.

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

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

'''Любищев не оптимизировал время, но измерял смысл прожитого времени'''. Когда в нему подходили «давай сделаем это» он отвечал «у меня не запланировано времени».

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

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

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

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

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

Начало действия и конец действия, и то именно сделал. Если не сделал – то не значимое. В день 10-20 записей, дальше оцифровать, для этого obsidian. И дальше – анализ лога с помощью ИИ. У него на сайте есть промпт (в презентации – ссылка), там зашиты его категории, но это появляется примерно через год.

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

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

Много целей не бывает. Цель – одна. Не важно, с командой работаешь, с семьей. Ты где-то хочешь быть через 10 лет.

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

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

== Анна Обухова. Зачем задумываться о счастье, если работы невпроворот ==

Работы невпроворот, а тут рассказ про счастье, уместно ли? Но счастье – оно про производительность. И в рассказе будет работа с собой, а не рассказ о том, как сделать счастливыми сотрудниками. Но можно работать с собой и передать инструмент сотрудникам.

Анна – Agile coach. Когда работала в швейцарском банке, процессы. Стало понятно, что работает с умными машинами, станки – в голове. И вспомнила, что биолог, и совещания, проведенные по-разному дают разную эффективность. Нейролидерство: берем нейрофизиологию и применяем к работе. Эффективность – 17% на приличных объемах, 60 команд.

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

Но нельзя сделать «пусть работа приносит результаты», сильно влияет внутренне счастье людей, разница до 50% по производительности, и там сложные связи.

Провели масштабный эксперимент – 900 тыс человек, масштабная система, метрики производительности. И померили 25% самых несчастных и самых счастливых: разница в 4 раза. Кто эти счастливые люди? Это американская армия, солдаты. Производительность в американской армии – по наградам, по продвижению – там производительность по-разному можно мерить.

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

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

Счастье измеримо. Но не happienes, а '''subjective wellbeening = positive affect - negative affect + life satisfaction'''.

Причины несчастья.

'''Причина-1'''. '''Перегрузка'''. Есть нейротрансмиттер '''серотонин''', он не про счастье, а про '''толерантность к несчастью''', он помогает нам не чувствовать несчастья.

# Это древняя молекула, есть еще у лобстеров: когда победил – серотонин 72 часа.
## Победное откидывание, уже от человека, любуюсь на то, что сделал. Когда делаем искусственно, то на 20 минут, и далее на сутки – понизился кортизол и повысился серотонин
## Лобстер, который проиграл – скрючился, съежися и у него 72 часа несчастья.
## Новая жизнь с понедельника – три дня: первый бодры и веселы, на второй – новизна, на третий – ой, других дел много, небольшое поражение и мы чувствуем это поражения до конца недели, в воскресенье – снова идея про новую жизнь.
# Послестрессовая ангедония. Отдельные рецепторы, начинаем хуже предсказывать, что может быть хорошее.
# Изменение нейронов при хроническом стрессе. Капелька по капельки больше усилий, разжижение мозга. Есть картинки префронатальной коры и миндалины – чувствительность в хроническом стрессе и без него – разные реакции. Мозг в разных состояниях.
# Ангедония победы. Там идет огромное поднятие дофамина. А потом дофамин падает. И не всегда возвращается в исходное, а ты выжат после огромного успеха, до пары недель.
# Снижение проводимости дофамина при зависимостях. Кокаин, алкоголь, сладкое, развлекухи. И получается зависимое поведение.
## Если что-то подало громадное количество дофамина, рецепторы сворачиваются. Съели плюшку, вечером дофамин активнее – плюшки вкуснее. Мы такое сделали, а потом надо сделать отчет, вырабатывается адекватное количество дофамина – а рецепторов нет.
## Как сделать себя несчастным на два дня? 15 минут повтыкать в рилсики. Были рецепторы – их нет, это видно, и это на два дня последействие! И уходит привычка радоваться, ты сделал и ничего не получил.

'''Советы Эпикура'''.

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

'''Причина-2'''. '''Потребности. Кажется, их удовлетворение дает позитивные эмоции, но это не всегда'''.

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

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

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

'''Смыслообразующая сверхцель – одна'''. Но назвать ее можно, когда больше 45% энергии. Энергию можно мерить, один из способов – по вариабельности сердечного ритма, гаджеты меряют стресс, энергия – то, что осталось. Welltory меряет батарейку и стресс, там модель сложнее.

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

Мечтал быть летчиком? Это не значит, что взрослый – именно летчик. Это человек, у которого есть напарник, перспектива и движение. Стартап – это похоже. Анна прекрасно в детстве рисовала, но родители отдали в музыкалку, а не художку. Она хотела бы быть художником. Но она бизнес-тренер, она для каждого выступления рисует картины, потом это превращается в выступление. Но это она поняла только 2-3 года. И эта потребность поддерживает счастье.

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

Следующий метод – факт-карты Андрея Курпатова, , они позволяют залезть в default network. И ты можешь это выгрузить, проявить путь.

'''Причина-3'''. '''Сравнение с желаемым счастьем обесценивает все есть – ты же в пути'''.

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

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

Выросли на природе, переехали в Москву – мозг запоминает. Но возврат к природе – не чувствует.

И в заключении: '''есть техники счастья – используйте их'''.

Каптерев проанализировал 10 научно доказанных техник счастья.

* '''Практики благодарности'''. Действует сразу, но без накопительного действия
* '''Социальность'''. Общение с не-родными – такси, бариста
* '''Улыбка и язык тела'''. Есть привычка рассматривать с позитива, подход «а зато…», не говорить «жизнь – боль»
* '''Расслабление и снятие напряжения'''. Не требовать «соберись, тряпка»
* '''Использовать сильные стороны, а не устранять недостатки'''
* '''Делегирование того, что не нравится делать'''
* '''Принятие себя''': относиться к себе с любовью и принятием, не ругать себя.
* '''Сверхцель''': у меня не только эта работа, у меня есть сверхцель себя, я к ней иду
* '''Оптимизм'''. Хорошее – увеличивает счастье

== Александр Зиза. 8 уровней эмоционального интеллекта ==

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

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

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

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

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

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

Есть разные определения, что такое – эмоция. Summary от ChatGPT: '''эмоция то, что двигает нас изнутри и выводит во вне. Дает энергию и призывает к действию'''.

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

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

Дальше – исторический экскурс в понимание эмоций как инструмента управления собой и другими.

* Впервые про эмоции и эмоциональный интеллект говорил Аристотель. Аристотель сказал: добродетельный может направить злость на того, кого нужно, в нужный момент и для достижения того, чего нужно. То есть эмоция используется для достижения целей влияния.
* Тогда же выделились две линии: эпикурейцы и стоики. Стоики говорили, что надо преодолеть эмоции, а эпикурейцы – что надо жить с эмоциями в гармонии. И те и другие находят последователей сейчас. Впервые объединил две точки зрения Цицерон. У него есть понятие саморегуляции: тот, кто хочет управлять другими, должен сначала управлять собой.
* Святой Августин. Впервые употребил эмоции в современном смысле, исследовал понятия интроспекции, самоосознания. Впервые – осознание эмоции внутри нас, и дальше можно жить с ней в гармонии.
* Франция, романтизм – предпочтение эмоциональной жизни перед рациональной. Декарт, Спиноза, Юм: эмоции – страсти, их можно направить разумом. Они не могут быть сильными или ложными, они нас куда-то двигают, но не дают ответ, что нам делать, куда двигаться, куда направить волю.
* Шелер, Сартр, Рожерс: Эмоции – индикаторы связывания смысла, и они – только для нас. Если мы эмоционируем, то это для нас, не объективная информация, и дальше мне надо с ними что-то делать.
* Фрейд и Юнг: эмоции – проявление бессознательных конфликтов и архетипов. Эмоции нас обманывают, заставляют действовать стереотипно.
* Барретт, Дамасис, Гоулман, Экман. У нас есть когнитивный конструкт, который превращает событие из-вне в движение в некотором направлении. '''Между стимулом и реакцией есть пространство – это наша сила и свобода'''.

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

'''Цель + Энергия == Мотивация''', и за ней должно быть действие. А если энергия не потрачена – то ее надо куда-то направить, израсходовать на что-то разумное. И есть схема из двух уровней: эмоции и рациональное мышление.

* Связкой Цель – Сознание занимаются технологии мышления, это самоопределение.
* Связкой Эмоция – Энергия занимается психология.
* А эмоциональный интеллект – связь эмоции и мышления.

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

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

8 уровней эмоционального интеллекта.

# Реактивный неосознанный – действуем по порывам души.
# Неосознанный позитивный – мы замечаем, и позитивно относимся, это интересно
# Реактивный осознанный – задним числом понимаешь, ретро.
# Контролирующий осознанный – в моменте останавливаемся
# Контролирующий проактивный – предсказываешь
# Проактивный неосознанный
# Управляемые эмоции, влияние 1:1
# Системное влияние на массы людей.

Переходы, повышающие уровень.

# Из реактивного в позитивный – позитивное понимание. Эмоции – это сигналы о неполадке, обратите внимание. Ловите переходы.
# Из позитивного – в реактивный осознанный: записываем, что происходит и разбираем на ретро.
# Как прервать эмоциональный захват? Чтобы снять эмоциональный захват, если ты этого хочешь 10-20 секунд. Фильм «Социальная сеть» 2010 – там шикарно описано. На героя давят, а он говорит: «дождь идет». Уронить чашку. Надо отсчитать 15 секунд, чтобы выйти на более высокий уровень коммуникации.
# Выход на проактивный уровень. Подготовить, изучить данные, сценировать поведение. Увольнение, исправляющая обратная связь, которая эмоционально сложна, и вместо нее разговаривают про задачи. Берите фреймворки и шаблоны, они есть. COINS.
# Когда мы пробуем сделать проактивное поведение не осознаваемой компетенцией, возникает ловушка аутентичности. Человек думает, что его эмоциональная реакция важнее всего остального, следовать своему состоянию, а не делать дело. Фильм «Дьявол носит Prada» 2006: отложить эмоционально насыщенное восприятие, чтобы сделать дело.
# Путь '''в эмпатию'''. Почувствовать другого через резонанс. Почувствовать, что с ним и придумать, какой совместный ход можно сделать. Не свою эмоцию навесить, а через вопросы или иначе попробовать понять. Человек умеет это делать неосознанно. Но можно воспитывать как компетенцию, психологов этому учат.
## Фильм «Предел риска» – жеский 1:1.
## Ким Скотт «Радикальная откровенность». Не умалчивать, а открыто говорить. Прямота + Забота. Прямота + Ярость – Агрессия, а Забота + Умалчивание – Разрушительная эмпатия. И есть Умалчивание + Ярость = Манипуляция.
# Системное влияние, лидерство – эмоционально принять, чтобы пошли. Приведен ряд – Стив Джобс и другие, переупаковка эмоции к эффекту.

Что осталось за бортом.

# '''Способы осознания проживания и интеграции эмоций'''. Что делать, чтобы остаться энергичным и не схватить психосоматику
# '''Проблема аутентичности''': как отделить собственные эмоции, несущие смысл, от наведенных чужих
# '''Усталость от рациональности''' часто влечет уход в магию, мистику и другие странные практики, обещающие серебряную пулю, но не дающие ее, зато выращивающие чувство собственной значимости: «ой, мои чувства значат для всего человечества».
# Прямое влияние на поведение с помощью эмоций: можно ли делать, в каких случаях будет win-win.

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

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

== Мария Седяева. Гибкое анимационное производство: такое возможно? ==

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

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

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

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

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

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

Но инвесторы занимаются документальными фильмами, про мультипликацию не в курсе, сказали «ты же умеешь – делай». Задача – 44 минуты за 2 года, а раньше 5 минут за год. Было понятно, что одна не справится, даже с друзьями, нужна команда. И тогда вопрос: как управлять, как передать замысел. Ведь придуманное – в голове, а в голове – каша, с передачей проблемы. Она из Екатеринбурга, и там нет опыта. Получается, надо расписать план на два года, понять кого надо нанимать, как успеть. А еще риски: сделали 44 минуты, собрались – а вдруг отстой получится. И что? выпускать плохой фильм?

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

Неожиданно пришло спасение. Книга Джесси Шелл «Геймдизайн», помимо гейм-дизайнерских штук рассказывает, как вести проект. Там очень ценное правило 50/50: '''любой проект планируешь так, будет есть половина времени и половина бюджета''' – тогда уложишься. И еще она узнала, что есть agile. Прикинула его на арт, вспомнила преподавателя по рисунку: должна рисовать, что в любой момент тебя можно остановить – будет произведение искусства. Выбрала scrum – он итеративный и способствует обучению команды, а это важно, когда нет опыта. Промежуточные демонстрации и постоянный поиск, проверки результата – подходит для решения творческих задач, когда нужно много пробовать.

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

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

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

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

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

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

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

После первой серии стало понятно, что получается, команду увеличили. И перешли спринты по 2 недели: серия делится на 3 акта – 3 спринта, потом спринт – серия целиком, и 9 неделя – приборка. Самое сложное – не дожимать на втором спринте то, что не успели в первом акте, а делать дальше, оставить доводку на конец, хотя сделано 80%. К 4 спринту есть список доделок – его приоритизируешь, отделяешь что важно фильму целиком, а что – перфекционизм. Получается не совсем классика скрама: но по духу – похоже: есть общее согласие, что серию таким образом можно сделать, и она на акты разбита разумно, при этом первые три спринта получается переменный скоуп, часть остается в доработки, а в четвертом идет честное планирование с оценкой приоритетов доработок. Переработок не допускали, если бы было понятно, что надо очень много доделывать – делали дополнительный спринт, такое бывало.

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

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

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

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

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

Как убедила команду убедила? Ей повезло – команда работала с ней раньше, они друг друга знали, и все они сразу после университета, у них нет шор. Они приходили на просмотры, вдохновлялись, а продвижение вперед давало уверенность в результате, успокаивало . А люди со стажем 5-10 лет приходили, смотрели на то, что внутри – и уходили – так не работают. Из зала была реплика; «Вы первый человек, который говорит, что скрам – успокаивает».

Пока была одна команда – было планирование во вторник, среда-пятница дейлики утром, а в конце 2 часа на просмотр и ретро. Потом ретро стали раз в месяц, а потом – по окончанию серии. По командам – планирование внутри каждой команды, а просмотры – общие. Дейли – онлайн.

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

Все ли остаются в команде? Не все, скрам-мастер в середине проекта решил быть продюсером. Но вел до конца. Может, ему надо было больше помогать.

== Алексей Рахманов из FUN&SUN. AI на службе техлида ==

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

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

Что они пробовали и используют?

* Баба Нюра – сканирование на инъекции и советы, если хотите с чего-то начать – то именно с этого. Большой проект подключают по кусочкам, чтобы пролезло в ограничения
* Автотесты ИИ пишет, но их надо доводить
* Реализация по Фигме, если просишь весь экран, получается плохо. А вот по отдельным блокам экрана реализует гораздо лучше.
* Агенты. Мультиагентская схема: один пишет, другой проверяет и они друг друга мучают

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

Как они начинали? Сначала – был интерес. В моменте щелкнуло «давайте сделаем» – и выяснилось, что много человек пробовали. Сейчас 25 вовлеченных, а 10 человек взяли и сделали. Попробовать развернуть – 2-3 дня, это вообще ни о чем: развернуть, поднастроить flow.

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

== Анатолий Дробков. Как продукту работать с RnD и добывать Technology Value ==

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

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

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

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

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

'''Конвейер''': Гипотезы – Отбор и ранжирование гипотез (результат vs ресурсы) – Проверенные гипотезы (успешные и не успешные).

'''Решение для планирования''': '''Fixed Effect Planing''', Берем 1-2 разработчиков на некоторый срок 2-4 недели, и они проверяют гипотезы. Если найдут хорошую гипотезу – будет успех, если нет – потеря ресурсов. Еще может быть вариант, что нашли перспективную, но надо доводить, и оценка доводки уже ясна.

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

Но! '''Нельзя оценивать результат таким же образом, как и для фич с предсказуемой разработкой''', Потому что высокая степень провала по проверке – особенность R&D задач. Есть два вида комитментов: на разработку и на R&D, где мы гарантируем проверку набора гипотез, и можно еще поощрить успех, если он получится, но не снижать оценку, если успеха нет.

'''Презентация и оценка результатов исследований'''. Разработчики часто говорят «пока ничего не нашли, надо еще месяц». Ситуация не прозрачная. Как понять, стоит ли продолжать разработку. Минимальный чек-лист: сколько гипотез проверено, хорошо ли оцениваем время проверки (по проверенным).

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

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

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

* Team capability – какие гипотезы умеем проверять и как быстро
* Technology capability – какие технологии понимаем и можем применять
* Technology value – по уровню пользы, по тому, куда роют конкуренты, куда идет наука

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

Кейс: две команды, одна прекратила разработку, вторая – оставила 2 FTE. Но поменялось распределение пользователей, фича стала востребована – команда выиграла.

'''Люди в команде R&D должны быть такие, чтобы их не демотивировало отсутствие внедрения'''.

'''R&D – это не пылесос денег и ресурсов, а возможность получить новые возможности'''.

== Митя Кожевников из Mindbox. Что происходит, когда 250 человек знают зарплаты друг друга ==

C опытом компании Mindbox я знаком минимум с 2018 года, когда слушал доклад Александра Горника на AgileDays о том, как они два года шли к открытым зарплатам. А в 2019 он выступил там же с провокационным тезисом: «Новый социальный контракт: в обмен на искреннюю работу на цели компании, она должна обеспечивать сотрудникам условия для счастья на работе – не стесняйтесь требовать выполнения этой части контракта», при этом счастье оценивается сотрудником субъективно. И это была фиксация нового тренда, который с тех пор развивается. Поэтому мне очень интересно послушать, как живет компания сейчас, как устроена система. Тем более, что в прошлом году в компании была реорганизация и вновь вернулся CEO – несколько лет компания жила без него.

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

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

Началось все с веры Александра Горника, со-основателя и директора Mindbox, в то, что '''для постоянно растущей выручки сотрудники должны быть счастливы'''. Выручка – понятно, а что такое всеобщее счастье?

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

Принципы Mindbox.

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

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

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

Карточку делаешь сам, руководителя у сотрудника нет, есть ведущий, но с ним не надо согласовывать. Но он может наложить вето так же, как все остальные.

На этой доске лежат все карточки, так что можно посмотреть не только кто сколько получает, но и всю историю зарплат сотрудников – она открытая. А по текущим зарплатам есть отчет.

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

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

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

Но нужно, чтобы то, что ты делаешь, было интересно не только тебе, но и команде и компании, и надо найти дело на пересечении всех трех интересов. Сейчас он выступает с докладом: ему интересно сделать доклад, команде – найти сотрудников, а компании – пиар.

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

Откуда берем то, что пишем на карточку повышения зарплаты? Цель Mindbox: '''полезный маркетинг без спама''', она – наружу. Есть стратегия: как будем идти к цели в ближайшие год-два. И есть оценка команд: как поработали на предыдущей фазе. Руководство формирует стратегию, команды уходят думать над тем, что будут делать в ее рамках – получается OKR, в котором ищут баланс – компромисс амбициозности и реалистичности. И это – план на 6 месяцев.

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

'''Минусы системы''', которые он видит. Команды у них большие, 15-20 человек, трайблы. И '''чтобы войти – надо «завалить буйвола»''' – показать, что ты соответствуешь ожиданиям. Ты зарплату видишь. Приходит архитектор на большие деньги. Ему на онбординге рассказывали про буйвола. Но он сказал, что будет по своему – попробовал принять кучу горизонтальных решений. Часть удачно, пришло, а часть – нет, он не смог продать, команда в цели не приняла, и предложения развалила. И он покинул со словами: «это хаос, я ожидал свободы, а тут убеждать надо». Это – не единственный случай, но и удачные – тоже есть. Это не для всех.

Что получается?

* '''Стабильно растущая компания''' – 30% в год.
* Высокая норма управляемости: 14+ на менеджера.
* Маленькая текучка – среди тех, кто завалил буйвола.
* eNPS не высокий, 41: ты понимаешь, что подходит не всем, у него есть хорошие знакомые, которым он не будет рекомендовать компанию, потому что им не подойдет

Резюме. '''Открытые зарплаты – не самоцель, это часть более сложной конструкции'''.

'''В ответах на вопросы'''.

* Отношение к тем, кто накладывал вето – не токсики. Наоборот, говорят «не побоялся ветировать».
* Есть грейды и вилка в них. Если кто-то получает больше на 5 тысяч за то же самое, и тебя это волнует – повысь себе, в чем проблема.
* Если приходит человек, он в рынке, а у других ниже. Они не хотят. И им приходилось помогать людям обосновать повышение зарплаты. И есть еще индексация.
* Проблем с кэшфлоу у компании не было, доходы растут больше зарплат, все видят все финансы, а не только зарплаты, и учитывают это.
* Если команда отстает от зарплаты на рынке вдвое, то, вероятно, менеджер от своих сотрудников получит развивающую обратную связь, и ситуация изменится.
* Вопрос: психологи не советуют сравнивать с другими, а с собой, а эта система провоцирует сравнение с другими. Ответ: Да, отчасти это так, но когда ты карточку заполняешь – ты как раз сравниваешь себя с собой в прошлом. От себя замечу, что тренд на сравнение с собой, а не с другими пошел из работ с детьми «с особенностями развития», и распространился на всех – подумайте об этом…
* Повышать зарплату в команде, где OKR не достигается – много сложнее по аргументам. А если достигается – то легче. Люди, которые берут заботу о OKR команды – будущие лидеры.
* Если хочешь контрофер – тоже можно завести карточку на зарплату, где описать ситуацию. А дальше – команда может ветировать или пропустить, бывают оба варианта.
* У большинства премия у них маленькая, используют оклады. Но есть конкретные договоренности по отдельным ролям, и они тоже публичны на той же доске: на карточках есть условия и размер.
* Нет задачи постоянно бежать, есть ребята, которые просто подстраиваются. И в собеседовании с конкретным кандидатом, мы учитываем позицию, на которую идет человек. От джуна – ждем, что станет мидлом. А если уникальный эксперт, например, data science – то рост не требуется.
* Повышение – не за компетенции, а за результаты: как четко идет, сыплются баги и так далее. Качество кода – обратную связь дадут из проф.сообщества, peer-контроль через соседние команды.
* Карточка увольнения – на ту же доску, обычно от менеджера, и дальше ее могут ветировать, свое workflow.
* От менеджеров хотели избавиться, был такой этап. Оказалось, что менеджмент – компетенция, для которой не у всех потребность в развития. И получались команды экспертов, в которых пропало взаимодействие с людьми, люди бегут, но недовольны. Кстати, это согласуется с опытом booking.com, о котором рассказывал на Teamlead-2018 Георгий Могелашвили: в командах без тимлидов операционка идет хорошо, а вот развитие сотрудников провисает.

Отмечу, что способ назначения зарплат и открытая информация о них – разные аспекты. Кому тема интересна, хочу дать ссылки на видео, в их описании есть ссылки на презентации. А у меня эти и другие кейсы описаны [https://vc.ru/hr/131904 в этой статье].

* [https://youtu.be/a1rVPIXqaDU Выступление Александра Горника на AgileDays-2018] про самоуправление и открытые зарплаты
* [https://youtu.be/-ntd7-QlelY Выступление Александра Горника на AgileDays-2019] про счастье
* И на AgileDays-2016 был интересный доклад Станислава Сажина [https://youtu.be/RSVub5m-3DM «Зарплату мне назначают сотрудники»] – как компания столкнулась с форс-мажором, для выживания в кризис сделали открытые зарплаты – а потом им понравилось и они оставили систему

== Андрей Волков из TSQ Consulting. Кто плохой и несговорчивый: начальник или… Я? ==

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

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

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

Когда попытки решения конфликта не имеют перспектив?

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

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

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

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

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

И стреляют нормы общения. Это американская компания, где good – надо работать, fine – хорошо, а bad – увольняйся. А тут поток bad, но при этом – продолжай работать. Еще она путала радикальную прямоту и хамство, вернее, называла свое хамство радикальной прямотой и гордилась этим. Радикально не совпадает культура и стиль общения, он привык, что голос не повышают.

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

Требование – быть на рабочем месте с 9 до 17 по Нью-Йорку, и если не застала на своем месте – уволим. Со мной все так работали. Все мягкотелые, а я одна могу сказать правду в лицо. Он поговорил с коллегами: руководители из Индии относятся к подчиненным как с низшей касте. То есть это нормально для нее.

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

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

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

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

Вопросы себе «Выполняю ли я указания начальства?», и ответ: «нет, я планирую работы, а не делаю доку, которую она хочет». Понимаю, что ждут доку, но не делаю – саботирую работу. Следую ли я новым правилам, понимаю ли их? Начальница написала, а мы – поржали. Хочу ли на место начальника? Да, хочу – она это считывает и боится.

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

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

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

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

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

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

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

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

Как аргументировал команде, чтобы она не разбегалась? Говоришь «Мы – профессионалы, давайте делать свою работу. Она не адекватна, но мы – адекватны». Ему это позволило год поддерживать команду.

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

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

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

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

А про позиционную коммуникацию я не так давно прочитал крутую книгу – '''«Алгебру совести» Лефевра''', где вводится формализм описания ситуации и представлений о ситуации со стороны действующих лиц, учитывающий, что при этом эти представления могут быть правильными или неверными, и дальше разбирается способы принятия решений на базе ценностных, а не рациональных представлений. Потому что человек действует ,исходя из ценностей, и именно ценности говорят ему: тут действуй рационально, а тут – забей на это и следуй за чувствами или действуй правильно. Если интересно, у меня есть [[Блог:Максима Цепкова/2025-10-12: Лефевр. Алгебра совести|краткий отзыв]], но вообще с этой книгой пересказ не работает, надо врубаться.
{{wl-publish: 2025-11-21 18:43:29 +0300 | MaksTsepkov }}
[[Категория:Китай становится лидером]][[Категория:ИИ-агенты]]

Блог:Максима Цепкова/2025-11-25 - AnalystDays: как ИИ поменяет театр ИТ-абсурда и много другого

2026-07-24T14:51:48Z

MaksTsepkov:

{{Conf-Ref}}
Конференция [https://analystdays.ru/ru/program/137857 '''AnalystDays'''] для меня оказалась очень содержательным завершением темы ИИ, которая началась на [[SQAdays-2025b|SQAdays]] и продолжилась на [[Highload-2025|Highload]], [[ArchDays-2025|ArchDays]] и [[TeamLead-2025-Msk|Teamlead]] (ссылки ведут на мои отчеты). Основных векторов развития два: (1) '''приложения с ИИ научились технологично встраивать в ИТ-ландшафт''' наряду с обычными приложениями, переходя от DevOps к ML-ops и (2) LLM успешно работает как индивидуальный помощник или специализированный функциональный агент, и теперь пора переходить '''к проектированию команд и компаний в целом с участием ИИ-агентов'''.

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

Помимо выступления Димы, про использование ИИ рассказывали Reydan Yasar, Анна Гурова Дарья Рассказова, и все выступления были про уверенное использование, а не про эксперименты. А Елизавета Французяк рассказывала про создание продуктов на основе ИИ. Были и другие доклады, но я слушал только эти.

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

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

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

== Дмитрий Безуглый. От техписа к архитектору: ренессанс системного аналитика ==

В программе выступление называлось иначе, «Не техпис, а архитектор решений: тихое возвращение системного мышления», но смысл такой же. '''Вот логика рассказа'''.

# '''В будущем команды и компании будут смешанными из людей и ИИ-агентов.'''
# '''Для успешной работы ИИ агента необходимо организовать правильное наполнение контекста, в котором он работает.''' 

# '''Аналитики могут взять на себя эту задачу, став таким образом архитекторами компаний.'''

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

А теперь – подробнее. Сначала было несколько вводных о текущей ситуации.

* На заре своей работы руководителем проекта Дима придумал, как эффективно организовать работу, чтобы проект сделали в 10 раз быстрее. Начальство не оценило идеи: заказчик платит T&M, мы же столько бабла не получили! Он для себя сделал вывод: не кормите плохую историю.
* Последние два года аналитики стали получать больше продуктов и иногда больше разработчиков – но, наверное, так долго не будет, так что стоит смотреть на изменения.
* Продуктовый подход – когда в компании есть направление или инициатива, где '''бюджет на какой-то проект не ограничен'''. Если вам долбят мозг KPI и оценкой эффективности, то продуктовый подход рядом не стоял. А если делают нормы, сколько времени надо делать ревью документа – это уже нищебродство.
* Кто пришел за созданием классных решений? У кого корпоративный налог больше 50%? Когда прилетает чайка-менеджер и даже не говорит, что сделать, а просто страдает – ужас.
* В 90-е – 2000-е аналитики а архитекторы были взрослые, осваивали UML. Системный анализ тогда – о том, как делать так, чтобы потом не было больно при изменениях. Наступаешь – не говно и не грабли. И не надо обращаться к коучу или еще-кому из-за стресса…
* Реальность аналитика сегодня – героический техпис. Они пишут не нужные документы потому что, так положено. Да, есть люди, которые испытывают удовольствие, когда вычитывают документы. Ужас не в этом. '''Через 3 месяца после внедрения количество созданных проблем больше количества решенных'''.
* Современные акционеры сделали CIO персоной нонграта, потому что с 2000-х ИТ много просит и обещает, и ничего не выполняет. '''Вместо больших классных систем – куча переработанных хотелок'''. Если отбились от совсем треша. Jira-менеджмент и тикеты, ничего хорошего.
* Каждая строчка кода – маленький кусочек бетона в бизнес. Чем больше софта – тем сложнее изменить процесс. В 2014 было 70% интеграции, а сейчас 90% – попытка догнать уходящий поезд: станок законодательстве и идеи CIO. Бизнес становится медленнее и тупит, бизнес все медленнее принимает решения.
* Пришел Agile и сказал «с документацией задрали». В Райффайзене роль аналитика вычеркнули, 3 года аналитики были, а названия – не было. '''Agile – о том, что бизнес будет счастлив процессом, а не результатом. Если пациента нельзя вылечить, ему можно помочь.'''
* 70% фич – серый трафик поперек процесса, когда продукты доходят до разработчиков и просят что-то сделать, потому что объяснить зачем – не могут, не говоря уже о метриках результата.
* Накоплен долг: технический, организационный, когнитивный.
* Если enterprise achitect приносит архитектуру бизнесу ему говорят: «свободен, это было год назад, и вообще я и так все знаю».

Итого, '''мы имеем иерархическую систему, в которой бизнес, который никогда не видел клиента, ставит задачу разработчикам, которые не знают ничего о бизнесе компании'''. Аналитики в ней соединяют тех, кому ничего не надо (разработчики) с теми, кто ничего не понимает (бизнес). '''Иди туда и не спрашивай зачем'''».

Чем выше уровень – тем меньше спрашиваем «зачем». Сначала забрали у аналитиков смыслы, потом продукты забрали решения по бэклогу, AI сам напишет спецификации. Claude пишет лучше, чем аналитик с 1.5 года стажа. Пока ты поймешь, что аналитик нифига не понимает, а просто переваливает с одного на другого проходит полгода. Продукты за 15 минут с помощью ИИ генерят идеи, и спускают их аналитикам «вычитывай и сделай ТЗ».

'''Система мертва, а мертвое не может умереть'''. Поэтому в такой системе аналитики останутся.

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

Логичный второй уровень – мы только делаем ревью документа ИИ. '''Результат – потеря когнитивной самостоятельности'''. '''Как только компания действительно начала использовать ИИ, способность самостоятельно принимать решение атрофируется. За год.'''

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

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

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

'''Уровни управления''':

# Автоматизация – делегирование работы роботу
# Информатизация – управление информационными потоками
# Цифровизация (цифровые двойники) + AI первого уровня (личные помощники)
# Внедрение AI второго поколения – личные помощники и ИИ-агенты
# Внедрение AI третьего поколения – AI enterprise management, композитный workflow людей и ИИ

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

Сейчас мы помещаем в workflow ИИ-агентов. Они могут делать триаж запросов, или оценку ценностей или пинать аналитиков и разработчиков по задачам. Строим гибридный workflow из людей и агентов. В результате то, что раньше делали 2 отдела из 50 человек, может сделать один бизнес-аналитик.

Индивидуальные ассистенты. У OpenAI управление проектами работает хуже чем у Claude. Но в версии 6 они делают управление для руководителей компании, и это – другой фокус. Как iPhone когда-то сделал телефон для менеджеров, который не нужен технарям.

Чтобы это работало, надо проектировать пространство компании. Диаграмма контекстов и проектирование потоков данных для формирования контекстов. Для этого нужна роль системного аналитика 2.0.

У него уже есть 3-4 кейса, когда в компании используют '''вайб-менеджмент'''. Курсор, сотрудники 15-20 человек. Результат встречи – обнови задачи по проектам и добавь задачи, дальше ИИ дает изменения на ревью, можно внести или откатить. Информация из любых встреч распространяется по всем нужным контекстам – не надо быть на всех совещаниях. ИИ нормально решает задачи такого типа: возьми стратегический контекст и контекст отдела продаж, и проанализируй, что там не так. ИИ выдает адекватный анализ за 2-3 минуты. Так что большая часть запросов сверху-вниз «объясни мне как работает» можно убрать.

В презентации – схема контекстов вайб-менеджмента Димы, но рассказать он не успел

<ol start="0" style="list-style-type: decimal;">
<li>Миссия / Purpose</li>
<li>Управление: модель, структура, стратегия</li>
<li>Лаборатория (Discovery)</li>
<li>Люди (Орг.)</li>
<li>Получение ценности (CRM)</li>
<li>Продукты (Development и Delivery)</li>
<li>Партнеры (Экосистема)</li>
<li>Орг.компетенция и знание</li>
<li>Поддерживающие системы, инструменты, технологии</li>
<li>Маркетинг (visibility, brand, communication)</li></ol>

'''Возможные позиции аналитика в этой истории'''.

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

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

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

== Максим Цепков. Архитектура софта и бизнеса в сложном ИТ-ландшафте ==

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

Как обычно, я не пишу конспекта своих докладов. Презентация [Архитектура софта и бизнеса в сложном ИТ-ландшафте] – на странице доклада, она информативна.

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

== Светлана Доронина. Use Case для мэра, халяльный кешбэк и видеоприемы психиатра: любопытные задачи в работе аналитика ==

Аналитик сейчас очень часто сталкивается с нестандартными кейсами, и ему надо уметь погрузиться в контекст и найти решение. Светлана рассказала почти десяток разных интересных кейсов. Для работы она использует BABOK как базу знаний, BPMN для структуризации, а подходы agile и lean дают решение через итерации и эксперименты.

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

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

User journey map рисуем Этапы обращения. Не тривиально, что '''результатом этапа является эмоция пациента''', на выходе – облегчение. Для каждого этапа – точки касания, которые должны обеспечить нужный эмоциональный результат.

User story map – пишем все варианты, по опыту – бизнес их точно придумает, поэтому лучше иметь ввиду их наличие. А дальше – управляем через приоритеты.

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

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

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

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

'''Кейс-3. Оценка поведения пользователей для совместных закупок при заказе товаров стоимостью до 100 рублей'''. Совместные закупки до сих пор распространены в Сибири. Механика следующая. Организатор договаривается об оптовой скидке при определенном объеме закупки и организует ее, получая 16% комиссии. Люди подписываются на то, что хотят получить. Однако, требуемое количество может быть набрано не по всем позициям, поэтому ассортимент выясняется по факту, может быть меньше запланированного. И это проблема: покупатель заказал довольно много разного, а в закупку попала одна позиция за 30 рублей, например, пакетик конкретных семян, и ему за этими семенами надо ехать в пункт выдачи, да еще платить комиссию 25 рублей с заказа. Если бы в заказ попало все, что он заказал, то проблем бы не было, а так – ему не выгодно.

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

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

'''Кейс-5. Отказ от красных цитат на федеральном информационном квартале'''. Заказчик, федеральный канал, выкладывал новости на сайт в не читаемом виде: в статьях много цитат на красном фоне. Договорились провести исследования, A/B-тестирование с разными цветами. Оказывается, цвет читателю без разницы, если он не красный. А красный – раздражает, это сигнал опасности.

А еще был запрос разобраться: почему поисковики не выдают статьи? Оказалось, что большое число цитат, которое редакция считала преимуществом и требовала от журналистов, нарушает уникальность материала: цитаты копируют, а связки пишут свои. И читатели воспринимают статью с множеством цитат как copy-paste, а они хотят чтобы журналист проработал содержание. По результатам поменяли редакционную политику, число цитат снизили.

'''Кейс-5. Увеличение числа участников спортивной секции путем опроса'''. Секция скалолазания пришла с запросом: какие материалы положить на сайт, для новичков или опытных? Оказалось, что они получили грант на секцию, и теперь ее надо собрать, и сайт – одно из условий гранта. И она предложила провести опрос, нужно было не дорогое решение. По сути опрос информировал родителей про такую возможность: есть секция, она бесплатна, отвлечет ваших детей от телефонов, можно заниматься с родителями, и будут бесплатные летние лагеря. За счет опроса численность учеников увеличилась на 15%.

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

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

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

И в конце презентации – список различных инструментов.

== Reydan Yasar. От партнёра к катализатору: инструменты ИИ для бизнес-аналитика и владельца продукта ==

Докладчица – из Стамбула, Boğaziçi University. Сейчас есть много ИИ-инструментов, полезных в работе аналитика и product owner. И в выступлении было их системное представление. Инструменты поделили по способам вклада в работу: Partner – Catalyst – Connector, и для каждой фазы работы указали, какой вклад может быть внесен ИИ, в какой роли играет ИИ.

Фазы работы тоже интересны, они '''формулируются как ответ на вопросы''', и мне кажется такое представление любопытным.

* Why – changing business expectations, need for speed, здесь места AI нет
* Who – AI as Connector, bridge between the people, teams and systems
* What – AI as Partner, assists in day-to-day work step
* How – AI as Catalyst, accelerate creativity, speed and exploration
* Technical how – AI as Partner and Connector, technically connects into process, data flow and tool integration

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

* Partner: Elicit, perplexity. claude ai brainstorme tool
* Catalyst: POwerBA.ai – требования и flow, StoriesOnBoard, DALLE, Figma story map
* Connector: SpinachA – recording meeting. Notion, Miro, Dovetail

== Анна Гурова из 2ГИС. LLM: Анатомия цифрового болтуна ==

В выступлении был исторический обзор развития LLM и его внутреннего устройства.

Отмечу, что такие обзоров я слушал несколько, авторы выделяют разные реперные точки развития. У Анны были следующие.

* 1960-е. Розенблат персептрон. На вопрос «идти ли гулять» выдает ответ по состоянию погоды с весами. Было много лабораторий – это мечта о будущем. Но результаты очень ограничены, даже с ИЛИ не справляются. И развитие остановилось.
* 1980-е – метод обратного распространения ошибки при обучении: получаем ответ, сравниваем, и затем коррекция весов в обратную сторону по цепочке.
* 1990-е – распознавание банковских выписок и чеков. А потом – игровая индустрия, игра за персонажей. И так ряд других направлений. Но последовательная обработка контекста была ограничением.
* 2017 – архитектура трансформера, обработка контекста целиком параллельными потоками. Входные данные – любые. На этом основаны современные LLM.

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

Как LLM строит ответ на вопрос: «будет ли котенок играть с мячом?»

* Преобразует вопрос в токены, у каждой есть словарь. BPE, WordPiect, SentencePiece.
* Embeding – преобразование в векторное пространство. Расстояние между векторами определяется тем, что встречалось рядом. Котенок – Пушистый близко, Котенок – Нефто далеко. А вот Котенок – Черный – близко, и Черный – Yanm – еще ближе. Word2Vec, GloVe – статические модели. Learnable Token Embeding – коррекция векторного пространства через контекст. Если котенок – это наш логотип, то мы этому обучаем модель.
* Positional Encoding – разметка последовательности, в английском это важно. Итого, '''из вопроса получили набор векторов, где каждый токен в своей позиции'''.
* Трансформер получает вектор и преобразует его: Attention → Residual+Norm → Feed-Forming.
** Attention – как токены-слова влияют друг на друга, что будет, если убрать
** Residual connection – остаточная связь, на каждом шаге проверяем, что смысл не утерян.
** Normalization – убираем все лишнее из обогащенного
** Feed-Forming – обогащение смысловыми блоками, применяется к каждому действию. Котенок – субъект игры. Пример API^ собрали со всех пожелания, проверили – не потеряли ли смысл, обогатили тем, что сказали, доработали контракт, проверили – не потеряли ли суть, пошли на следующую встречу
** Идем циклично по слоям, пока не закончится, не останется несколько векторов
** Выбираем следующий вектор: максимальный вес, или ядерный – случайным образом, или как-то еще.
* В результате получаем развернутый ответ из всего, что оказалось рядышком.

Зачем это нужно понимать аналитику?

# Осознанно писать промпты и общаться с LLM.
## Модель понимает структуру, списки, и чем лучше задаете структуру – тем лучше модель поймет.
## Векторы – если используйте слова в специальном смысле, терминологию – модель не поймет. Задайте глоссарий.
## Модель усложняет смысл каждого слова отдельно. Если нужен json – напишите json.
## Помним про ограничения контекста. Если у вас очень большой объем текста – не впихивайте сразу. Если надо проверить договор, то запихнули целиком и спрашивают про платежи. Надо сфокусировать, например, на пункте три – про платежи. Делим на чанки.
# Контролируем риски.
## Галлюцинации: используй правила отказа, проси источники и цитаты из них. LLM по умолчанию идет вширь и вглубь, они выдумывают ГОСТы, если просишь выдать, а его рядом нет. Просить отказ надо явно.
## Устаревание данных. GPT-4 ничего не знает про GPT-5. Проверяй дату среза, используй RAG, добавляй актуальное в промпт.
## Потеря контекста: делим на чанки, используй резюме контекста и обновлять промпт.
## Ошибки интерпретации: добавляй примеры и антипримеры, делим задачу на шаги. Проси пошагово написать, что будет делать, а потом – попроси работать по этим шагам.
# Выбираем подходящие модели.
## Что я хочу? Instruction tuning, Generation, …
## Что важнее: точность, скорость или стоимость
## Длина контекста: context window и RAG integration
## Безопасность

'''LLM отвечают так, как будто живой человек. Но это не так. Она не думает о смыслах, так, как думаем мы, у нее нет ни здравого смысла, ни богатого личного опыта'''.

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

Что будет с приходом LLM? Многие роли поменяются. Но как – неясно. Но мы найдем место и адаптируемся…

Анна – амбассадор ИИ. Использует для валидации требований, проверки орфографии, создания тест кейсов, описания API. Примерно половину задач отдает LLM, потом проверяет и доводит результат. Не использует LLM, когда задача в узкой области или касается 2GIS процессов – надо передавать много контекста.

== Дарья Рассказова. Как с помощью ИИ провести обследование и сбор требований в новой предметной области ==

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

В состав ИИ-помощника входят: '''OpenWebUI''' – интерфейс, '''Ollama''' – запуск моделей, '''OpenRouter''' – маршрутизация, '''LiteLLM Proxy''', '''MCP Atlassian''' – доступ моделей к корпоративным источникам в confluence, это их внутренняя разработка. Система работает локально, но может обращаться к внешним LLM и API.

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

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

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

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

Подводя итог, ИИ дал не только инструменты, но и повод пересмотреть процессы. Не просто убрать рутину, а позволяет работать более качественно. '''ИИ работает не за нас, а вместе'''.

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

== Елизавета Французяк из Гринатом. От идеи до эффекта: как аналитики превращают гипотезы в ИИ-продукты ==

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

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

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

Поэтому сделали первый этап быстрой проверки гипотезы на практике. И для этого надо еще сформулировать критерии успеха!

Workflow получился из двух частей: сначала Гипотеза: Формирование → Исследование → Оценка результата, а уже затем Проектирование → Разработка → Тестирование → Поддержка.

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

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

Дальше идет исследование и разработка прототипа. Для оценки резюме использовали вероятность что кандидат дойдет до конца воронки. Это первый этап работы рекрутера – ранжирование кандидатов.

Прототип готовят так: data sciencetist выбирает модель машинного обучения (временные ряды, кластеризация и т.п.), для нее готовят данные и загружают. Это дешевле проекта, хотя и не мгновенно, занимает 2-4 недели, а в сложных случаев до 3 месяцев. Но это все равно не полный проект, который предусматривает настройку потоков данных, дообучение и так далее.

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

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

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

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

== Nikita Taskin и Anastasia Ilyina. Постанализ юзкейсов, или как спроектировать непрерывную ABAC-авторизацию UI и API ==

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

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

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

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

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

И появился социальный логин и делегирование проверки прав провайдерам, Policy engine, которые предоставляют набор прав пользователя. В 2010 концепция zero trust: явная проверка в каждом запросе, непрерывная авторизация, наименьшие привилегии и предоставление о взломе – враг внутри и надо отследить аномалии.

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

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

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

Use case – рисуют карту. Список задач, создание задачи – команда и атрибуты, найти задачу, просмотреть, редактировать, потом заархивировать. Табличное и карточное представление.

Фронт и бэк. Чтение – бэк, а отрисовка карточки в зависимости от прав – фронт, но при запросе на бэк тоже идет проверка прав.

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

Взаимодействие фронт-бэк идет по таск-API Post-Get-Patch.

Для версии-1 – достаточно было проверить роль команды, а для get – фильтр по командам. Можно ли сделать API-авторизацию на API-шлюзе? Нет. У него нет данных. А еще могут подделать данные. А запрос данных – сетевые взаимодействия, хотя можно кэшировать. Что делать, чтобы идея выиграла? Сделать кэширование, query-параметры. Я, правда, не понимаю, как это спасает от подделки параметров вызова.

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

== Александр Федоров из Райффайзен. От недель к минутам: как DBT + Airflow перестраивают работу аналитика и ускоряют процессы разработки ==

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

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

Идея решения – сделать платформа самообслуживания на основе DBT+Airflow, которая позволит аналитикам самим доводить задачи до результата, сделать витрину данных для пользователя.

* DBT – инструмент трансформации данных. ETL – находим на источники, загружаем и обрабатываем, а DBT трансформирует уже загруженное.
* Airflow – оркестрация рабочих процессов. Выстраивается граф, вершинами являются задачи.

Бизнесу – быстрое решение. Аналитикам – быстрая проверка гипотез, простые конфигурации на yaml и не нужен python. Инженерам – фокусировка на инфраструктуре.

Под капотом.

* dag-factory. Генерация dag-файлов по yaml
* cosmos – интеграция dbt в yaml
* ruamel.yaml – импорт сложных конфигураций

А чтобы прод не лег от тяжелых запросов, модели делают на предпроде, а перед выводом в прод – review.

Решенные проблемы

* несовместимость dag-factory и cosmos – хотя делала одна команда. Расширили своим парсером.
* большое количество дублирования и сложность файлов – механизм якорей в yaml чтобы выносить

Шаблон YAML – ключевой момент для описания yaml-конфигурации. И визуализация.

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

== Наталья Должкевич из Райффайзен. Критическое мышление: как не превратить анализ в драму ==

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

Ты строишь продукт, а получается монстр. Чем умнее человек, тем больше рисков сделать ошибку, если не умеет мыслить критически. Приходят: кнопку сделать зеленым, потому что я так думаю. А потом конверсия упала… Надо уметь отделать личные мнения от аргументов. Делали систему, в ней 12 полей у каждого контакта. Оказывается, большая часть пустые – если бы запросила данные, то не потратили бы кучу сторипойнтов.

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

Когнитивные искажения. Мозг действует по шаблонам и дорожкам, и делает это через искажения. Об этом был ее доклад на AD-19.

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

'''Приемы''': смена ролей, три глупых вопроса (что такое CRM, какова цель продукта), назначение антилидера-критика, реверсивное мышление (как сделать, чтобы на мероприятии никто не зарегистрировался), игра в заказчика, пять почему.

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

'''Критическое мышление начинается с вопроса «зачем»'''. Для нее это – главный вопрос.

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

А вот про чрезмерно сложные решения есть такая засада. Есть исследования командных ролей Белбина, и они показали, что Генератору идей, который как раз порождает сложные решения, обязательно нужен умный оппонент, чтобы избежать излишней сложности, обычно это роль Аналитик-Стратег. Обе роли могут совмещаться в одном человек (у меня это так), но оппонировать самому себе он не может, потому что для него собственное решение уже является простым. Хотя он может задать себе вопрос: «Как придуманным будут пользоваться?». Я в некоторый момент начал его задавать, и не только себе, но и другим людям, предлагавшим сложные решения. Если задаешь другим, то лучше так: «Мы сможем научить пользователей, или они будут обращаться к инженерам поддержки, а она – приходить к тебе, чтобы ты все настроил?», это помогает лучше, потому что Генератор обычно не хочет решать задачи поддержки. Подробнее про командные роли Белбина у меня есть [[Belbin|статьи и доклады]].

== Сергей Баранов. Как архитектура может обанкротить продукт и что с этим делать аналитику ==

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

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

Но архитектура – важна, Фаулер говорил, что архитектура – невидимый слон в комнате. Цена архитектуры – это не прямые расходы на лицензии и поддержку выбранной базы данных, это '''opportunity cost''' – какую выгоду мы не можем получить из-за выбранных архитектурных решений, какие ограничения она накладывает. Если выбрали Postgress – чем при этом пожертвовали? Выбрали супер-быстрый rpg, который в России знают только 150 человек – какие последствия для поддержки и развития?

'''Архитектурные решения часто дают невидимую сложность, которая несет когнитивную нагрузку''', и дальше разработчикам и инженерам сложно, у них стресс, который блокирует мозги – в результате они принимают плохие решения. Получается, что платим столько же, а ценности получаем меньше, потому что система сложнее. А дальше сложность накапливается, растет технический долг, идет деградация архитектуры. Есть оценки: объем технического долга в США 1.52Т$, а архитектурный из них – самый жесткий.

Еще одна цена архитектуры – '''cost of delay''', цена задержки поставки решения из-за сложности архитектуры. Ее тоже понимают плохо, потому что мыслят итерациями. МЧС, скорая, пожарные – те хорошо понимают. В ИТ цена пониже, но есть. Вывели фичу на неделю позже – и конкурент получил кусок рынка и возможность продавать дороже. Фича не вовремя – бюджеты выходят из под контроля.

Казалось бы, при чем здесь аналитики? Долг архитектурный – пусть архитекторы и разбираются. Но в SDLC есть analysis и design, там нет архитектора. А еще проблемы проявляются между testing и maintainance.

'''Где аналитик соприкасается с архитектурой?'''

'''Сбор требований'''. Аналитик фиксирует бизнес-задачу. Есть архитектурные ограничения. Правильный вопрос аналитика: можно ли реализовать требования в текущей архитектуре, как новая фича повлияет на существующие модули? Нужно формулировать требования в архитектрном контексте.

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

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

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

'''Добавление в бэклог'''. По задачам есть зависимость, в том числе – в архитектуре. И вполне может получиться, что из 100 задач 90 сделали, но ни один из 10 эпиков не готов.

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

Задача – построить стратегию разрешения зависимостей.

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

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

Реальный кейс. В одной компании постановки были проработаны на 120 задач, это 1.5 года разработки. Проработка новых – не имеет смысла. Что аналитики будут год делать? Они стали подключаться к тестированию и сдаче, и скорость выросла в 2-3 раза. И эти задачи сделали за 5-6 месяцев, и пошло по потоку.

'''Тестирование'''. Критерии приемки. И архитектурные проблемы. На малых данных ОК, а на больших потянет? Прод-данные, прод-поведение поиска… Сделали поиск по первым буквам – хорошо. А в продашн на каждую букву идет запрос к БД – база падает.

'''Новая фича'''. Нефункциональные требования (NFR) могут потребовать новых компонентов. Как фича может сломать архитектуру? В системе сделан шардинг по регионам, при этом маркетинговую компанию проведи только в одном, и нода упала от перегрузки.

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

'''Взаимодействие с архитектором'''. Аналитик пишет простое требование и думает “оно простое”, кнопочку изменить – а это по всем слоям изменить атрибут, и еще выгрузку поправить. Или фичей пользуются несколько пользователей, но она тяжелая и роняет работу остальных. Кейс года – для 3 сотрудников сделали отчет, который роняет БД на проде. В тестовом контуре все хорошо – там нет конкурирующих пользователей.

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

Новые типы решений – DSL, rule engine или новый COTS – какую технологию выбрать. Выбор между разными облачными провайдерами. Может, выбрав одного – мы получим недостатки у другого.

'''С чего начать аналитику?''' Барьер часто в том, что неясно о чем общаться с архитектором. Поэтому он в каждом месте вписывал вопросы. И объясняет архитектору: я хочу, чтобы мои требования вписывались в архитектуру. И сделать план по неделям. Для начала – встретиться, попросить рассказать, выявить долги, сделать реестр рисков. Потом выстроить практику совместного анализа требований (и у менеджера ее проявить), создать шаблон для ASR (архитектурно значимые трбеования), обучить команду.

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

Архитекторов мало, аналитиков – больше. Они часто конфликтуют. А будущее определяют они совместно, надо сотрудничать, потому что вместе – сильнее!

'''Вопрос-кейс'''. Есть требование, которое не лезет в архитектуру. Рефакторинг – 600 часов. Заказчик их платить не хочет, всегда за 50 часов делали – поверх старого. '''Ответ'''. Архитекторы планируют на годы, продуктовые команды – недели и месяцы. Была ошибка, или правильно, но давно. Накоплено много долга, управление арх.долгом – они известны, их можно встраивать в процесс. Построены они на принципах в agile-манифесте. Компрометация Agile – потому что его продавали как средство за 2 недели сделать то, что делали 2 месяца. Там про то, как не наращивать TTM. Он бы заглянул в Sonar-куб, и не накапливал новый, а при этом придется отдавать старый. И сделать точки расширения там, где требуется гибкость – и именно там делал иначе.

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

'''Вопрос: можно ли архитектуру?''' Архитектуру можно эффективно вынуть, у него был кейс: есть неделя извлечь знания из архитектора. Сделали воркшоп на 50 человек, в миро – быстрое восстановление архитектурных знаний. Для восстановления есть методика – у Сергея было выступление, оно записано.

== Татьяна Половинкина Цифровой колониализм мозга: как выжить в эпоху информационного цунами ==

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

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

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

* Зависимость от социального одобрения
* Страх что-то упустить (FOMO)
* Тяга к новизне, которую дает ориентировочный рефлекс
* Дофаминовые капканы

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

Что делать, чтобы этого не было? Есть простые практики.

* Солнышко в руках – от тревоги. Обнять себя и погладить, у каждого – свои точки
* Заземление: мы живем прошлым или будущим, а надо почувствовать реальность здесь и сейчас – она бывает прекрасна
* Замедление 4-3-2 – увидеть свое окружение: называем 4 предмета, которые можно увидеть, 3, которые можно пощупать и 2, которые можно ощутить (мягкое, скользкое)
* Жужжалка – зажать ушки и искать свой звук вибрации (нужно пробовать алфавит и разные гудения-жужжания) – он у каждого свой , и если найдешь – получаются интересные ощущения

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

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

[[File:AD2025b-Половинкина-Цифровой-аутизм.jpg|600px|Половинкина. Цифровой аутизм]]

Но вот если на инфографику всерьез посмотреть, как на способ диагностики аутизма, то становится весьма печально, потому что я увидел легкий способ '''навесить ярлык пожизненного заболевания практически любому ребенку'''. Реально. Я полез искать источники, и обнаружил эту инфографику в изданиях профессионалов: [https://znanio.ru/media/pamyatka_chto_takoe_autizm-42631 Рахматуллина Лилия Рамиловна. Памятка. Что такое аутизм?] (надо нажать «Картинками», чтобы посмотреть не скачивая), а в [https://infourok.ru/metodicheskie-rekomendacii-dlya-pedagogov-po-detyam-s-ras-2675077.html этом списке материалов] она на 3 слайде презентации Байкаловой Ольги Александровны, адресованного школьному психологу (второй материал в списке), при этом английский вариант этой инфографики тоже есть, и даже в стебном варианте, где одна из иконок заменена на «играет в minecraft». Поэтому мамы и папы, относитесь осторожнее к тому, что вам говорят психологи. Потому что учителя заинтересованы в том, чтобы вместо реальной работы с вашим ребенком, повесить ему ярлык сложного. Отмечу, что в 1930-е годы при переходе на массовое образование была аналогичная история: не слишком послушных или успевающих детей начали отправлять в спецшколы с особенностями развития. Тогда это пресек Сталин, заявив, что советскому обществу нужны здоровые дети, так что пусть учителя в школах делают свое дело, а не устраивают саботаж (цитата неточная и по памяти). А сейчас спасение утопающих – дело рук самих утопающих, вернее, их родителей.

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

Вопросы для самопроверки:

* Какую интересную книгу прочитали за последний месяц?
* Какая новая идея посетила за последнюю неделю?
* Когда я в последний раз останавливался – смотрел в потолок.

Книга Джеймса Клира «Атомные привычки». '''Основное – не ставить цель, а сделать вокруг себя систему, которая заставляет делать дело'''. Сделать привычку очевидной, сделать ее привлекательной (10 приседаний за тупление в канал), сделать легкой и сделать приятной. Информация отравляет мозг и душу, должна быть дозирована.

Цифровой детокс. Лагеря в лесу без телефона.

'''ИИ'''. Работа с ожиданиями. Вопли: LLM уничтожит способность мыслить. До этого тоже самое говорили про калькулятор. А Платон говорил: «мы разучимся помнить, записывая на бумаге». А про часы говорили, что мы разучимся жить в своем ритме, а будем подчиняться механическому прибору.

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

* Не надо переоценивать LLM. Искусственного интеллекта еще нет. С этим тезисом я не согласен: либо мы признаем за LLM наличие интеллекта, либо мы должны признать его отсутствие у большинства людей, потому LLM их превосходит, и я выбираю первое.
* LLM есть, и его надо уметь использовать: выживает не самый сильный или умный, а тот, кто может адаптироваться.
* LLM никогда не сомневается. Я не согласен, LLM оценивает достоверность ответа, и в ряде случаев продолжает поиск новых материалов, а не останавливается, то есть поступает аналогично человеку.
* Что бы LLM не выдал, именно вы проецируете это дальше, и ответственность на вас.
* LLM – для вас. Он хвалит и дает теплоту. Это верно.
* У LLM нет целей, нет мыслей, он не способен принципиально новый контент делать. А человек может оперировать символами и метафорами, формировать ментальные модели. Тут тоже не согласен: LLM может оперировать символами и метафорами, формировать ментальные модели, создавать новый контент не хуже человека – если ему поставить такую задачу. Задачу надо ставить, потому что LLM специально спроектировали без целей, у него есть одна предзаданная цель – продолжить разговор. А вот мысли у него есть, нет лишь активного режима внутренних размышлений.
* LLM не мыслит, а вычисляет, нет случайности. Это просто неверно, когда LLM выбирала самый вероятный ответ, то качество общения оказывалось ниже, поэтому там ввели специальный параметр, управляющий этим, который еще и настраивать в моделях можно.

'''Эмоции'''. Это очень рациональный механизм, который появился в ходе эволюции как способ выжить. Страх – избегание опасности. Гнев – движение к изменениям. Грусть – срубили деревья, а корни остались, вычистить пространство. Радость = благодарность: спасибо миру, солнышку, близким. Любопытство – поиск новых путей и возможностей. '''Эмоция – это энергия, эмоции – круто и здорово'''.

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

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

Важно повторять каждый день: качественно дышать, спать, есть, пить, двигаться. Замедляться и дальше бездельничать, получать качественный контент, завершать циклы стресса. '''Будьте куратором своей жизни''': что вы получите, листая ленту?

'''Любить себя? Нет, любовь – всегда про нескольких'''. Любить себя – уходить в одиночество, не надо.

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

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

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

'''Реплика'''. HR не смотрят на совместимость команд, и это боль. '''Ответ''' – нет, это не страшно. Да, есть тесты, можно организовать. Но она верит в двухстороннюю эволюцию команды: ты растешь в команде, и при этом команда растет в целом. И это хорошо. Не надо искусственно создавать хорошие условия. Я с этим согласен лишь отчасти: конфликты есть констркутивные, в которых мы движемся вперед, развиваемся и получаем результат, и деструктивные, где мы разрушаем себя, других и результат. Конфликты можно предсказать, оценивая совместимость, и HR должен позаботиться о том, чтобы конфликты были конструктивны и вели к развитию. Например, за счет того, что тимлид верит в эволюцию команды и умеет ее организовать. НО есть и другие способы.

== Анна Обухова. Сколько энергии нужно, чтобы быть аналитиком? ==

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

Для заинтересовавшихся другими выступлениями сразу напишу, что у меня есть сборка '''[[Анна Обухова и другие про нейрофизиологию в работе]]''' с моими конспектами, а на youtube поиск "Анна Обухова" дает много выступлений. На RuTube тоже есть, но меньше.

А вообще нейрофизиологи очень много узнали о работе мозга. А вот психологи не торопятся подвергнуть свои модели сомнению и пересобрать их с учетом нового знания. Меня это огорчало настолько, что пришлось попробовать сделать это самому, так родилась книга [[:Категория:Модель личности|Инженерная модель личности]].

А теперь – содержание выступления. К теме нейрофизиологии Анна пришла, когда работала в банке UBS: она руководила разработкой по ценным бумагам (security), у нее было 40 владельцев продукта и 60 команд. Идея в том, что мы работаем с умными людьми, рабочие станки у них находятся в головах, и если их настроить, можно увеличить производительность. Измерения говорят, что получаем 17% чисто на настройке мозга.

В организме есть 4 слоя энергии: внутри клетки, электрический, стрессовый, нейромедиаторный.

В каждой клетке есть митохондрии, и на мембране происходит выработка энергии АТФ, отрывается одна группа. Это – очень тяжелая молекула, на день нужно 40 кг. Поэтому запас клеточной энергии есть только на 5-6 минут, идет постоянный обмен и восстановление энергии в клетке. Расход обычно превышает восстановление, но восстановление быстрое. Устали на тренажере – отдохнули минуту-две – и готовы к следующему.

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

Мозг обеспечивает энергию на желание и действие. Упрощенная схема.

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

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

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

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

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

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

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

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

Вы получили плохой email, переживали – и теперь любой email – потенциальная опасность. Может быть более избирательно, не любой, а только от начальника или плохого клиента. Но это происходит еще до того, как вы email открыли. Миндалина говорит: энергия нужна на привычные действия. Бегать, орать, копать канаву будете быстрее, а вот думать – не сможете. При этом адреналин в крови распадается 15 минут, а вот у кортизола полураспад 1.5 часа, а значительные следы остаются сутки. И у вас все это время плохо работает голова. Быстро убрать Кортизол – не получится. Есть мышечные техники, но пока вы их делаете уже пришел следующий емайл. Так что надо успокоить себя и разжать эту причину, чтобы стресс не возникал.

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

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

Изменить из всего этого можно только уровень стресса. Определяют гаджеты по сердечному ритму – там разница биения. В теории можно по кортизолу, но его очень сложно надежно замерить, большие ситуативные вариации. У трубы дофамина есть сечение, и стресс показывает, сколько уходит на текущую деятельность, то есть не доходит до префронтальной коры. У Welltory есть более сложная модель, она выдает уровень стресса и отдельно энергию батарейки. Есть ресурсная модель человека, при этом не у всех размер батарейки 100%, в модели абсолютная шкала. Вот такой слайд требуемого уровня энергии получается.

[[File:AD2025b-Обухова-ДофаминЭнергия.jpg|600px|Обухова Дофамин и энергия]]

При этом есть ситуативные колебания. Человек сидит пьет кофе, у него 74% стресса, но ему нормально. А вот постоянно меньше 40% энергии – выгорание. Если энергии 42% и больше – человек смотрит вперед, строит картинки будущего в мозге. И чем больше энергии – тем дальше может отодвинуть. Планы на год – надо 60% энергии. Сидеть пить кофе, когда 60% энергии скучно: у человека пошли идеи, что бы такое сделать. А если сангвиник или холерик, то срабатывает сила сдувающая с дивана, и он бежит на две экскурсии подряд.

Что человек может в зависимости от уровня энергии?

* Для привычной работы на конвейере достаточно 20-25%
* Чтобы подлизываться к начальнику нужно 30-35%.
* А чтобы выдавать результат умственной работы, надо больше: в знакомых условиях – 35%, если условия – новые и надо адаптироваться – то нужно 40%, чтобы уверенно работала префронтальная кора.
* '''Уровень 45% – водораздел, на нем начинаешь понимать, что хочешь ты, а не только чего хотят от тебя'''. Не всем компаниям нужны сотрудники с уровнем 45+%, потому что с ними надо индивидуально договариваться. А ниже работают кнут и пряник, правда приходится разбивать задачи на достаточно мелкие кусочки, чтобы их понял крокодил.
* '''На 60% перестают бесить люди'''. До этого, если есть Вася, который лажает, то тебя лично оскорбляют результаты Васи, это личностный конфликт. На 60% мозг отделяет: есть Вася, он делает хрень, но это не конфликт меня с Васей, это конфликт меня с результатом, и человек может разобраться все.
* На 65% – появляются идеи, которых не было.

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

Добавлю тут, что после выступления мы обсуждали эти вопросы, и Анна сказала, что техника Worklife balance, колесо баланса требует 60+% энергии, для тех, кто уже устал она бесполезна. Спрашивать у утомленного человека, что он хочет бессмысленно, он хочет, чтобы от него все отстали.

Дальше выступлении Анна взяла профессиональный стандарт системного аналитика компетенции бизнес-аналитика от IIBA и выписала уровни энергии, требуемые для каждой строки, обязанности и IIBA. Для Junior достаточно 35-50%, но только там, где работа в освоенной области и с наставником. На освоение нового нужно 60+% И горизонт планирования у него месяц.

Среднее количество энергии офисного сотрудника – 33%, он не справится.

У Middle – кастомные процессы, а еще требуется, чтобы твои идеи воспринимались другими людьми, а это 55+% Получается профпригодность 55-60%, а для катомизации процессов 60-65%, и горизонт планирования год.

Компетенции старшего аналитика требует 60% энергии. Тимлидам, чтобы держать процессы, нужно 40%, для хорошего agile – 45%. Определение стратегии – 75% и горизонт несколько лет.

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

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

И в конце доклада – '''практики, как повышать и держать энергию'''.

# Общий смысл
# Работа со стрессам
# Вернуть дофамин – наполнить трубу

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

Вам может не действовать – ищите свою, таких практик много, и достаточно освоить пару, много не надо.

Как протащить энергию к префронтальной коре – модель AGROW (Action GROW). Там схема вопросов? которая обеспечивает движение, сначала смысл, потом переключение намерение-реальность.

# Что ты собираешься делать – какая задача?
# Частью какой большой цели она является?
# Как ты поймешь, что цель достигнута?
# Где ты сейчас (как ты)?
# Что уже сделано (как задача)?
# Что могло бы быть следующим шагом?
# Что будет следующим шагом?
# Когда начнем делать шаг?

Нельзя переставлять и выбрасывать куски. Вопросы 6 и 7 – похожи, но задаем два: если сразу 7, то может быть ступор, страх. Метод конфигурирует мозг, ч тобы начать делать задачу.

'''Актуализация результата'''. Я сделал задачу – и что, что я получил? Дает признание, что мои действия привели к моему результату – внутренний мурк, серотонин. Однократно – не заметно, 14 единиц, но на полдня есть эффект. А если 6 задач, то синдром горячей руки, состояние я офигенный, я справлюсь.

# Описание стартовой ситуации
# Перечислить все, что сделал (процесс, активный глагол)
# Описать результат
# Определить, зачем мне этот результат (как я его использую на благо себе)

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

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

Отмечу, что это – короткий вариант. В полном добавляется еще пункт «Как я могу рассказать это другим» – тогда задача превращается в часть личной истории и записывается в долговременную память. На AgileDays-2022 Анна рассказывала нейрофизиологию процесса, записи этого выступления нет, но есть мой конспект – по ссылки в начале раздела.

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

[[Категория:ИИ-агенты]]
{{wl-publish: 2025-11-25 19:47:25 +0300 | MaksTsepkov }}

ИИ-2041. Десять образов нашего будущего. Кай-Фу Ли и Чэнь Цюфань

2026-07-24T14:50:55Z

MaksTsepkov:

Опубликовано в Tg частями 09.12.2025 - 11.01.2026, я читал с перерывами. Посты по новеллам: [https://t.me/mtsepkov/1088 первая], [https://t.me/mtsepkov/1108 вторая], [https://t.me/mtsepkov/1109 третья] и [https://t.me/mtsepkov/1110 продолжение], [https://t.me/mtsepkov/1111 четвертая] [https://t.me/mtsepkov/1114 пятая], [https://t.me/mtsepkov/1115 шестая], [https://t.me/mtsepkov/1116 седьмая], [https://t.me/mtsepkov/1126 восьмая], [https://t.me/mtsepkov/1127 девятая], [https://t.me/mtsepkov/1128 десятая]
[https://www.facebook.com/mtsepkov/posts/pfbid04GcX4uZc3sdYkjrBSyizdQHoRJsAC4Bbt7vDYtG8siAhHYgoqM1zeNqun1wdMHApl Пост на FB о первой новелле]

= Первая новелла - ИИ требует жить по правилам=

{{:Блог:Максима Цепкова/2025-12-09: ИИ-2041 - первые впечатления}}

= Вторая новелла – политический пиар =

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

Общее впечатление, что '''социально-экономическая действительность романа в 2041 году не изменилась и примерно соответствует существующей''' – подтверждается. Может, для авторов это логично, ведь концепт Фукуямы про конец истории на западе принимают всерьез, а авторы в значительной мере несут американскую культуру, хотя по происхождению китайцы с Тайваня. При этом '''темпы развития ИИ''' в представлении авторов, на мой взгляд, '''сильно занижены'''. Понятно, что роман говорит о том, что более-менее вошло в повседневную жизнь, но развитие смартфонов хорошо показывает, что для широкого распространения не требуются десятилетия, а достаточно года-двух. Сотовая связь действительно развивалась медленнее, там было нужно вышки везде поставить, а для ИИ это не нужно, базовая инфраструктура интернета есть. Но представления о низких темпах развития ИИ, кстати, соответствует времени написания книги – 2020-2021 годы, когда ChatGPT только появился. Быстро развиваться и умнеть он действительно начал позднее, что вызвало письмо сотни ученых с призывом остановить исследования из-за непредсказуемых последствий. Впрочем, сейчас об этом призыве, по-моему, забыли.

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

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

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

Чем-то этот сюжет напоминает Обитаемый остров Стругацких (только без Странника), где тоже правит анонимная группа. В реальности такая штука тоже встречалась – красные кхмеры Камбоджи. А еще ИИ тут – лишь новый инструмент масс-медиа. У Марка Твена есть хороший рассказ про современную ему политику «Как я баллотировался в губернаторы» – технологии отличались, а суть была та же.

= Третья новелла – воспитание и образование =

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

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

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

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

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

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

Меня тут недавно в обсуждении на канале попросили ссылок про превосходство ИИ-психологов, и один из читателей быстро [https://www.forbes.com/sites/dimitarmixmihov/2025/02/17/a-new-study-says-chatgpt-is-a-better-therapist-than-humans---scientists-explain-why/ статью с подтверждением] и [https://www.psychiatry.org/news-room/news-releases/new-research-human-vs-chatgpt-therapists статью с опровержением]. Как бы тема не однозначная. Только в статье с подтверждением – нормальное исследование слепым методом, 830 кейсов. При этом выяснено, что самые высокие оценки получили ответы ChatGPT, о которых пациенты подумали, что им отвечает психолог, самые низкие - ответы психологов, приписанные ChatGPT, а остальные - посередине. Статья в Forbes, но там в начале есть ссылка на исследование, в котором все детали. А вот статья о превосходстве людей - это просто опрос психологов, где они должны были сравнить два конкретных описания одного кейса - от ChatCPT и от человека, и не написано, что они это делали в слепую, так что вероятно они знали, кто автор. Это - фигня, а не репрезентативное исследование, с моей точки зрения.

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

= Четвертая новелла – вечный ковид =

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

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

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

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

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

= Пятая новелла – индустрия игр =

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

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

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

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

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

= Шестая новелла – роботакси =

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

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

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

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

Любопытно с экономикой. Авторы в разборе говорят, что 75% стоимости такси сейчас – зарплата водителя. Возможно, именно под это были бизнес-планы. В Штатах (Waymo) сейчас роботакси стоит дороже, чем с водителем, а вот в Китае, в Ухане, где у Baidu больше всего покрытие и поездок цена действительно ниже на 20-40%

= Седьмая новелла – физик-террорист =

Седьмая новелла – это трэш. Гениальный физик решает отомстить всему обществу и создает квантовый суперкомпьютер, которые ломает закрытые ключи bitcoin, похищай кучу денег, запускает рои дронов размером с небольшую птицу, которые должны целенаправлено отстреливать персон из элиты, а также компьютерных профи, и взрывает две атомных бомбы в стратосфере, чтобы электромагнитный импульс погубил всю электронику планеты. И все это из-за одной травмы, правда серьезной: в Калифорнии вспыхнул сильный пожар в лесах, в котором погибли его жена и дочь, он их почти спас, и все сказали «пожар – природный», хотя на самом деле там деградировали высоковольтные линии и это послужило причиной. Его героически останавливает ситуативно сложившийся союз полиции и хакеров, у которых он спер биткоины (которые они раньше сперли у других), но остановить не могут. Хотя, возможно, бомбы не взорвутся. В общем, классический боевик, но вот логика сюжета – отсутствует и куча технологических накладок, впечатление, что авторы не понимают технологий, о которых пишут, или сознательно вводят в заблуждение читателя. Разбирать детали – не буду.

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

При чем, похоже, гражданское применение из-за безопасности останавливать не собираются, в 2024 компания EHang в Китае получила разрешение на продажи беспилотного воздушного такси и начаты продажи. Заявка была в 2020. Кстати, в шестой новелле про беспилотники о таких такси не говорят, только про автомобили – а именно тут реальное изменение будущего.

= Восьмая новелла – безработица =

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

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

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

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

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

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

= Девятая новелла – счастье =

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

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

В общем, у меня от прочтения возмущенная печалька по поводу американского образования. Авторы явно полагают, что актуальная модель счастья – это пирамида Маслоу, созданная в 1940-е. На нее есть ссылки и в новелле и в разборе, принц работает на нижних уровнях, а сестра говорит про следующие. Со времени создания модели прошло 80 лет, и наука не стоит на месте! Есть всемирно признанные модели, например, модель Шолома Шварца, который выделил 10 образов счастья в 1992, то есть больше 30 лет назад, она развивается, проводятся исследования по всему миру, количество образов дошло до 19. О ней и о других можно было запросто узнать пять лет назад, во время написания книги: спросить у тогдашнего ChatGPT или по-старинке, у Google. И при разработке компьютерных игр используются свои модели для удержания игроков, тоже описывающие разнообразие людей. Почему в новелле – уровень почти вековой давности понимания предмета?

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

= Десятая новелла – изобилие =

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

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

На этом – все. Если говорить '''о книге в целом''', то впечатления такие.

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

[[Категория:Книги]][[Категория:Общество]][[Категория:ИИ-агенты]]

Блог:Максима Цепкова/2026-03-29: ИИ не конкурент, а помощник и друг – китайский опыт (статья на habr)

2026-07-24T14:50:29Z

MaksTsepkov:

{{RightNote|[[:Категория:Китай становится лидером|Еще про китайский опыт]]}}

Подготовка к выступлению на AIconf о китайском опыте развития ИТ побудила серьезно проработать тему ИИ. В результате родилась отдельная статья, которую я сегодня опубликовал на habr: [https://habr.com/ru/articles/1016504/ «'''ИИ не конкурент, а помощник и друг – китайский опыт'''»].

[[Категория:Китай становится лидером]][[Категория:Статьи]][[Категория:ИИ-агенты]]
{{wl-publish: 2026-03-29 13:34:20 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2026-04-04: TechWriterDays-2026 - ИИ и DosAsCode

2026-07-24T14:49:58Z

MaksTsepkov:

{{Conf-Ref}}
В пятницу 27.03 заглянул на конференцию технических писателей [https://techwriterdays.ru/ru/program/137253 '''Tech Writer Days''']. Конференция двухдневная, но у меня получилось только один день, делюсь своими впечатлениями. Я на этой конференции первый раз, хотя это – уже третья конференция. Три трека, два дня. Я с удовлетворением хочу сказать, что этот новый проект Влада Орликова вполне успешен. Сообщество технических писателей получило свою конференцию.

[https://t.me/mtsepkov/1155 Пост в Tg]

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

Вообще вопросами организации документации в практическом залоге я занимался очень давно, в конце 90-х, когда еще не существовало вики-систем. Мы тогда для наших проектов делали систему ведения документации в разметке sgml (это предшественник html), которая позволяла вести документацию в текстовых файлах под системой контроля версий, а также собирать с одних исходных текстов word (rtf) для печати и гипертекст html-chm, который использовали как справку по системе.

Сейчас этот подход называется docs-as-code и является основным, хотя часть команд продолжает использовать вики-системы, а кое-кто по-прежнему предпочитают word. Впрочем, про word замечу, что основной вопрос не к команде проекта, а к заказчику. Если он хочет работать с word-файлами, да еще активно проходиться по ним в режиме редактирования, то doc-файлы наиболее эффективны. Вообще к выбору способа документации надо относиться прагматически. У меня по этой и смежным темам было выступление на TeamLead Conf [https://mtsepkov.org/ProjectDocs Управление знаниями: какие документы нужны и что в них фиксировать].

Тема '''docs as code''' – одна из основных на конференции, и я послушал пару докладов о современных средствах ведения такой документации – MkDocs и Hugo. И на одном из них увидел, что идет не просто изменение технических средств, а об изменении задач бизнеса по отношению к документации: документация превращается в информационный портал, бизнесу важно видеть метрики использования и проводить A/B-тестирование. А еще в одном докладе речь в нем шла о том, '''как дешево включать в документацию видео''' – современные технологии это позволяют. Заметим, что подход docs as code тут является рамкой: видео делают для маленьких фрагментов, где это востребовано, и обновляют по необходимости.

Отмечу, что среди выступлений про docs as code получилась забавная пара: Денис Лимарев, рассказывая про MkDocs, сказал, что его вдохновило на это выступление Никиты Груздева на предыдущей конференции, а Никита Груздев рассказывал, как они переходят с MkDocs на Hugo из-за требований бизнеса к возможностям тестирования A/B-тестирование документации.

А основная тема этой конференции для меня было '''использование ИИ'''. Я с удовлетворением хочу отметить, что, несмотря на кликбейтные заголовки о замене людей ИИ-агентами, содержание доклады вполне прагматично: '''люди оценивают возможности использования LLM-систем и включают их в рабочие процессы там, где это уместно'''. Я это отмечал еще на осенних конференциях [[SQAdays-2025b|SQAdays]], [[Highload-2025|Highload]], [[ArchDays-2025|ArchDays]] и [[TeamLead-2025-Msk|Teamlead]] и [[AnalystDays-2025b|AnalystDays]] (ссылки ведут на мои отчеты). И это – радует. Потому что еще летом такого однозначного впечатления не было, и прагматичные доклады перемежались с рассуждениями о полной замене людей и другими подобными темами, популярными в инфополе. Вообще, когда я в октябре был в китайских технологических компаниях (Baidu, Xiaomi, SenseTime и других) меня сильно поразила разница в отношении к ИИ там и у нас. Об этом я писал в отчете, а на днях опубликовал статью на habr [https://habr.com/ru/articles/1016504/ «ИИ не конкурент, а помощник и друг – китайский опыт»] с подробным анализом. Если тема Китая интересна, то в статье есть ссылка на отчет о поездке.

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

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

== Камила Мазаева из Альфа-Банк. Кому доверить ревью API — техпису или искусственному интеллекту ==

<blockquote>Ссылка [https://techwriterdays.ru/ru/talk/141082 Кому доверить ревью API — техпису или искусственному интеллекту].
</blockquote>
Реально доклад был о встройке ИИ в workflow процесса подготовки и публикации документации в качестве отдельного шага – промежуточного ревью, в ходе которого проверяется убирается ряд технических проблем. В результате разгрузились технические писатели, ревью которых стало узким горлом с ростом числа команд, а аналитики, которые у них готовят документацию, стали получать обратную связь за минуты, не ожидая, когда технический писатель освободиться, и это ускорило процесс в целом.

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

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

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

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

Промпт: роль – Техпис в банковской сфере с опытом больше 10 лет, глоссарий терминов, стилистический гайдлайн и конкретные задачи по проверке: орфография, пунктуация, json-схемы, соответствие между видами кодов (успех-ошибка и его описание). Он длинный.

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

И дальше сравнивали результаты для трех вариантов работы: только техпис, ИИ, и ИИ и техпис вместе. Метрики сравнения: граматика и орфография, читаемость (короткие предложения и простые слова), стиль и консистентность, полнота, скорость. Что получилось? Скорость возрастает 10-30 раз. Хорошо обеспечивается формальная корректность – орфография, пунктуация, забытые параметры, единый вид. Особенно важно – всякие английские слова, где люди часто делают ошибки. В презентации есть таблица.

Где ИИ уступает?

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

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

Примеры из практики.

* Успех. Быстро находит, что один параметр limit по-разному описан в разных методах.
* Неудача – литературно улучшили описание алгоритма сортировки от инженера, нарушив при этом содержание.

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

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

'''Ответы на вопросы''' в тезисном виде.

* Про модели. В альфа-ген есть разные модели, пробовали и температуру регулировали, но основной фокус все-таки на промпте. Дообучение – тяжело, промпта оказалось достаточно.
* Если брать публичные модели – Grok лучше GPT справляется. Но это – личный опыт, рабочие задачи они через публичные модели не решают.
* «Как подключили style guide? Я пробовала – он отказывается соблюдать.» Они с этим тоже сталкивались, блок с терминами и списками, но давали явные указания: не переименовывать термины и прочее, решили правками промпта.
* С ревью спецификации промптами не обошлось, приходится обучать агента, это – в процессе. А про Open API модели знают как справляться, это проще.
* Трудозатраты – примерно 2 недели плотной работы (fulltime) при наличии примеров.
* Как разработчики/аналитике восприняли, не считают ли что дополнительная работа? У них нет опции игнорировать. Но техпис все равно бы выдал ошибки для исправления аналитику, а так он их быстрее покажет.
* О доступе к коду. Пока агент смотрит тот фрагмент, который ему дали. Но они работают над предоставлением доступа.

Я хочу сказать спасибо за доклад. А еще? емея ввиду передачу ИИ большого контекста и обучение его решению задач по сложным правилам, хочу рассказать интересный кейс. Анатолий Левенчук с июня 2025 года дорабатывает системный подход, чтобы он стал применим для личности и сообществ. И делает это с помощью ИИ-агентов, и чтобы они эффективно работали, потребовалось сначала их самих научить современному системному подходу – по умолчанию у них всплывает версия 1960-х, потому что она наиболее распространена. Метод – описать правила системного подхода на английском языке, при этом не разговорном, а в стиле промышленных стандартов – ИИ с этим хорошо работает. Уже осенью в процессе работы был получен результат, который начал использовать не только сам Анатолий, но и другие люди из сообщества для обсуждения своих проектов. Система правил – большая, более 2 млн знаков, но ИИ подхватывает. Так что можно использовать этот опыт, и в для вашей области: Анатолий достаточно плотно описывает, как именно он работает, в своем блоге, так что можно посмотреть на метод работы и на организацию правил. В декабре я был на семинаре у Анатолия, и в [https://mtsepkov.org/FPF-2025-12 моем отчете] есть опорные ссылки для тех, кому интересно.

== Александр Яковлев. Масштаб, сложность, автоматизация: как агенты изменили процесс документирования в Yandex Cloud ==

<blockquote>[https://techwriterdays.ru/ru/talk/140813 Масштаб, сложность, автоматизация: как агенты изменили процесс документирования в Yandex Cloud]
</blockquote>
Это рассказ о том, как делали агента, помогающего писать документацию. И об '''архитектуре конструкции агента''' – тем, что лежит между системным промптом и промптом, который пишет пользователь, и снабжает агента необходимым контекстом для эффективного применения в рамках конкретного проекта.

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

Гипотезы

# Агенты могут создавать готовую документацию
# Мы будем писать промпты, а не доки
# Главное – промпты и модель

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

Правила использования.

# Агент не может работать с git самостоятельно, запрещаем commit и push.
# Если в доке есть инструкции, которые можно протестировать – это делают люди, потому что тестирование – это лучший чек. Это – очень интересное правило, оно связано не с ограничениями агента, а с сознательным разделением обязанностей.
# Надо понимать, зачем используем агента, и не делаем сами
# Весь цикл постановки задачи агенту и исполнения должен быть быстрее. Контекстную замену делаем сами.
# Делегируем выполнение, но несем ответственность за результат.

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

* Системный промпт. Инструменты, код, автозамены, запуск браузера.
* AGENTS.md – соответствие стандарту. Есть пример, он создается тоже с помощью агента. Описывают, зачем существует репозиторий, что где лежит.
* Режимы и Правила. Режимы – это те промпты, которые описывают что и как делают. Что такое быть техписом и что должно быть в доке. Правила – о том же, но для проекта
* Agent skills – навыки. Например, работа с yaml-файлом или редактирование markdown или редактирвоание через change log.
* Промпты, команды, шаблоны агенту чтобы делать конкретную задачу.

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

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

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

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

* Тикеты
* Скриншоты – агент способен распознать и поправть док
* Справочники API, CLI, Teraform
* История изменений через команды консольного git – release note, change log и так далее. Это агент делает успешно, раньше создание таких документов занимало 2-3 дня, а тут достаточно 15 минут по заготовке от агента.

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

Агент может проводить анализ исходников: ссылки, метаданные, формулировки, схемы.

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

Примерный цифры в токенах. Создание инструкции – 50 тыс. (при том, что правила – 20 тыс.) Работа с разделом – ограничена контекстным окном, 150 тысяч. Новый проект (новый справочники, переписать доку, убрав недоступные снаружи – 200 тысяч и больше)

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

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

Что недоступно?

* Эмпатия – представить на месте человека, который в три ночи поднимает упавший сервер
* Продуктовые: насколько наш продукт решает проблемы пользователя.
* Проверка на соответствие реальности: не может спросить: «а ты точно зарелизил?»

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

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

== Никита Авилов. Сам себе редактор: ИИ для вычитки текста и локализации ==

<blockquote>[https://techwriterdays.ru/ru/talk/140691 Сам себе редактор: ИИ для вычитки текста и локализации]
</blockquote>
Выступление было о практическом опыте – как использовать ИИ для вычитки текстов и локализации. Но в начале было немного ликбеза.

Чат-боты порождают ответ слово за слово, на цепи Маркова. T9 подсказки, без истории. Чем меньше корпус данных – тем менее точный результат.

Промпты – добавляют конкретики. Роль + Задача + Формат, Роль + Контекст + Задача. Не просто «переведи это», а «ты редактор перевода по промбезопасности, проверяешь переводы, проверь такой перевод и ответь одним словом, верно или неверно».

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

RAG – web-поиск и поиск по базе знаний – он ходит в источники, добавляет информацию к запросу и генерирует ответ с ее учетом.

С чат-ботами можно

* Брейнстормить, когда ты подбираешь синонимы и термины
* Проверять ошибки орфографии
* Генерировать иллюстрации – но не все умеют.

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

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

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

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

Модели интегрируют в системы разработки, например, разработки документации: выделить текст, и запустить промпт на него. Как сейчас в браузере – «объясни». В промпте описываешь: организация оформления, особенности стиля и единообразие

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

Подключить модель к глоссарию – пока не получается, но пробуют.

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

'''Сценарии для локализации'''. Есть плугин для Chrome и SmartCat. Можно переводить, и проверять. Но локально, без учета контекста и глоссария и памяти переводов. Удобно переводить на третий язык. Английский, русский, немецкий тоже примерить.

У них есть лингвистические автотесты – спеллинг, качества текста и так далее. Редактура с чат-ботом снимает число инцидентов.

Вычитка на статью 2 тыс знаков сократилась вдвое 30 минут – 15 минут, локализация тоже вдвое, при этом качество релизов возросло.

ИИ не создает нового и не принимает решения. Он не заменит писателя, но умение его интегрировать в flow повысит ваш скилл. Как раньше умение работать с компьютерами.

== Денис Лимарев. Имбовый портал документации на MkDocs: Markdown, Docs as Code и CD. Что сегодня и что завтра ==

<blockquote>[https://techwriterdays.ru/ru/talk/140839 Имбовый портал документации на MkDocs: Markdown, Docs as Code и CD. Что сегодня и что завтра]
</blockquote>
Фишка их технологии использования – локальный сервер сборки mkdoks – в контейнере на своей машине – ты правишь файлы, он это отслеживает и в онлайн показывает. А вообще на использование MkDocs Дениса вдохновило выступление Никиты Груздева.

Дальше – тезисно про использование, что я успевал помечать.

* Разработка – в отдельной ветке по задаче. А дальше ты это отдаешь, merge request
* Style guide и глоссарий – есть, динамически меняем
* Используем шаблонизатор Ginger – чтобы переиспользовать текст и там простые include с условным форматированием
* Еще плугины – работа с изображениями и генерация pdf
* Есть проблема – ссылки на статьи на русском: Gitlab и MkDocs – по разному создают якоря. С этим сложно, есть вариант, но там за уникальностью вручную следить
* Линтеры побороли, держим два словаря
* В Material для MkDocs есть много решений. Но разработчики объявили, что развивать не будут, и предложили новый продукт, совместимый. Пока ждут.

== Никита Груздев из VK Tech. Особенности национальной миграции с MkDocs на Hugo ==

<blockquote>[https://techwriterdays.ru/ru/talk/141042 Особенности национальной миграции с MkDocs на Hugo]
</blockquote>
Миграция с MkDocs на Hugo была вызвана бизнес-требованиями.

* Собирать с порталов документации продвинутые метрики, которые требуются маркетингу, Hugo это обеспечивает.
* Проводить А/B тестирование – если надо провести изменение темы, то на MkDocs это очень сложная задача, а в Hugo – из коробки.

На этом преимущества Hugo заканчиваются, и начинаются недостатки.

MkDocs – это Python, открытое большое сообщество, там есть много готовых решений, а Hugo – Golang, закрытое сообщество, все делают сами.

Не хватало функционала, который они использовали - Печатные формы – не было - Автор и дата обновления документа - Открытие картинок по клику – там скрины, их увеличивать надо - Единый источник – его не было, а тут заявзка - Hot reload и быстрая локальная сборка – это было

Однако, у Hugo из коробки есть много тем, а в MkDocs, по факту, одна, остальные для фана. И Возможности кастомизации выше, можно внедрить свои компоненты. В MkDocs для этого надо делать свою тему, а это очень дорого.

У них была '''своя команда разработчиков Hugo''', и они были уверены, что необходимое докрутят. Перед решением они оценивали, сколько займет доработка Hugo и MkDocs. По Hugo получили 2 человеко-месяца. А в MkDocs получался исследовательский проект, потому что бизнес-требования он не поддерживал. Поэтому и приняли решение.

Какие были проблемы.

* Запуск Hugo на Windows – проблема, надо было сделать команды запуска.
* В Hugo больше конфиг-файлов. В MkDocs есть единое место, и это удобно, даже если там 500 строк. В Hugo многое задает вложенность директорий, и дальше в каждой надо прописать много всего в конфиге.
* Пришлось переделывать всю навигацию – в Hugo она завязана на структуру папок. Это непривычно, а где-то мешало: в mkdocs можно из двух мест сослаться на одну статью или раздел, а в Hugo так не получится, надо дублировать.
* Инфоблоки и табы пришлось переделать. Для инфоблоков получился скриптик, но все равно его приходится проверять
* Размеры картинок. MkDocs неприхотлив, там написали стили и использовали для всех. В Hugo зависит от того, как поработали разработчики, и там тяжело, рутинный процесс. Сначала html в Markdown, потом проставить размеры.
* Единый источник, для которого использовали Ginger – просто отдублировали, переведя в Markdown. Взяв слово с разработчиками, что они сделают.

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

== Ольга Стрельцова. От кастомизации ПО к кастомизации документации: видеоинструкции для уникальных решений ==

<blockquote>[https://techwriterdays.ru/ru/talk/140963 От кастомизации ПО к кастомизации документации: видеоинструкции для уникальных решений]
</blockquote>
Компания, где работает Ольга, выпускает микроконтроллеры. Их используют в станках, разных стартапах, а также для разных хобби. При этом они заказывают какие-то индивидуальные характеристики, которые обеспечиваются при изготовлении и в прошивке. И для всего этого нужна документация. При этом есть тонкость: микроконтроллер встраивают в устройство, например, в станок, квалифицированные инженеры, владеющие техническим языком и умеющие понимать сложные технические документы. Но дальше пользователями этого устройства являются конечные потребители, например, простые рабочие. А микроконтроллер не полностью скрыт, с ним надо выполнять технологические операции, настраивать конфигурацию, которая будет влиять на работу устройства. Как это делать, зависит от прошивки, и с новой версией прошивки способ действия может измениться – надо поддерживать актуальность.

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

Когда-то была идея, что надо сделать видеоинструкции. Но это отложили, потому что дорого. А теперь достали, появились новые технологии: снять можно смартфоном, многое обработает постпрдакшн – ИИ рулит. И обновлять можно быстрее. Но от документации не отказались – у видео нет полноты и точности техописания, полное видео все равно дорого. Сделан '''гибрид: есть док, и есть видео по точечным, самым больным моментам''', именно на них снимают. Видео – не end-to-end, это длинно, никто не досмотрит. Пишем шаги, а внутри – маленькие порции видео. Длительность одного ролика – '''до минуты''', больше человек не запоминает. Если какие-то изменения затрагивают болевые точки – видео обновляем. Но ролики короткие, и эти точки меняются редко.

Как это делают?

# Анализ точек, раскадровка – это самое важное.
# Подготовка и запись – на смартфон
# Монтаж – надо уметь, но ИИ рулит. И субтитры – люди не слушают, а читают с экрана.
# Тестирование на стажере
# Выкладка в систему клиента.

ИИ.

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

Снимают метрики: сколько раз пришли, посмотрели ли до конца, опросники, благодарности суппорта.

От техписа требуются новые навыки, чтобы все это сделать: сценическое мастерство и другие. И техпис эволюционирует. И оценка не по числу страниц. Эксперименты стоит поощрять.

В презентации есть ссылка – весь доклад в одном рилсе. Там меньше минуты на 15-минутный доклад.

== Антон Жуков. UI Kit как источник истины: путь от макета до продукта ==

<blockquote>[https://techwriterdays.ru/ru/talk/141046 UI Kit как источник истины: путь от макета до продукта]
</blockquote>
Сложность больших продуктов – постоянные мосты: между разработкой и бизнесом – решение общих задач, между бизнесом и интерфейсами чтобы не было красивой картинки и между интерфейсами и разработкой

Первоначально – был флагманский продукт с сильным дизайнером. А потом в департамент приехала легаси-платформа, которую предстояло разделить на три новых продукта: бизнес-метрики, А/B эксперименты и работа с гипотезами. Вместо одного продукта – 4. И в одном современный интерфейс, в остальных – старое. Есть перспектива продуктов будет больше.

Если действовать старыми методами, то все расползется, каждый продукт пойдет по-своему. Они поймали проблемы заранее и решили ,что нужен единый источник истины для разработки всех продуктов, этим источником стал '''UIkit''' – единая дизайн-система, о ней и был рассказ.

Какие были требования? Консистентность, Масштабирование, Единый источник истины и Общий язык – для аналитика, разработчика, документации.

Консистентность – единый стиль для всех продуктов линейки. И готовые кирпичики для новых продуктов, чтобы сосредоточиться на бизнес-логики. Источник истины – уважаемый стандарт. Общий язык – для аналитика, разработчика, документации.

Первая боль разработчиков: одни и те же компоненты переписывают несколько раз. Идея написать однократно и все проработать. С ней пришли к дизайнерам, они тоже устали от рисования одного и того же. И техписы – процесс сбора терминологии, место четкой документации, и можно делать стандарты.

Основа UIkit – Storybook, стек – react и figma. '''Storybook – витрина компонентов''', каталог, в котором про каждый элемент можно во всех вариациях посмотреть, какой он бывает. Это полигон, где разработчик может отлаживать компоненты: как ведет себя кнопка загрузки, как показывают пустую таблицу или таблицу где 100к строк. И там же можно описывать use case. B это – мост к дизайнерам, компонент можно привязывать к фрейму в фигме и сравнивать как работает на макете и внутри. И все это можно сделать до того, как улетит в прод.

Внедрение Storybook потребовало усилий.

# Сопротивление: зачем тратить силы на обобщенную разработку
# Архитектура – потребовалось переписать код, отвязать компоненты от внешнего мира. Разнесли по слоям.
# На каждый merge request поднимается отдельный экземпляр story book, и можно пощупать до релиза, как оно устроено

В Storybook – код снипится. Разработчику не надо искать примеры в коде, он может увидеть реализацию любого компонента и скопировать. Есть встраивание в фигму – можно вставить компонент, и иметь навигацию. И наоборот, можно компонент фигмы вставить в storybook, и проваливаться в него. Получается сквозная навигация: фигма и ссылка на конкретную ноду story book.

Процесс. Конкретный вариант design review. Длинный процесс: бизнес-требования и задача в jira, ux-исследование конкурентов, проектирование дизайна, технический эпик – разработка, когда готово – проверка дизайнером на соответствие макетам, а продукт по бизнес-требованиям, финальная тестирование и релизы, потом мониторинг результатов.

* UIkit хранит и текстовые стандарты – терминология, связанные формулировки
* Интеграция с i18n – ключи, перевод и локализация, валидация
* Техписателям – ведение глоссария и проверка
* Переводы можно вести отдельно от разработки, можно выгружать в систему перевода, синхронизация с платформой перевода в обе стороны. У них проплиентарная transmate, но есть и open source
* Можно переключать языки и смотреть, как будут длинные немецкие слова или другие сложности.

Роли в системе.

* Дизайнеры – визуал, токены локализации, единообразия
* фронт – реализация поддержка
* техписатели – формулировки, гайды
* продукты – приоритеты и метрики эффективности

В презентации были скрины – примеры компонентов и фич.

Очень помогает внутренний блог с сообществом. Они пишут, какие процессы, как решались конкретные задачи и так далее – чтобы другие внутренние команды брали опыт. Коллеги – читают, и это облегчает онбординг, и приносят новые идеи по улучшениям. А еще блог оставляет следы решений.

== Елена Стеблюк. Внутреннее продвижение базы знаний: от справочника до культуры работы с информацией ==

<blockquote>[https://techwriterdays.ru/ru/talk/140867 Внутреннее продвижение базы знаний: от справочника до культуры работы с информацией]
</blockquote>
Компания edna создает продукты для уведомлений: запись к врачу, смс от банка и так далее, она там работает несколько лет. База знаний досталась по наследству, туда практически никто не заглядывал. До edna она работала в superjob, там базу знаний активно использовали. Она пошла к пользователям, они говорят: не удобно, долго, ответа не будет, проще пойти к коллеге или в чате спросить. Но из ее опыта результат – ошибки, снижение качества и другие потери. И потому начала работать над исправлением ситуации. Получается успешно, в выступлении делится опытом.

Пользователи – менеджеры по продажам и поддержка. Им надо с минимальными затратами получить ответ. Их пользователи вообще не любят многобукв.

Что надо? Актуальный контент. Приятный визуал, форматы, понятный процесс работы с базой, помощь и обучение. Как она двигалась?

* Автоматизация – боты, подсказки в CRM и так далее. По любому каналу надо давать понятный и краткий ответ, а дальше – переход по ссылке в базу
* Интеграция с рабочими процессами. Куда бы не пошли с вопросом – будет краткий ответ и ссылка
* Новостной дайджест – анонсы, и еще итоги в конце месяца со ссылками
* Ссылки в обучающих материалах
* Обучение работы с базой, простые видео
* Включение в онбординг – это классная точка входа, у сотрудников пока нет представления о том, где в компании получать информацию и он обращается к базе, если научить.

Они изучили как пользуются, выслушали ожидания, выписали разрывы сделали предварительный план. И пошли работать над контентом, делают статьи понятнее, в презентации был пример – преобразование статьи из текста в схемы. А параллельно провели – первое обучение. Обучение записали, и отдали с инструкциями тому, кто отвечает за онбординг. И начали интегрировать в разные точки внимания.

Сейчас – работа продолжается. Тут был кейс – вечно занятый руководитель принес контент. Оказывается его настолько часто начали спрашивать по работе с соцсетями, что он записал инструкцию.

Активное общение с пользователям дало проблемы. Например, выяснили, что во многих описаний продуктов не хватает продажной специфики – целевая аудитория и так далее. И начали добавлять.

Какие на этом пути возможны ошибки? Нельзя думать, что можно обновить один раз и отпустить на свободу, это – постоянный процесс. И нельзя доводить за крайности, когда эксперты просто шлют ссылку на базу знаний, надо общаться с пользователями.

Актуализация базы – больной вопрос. Тут они работают по ключевым точкам. Например, при выходе ключевых фич для менеджеров проводится обучение, и к обучению обязательно должна быть готовы материалы по этим фичам.

== Семён Факторович из documentat.io. Пора классифицировать работодателей ==

<blockquote>[https://techwriterdays.ru/ru/talk/140949 Пора классифицировать работодателей]
</blockquote>
Выступление Семена включало две части.

# Плановое содержание – анализ по результатам опроса техписов о рынке труда, который они ежегодно проводят и рассказывают на конференции. Самое интересное там – что распределение зарплат не является нормальным, а имеет два горба.
# Внеплановое: опрос в феврале показал, что 11% респондентов сократили с начала года, против 1% в 2025, и они решили это провести дополнительный анализ о причинах – вдруг это связано с профессией, например, с внедрением ИИ.

И каждая из частей включала предложения услуг documentat.io, адресованных тестировщикам и направленных на развитие иституализации профессии. Для меня – открытый вопрос, как к этому относиться. Потому что, с одной стороны, это – реклама услцуг конкретной компании. Но, с другой – компания претендует на почти институциональную позицию для профессии техписа, и если это признать, то это уже не реклама, а информация. 
Внеплановая часть про увольнения была первой. Если кратко – гипотеза про ИИ не подтвердилась, более того, сокращения вообще не связаны с позицией технического писателя. В большинстве компаний, где они прошли, идут общие сокращения ИТ, закрывают проекты, и техписов сокращают наряду с другими. При этом крупные компании продолжают прием, вакансии у них открыты. Так что профессия востребована, большинство сокращенных успешно устроились.

Почему идет сокращение ИТ? У них интересный ответ. Тренд начался еще в 2023 году и не в России – Америка, Европа. '''Причина – сдувание ковидного пузыря'''. В ковид многие увидели, что ИТ можно нанимать на удаленку дешевле, чем в офис – не только зарплата, но и помещение и компьютеры не нужны. И начали увеличивать штат при том же бюджете. В 2023 это начало сдуваться.

Так что они видят такой сценарий развития будущего: ИИ профессии не угрожает, но спрос пока невысок и не увеличится, поэтому компании буду более требовательны. Это – '''не предсказание''': бизнес не предсказывает будущее, а выбирает сценарий развития рынка или несколько, а дальше исходя из него строит стратегию и планы в ее рамках.

Если их сценарий верен, то сейчас для всех хорошее время подумать над повышением ценности и видимости на рынке. А еще подумать о своем резюме: HR сейчас анализируют предложения с помощью ИИ, и уже потом смотрят сами, и резюме стоит формировать с учетом этого.

И тут у них есть предложение. По их оценкам, Documentat – марка качества. Даже если ты не работал, а просто проходил курс или проходил собеседование, но не попал. Поэтому они решили провести эксперимент, который даст возможность любому упомянуть Documentat в резюме, чтобы повысить ранг. Два варианта сертификации. Первое – «пригодность к найму в Documentat» – mock-собеседование, свидетельство техписательской годности.

Второе – сертификат на профстандарт, это будет по-взрослому, с тестами. При этом в профстандарт заложено много специализаций в рамках профессии, так что дополнительно вы узнаете свой профиль.

Тут вот что интересно. В ряде компаний сейчас для повышения зарплаты предлагают пройти собеседование и принести офер, и тогда они сделают контр-офер. Достаточно ли будет собеседования в Documentat для этого?

Теперь про результаты опроса. На 02.2025 медиана 140к, в 02.2026 – 150к, прирост выше инфляции, и это – хорошо. Когда показываешь такую медиану, то есть две реакции: «а что так мало?» и «а что так много?» И Они решили посмотреть распределение. Выборка дает вилку 40-380, при этом распределение – сложное, с несколькими пиками.

Для таких распределений есть способ исследования – представить его как сумму нормальных. Было исследование зарплат программистов в Европе, США и Индии – обнаружили, что там сумма трех нормальных с медианами 1к, 2к и 3-5к евро. Предположение, что это отражает зарплаты в трех категориях компаний: локальные компании, федеральные (Европа целиком) и бигтех. Но это – лишь предположение, так как респонденты не указывали компанию.

Зарплаты техписов в России – сумма двух нормальных горбика: медиана 133 тыс (40-225) и медиана 235 тыс. (80-380), первая категория вдвое гуще, чем вторая. В чем разница, понять не получилось, потому что конкретную компанию респонденты не называют, только ее характеристики. Было много гипотез, которые не подтвердились: это не столица – регионы, не ИТ – инхауз, не государственная – коммерческая, не квалификация джун-сеньор или число лет работы. Данные не позволяют определить в чем разница.

У них возникла гипотеза: разница в том, насколько бизнес понимает ценность документации. Там, где понимает – он строит зрелые процессы, делает комфортную работу писателей и ценит их труд. Но это лишь гипотеза, данными не подтверждено.

И это породило вторую идею – сделать компаниям аудит, чтобы оценить зрелости документационной культуры. Будет сертификат как лычка. Впрочем, из зала было возражение: а зачем компании это надо? Чтобы кандидаты видели лычку и просили вдвое больше?

У меня, если честно, большие сомнения в этой гипотезе. Не знаю, как с техписателями, но по разработчикам и тестировщикам я знаю, что кандидаты от некоторых работодателей просят больit в полтора-да раза «за политику», которой приходится заниматься – компенсируют таким образом будущий стресс, на который идут сознательно. И со зрелостью процессов это не связано, потому что политика обычно включает в себя еще и бюрократию. Конечно, в компаниях-то считают, что это не бюрократия, а «высокая культура формальных согласований», отражающая зрелость процессов, но у кандидатов – другое мнение. Может, и тут дело в этом.

А вторая моя гипотеза – что есть компании, где перед техписами стоят достаточно простые, регулярные задачи, а есть – где высокая сложность или неопределенность. Во второй придирчивее отбирают и больше платят. При этом квалификация не нормирована, в обоих типах компаний есть джуны-мидлы-сеньоры, чтобы обеспечить карьерный рост. Косвенное подтверждение гипотезы – что ситуация, когда в одной компании ты сеньор, а в другой – джун или чуть больше – относительно типичная.

По поводу идей сертификации из зала прозвучал вопрос: а не становятся ли таким образом техписы на тот печальный путь, которым идут учителя и ряд других профессий, где государство это все сделало обязательным и взяло в свои руки. Семен этого точно не хочет, и обещал подумать, как этого избежать.

[[Категория:ИИ-агенты]]
{{wl-publish: 2026-04-04 08:42:48 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2026-04-14: Анатолий Левенчук - мультиагентная работа над FPF

2026-07-24T14:49:14Z

MaksTsepkov:

{{RightNote|[https://t.me/mtsepkov/1157 Пост в Tg]}}

Заглянул тут в [https://ailev.livejournal.com/ '''блог Анатолия Левенчука''']. Я уже писал в разных постах и отчетах о конференциях, что Анатолий с июня 2025 собирает '''First Principle Framework''' (FPF) – описание системного подхода для ИИ, первый релиз вышел в сентябре. Цель самого Анатолия – пересобрать с помощью ИИ системный подход так. чтобы он был применим к модели личности человека и к сообществам, чтобы доработать руководства. Но вообще такой описание резко повышает качество общения с ИИ-моделями, поэтому участники сообщества Школы системного менеджмента (с мая 2025 – Мастерская инженеров-менеджеров) подключают его для обсуждения своих рабочих проектов. В декабре я был на большом семинаре у Анатолия и [[FPF-2025-12|публиковал отчет]], там есть ссылки и на сам фреймворк, и на посты Анатолия с описанием метода работы с бригадой ИИ.

А тут увидел, что с начала марта Анатолий перешел от ручной разработки FPF с помощью чатов с агентами к мультиагентной с помощью Codex App. И в последних постах очень подробно описал, как это у него устроено: три агента – executor, reviewer и platform engineer, организующий работу другим агентов, внешнее review сильной GPT-5.4 Pro (внутри работает GPT-5.4 xhigh), и он сам, принимающий ключевые решения по продукту и присматривающий за ходом процесса. При этом процесс работы – описан, агенты ему следуют и дорабатывают. И вся информация передается через файлы, так что все ходы записаны.

На мой взгляд. все это очень интересно для тех, кто сейчас строит свои системы агентов. Ну и мне самому тоже, поэтому я хочу сохранить ссылки. В [https://ailev.livejournal.com/1796405.html этом посте] – описание устройства мультиагентной схемы. [https://ailev.livejournal.com/1795589.html Здесь] – про старт работы и первый подход к организации. А [https://ailev.livejournal.com/1797223.html вот это] – очень интересный пост, где Анатолий описывает типичные ошибки агентов, которые надо учитывать в ходе работы. Они – те же самые, что свойственны человеческим командам. Например, стремление создать много регламентов так, что большая часть токенов начинает уходить на административную, а не на содержательную работу, или упрощение задачи так, что теряется суть, и так далее. Это уже не просто обобщенное описание «ИИ-агент – новичок, не знающий контекста вашего проекта», '''ИИ-агент получает понятные поведенческие характеристики''', которые надо учитывать при построении процесса.

В [https://ailev.livejournal.com/1796971.html этом посте] – текущее состояние самого FPF (лежит на github https://github.com/ailev/FPF). В нем появились пути для решения разных задач: правка проекта в текущем состоянии, работа с неоформленным, сравнение и выбор вариантов, работа с языком. И я буду иметь это ввиду на будущее, потому что задачи управления большим проектом у меня лично сейчас нет, а вот некоторые из этих задач, думаю, скоро появятся.

В заключении должен с сожалением отметить, что в этом году я не попаду на конференцию Анатолия, на которых был с 2019 года – она будет в эти выходные. а я буду в Иннополисе. Печалька. А кому интересно – присоединяйтесь. Но там контент для тех, кто «в теме».

[[Категория:Системное мышление]][[Категория:ИИ-агенты]]
{{wl-publish: 2026-04-14 22:03:08 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2026-04-20: Merge-2026 - интересные выступления и хороший нетворкинг

2026-07-24T14:48:51Z

MaksTsepkov:

{{Conf-Ref}}
17-18.04 Был и выступал на [https://tatarstan2026.mergeconf.ru/ MergeConf] в Иннополисе. Прошлый год я пропустил, а в 2024 был дважды: в Иннополисе и в Москве. Так что впечатления – ожидаемые, конференция с качественными докладами и хорошим нетворкингом. В этом году нет афтерпати, это, конечно, жаль, но все равно, атмосфера – хорошая. Два дня, 11 треков, много мастер-классов и круглых столов. Так что я желаю организаторам успехов.

И один из круглых столов дал очень сильное впечатление, я бы сказал вау-эффект, хотя это не совсем точно. Это '''круглый стол по вайбкодингу в секции маркетинга'''. Секция – важно, потому что это – точка зрения заказчика, а не разработчика. Обсуждая заранее его с одним из коллег я выдвинул гипотезу о том, что говорить будут «Как же эти разработчики нас достали! Наконец-то можно без них!» И я угадал. Эксперты и участники в зале делились историями о том, как у них работает вайбкодинг, какие задачи получается решать. Главное – у них все работает. ИИ создает нужный софт лучше, чем разработчики. И умеет структуру, правда, специально просить надо, но это обучаемо. И не ноет. А при обсуждении задачи указывает на проблемы, и ты понимаешь, что с разработчиком бы это вылезло на третьей итерации в виде претензии «А че ты не сказал раньше?» И итераций до получения результата меньше, чем от разработчиков, и без дурацких вопросов. В общем, я сидел и записывал реплики, смотрите их в отчете, я начну именно с этого круглого стола.

Да, основной набор задач там все-таки касается не слишком сложных приложений. Но и не тривиальных. А про сложные говорили на других круглых столах и докладах, там тоже все неплохо. На '''круглом столе по ИИ у аналитиков''' один из участников, владелец аутсорсиговой компании, сказал, что он сильно сократил разработчиков: из 10 проектов они остались только на двух, а остальные 8 вайбкодят аналитики вместе с ним самим – он ставит процесс, разбирается с граблями и учит аналитиков их обходить. В этом круглом столе я был одним из экспертов, поэтому конспекта не будет: увы, конспект и участие совместимы слабо. И записи тоже, увы, не будет: Merge не делает записи, так было и на прошлых конференциях, у них такая позиция.

Из выступлений хочу отметить '''мастер-класс Максима Дорофеева''', который был посвящен '''пониманию''' – как при передаче от одного человека другому, так и человеком самого себя, собственных планов. В мастер-класс было встроена игра, интерактивное обсуждение планов с другими, которое показывает, что за '''планом или другим высказыванием часто скрывается некоторая цепочка слов, смысл которого неясен даже самому автору'''. В коммуникации эта цепочка слов как-то интерпретируется другим человеком, и чаще всего смысл искажается или теряется, происходит «инъекция говна» – прикольный образ, иллюстрированный картинками. Интерактивную игру Макс создал вайбкодингом, и, как он говорил в кулуарах, раньше таких возможностей не было, был бы аналог на бумаге и других подручных материалах гораздо худшего качества. Кстати, у мастер-класса была очень интересная форма: вместо презентации Максим быстро вставлял рисунки и делал схемы в holst.so.

А выступление Павла Аргентова о функциональном программировании вызвало у меня воспоминания-размышления о парадигмах программирования и их исторической классификации на императивные и декларативные, исторически проведенная граница в которой давно потеряла смысл, однако сохраняется на своем месте. Инженерные науки тут не лучше психологии, где умозрительные границы, проведенные авторитетами век-полтора назад, сохраняют, хотя нейрофизиологи давно показали, что деление следует проводить иначе. Так что помимо конспекта выступления будут еще эти мои размышления.

На этом общие впечатления я завершаю. Теперь – цитаты из круглого стола маркетологов и другие выступления на которых я был: сначала – по теме ИИ, затем – остальные. Их не так много, потому что три слота я выступал сам. и еще несколько пропустил выступления в польщзу нетворкинга. И, в любом случае, из всех 11 треков это малая часть.

Я тоже выступал: «[[DDD и современная архитектура: как проектировать модель и отражать ее в код (Merge-2026)]]». Конспекта моего выступления тоже не будет, но можно смотреть предыдущие, в статье есть презентация и ссылки.

== Секция маркетинга, круглый стол: Вайбкодинг для всех: вымрут ли разработчики как динозавры? ==

[https://tatarstan2026.mergeconf.ru/networking/kovalev-yuzhanin-krylov-ilyuhina Круглый стол на сайте]

Формат стола – отдельные реплики и истории. Я это записывал. А общий смысл я уже передал: да здравствует вайбкодинг, он делает маркетологов незаивсимыми от разработчиков. Наиболее сильную цитату вынесу в начало, остальное – в порядке услышанного.

'''Когда менеджер, который имел дело с разработчиком, начинает вайбкодинг – это другой мир. Никто не ноет, никто не ушел курить.''' При обсуждении она рассказывает проблемы, и ты понимаешь, что от разработчика бы ты о них услышал только на третьей итерации в формате «а че ты не сказал». Сидишь ночью вайбкодишь – это кайф, результат без нытья.

NoCode и LowCode – ограниченная коробка, это и минус, но и плюс по безопасности. Вайб-кодинг – любой полет фантазии, но дыры в безопасности, когда сливают учетки и кошельки – запросто. Поэтому полезно отдавать разработчикам на ревью, если есть такие риски.

Кейсы: сервис textprice – калькулятор для копирайтеров с обоснованием цены. И скрипт на питоне – чтобы названия файлов в Google-доке. Сопоставление было раньше вручную тяжелое, 50 файлов требовало несколько часов. А тут автомат, и еще ширину обрабатывает.

Делают сами, потому что отдел разработки всегда занят. О нем вообще не думали. Вообще было отношение, что внутренний редактор – надо просто принимать проблемы. А это можно изменить. Это ментальный переключатель. И вообще независимость от разработки – это вау! Разработчик – боль.

Реально сделать прототип ко второй встрече с клиентом. Или клиабельный прототип интерфейса в фигме. Самим. А еще они вытащили все материалы по всем роектам в общее хранилище, и ИИ отвечает на вопрос «что там с проектом». Но там – конвейер, чтобы сделать хороший ответ. И общее хранилище нужно, нейронка по 5-7 сайтам плохо бегает.

Актуальная задача – перейти поддержку с телеги на макс, вернее, макс добавить как канал поддержки. Cursor дали задачу, описание api макса и существующий код, который был заточен од телеграм. Взлетело с минимальными доработками, два дня вместо двух недель. Но он задал модель реализации и потребовал выделить промежуточный слой, который общий и будет маршрутизировать в нужный мессенджер, чтобы расширять, если придется. И с особенностями ИИ справился, в телеге есть оплата звездами, он сказал, что это надо скрыть в зависимости от канала обращения – и это сделали.

Опыт. '''Я уже часть задач не даю разработчику, потому что они задают дурацкие вопросы, а ИИ сделает без них.'''

Опыт. '''Проверка кода после джунов требует большей тщательности, чем после ИИ'''. Но ИИ-шке надо было написать рекомендации – style guide. А для pet-проджект вообще код не смотрят. Но структуру дерева файлов все-таки смотрит. Хотя тоже не везде.

Опыт. '''Количество итераций до готового проекта – сильно уменьшается с ИИ по сравнению с разработкой'''. И итерации быстрее, но это понятно. А тестировщик может сам исправить простые ошибки с помощью ИИ, не возвращать разработчикам.

Кейс. Человек работает с ML в МТС. ИИ помогает в изучении алгоритмов, онбординге в новые процессы и проекты, разбирается со структурой БД, и еще куча задач – ЖКХ поругаться и так далее. Устроился в новую компанию, ему надо изучить проект, осмыслить. Но там Алиса и Gigachat, западные модели нельзя использовать, а наши – не тянут. Но по совету Gigachat скачал Llama и открытую модель DeepSeek – всего 7Мб. Поставил локально, отняло чуть больше часа. И дальше дал зарос на DeepSeek. Тот ушел в раздумья на 40 минут, но ответ – дал. И это на компе за 20тр. Ему это сэкономило 1-2 спринта онбординга в проект.

Новые сотрудники – запросто разворачивают дешевые модельки у себя локально. Он пришел рассказать, что дешевле взять готовое – а он показал локальные результаты.

Кейс. Пару лет назад заключили контракт с одним банком. Штатный программист не тянул, он нанял студию, они год делали, до конца не сделали, но как-то сдали, 2.5м убытка. И по договору был, нужна была поддержка, у студии – комические деньги, он нашел одного fullstack-разработчика, тот тянул. Это история два года назад. А сейчас оявилась задача расширить, о спросил разработчика – и тот предложил переписать. И навайбкодил, весь преокт обошелся в 250 тр.

'''Ключевая роль человека – во-время чуть-чуть направить'''.

== Игорь Рыбаков. Как мы перестраивали работу аналитика с AI ==

[https://tatarstan2026.mergeconf.ru/speakers/analytics/prodanasys/rybakov Выступление на сайте]

Очень содержательный рассказ о поэтапном освоении ИИ для работы аналитиков, начиная с GPT-3 несколько лет назад.

* Чат – несколько лет назад, CahtGPT-3. Проект, где много use case расписать. Шаблонизировать типовые действия: use case, yaml, реестр требований, резюме встреч. Перспектива была, но отладка работы занимала больше, чем если бы писал сам – в знакомой области. А '''погружение в новую область''' было лучше и быстрее, чем через статьи.
* Развитие. Работу с чатом – совершенствовали, контекст больше. И рабочие схемы – формирование промпта, итерации размышления, направление. Роль, контекст, самопроверка, план выполнения, цепочка мыслей. Рабочие промпты под шаблоны use case, yaml, резюме встреч, user story, uat. Уже начало давать профит. И до сих пор '''80% работы закрывается чатом с промптами'''.
* Диаграммы – PlantUML. Это замечательно. Диаграммы последовательности, c4, процессы, ERD, архитектура. LLM умеет создавать и умеет понимать твои диаграммы, это тоже профит. При этом диаграммы можно было связать между собой. Но работает только для системных артефактов – там нормировано. А с бизнесом надо неформально.
* Deep Research – погружение в новую предметку. ИИ умеет собирать информацию с инета, и переваривать несколько циклов. За несколько циклов можно много понять про заказчика – многие публикуют на хабре и форумах инфу. Workflow: Компания, Рынок, Предметка с проблемами, Гипотезы – подготовка первой встречи с экспертами. Половину vision можно собрать. Отдел аналитики начал получать профит. Разработчики – тоже.
* А вот HR и Менеджеры – первичное использование без системных промптов, у большинства сделать сложные промпты не получается. И они начали работать с агентами, чтобы дать им инструменты.
* Одно из достижений – '''сметирование''': есть тендерное задание и надо за 5 часов дать оценку. Просто запихнуть в ИИ тендер – нельзя, будет много фантазий. Процесс: вводные данные по клиенту, сбор контекста и гипотез, вопросы и риски (MVP, релизы, требуемые доки), черновик структуры решений, передача на доработку. Вопросы зашиты в отдельные md, каждый такт проверяется человеком и дорабатывается. Запрос в мессенджер – агент выбрал сценарий – первый проход – результат в мессенджер – решение человека. И это – думающий алгоритм совместной работы. Сильно помогло в небольших процессах. При этом 80% закрывается чатом.
* '''ИИ для прототипа'''. Очень большой профит. Набросать экраны типа figma make – кликабельный прототип для заказчика. Постановка дизайнеру – сложно, но для первичного обсуждения с заказчиком-визуалом – ОК.
* Переход к новому формату работы. У каждого клиента – свои боли и свой способ работы: где-то фокус на интерфейсы, где-то cjm, где-то что-то другое. Понять архитектуру процесса может опять только аналитик. Поделили на блоки, начиная с интервьюирования. На блоки делит аналитик – ИИ не смогла взять. У каждого блока свой сценарий применения ИИ, у каждого вход и результат. Уровень привлечения ИИ различается – проекты разные. Я думаю, что поделить на блоки ИИ тоже сможет (как черновик), просто надо сделать грамотные промпты, это же достаточно нормированная тема – разделение работы на этапы в различных вариантах.

Итого. Каждый аналитик задает стратегию работ. Увидеть результат, Собрать процесс аналитики, определить, где подключать ИИ. Пока это в виде регламентов, и аналитик направляет ИИ, с системными промптами, но в принципе тут агенты тоже помогут.

Будущее – бизнес-запрос, функциональные блоки, AI и vibe-coding (пока он хорош для пет-проектов, но не для прома с большим контекстом), инженерные практики. И станет он ИИ владельцем информационной системы.

ИИ не заменит аналитика, он сам никогда так не думал – но он ускорит. Он поможет погружаться к предметку – и это надо уметь. Больше внимания надо уделить ценности. Фокус сместился в понимание процесса мышления – как мы получаем результат, какая цепочка приводит к нему – чтобы направить ИИ.

И коммуникация остается на человеке. 50% времени он работает психологом, процессы зашиты на конкретных людях. Даже если вы приносите идеальный результат – его надо продавать. И выманивать информацию – смотреть на невербалку, искать ходы в коммуникации. Впрочем, я думаю, ИИ тут тоже может помочь, например, если описать портреты людей, с которыми ты ведешь коммуникацию, и обкатывать на них сложные моменты, вырабатывать аргументы.

Решение вопросов – через взаимодействие с ИИ. Промпт не пишешь сразу хороший, так что его надо докручивать, а в моменте идти во взаимодействии.

'''Вопрос'''. Сколько внедряли, какой саботаж, какие метрики? Ответ. После испытательного срока остаются люди, которые понимают необходимость ИИ, так что саботажа нет. Сколько с нуля – не знаю, у нас процесс шел поэтапный, и каждый раз инкремент, да еще ограничение ИИ – два года назад было хуже. Сейчас можно форсировать, но эффект он не знает. Метрику снимал – количество задач. Персонал не сократился – высвободившееся время уходит на качество и позволяет снижать цену.

'''Вопрос'''. Как получается из аналитиков растить архитекторов ИИ? Ответ. То же самое, как с любым процессом. Группа евангелистов, которые продвигают и распространяют – как с любой практикой?

'''Вопрос'''. А галлюцинации? Ответ. Конечно есть. Решение – дорабатываем системный промпт. Как правило, при общении с бизнесом, там формируем в промпте границы. И еще разбивка на шаги, чтобы они стали более определенными.

'''Вопрос'''. Как побуждаете аналитиков? Ответ. Как с новым софтом. Всегда будет те, кто по-старому. Пропагандируем. И повышается требования за счет ИИ. Если он успешно решает задачи по-старому – и хорошо. Но если начинает отставать, а меняться не хочет, то показываем: уже джуны тебя обгоняют!

== Сергей Бурцев. ИИ убьёт видеопродакшен? Мы проверили — и наняли вдвое больше людей ==

[https://tatarstan2026.mergeconf.ru/speakers/marketing/content/burtsev Выступление на сайте]

Выступление – множество кейсов о мощи современного ИИ в создании видео, в докладе примеров реально много. Но, все-таки, полтора года назад на UIC.dev я видел гораздо более впечатляющее выступление Льва Бахарева «Ситуативный ИИ-контент: от брейнштормов к готовым проектам за минуты», у меня на сайте есть [http://mtsepkov.org/UICdev-2024 краткий конспект], но там интересно смотреть [https://vkvideo.ru/video-184504774_456239235 видео] (надо подписаться на канал конференции). Возвращаюсь к выступлению.

Кейс. Строительная компания DARS 25 лет, надо срочно стать фильм. Интервью – да, но в кадрах нужна реальная стройка. А это зима, и стройка – не фотогенична. И генеративный ИИ – помогает. Реальный ролик, там смесь ИИ, видео из стоков и реальной съемки, и хорошо получилось.

2-3 года назад ИИ не было на таком уровне. Они по одному заказу делали заставку: зеленая горилла бегает по Москве, сравните – было печально по сравнению с нынешним уровнем. Но уже тогда круто по срокам и стоимости.

Есть проблема достоверности. Делали ролик про Симбирск, и показывали 17 век. Это очень сложно. Но возможно, просто надо уметь: убрать голливудский налет, использовать реалистичные планы местности, образцы архитектуры и одежды и много других деталей.

Кто-то из коллег не хочет обучаться новому, и остается на старых технологиях. Но ИИ дает резкий скачок по производительности, и дальше вопрос конкуренции. Отмечу, что это не означает, что переход на новое обязателен: есть же до сих пор узкие сегменты, где обувь мастера шьют по индивидуальному заказу по старым технологиям. Так и в мультипликации – есть те, кто рисует мультики вручную или делает на пластилине, как и раньше. Там – своя экономика, а где быть – вопрос личного выбора.

ИИ уже умеет технику – титры, графику и эффекты поверх, можно обходиться без специализированных программ. Для этого нужен опыт, насмотренность и режиссура, чтобы сформулировать промпты. Но если у вас есть видение, что должно быть на экране в результате – вы можете этого добиться. Сами, без большой команды, которая раньше была необходима. Обращение к экспертам за отдельным советом или обучению и найм команды профессионалов – сильно разные режимы работы, сроки и затраты.

И это дает новые возможности, прежде недоступные. Кейс. Депутаты решили поздравить коллег с 8 марта – и сделали ситуативную юмористическую историю. Пиксаровские 3d-модели одних депутатов доставляют другим поздравления по модели города с разбитыми дорогами и другими препятствиями, которые тоже приземлены на реальные проблемы города. И озвучка идет полусинтезированным голосом.

Кстати, Pixar, когда ее базу подгрузили в ИИ для обучения, сначала хотел подать в суд, а потом не только одобрил, но и дали дополнительный материал.

Прототипы фильмов и роликов для разных тендеров запросто можно делать, это быстро, недорого и адекватно передает идею. Сделать видео картинка из Лондона 17 века для будущей игры – запросто.

Интересно, что поменялись сравнительные цены. Недавно самым простым было 2d, дороже 3d, а потом – реальные актеры. И ИИ – наоборот, проще – реальный человек, сложнее – 3d pixar, а 2d – еще сложнее. Недавно делали мультфильм про жизнь конкретного человека, как часть презентации к юбилею. Мультфильм – сложнее, чем видео.

В компании снова важен системный администратор. Vpn, модели – они каждую неделю меняются, часто подбирают модель под задачу. Все примеры, скорее всего, с разных моделей. Поэтому не получится купить одну подписку и там все делать – нужны разные модели. Они следят за расходами, в презентации был график. Появились генералисты и программисты, которые делают по общему замыслу или дорабатывают то, что не получилось снять.

В целом '''доля творческой работы возросла примерно с с 40% до 70%''', ушла рутина. '''Пропал языковой барьер''', они успешно работают на английском рынке без английских актеров, раньше это было невозможно. В профи-среде для крупных заказчиков видео не стало дешевле – они придирчивы к деталям как в классике. Но появилось больше возможностей. А в свободное время они делают рилсики про космос и на другие интересные темы – сейчас это просто.

== Андрей Бровко из Авито. Spec driven AI. Как обеспечить качество? ==

[https://tatarstan2026.mergeconf.ru/speakers/development/qa/brovko Выступление на сайте]

Мастерство ИИ в разработке растет. Есть бенчмарк SWE-bench, основанный на решении реальных задач из open source проектов, там начинали с 2% в GPT-4, в 2025 было 73-75% для Opus, а сейчас уже более 100%. И если год назад Карпатый говрил про вайб-кодинг, то в сейчас речь идет про Agentiс Еngineering, создание кода с помощью ИИ-агентов как регулярный инженерный процесс, мастерство в котором основывается на том, что мы понимаем, как рождается код и как его контролировать. И Андрей рассказывал про опыт использования ИИ-агентов в разработке Авито. Цель – удешевить и ускорить разработку.

При этом скорость конкретного опытного разработчика снижается: надо контролировать ИИ и давать задачи. А вот процесс целиком от внедрения ИИ ускоряется в 2-3 раза. Правда, количество уязвимостей от ИИ-агента больше в 2.7 раза, и с этим надо работать.

В 2025 были пилоты – группам инженерам давали подписки. На метриках роста производительности не видели, но и падения не было. А известно, что переход на новый инструмент, как правило, вызывает замедление – надо разобраться с тем, как он работает. Как результат пилотов, сейчас есть понимание, что работает и методика применения, а также централизованная база навыков. В планах масштабирование и внедрение в процессы,

Три секретных ингредиента.

# Умная модель. Sonnet, Opus, Codex
# MCP – интеграция с внутренними сервисами: доступность агенту документации и возможность ее обновления, доступ к коду и возможность поставить pull request, доступ к задачам в jira
# Описание навыков – специфических особенностей компании: pipeline разработки, применяемые технологии, способы тестирования и так далее

Их pipeline '''Spec driven AI''' основан на разработке тестов до кода, это вариант TDD: спецификация (user story и acceptance) → Тесты → Тесты не проходят → Генерация кода → Тесты проходят.

Если детальнее, то получаются такие этапы, выполняемые ИИ-агентами и людьми по-очереди или совместно. - Задача в Jira в свободной форме - Трансформация в машиночитаемую форму по шаблону: цели, acceptance criteria и так далее. - Ревью продакта и инженеров - Декомпозиция задачи - Проектирование и наполнение техническими деталями - Ревью техлида - Генерация красных тестов (тест проверяет функционал, которого нет) - Ревью теста - Генерация кода - Автотесты зеленые - Чеклист ручной проверки. Его может создать агент – он знает тонкости раеализации - Ревью кода - Релиз в тестовом окружении - Тестирование - Релиз в прод - Мониторинг работы

Понятно, что после ревью идут доработки, возвраты на предыдущие этапы.

Для организации pipeline есть фреймворки для этого. Они смотрели

* '''SecKit''' – тяжело и надо вычитывать
* '''Superpower''' – там проще, есть такт брейнсторминга, а тесты вперед, используют его

Инженер не печатает код, а ставит задачу, валидирует и принимает результат. Разработчики тоже иные. И QA – модель может написать автотесты, а его роль – стратегия качества, SDLC и CI/CD, настройка агентов, аудиты качества и так далее. Пока трансформация не произошла, но туда идут.

Для стратегии тестирование есть типовое оглавление, начинается со спецификации и критериев приемки. Оценку рисков модели не слишком хорошо пишут, им не хватает знания контекста конкретного проекта, а без них получаются абстрактные риски, которые никого не волнуют.

Человек проводит ревью тестов – они становятся частью спецификации, в каком-то объеме ревью кода, но его становится очень много. Тут нужна помощь агентов – их надо учить. Приемочное тестирование – агент не слишком хорошо представляет пользовтелей, работающих с продуктом. А еще – проверка артефактов агентов, инструкций и тулов. И проверка безопасности и учет особенностей LLM.

Ближе к концу был забавный слайд. Оказывается, Роберт Мартин предлагает выбрать 3 характеристики из 4: Скорость, Бюджет, Качество, Объем, и говорит, что все четыре недостижимы. А в свое время говорили про проектный треугольник Быстро – Хорошо – Дешево и говорили, что достижимо лишь два любых. [https://en.wikipedia.org/wiki/Project_management_triangle Wiki говорит], что концепция восходит к 1950-м, а автор неизвестен. Сначала я подумал «вау, прогресс, научились достигать все три». А потом понял, что проектный треугольник рисовали при неизменном скоупе (объеме) проекта, а сейчас им тоже начали управлять. Впрочем, нормальных подтверждений концепции нет, в реальных проектах сплошь и рядом получается медленно, дорого и плохо одновременно.

Как они делают сравнение разных моделей? Через тесты и метрики. Используют внутренние и внешние метрики, метрики эффективности (DORA- пропускная способность против нестабильности). На слайде были выписаны, но в целом там понятные и широко используемые метрики процесса разработки, никакой ИИ-специфики нет. Экономически использование агента окупается уже при 4% ускорения – разница месячной подписки и зарплаты разработчика громадная.

Реально эффект больше, но отделить фактор ИИ от остального – сложно. Потому что производительность разработки в Авито растет уже много лет, и резкого увеличения на графиках нет. Однако на конкретных типах задач видно ускорение, например, отчет, который раньше отлаживался бы человеком полчаса-час, агент с доступом к данным по MCP делает за пару минут.

Риски.

* Agent shadowing – он копошится, а вы не смотрите вообще. Он может копошиться очень долго.
* Безопасность и governance
* Риск утечек персональных данных и коммерческой тайны
* Ускорение без контроля качества превращается в ускоритель разработки техдолга.

Поэтому в pipeline – и люди и агенты, и это должна быть содержательная, а не формальная конструкция. Цитата: «если архитектура, тестирование и релизный процесс слабые ИИ-агент ускоряете поставку дефектов». Отмечу, правда, что это громкое заявление – от компании, которая берет деньги за наладку процессов, так что они – предвзяты, и борются за свое место в условиях массового распространения ИИ.

Вопрос. Как убедили ИБ использовать модели вне контура компании? Ответ. Это было непросто, и повезло, что руководитель увлекается идеей ИИ. Но есть условия: какие домены можно выносить во вне, а что крутить только на внутренних моделях, есть сервисы анонимизации для выноса наружу или даже предоставления моделям доступа, есть разметка в документа«noAI».

Насколько сильная модель нужна? Они начинали несколько лет назад с малых моделей, там контекста не хватало, эмпирически вычислили, что надо минимум 32к. Сейчас это есть, и уже начинается обратная проблема: в контекст можно запихнуть очень много, и модель расфокусируется, теряется в том, что ей сказали. Надо следить.

== Максим Дорофеев. А кто сказал, что у человека интеллект не искусственный? ==

[https://tatarstan2026.mergeconf.ru/speakers/management/methodology/dorofeev Выступление на сайте]

Это был рассказ о проблемах понимания. Не только про искажения передаче другим, но и о том, что человек часто сам плохо понимает, что говорит. Даже когда пишет свои планы. Он просто плетет цепочки из слов. И это не просто рассказ – была интерактивная игровая демонстрация этого эффекта. Правда, я был только в начале: мастер-класс был два слота, а я после первого ушел выступать сам. Так что рассказ в сокращении.

Предположим вы сидели на докладе. В конце вопрос: «Поняли? – Вроде да!» '''А как вы поняли, что поняли, если еще ничего не сделали?'''

Когда-то он был в научной командировки во Францию. Между собой французы говорят на французском, они не понимают. И они с коллегой придумали шуточную теорию вербальных актов, когда человек что-то ритуально произносит и на это столь же ритуально реагирует, без всякого смысла. Потом он много лет работал в ИТ, а затем сделал компанию обучения. И тут всплыло, что это – не шутка: '''Люди приходят, говорят слова – и не понимают, в них нет смысла'''.

Почему не сделал задачу? – Не успел! – Надо было расставить приоритеты!

Звучит умно, но что все-таки надо было сделать иначе – не ясно. Глупые люди тоже умеют говорить умные слова. Вот если бы умение говорить умные слова разблокировали только с дипломом, и ты не мог сказать «дофамин», если не понимаешь, что это такое – жизнь была бы лучше.

Замечу, кстати, что в Китае дело обстоит именно так. В школе ты учишь 2-3 тысячи иероглифов и не сразу, а постепенно, есть график освоения по классам. А потом, вместе с освоением программы ВУЗа, ты учишь иероглифы, которыми записываются понятия из твоей специальной области. А пока не выучил – ты просто не можешь прочесть профессиональные статьи. Написать и сказать тоже не можешь.

Своими словами мы описываем не вещи или явления, а свой опыт их восприятия. Многие люди говорят о вещах и явлениях, и думают, что про них. А это – про восприятие. «Эта книга плохая» – нет, это говорящий думает, что книга плохая. Почему он так решил, мы не знаем. Он взял книгу, почитал, подумал, и не нашел ничего нового, или прочитал фигню – это его оценка. Может быть проблема в книге, может в восприятии, может быть в осмыслении. Где по пути была инъекция говна, которая испортила оценку – мы не знаем. А некоторые люди могут вообще не читать книгу, а сложить мнение из того, что он услышал другого. В уши испражнялись и ты передаешь. Оценивал ли ты источник. Сейчас вариант «читал в пересказе ИИ», ИИ же хорошо пересказывает – а это тоже неточно.

У Максима не было презентации, а была [https://app.holst.so/share/b/a12a2da5-67fe-4ad4-97f5-fde21c91f291 доска в holst], где он быстро рисовал картинки, или копировал из заготовок. Я не знаю, оставит ли он доступ, так что одну картинку я оттуда заберу на память.

[[File:DorofeevMerge26-Communication.jpg|Инъекция говна в коммуникации|600px]]

А дальше в социуме получается так: мы подменяем то, что истинна на то, что чаще слышали. Прав не тот, кто проверил умозаключение, а тот, кто громче кричит об этом и шире транслирует то, что говорят другие. Обилие метафор – признак пересказа, за которым, чаще всего, нет оснований. Когда разработчики говорят «менеджмент живет в мире розовых пони и не знает, что за ад в разработке» или инженеры поддержки утверждают, что «разработчики подкладывают нам дерьмо, а мы разгребаем», то люди как бы понимают, но конкретного смысла за этим нет. Кстати, по обоим тезисам на доске есть прикольные картинки.

«'''Гарри Поттер и методы рационального мышления'''», цитата. Гермиона: «Почему у людей не получается стать собой?» – Поттер: «Мы уже сами, а не чьи-то копии. Но если отвечать в духе вопроса: то это происходит потому, что люди набираются всякой ерунды и бездумно ее повторяют». А '''Бернейс в книге «Пропаганда» (1928)''' заметил: «Когда-то думали, что грамотность даст человеку возможность мыслить самостоятельно. А реально '''всеобщая грамотность дала человеку не разум, а набор штампов, приправленных рекламой'''. Он у людей одинаковый, и потому у них будет одинаковый отклик при воздействии – так работает пропаганда».

Штампов много. Но главный вопрос в передаче: что передают широко, а что – не популярно. Выпустили мессенджер и все говорят, что он – плохой. И вопрос не в мессенджере, а в том, как это появилось и как передали. Штампы – как закэшированная страница, и плохо, когда кэш не актуален.

Но дело не только в передаче. Люди очень часто вяжут умные цепочки слов без логики и наполнения смыслом. Типичный план жизни выглядит примерно так: «Я закончку универ, потом … эээ … будет много разного, а вот потом – я живу за границей в огромном доме и у меня много денег». Середина, которая должна провести от начала к концу – отсутствует. И это – не преувеличение, так мыслит большинство.

Интересно, что Станиславский требовал от актеров ознакомиться с пьесой, но не разрешал говорить на репетициях словами пьесы. Он сначала требовал обыграть все своими словами, чтобы актер понял смысл, а не бездумно повторял слова. И только потом можно было говорить словами автора. Тогда получалась реальное проживание, а не бездумное повторение.

Чтобы показать, что люди плохо понимают – интерактивная игра. Заодно по результатам Максим обработает, чтобы понять – где именно дыры у людей сейчас.

Игра устроена так. Каждый пишет свой план в формате «Я планирую ''что-то'' для того ''чтобы было вот это'', по итогам чего ''достигну цели'', которой хочу». Например, так: «Я планирую получить диплом магистра, для того чтобы устроиться на крутую работу, по итогам чего накоплю на первый взнос на ипотеку». Дальше идет объединение в пары или тройки – каждому, кто написал план – назначаются 1-2 душнилы, которые видят план и пишут вопросы. Для душнил есть шаблон, чтобы не уходили в сторону: они выделяют конкретное слово, и дальше есть шаблоны вопросов для каждой части речь – существительного, прилагательного, глагола. Потом – такт обсуждения вопросов. И игровая механика с баллами, которые игроки ставят себе и друг другу, оценивая, насколько люди понимают, что говорят.

Пока шла игра, Максим приоткрывал планы и вопросы. Там по-разному. Где-то – формально, а где-то реально по содержанию. А дальше я, увы, ушел.

== Кирилл Морозов. Мифы о поколениях: доказательный менеджмент ==

[https://tatarstan2026.mergeconf.ru/speakers/hr/efficiency/morozov Выступление на сайте]

'''Основное сообщение доклада: перестаньте использовать теорию поколений!''' В 2010-х, то есть уже 5-10 лет назад, была серия исследований, которая на статистике показала: на статистике теория не подтверждается. А у нас ей продолжают учить, и ловят хайп темы «как работать с зумерами». И ладно бы просто учили, но ее потом используют для построения систем управления и мотивации персонала, и получается фигня, которая наносит реальный вред. А также еще ее активно используют для оправдания: «Почему закрыл вакансию? – Так я – зумер!» или так: «Почему у тебя уволился сотрудник? – Так он – зумер, поколение такое».

А затем в докладе был серьезный разбор: '''как реально должна быть устроена компания, чтобы сотрудники были мотивированы'''. Заметим: не система мотивации, а компания в целом.

А теперь подробнее. В самом названии «теория поколений» – обман. Это – не теория, а концепция. Нет критериев, по которой она является теорией. В мире уже говорят больше с точки зрения опровержений, а к нам она докатилась и хайп ловят темы «как работать с зумерами».

Концепт, который лежит в основе, такой: людей можно делить по годам, которые привязаны к значимым событиям, и все люди, попадающие в один интервал (поколение) мыслят и действуют одинаково. Почему?

* Люди одного возраста переживают общие события – развал СССР, Великая Отечественная, или их аналоги в Штатах – великая депрессия, подъем 1960-х.
* Опыт формирует уникальные базовые ценности и привычки. Зверства бельгийцев в Африке – рубить руки за невыполнение плана. Когда на глазах у отца рубят руку ребенку – повлияли на африканцев. А вот на бельгийцев в далекой Бельгии – нет.
* Верно, что травмирующий опыт оставляет следы – но он оставляет следы и на ребенка и на ветерана. Идея, что нельзя выкидывать хлеб – у всех переживших войну.

Что можно взять из этих концептов? Значимые события действительно влияют на людей. Только влияют они по-разному: в 90-е одни накапливали капитал, а другие – выживали и у них – различное отношение, и различный опыт. Так что деление по поколением удобно, но чрезмерно упрощает.

В презентации – несколько ссылок на научные исследования, которые показывают, что корреляция между поколением и характеристиками поведения, включая производительность труда – отсутствует, и в целом разница по производительности труда у людей разного возраста ничтожна. Можно уверено утверждать, что год рождения не формирует уникальный код человека. По всему миру – все по-разному.

Почему теория поколений она вредна?

* Если мы принимаем, что она работает, то принимаем, что есть зумеры и миллениалы, и мы работаем с ними по-разному – две системы мотивации, управления и так далее. А при большем разбросе возрастов в компании надо еще больше систем делать. Если так поступают, то получается дискриминация по возрасту, которая реально приносит негатив. 

* Теория используется для оправдания. Человек таков, потому что родился в конкретный год, и не виноват в этом: «Почему закрыл вакансию? – Так я – зумер!» или «Почему уволился сотрудник? – Так он – зумер, поколение такое».

Я тут замечу, что теория поколений – реальна фигня. Наблюдения над относительно небольшой социальной группой в США обобщили на весь земной шар без всяких оснований и начали продавать как готовые рецепты. Но машина впаривания серебряных пуль работает. Так что разоблачение теории поколения – это как разоблачение рекламы или пропаганды. Если человек с мозгами, то он и так не поверит, а если без мозгов – то вряд ли поможет. Но все равно, если в результате выступления ей меньше станут верить, то оно полезно.

'''Что же реально надо учитывать?'''

* Есть эффект возраста, возрастные динамики. Черчилль: «Если в 20 лет не либерал – у него нет сердца, а если в 40 лет не консерватор – нет мозгов.» Только учитывать, что в разных социальных группах возрастные динамики проявляются по-разному. Черчилль говорил о конкретном слое британских джентльменов. А если смотреть сейчас, то чем человек моложе – тем свободнее в своих воззрениях, у него меньше привязок и он легче меняет работу.
* Есть эффект глобальных событий, и не только войн или кризисов, как 90-е, но и развития технологий: появление смартфонов без кнопок, соцсетей и так далее.
* Эффекты интерферируют: возраст влияет на реакции на событие.

Что изменилось сейчас?

* Появилась удаленка, ковид дал опыт всем, люди попробовали и это – не отменимо.
* Нет ведра с крабами. Крабы не выбираются из ведра, потому что их другие затягивают.
* Легкий переход между компаниями у молодежи: нет накопленного багажа, сильно работает интерес. У него тоже в 20 лет не было проблем со сменой работы, а сейчас стал разборчивей. 

* Поведение будет изменятся с возрастом, но мир не поменяется обратно.

'''Что все хотят? Справедливая оплата труда, признание и адекватный руководитель'''. Это – база, которую надо обеспечить. И дальше будет только хуже.

Кирилл не раскрыл, почему раньше эти требования были не обязательны. Мое мнение – рынок труда перешел от профицитного, на котором работодатель диктует условия, к дефицитному, на котором условия диктует специалист, именно он выбирает работодателя. Да, есть ситуативные колебания, и в моменте в ИТ идет сокращение проектов и люди ищут работу, но это – кратковременно, так происходит регулярно в соответствии с экономическими циклами меняется точка равновесия. А вот переход к дефицитному рынку – долговременный тренд, это следствие перехода от физического труда к умственному, при чем такому, где человеческий фактор имеет решающее значение. Это хорошо показано еще у Друкера более 25 лет назад: в его Энциклопедии менеджмента есть отдельный раздел про тренды будущего и даже отдельная книга «Менеджмент. Вызовы 21 века». Он предупреждал, что такое будущее наступит, и раскрывал механизмы. И вот оно наступило. А в ИТ про ключевую роль человеческого фактора писал Том ДеМарко еще в 1980. Все это – старые новости.

'''Каждое из требований Кирилл подробно раскрыл'''.

'''Справедливая оплата труда'''.

* Прозрачные правила: сотрудник четко понимает метрики и алгоритм повышения зарплаты. Понимать, за что платят. Во многих компаниях этого нет. Хороший вопрос: спросить сотрудника и руководителя «за что зарплату платят» и сравнить результат
* Фокус на результат: компания оплачивает реальные навыки и закрытые задачи. Удаленка породила индивидуальный капитализм: подработки или работу на нескольких местах.
* Отсутствие предвзятости – без эйджизма и другой дискриминации, а то «зумерам все, а милениалам – ничто?» Одна прозрачная система управления. Если в корпкультуре принято ругаться матом, то собирайте таких сотрудников, нет проблемы. Но подсвечивайте на входе и понимайте, что не все пойдут. Если руководитель в цеху ругается, то и на собесе нет смысла на собеседовании демонстрировать приличное поведение.
* Рыночный уровень зарплат – аналитик (и другие) реально сверяет ставки с конкуретнтами. Бренд влияет на ствки в разные стороны.

Конечно, настраивать все это сложнее, чем просто сказать «зумеры не хотят работать».

'''Признание'''.

* Регулярная обратная связь. Не раз в месяц. Практика: «сделай – прокукарекай» в рабочем чате – и это лайкают сразу.
* Публичное одобрение – руководитель выделяет результаты перед всей командой. Пикборд перед кабинетом руководителя, например.
* Внимание к идеям: никто не знает бизнес, чем вы сами. И есть направления, где сотрудники разбираются лучше. И поэтому их идеи будут ценные. Главное, чтобы они начали говорить. Клиника Фомина: есть план роста бизнеса на идеях сотрудников, и это у них существенная часть прироста бизнеса.
* Доверие к экспертизе – свобода действий, прежде всего – право на ошибку.

'''Адекватный руководитель'''.

* Четкие задачи: есть цель и она каждый день не меняется. Эффективная команда: есть цель и все в команде понимают одинаково. «Нам надо нанять продавца» – HR приводит BizDev, enterprise-продавец, а идея была – обработка потока входящих заявок, их много. Потому что цель проговорили абстрактно.
* Честная коммуникация: когда кризис – не скрывать. И про хорошую тоже рассказать. Это снижает уровень стресса, они из режима выживания и тревоги переходят в режим продуктивной работы.
* Защита от стресса – это выделил отдельно, хотя связано в предыдущим.
* Развитие вместо контроля, наставник помогает расти. Это – по желанию, если предыдущие выполняются.

== Михаил Усов из VK. Хайпкодинг: вчера, сегодня и завтра языков программирования ==

[https://tatarstan2026.mergeconf.ru/speakers/development/backend/usov Выступление на сайте]

В выступлении – личная история и размышления о том, стоит ли менять языки, изучать новые, и по каким причинам. '''Основной посыл: не стоит гнаться за модой или деньгами, а надо менять, если устал или стало скучно и ты хочешь изменений. И изменения – не обязательно смена языка, можно пойти вглубь''', в изучение фреймворков и механизмов, в Java полно таких возможностей, и в других языках – тоже.

Я бы сказал, что в чем-то это – антитренд: не идите в ширь (T-shape), копайте вглубь (I-shape). И, возможно? это действительно уместно, потому что часть людей идет вширь, вообще не вырастив ногу, а скользя по поверхности. Впрочем, еще есть деление людей на дайверов и сканеров от Барбары Шер, и она говорит, что сканер – это тоже нормально.

У него знакомство с программированием началось в детстве, с книги «Энциклопедия профессора Фортрана» – концепция описания алгоритма на примере чистки картошки была интересна и произвела впечатление.

Я замечу, что на одном из ЛАФ на афтерпати была командная игра для аналитиков: одна команда писала другой инструкцию, как приготовить сэндвичи из набора продуктов (хлеб, колбаса, сыр, все в упаковках), а другая их выполняла. Побеждала та команда, которая написала инструкцию, в результате выполнения которой сэндвичи получились больше похожими на идеал. У многих команд сэндвичи получились не съедобные – «пункт снять целофан» для какого-нибудь ингредиента забывали массово, не говоря уже о том, что масло надо размазать, а помидор – порезать. Но вернемся к выступлению.

В 5-6 классе была информатика, Турбо-Паскаль. Но тогда не увлекло. Осознанный выбор был позднее – '''php, чтобы писать динамические сайты'''. Самый популярный тогда. Был еще Perl, но он уходил. Учебник был на CD, и вместе с ним – дистрибутивы для развертывания у себя. Выбирать язык самому понравилось больше. А потом перешел на Java, обучился тоже сам.

Сегодня самый популярный – python, держит лидерство около 5 лет. Еще JavaScript и Java. А по сайтам вакансий после python – sql. Но на рейтинги опираться не стоит.

Правда, почему не стоит опираться на рейтинги, Михаил не объяснил. Выбор php был ошибкой? И зачем он про них рассказывал несколько слайдов в этом случае, тоже не понятно.

Я бы тут сказал следующее: реальный выбор всегда касается определенного класса задач или области работы: есть enterprise, автоматизация корпораций и банков, есть public web – соцсети, маркетплейсы и смежные задачи, есть ML и анализ данных, и так далее, областей много. В каждой области – свои языки, свои типы задач, своя культура разработки. И выбирать надо направление работы в комплексе. В этом смысле Михаил был прав с php, если динамические сайты – то, что нравилось.

Дальше был тезис, что мнение, будто за один язык платят больше, чем за другой – миф. Он в свое время именно поэтому пошел на Java. Впрочем, что это было ошибкой Михаил явно не сказал. Он перешел к рассуждениям про публично публикуемые уровни оплат, где лидирует Objective-C, и указал, что рейтинги не надежны, потому что не у всех вакансий указана зарплата.

Я тут опять укажу на типы задач. На Objective-C пишут драйверы и другой системный софт, этап работа требует высокой квалификации и потому стоит больше. На Java решают самые разные задачи, и спектр зарплат поэтому очень широкий. При этом на Java есть сегмент разработки в корпорациях, где платят больше не за язык, а за согласие работать в условиях токсичных политических игр. И так далее. То есть главное все-таки направление работы и классы задач, а язык – вторичен.

Языки не умирают. PHP – жив. Не стоит гнаться за новым, опасаясь, что твой – умрет. Многим языкам 15+ лет, даже тем, которые полагают «новыми».

'''Единственная причина менять язык – не перемены рынка, а усталость от языка, или желание сменить специализацию на то, где нужен другой язык – то есть желание изменений'''. Вместо смены языка можно углубиться. Например, разобраться в многопоточности Java или в конкретных фреймворках – многие знают по верхам.

Как стать сеньором? Просто не увольняться! Через 5 лет большинство уйдут, а вы станете экспертом. Но я отмечу, что это было сказано в эпоху вечных проектов, а сейчас велика вероятность, что проект закроют и ты окажешься на рынке с никому не нужными устаревшими знаниями. Я знаю таких людей, им было тяжело перестроиться.

== Сергей Иванов из Aston. Инженерия доверия к событиям: как мы ловили и закрывали дыры в гарантиях Exactly-Once после 3 месяцев продакшена ==

[https://tatarstan2026.mergeconf.ru/speakers/development/backend/ivanov Выступление на сайте]

К сожалению, у меня не получилось послушать доклад с начала. А он был на важную тему. Дело в том, что, вопреки наивным представлениям многих людей, протокола, который бы обеспечивал точно exactly once не существует. Бывает at least once с возможным дублированием сообщений, или наоборот, at most once с их возможной потерей. В некоторых средах ты можешь это настраивать на уровне потока сообщений, в других есть только поведение из коробки.

При этом в тестовых средах все обычно доставляется однократно, специальных режимов эмуляции потерь и дублирования сообщений не предусмотрено. Поэтому поведение не тестируют и не прорабатывают. А надо, да еще отдельно разбираться с доставкой сообщения и получением квитанции о его доставке и обработке.

Основная мысль выступления: учитывайте эту особенность и '''предусматривайте мониторинг и средства разбора'''. Простого применения паттернов недостаточно. Например, ведите на отправителе и получателе счетчики, и разбирайтесь, когда они разъезжаются. Это – очень правильная мысль,

Правда, тут есть тонкий вопрос: что значит, что счетчики разъезжаются, какие точки отсечки. Ведь очередь никогда не бывает пустой. А еще счетчик не гарантирует, что сообщения обработались правильно, потому что гарантия порядка сообщений тоже обычно отсутствует. А если два update на атрибут объекта пришло в другом порядке, то состояние будет отличаться, если, конечно, это не было специально предусмотрено.

А еще предусматривайте способы для исправления ситуации, если проблема диагностирована. Например, возможность повторной отправки сообщения. И это тоже очень правильная мысль.

Проблема в том, что многие техлиды уверены: всегда приходит корректные события, все линии надежны. И приходится преодолевать их сопротивление. Это подтверждаю.

== Павел Аргентов из Evrone. Древняя магия в повседневном коде: пять принципов функционального программирования в пяти языках ==

[https://tatarstan2026.mergeconf.ru/speakers/development/rnd/argentov Выступление на сайте]

Основной посыл выступления в том, что функциональное программирование – способ мышления и набор принципов, который можно реализовывать на многих современных языках программирования, он туда встроен как один из вариантов, наряду с императивным. Это было показано в примерах на OCaml, Scala, Python, JS и Rust, а на github у Павла лежат примеры еще на 11 языках вместе с песочницей, где все это можно развернуть и пощупать, в презентации была ссылка.

Функциональное программирование основано на алгебре лямбда-исчисления Черча, разработанной в 1930-е. И тогда же была их совместная статья с Тьюрингом, где было обоснована эквивалентность лямбда-исчисления и машины Тьюринга, то есть потенциальная выразимость любой программы в этом формализме.

Фишка функционального программирования – отсутствие не-локального, то есть выходящего за пределы конкретной функции, состояния. Что дает большие возможности для параллельного вычисления, актуальные сейчас.

В любом языке есть малые функциональные фрагменты – выражения, которые могут быть сложными и оформленными в виде функций, работающих только с локальными переменными. Но на ранних языках программирования (Fortran, PL/1, Algol) этим ограничивалось, более сложные конструкции нельзя было представить, требовались циклы и работа с глобальными переменными и массивами. И были отдельные языки, как LISP в которых вместо циклов можно было использовать рекурсию, а сами функции представляли собой объекты, на которые можно было ссылаться и делать на их основе другие объекты. На LISP я не работал, но дорабатывал систему генерации документации Schema и много работал с разными xsl-генераторами, так что опыт подобных языков есть, не считая fluent-выражений в современных языках, о которых речь пойдет дальше.

Постепенно функциональные возможности в распространенных языках программирования расширялись, и в современных языках они представлены очень широко, так что на них можно писать в функциональном стиле.

В функциональном программировании: программа – совокупность выражений, программа превращается в высказывание. Можно считать алгебраическим выражением. В этом отличие от императивного, где у нас – инструкция, как по шагам достичь результата. В императивном надо постоянно думать о том, в каком состоянии будет программа, особенно если пишем многопоточное. А выражения всегда вычисляются в значение, свертываются без побочных эффектов. Значение – функция, скаляр или вектор. И это, в свою очередь, компонуется в другие выражения.

Таким образом, современные языки – гибриды, они смешивают разные парадигмы. Пионером гибридного языка, сочетающего процедурную, объектную, функциональную и реляционную парадигмы стал C# 3.0 (2008). Авторы преследовали сугубо прагматичную задачу: научиться в прикладном коде включать фрагменты SQL-операторов в языковые конструкции на объектном языке нативно, то есть оперируя объектами языка, но чтобы втянуть реляционную парадигму потребовалось еще и функциональная. С тех пор еще подтянулся синтаксический сахар обеспечивающий комфортную работу с акторами и реактивное программирование – набор парадигм еще увеличился. Но теоретики до сих пор не освоили это достижение инженеров, и продолжают бороться за чистоту конкретного использования, говоря «фу» на гибриды, например, функции с сайд-эффектами и состоянием.

Но вернемся к выступлению. Павел показал ряд примеров функциональной работы на разных языках, идеи достаточно похожи. Это fluent-модель записи выражений, когда мы берем коллекцию объектов и далее начинаем на нее накладывать различные условия, проводить агрегации и так далее. При этом на каждом шаге получается производная коллекция, исходная не модифицируется – в отличие от классической обработки в цикле. А оптимизированный компилятор или виртуальная машина языка обеспечивают, чтобы эти вычисления были относительно эффективны, а не превращались в перекладывание громадных массивов данных. Но дальше все упирается в возможности этого оптимизатора и ваш способ написания, тут дело обстоит примерно так же, как с SQL-операторами выборки сложных данных. Впрочем, вопросы эффективности были за рамками выступления, примерчики были простыми.

Примеры были на пяти языках и была краткая характеристика.

* OCaml – язык богов, но лучше Haskel. B гуманный, не для ученых.
* Scala – Ocaml с другим синтаксисом и поверх JVM.
* Python – для младших научных сотрудников, не для промышленного использование, но он оказался удобен для широкого класса задач. Так же, как Perl придумали для обработки больших текстов, а он понравился и сделали общим языком.
* JS – самый функциональный из нефункциональных.
* Rust – в нем много из функционального мира.

И были примеры, иллюстрирующие функциональный способ решения.

* Считаем сумму скидок для заказов дороже 100, у которых скидка 10%. Не цикл по заказам, а fluent-выражение – последовательный набор фильтров по условиям и свертка.
* Считаем сумму четных чисел – аналогично.

В python важно понимать, что далеко не все является выражением, можно писать функционально, а можно – императивно.

Дальше примеры про работу с функциями в функциональных языках. Фишка в том, что функция является объектом, и мы можем передать ее как аргумент в другую функцию, получить композит. Когда у нас фильтрация или агрегация идет не явно заданным образом, а с помощью функции, передаваемой как аргумент. Это концепт '''HOF''' – high order functionб и мы можем не просто вызвать функцию, но преобразовать или обернуть ее: сделать '''замыкание''' – захват лексического окружения или '''каррирование''' – сделать из функции от трех аргументов трех функцию из двух, зафиксировав один из аргументов.

Отмечу, что ссылки на функции в императивных языках появились еще в C, и многое из этих возможностей ими обеспечивается. Так что границу между синтаксическим сахаром и продвинутыми функциональными возможностями можно проводить очень по-разному. Но синтаксический сахар, упрощающий сложные конструкции и снижающий когнитивную нагрузку – важен.

Пример работы с функциями – определяем функцию над элементом и применяем ее к списку. Содержательно это можно применять для вычисления налогов: отделяем вычисление конкретного налога или комиссии от функций, обрабатывающих коллекции документов и сделок. На OCaml это пишется коротко, Scala – длиннее, нужны сигнатуры каждой функции и в Rust – тоже. А вот python требует специальной библиотеки. И JS тоже, нужна ramda.

Правда, не знаю, про python, а про смысл rambda в JS я не понял. Работая над конспектом я бегло посмотрел статьи с примерами, и утверждения о том, что «код получается чище и понятнее» мне кажутся надуманными. На мой взгляд, примеры с rambda наоборот, читаются хуже и требуют дополнительных знаний.

'''Чистая функция''' – когда значение зависит только от аргументов, и ничего не изменяет – нет побочных эффектов. Это важно для многопоточного программирования, получается независимость от порядка вычислений и параллелизм. И был пример для работы со скидками – чистая и не-чистая функция.

Иммутабельность. const/val – запрет перезаписи переменной. Мы должны либо дисциплиной либо средствами языка сделать так, чтобы нечто не меняло свой внутренний мир. Это становится важным, когда мы работаем с большими структурами – коллекциями, списками, деревьями, и делаем цепочку преобразований над ними. Формально на каждом шаге получается дубль с какими-то малыми изменениями, а задача – обеспечить такую оптимизацию памяти, чтобы этого дубля не было, а были лишь изменения, и при этом еще сохранился оригинальный вариант, если он где-то продолжает использоваться. На тему, как именно это обеспечить написаны докторские диссертации. Подробности можно посмотреть в книге Окасаки «Чисто функциональные структуры данных».

Дальше в выступлении была таблица баллов за функциональное программирование в разных языках.

А потом '''кейс практического применения функционального мышления''', он интересен. Речь была именно о мышлении в функциональной парадигме, а не конкретных языках. Есть система на Ruby on rails, сделанная и много лет развивавшаяся ad-hoc. Ее надо разобрать на сервисы. Идея состоит в том, чтобы выдергивать оттуда код и укладывать в pipeline.

Это довольно сложно пересказать, потому что рассказ шел на картинках, показывающих цепочки вызовов. По сути, мы представляем обработку команды в системе как функцию – цепочку (pipeline) последовательных вызовов сервисов, по ходу которой первоначальная команда преобразуется в другие. При этом мы не уходим в рекурсию, когда один сервис вызывает другие, как в императивной реализации, а разворачиваем pipeline вызовов, реализующий success-сценарий. При этом, если еще нужна пост-обработка результата от внутреннего сервиса, то это обеспечивается в парадигме реактивного подхода, передачей функции пост-обработки.

На каждом шаге к success-сценарию еще добавляются побочные ветки ошибочных сценариев разных классов, это тоже важно и явно видно. А граница между успехом и ошибкой – пунктирная, она зависит от трактовки запроса: «сделай это» или «попробуй сделать это», на схемах это было. Например, при резервировании товара под заказ, если смогли из 3 единиц зарезервировано две, можно рассматривать как успех, хотя и не полный, или как провал. А вот если прервалась связь или сервис упал и ответ не получен – это точно ошибка.

В реализации мы опираемся не на active record, а иммутабельное dto (транспортный объект). Команда – функциональный объект, call с bind – монадное связывание «и если все хорошо – связываем». А fail – идет возврат быстрый. DO-нотация на yield вместо обычной дает иллюзию императивного программирования. Команда-функция возвращает Success или DomainError – иммутабельный value object.

В целом пример – интересный. И фишка именно в развертывании обработки в pipeline в функциональном стиле вместо рекурсивных вызовов между сервисами. В результате чего сервис может, сделав свою часть, браться за обработку следующего запроса, а не ожидать завершения.

А в заключении конспекта я хочу пару абзацев сказать про '''декларативное программирование'''. Павел активно о нем говорил, поскольку функциональное программирование принято считать частным случаем декларативного. Есть таксономия, где на верхнем уровне – деление программирования на императивное и декларативное. В императивном мы пишем машине инструкцию по шагам – что делать, а в декларативном – определяем результат, а дальше машина как-то сама его достигает. Граница проведена в 1960-е, и там было все понятно: Fortran, PL/1, Algol – императивные языки, инструкции для машины, транслируемые в ассемблер и далее – в код. А LISP, поскольку вовсю работал с рекурсивными вызовами и большими списками, которые в лоб в императивные команды не транслировались, требовал более умной реализации. В 1972 за LISP пришел Prolog с идеей «мы опишем мир в виде логических утверждений, и компьютер сам сможет решать задачи» – именно так в то время понимали ИИ. А в 1974 – SQL, реализующий реляционную парадигму работы с базами данных, его операторы работают с большими массивами данных, и реализация требует сложных преобразований. И вроде все логично.

Но дальше языки начали смешиваться: компиляторы Фортрана начали проводить крутую оптимизацию, сопоставимую с SQL, в C появились указатели на функции, что расширило использование функциональной парадигмы внутри императивного языка, появилась перегрузка функций по сигнатуре и динамическая типизация, разметка текстов для подготовки документов, позднее – декларативные описания для экранных форм, а рост производительности и памяти позволил разворачивать работу с массивами в циклы без особой оптимизации и так далее. Парадигмы смешивались, и '''деление языков на императивные и декларативные''', проведенной в 1960-е '''потеряло содержательный смысл'''. Но, поскольку оно зафиксировано в академических работах, то по-прежнему присутствует.

А вот парадигмы программирования – процедурная, объектная, функциональная, реляционная и акторная – по-прежнему несут содержательный характер, это определенный подход к мышлению. И есть еще декларативный подход, когда мы задаем систему правил или описание структуры, а дальше идет их интерпретация. Чаще всего это относится к конкретным обрластям. Например, я делал прототип в виде бессерверного приложения в броузере, где декларативно описывалась геометрия витрин торгового зала магазина и система правил выкладки обуви на этих витринах, а система порождала конкретную выкладку с учетом наличия обуви в магазине. И приличная часть кода там была в функциональном стиле, fluent-выражения над коллекциями. Кстати, прототип пошел в пром и проработал три года, прежде чем этот функционал включили как составную часть в большую систему.

Но можно делать не только конкретные приложения, но и фреймворки. Описываем типы справочников и документов и графы переходов документов между состояниями, а на выходе получаем полу-готовое приложение с таблицами структурами в базе данных, таблицами документов в интерфейсе с фильтрами для работы и формами для заполнения, а также кнопками вызова переходов для обработки документов. Понятно, что нужна еще содержательная логика, помимо CRUD, и она может быть подключена на любом языке в рамках тех же деклараций. Или включена внутрь на скриптовом языке, как в html встроен JScript.

На этом я, пожалуй, завершу размышления. В общем-то получилась отдельная статья, но пусть пока будет в этом отчете.

== Наиля Галимова из Билайн. Data QA: преодолевать хаос в данных и не сойти с ума ==

[https://tatarstan2026.mergeconf.ru/speakers/analytics/data/galimova Выступление на сайте]

Это рассказ о том, как разбирались с хаосом интеграции. Входящая ситуация – есть множество данных, команды сами их меняют, при этом интеграция снаружи команды и они не знают о потребителях. И у каждой команды – свои представления о качестве и сроках инцидентов. Поэтому, естественно, интеграция регулярно ломается, а раскопки по инцидентам занимают до месяца. Как результат – команды не доверяют другим: дублируют данные, потоки и проверки.

Чтобы разобраться с этим, стартовали большой проект Data Governance, частью которого было внедрение системы Data Contract – контрактов на поставку данных.

Нельзя сказать, чтобы интеграция была не описана вообще. Для большинства были описания в confluence, но при этом актуальность их была неизвестна, и далеко не всегда обе команды знали про это описание. Поэтому нужно было что-то более надежное, чем статьи в confluence.

Рассматривали две системы .

* SODA – там есть дата-контракты, можно проверять, настроить под себя. YAML-файл с параметрами поставки.
* Data Catalog – там тоже есть контракты. Если если туда втянуты описания корпоративных данных – то просто накликать контракты. И это – понятнее, чем YAML-файлы.

Выбрали Data Catalog.

Два уровня описания описания.

# Условия поставки данных – соглашение от поставщика широкому кругу, что он может выдать.
# p2p-контракт – это договор между поставщиком и потребителем.

Пока они причесывают то, что есть, описывая первый уровень.

Условия поставки включает описание структуры объекта данных, глубину хранения и регламент обновления, а также владельца данных и группы инцидент-менеджмента. И идет контроль с алертами. С обновлением данных есть важные нюансы: одному потребителю может быть важно время обновления, а другому – полнота получаемых данных. И надо, чтобы система это подсвечивала.

Они сделали платформу, провели пилот. Для пилота искали лояльных – тех, кто устал от вечных проблем. Встраиваются в roadmap, дают инструменты с низким порогом входа, self-service платформу, и ИИ-агентов для помощи. Сейчас масштабируют, в компании накопилось очень много витрин – помогают приоритизировать.

[[Категория:ИИ-агенты]]
{{wl-publish: 2026-04-20 17:10:48 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2026-04-27: AIconf – копилоты становятся must

2026-07-24T14:48:27Z

MaksTsepkov:

{{Conf-Ref}}
В понедельник 20.04 участвовал и выступал на [https://aiconf.ru/2026 '''AIconf'''] – конференции онтико по AI и ML. Один день, три трека, 425 человек на площадке и 485 online в Технограде на ВДНХ, параллельно с Golang Conf.

Основное впечатление было получено на обсуждениях в кулуарах конференций – они общие. '''За полгода сформировалась общая оценка, что разработка с копилотами существенно поднимает эффективность''', мидл с копилотом делает существенно больше, чем без него, работает примерно как раньше сеньор, а на сеньоре остается архитектура. Позицию джуна не обсуждали.

При этом '''эффективность команд разработки поднялась настолько, что узким местом становятся продакты''': если раньше один продакт мог работать с несколькими командами, а некоторые команды жили без продакта, то теперь ограничение по обработке бэклога на нем. Это не значит, что бэклог опустел, он по-прежнему длинный и повышение производительности разработки в большинстве компаний не означает сокращений, однако продакт делал определенную работу по каждой задаче, и он не справляется.

В целом ничего удивительного, над эффективностью разработки с помощью копилотов много работали, а над повышением производительности продакта – нет. У него, конечно, тоже есть помощь от ИИ – он может использовать чат, но в этом вместе эффективность меньше. Впрочем, думаю, что с этим тоже справятся. Отмечу, что полгода назад, на обсуждениях в кулуарах Highload и Teamlead такого общего мнения не было, были разные эксперименты, у одних – более успешные, у других – менее, и было достаточно много скепсиса наряду с энтузиазмом. Теперь скепсис ушел.

Правда, это среди руководителей разработки и активно интересующихся технологиями – на конференции ходят они. Что касается основной массы разработчиков, то ситуация, как с любыми новыми технологиями, как в свое время была с теми же вики-системами вместо ворд: энтузиастов 10-15%, остальных надо драйвить. И если в компании до 150 человек, то драйв передается просто за счет того, что люди друг друга знают и активные объединяются, специальной организации не требуется, и достаточно поддерживать процесс, и то когда их разработчиков 1500 и более, то уже надо специально организовывать пилотные зоны и демонстрировать в них эффективность другим. Но технологии принципиально не отличаются.

'''Произошедшие изменения меняют требования к разработчикам: они должны уметь работать с копилотом'''. Правда, в описание компетенции это пока не преобразовано, выступлений на эту тему не было. И на других конференциях я тоже не слышал конкретизации. Впрочем, это – достаточно общая вещь про soft skill компетенции, что такое «хорошая коммуникация» тоже раскрывают редко.

Если же говорить про выступления, то там – аналогично другим конференциям: практиками делятся, ИИ-агентов технологично встраивают в пайплайн разработки. Кстати, может, это я с опозданием заметил, но в обсуждении процесса разработки workflow поменялся на pipeline, такое прорастание devops-терминологии. И еще, забегая вперед – для технологичной встройки в пайплайн уже недостаточно описать процесс с помощью доски, требуется более детализированное описание с помощью n8n или аналогичных инструментов. Но это впечатления уже следующей конференции, SQAdays, подробности будут в отчете с нее.

Еще в терминологии звучит «кожаные мешки» про людей, при этом ИИ «жестянкой с болтами» не называют. И это такое «мы», из которого говорящий себя исключает, он говорит про других, не про себя. Ну, примерно как в обсуждении общественных тем употребляют «быдло». Так что я бы такой слэнг явно возвращал говорящему как оценку и пусть подумает.

Еще из общих впечатлений: на конференции было два выступления про научные публикации. И есть впечатление, что этот жанр окончательно стал разновидностью масс-медиа. Научная значимость публикации определяется исключительно появлением на нее ссылок, ни о какой научной новизне или других характеристиках речи не идет. Что практически размывает границы науки до полной неопределенности. В принципе, в этом нет особой проблемы, если рассматривать науку просто как сообщество. Но это – сообщество, которое претендует на общественную полезность и, на этом основании, финансирование от государства, а вот судить предлагает именно на основании публикаций. На мой взгляд, получается не очень хорошо. Впрочем, доклады были не о месте науки, они лишь давали практические советы: что изменилось в подходе к публикациям, и как их сделать, если тебе хочется или нужно играть в игру научной значимости.

Ну а теперь про выступления. Презентации уже выложены на сайте, записи будут для участников и купивших видео.

== Максим Цепков. IT-ландшафт будущего: как китайские tech-гиганты и культура меняют мир ==

[https://aiconf.ru/2026/abstracts/17449 Выступление на сайте конференции]

Мое выступление [[IT-ландшафт будущего: как китайские tech-гиганты и культура меняют мир (AIconf-2026)|'''IT-ландшафт будущего: как китайские tech-гиганты и культура меняют мир''']] было посвящено осмыслению опыта моей осенней поездки по китайским технологическим компаниям: Baidu, Xiaomi, Little Red Book, SenseTime и другим, и последующем осмыслению темы.

Фокус выступления был именно на корпоративную культуру и практики разработки, а также отношение к ИИ, которое в Китае сильно отличается от нашего. Там в инфополе отсутствует тема замены человека на ИИ и связанных с этим страхах, и разработчики тоже думают не о том, как заменить человека, а о том, как ему помочь, повысить его производительность. И, отмечу, такие задачи решать гораздо проще, чем полную замену, что позитивно влияет на скорость прогресса в целом. И возмущения глупостью LLM тоже нет: недостаточную сообразительность воспринимают как естественное в период обучения, и полагают, что роль человека как раз в том, чтобы поскорее научить ИИ, чтобы он мог лучше помогал людям. В общем, ИИ – партнер, а не конкурент. Подробности – на слайдах презентации и в других моих статьях. И в моей новой книге: я надеялся успеть выпустить ее к конференции, но не успел, выйдет в мае. А еще можно смотреть вебинар [[Влияние технологий на изменение мирового порядка и глобальную конкуренцию (Вебинар СШЭ)|Влияние технологий на изменение мирового порядка и глобальную конкуренцию]], там, правда, меньше ИТ-фокуса, зато больше раскрыта тема развития мира в целом ходе технологических революций.

== Дарья Шатько. Как мы внедрили LLM-судей в автоматизациях клиентского сервиса: подход, грабли, уроки ==

[https://aiconf.ru/2026/abstracts/id10704551 Выступление на сайте конференции]

Дарья – из Yandex Crowd Solutions – поддержка Яндекса: 80+ сервисов, 4.5 млн обращений, 2700 операторов. Задачи ИИ – ботик, помощь оператору, агенты. И надо оценивать качество работы ИИ, для этого создан ИИ-судья, который оценивает качество. Не всех ответов, а выборочно, и его оценки сопоставляются с оценками экспертов, на которую отправляется 3-5% оценок судьи. То есть такая постоянная система мониторинга и оценки качества, нацеленная на выявление проблемных мест для дальнейшего улучшения. В выступлении – рассказ о настройке ИИ-судьи. Я бы отметил, что это не сильно отличается от настройки организационной системы для качественной поддержки, просто она теперь состоит не только из людей, которых мы обучаем, но и из LLM-агентов, которых мы настраиваем.

Контекст формируем через поиск по документной базе и обогащение контекста. С помощью агентов добавляем информацию о клиенте и его заказах.

Чатбот – понятная история. Flow: кнопка «чат с поддержкой» → сообщение в свободной форме → классификатор интента → (ответ | кнопки | уточнение) → (LLM-рефраз по шаблону | ответ RAG | ответ агента) → Вопрос решен? → (завершение | оператор)

Как замерять качество? Есть классические метрики бота: CSAT удовлетворенность пользователя (очень полезная, в ней разные сценарии), AR доля решений ботом (80%), возвращаемость – повторные обращения по той же причине, ART – время решения проблемы пользователя. Метрики – понятные, но соотношение CSAT и AR может быть любым и надо погружаться внутрь.

Способ – посмотреть на Flow и оценивать шаги.

* Первое – классификация интентов. Там есть свои метрики для классификаторов. Но есть вопрос: откуда брать ground truth – что было на самом деле. Для этого LLM может постфактум посмотреть диалог и провести классфикацию – сравнить и начальной.
* LLM перефразировала ответ по шаблону: насколько здорово она это сделала, насколько хорошо сработал промпт. Смотрят расстояние Левенштейна – был ли перефраз вообще. А если сработал – то насколько хорошо: тон ответа, учет контекста диалога и галлюцинации.
* Поиск о RAG: что-то нашли, насколько поиск был релевантным: точность, релевантность и полнота индекса, по которому поиск. Полнота очень важна, какая-то информация может просто отсутствовать в индексе, и ее никогда не найдут.
* Проверка ответа: good-middle-bad.

Для агента – тоже ответ, как RAG. А еще адекватность использования инструментов по trace: правильность выбора, хорошая работа самого инструмента (быстро и правильно выдал ответ) и эффективность шагов – у агента могут быть циклы, стоимость и скорость. А еще количество эскалаций агентом на человека и качество плана.

Итого, как устроить оценку качества? Нужны диалоги, данные и контекст клиента, историю обращений, маршрут клиента в диалоге и диалог с оператором.

Критерии хорошо-плохо. И разметка – ее может делать эксперт, но интересно, чтобы ее делала LLM, возможно – другая. Почему проверка той же самой LLM работает, если ответить она не смогла? потому что даем больше контекста, у нас есть полный диалог, и мы не ограничены временем ответа. А еще нам надо лишь оценить ответ, а не решить задачу.

Судья может сравнивать ответы – это на этапе настройки, пилоты и эксперименты. А в проде – оценка по критериям, потому что там нет правильного ответа. Но если решал оператор, то его ответ можно рассматривать как целевой.

Структура промта – есть статьи, где уже приведены шаблоны. Там задача, критерии и рассуждения про шаги, которые можно сгенерить. И если есть потоки – можно альтернативно взвешивать. Фреймворки Ragas, DeepEval, Langfuse – там много заготовок, можно от них стартовать. И там же подходы по логированию и интерфейсы. Это дает quick start.

Как подключать в прод? Количественные метрики – смотрим на дашборд. Проверка на судью – не 100%, а какая-то доля. И не весь диалог, а по кусочкам. И 3-5% из потока на судей идут на экспертный контроль качества для проверки и донастройки самого судьи.

Улучшение промпта. Качество смотрим по отношению к экспертной разметке, и сравниваем. Промпт-инжиниринг для судьи – как для обычных промптов. SGR пробовлаи, не помогло, а DSPy как библиотека улучшений – помог.

Калибровка. Смотрим распределение судьи и экспертов. Например, может оказаться, что судья более строгий, чем эксперты. И можно корректировать оценку качества от судьи статистически. Только надо учитывать, что экспертная оценка не всегда чистая, есть разногласия. Замечу, что это прикольно: не исправить судью, а откорректировать его оценку – как нормировка для ЕГЭ, и лично я смысла тут не вижу, уш лучше коридор доп3устимого честно менять.

Перефраз – оптимизация по DSPy – смотрим оценки судьи. И калибровка – таблички работы и пояснения, как с этим работать.

Кейс. Агент в поддержке промокодов – ответ на вопрос «почему я не получил бонус»? Как проверить агента? Вычитывают агента, и дальше закладываем в типы ошибок, чтобы был мониторинг. Но если много вычиток, то 10 вариантов – это 10 оценок, это тяжело. Вместо этого группируют критерии в граф, и идут по нему, проблемы ловят, не доходя до конца. Более того, часть проверок можно сделать rule based без LLM, вплоть до 9 из 10 на правилах.

Самая частая проблема при настройке судьи: мы подсунули диалог судье, сверяем с экспертами, но не учитываем, что эксперты имеют гораздо больше доступа к контексту, чем дали судье – они никогда не сойдутся.

Судья – это тоже часть автоматизации. У него есть стоимость. Для полноты ответа судье тоже хорошо бы подкинуть контекст, качество поиска – ограничение для агента. Надо держать разумную оценку. Если судью построили – его тоже на дашборд, мониторим сходимость с экспертами, она может разъехаться в любой момент.

Монетизации в мониторинге нет, но в углубленной аналитике они это смотрят, в том числе ответы судей учитывают.

Обновление промпта для судьи. Хотелось бы автомата: мы смотрим на ручеек от экспертов, и как разъезжается – запускаем докрутку. Однако, изменения чаще всего из-за изменений в продукте, о которых эксперты знают, а LLM почему-то нет. То есть надо не промпт усовершенствовать, а контекст увеличивать, тут другой процесс.

== Виктория Костерина. Разметка против реальности: как фрод выявляет слабые места датасета ==

Система контроля работы курьеров. В процессе выполнения заказов курьеры делают множество фото, по ним ИИ контролирует соблюдение ими правил работы: опознание самого курьера, выполнение требований по ношению формы и так далее. В целом – понятный процесс: есть оценка ИИ и выборочные проверки людьми, следят за сходимостью метрик, а когда они начинают расползаться – значит в модели какой-то провал, надо его выявить и дообучить модель.

Люди – изобретательны, форму просто накидывают, подставляют фото вместо реального лица, делают крупное фото 3d-модели артефакта крупным планом и так далее. При этом часто это уже есть в датасете, просто надо сначала с помощью ручной разметки и ML найти такие фото, затем на них дообучить модель, которая классифицирует поток фото от курьеров.

== Дана Миндзаева из Cloud.ru. ИИ в enterprise: на что вы тратите миллионы ==

Cloud.ru предоставляет облака, в том числе – для хостинга ИИ-агентов, и они совместно с Высшей школой бизнеса провели исследование об использовании ИИ. Опросили 100+ специалистов, провели 30 глубинных интервью и 15 анализов кейсов внедрения. Я бы сказал, что часть результатов – очевидные, а другие – не обоснованы. Что очевидно: 96% организаций планируют расширять внедрение ИИ, при этом 2/3 проектов остаются на стадии пилота. На мой взгляд, это – логично.

Из этого делают вывод, что ИИ-агенты на пике ожиданий, хотя обоснованность такого вывода сомнительна: вполне может быть, что до пика еще далеко. А то, что 2/3 проектов по новой экспериментальной технологии не выходят из стадии пилота – вообще нормально. Потому что проект по новой технологии – это же исследовательская штука, он далеко не всегда завершается успехом. То, что любой проект должен быть успешен – дурацкая идея, хотя и распространенная в корпоративной и государственной среде, не только российской.

То, что компании тратят на эти проекты миллионы, цифрами не подтверждено. Повышение производительности – показано, хотя и оговорено, что «с измерением есть трудности». В презентации – диапазоны, 10-45%, а среднюю цифру в 30% я слушал во множестве источников. При этом получается срок окупаемости в 5-7 лет и это – основание для закрытия проектов. У меня тут понятный вопрос: а что, такой срок был не очевиден для старта проекта? Потому что если 30% производительности дают 5 лет окупаемости, то что, были какие-то основания предполагать многократный рост? Или не учли какие-то очевидные вложения? Или об этом вообще не думали на старте, кто-то просто осваивал бюджет исследований?

О низком качестве проектов как таковых, и чистой работе по освоению бюджета говорит и то, что в ходе проекта вскрывалось низкое качество или отсутствие процессов или отсутствие данных. Это, конечно, может быть не очевидно на входе, но это надо проверять сразу и обычно для этого достаточно 1-2 дней работы аналитика, в крайнем случае – недели. Вряд ли в обследовании были проекты, которые закрыли через неделю работы одного человека, обычно такую штуку проектом не называют. Отмечу, что среди многочисленных проблем с проектами внедрения ИИ низкое качество самих проектов упомянуто не было.

Способы увеличить шансы на успех в презентации были, но они – очевидные и без каких-либо метрик и кейсов, которые бы говорили, в какой доле проектов именно они применялись и как повлияли. Среди них прикольно смотрится «поддержка руководства без ожидания окупаемости» – понятно, что если руководство просто согласно лить деньги без ожидания результата, то проект будет вечно успешен. Равно как и проблемы тоже перечислены без какой-либо статистики, а их формулировки напоминают типичные оправдания, потому что большинство таких причины можно было проверить на старте.

== Панель от хайпа к прибыли – встройка ИИ в продукт ==

Спикеры обсуждали практическое применение ИИ и вайбкодинг. Я делал заметки, и дальше – некоторое обобщение без авторства. Я его делаю для себя, чтобы выделить главное, уложить в свою картину. И наверняка там много интерпретаций.

ИИ – разнообразен и часть из него – давно известное и успешное, приносящее деньги: рекомендательные системы, классификация, облегчение генерации текстов, например, при подаче объявлений в авито, и так далее. С ними – понятно, и надо прагматично мерить эффект, что рекомендации реально помогают пользователю, а не превращаются в навязчивую рекламу, от которой он идет на другой сайт.

Другие – новые, например, быстро создать прототип вайбкодингом, и с ними тоже достаточно понятно: мы сокращаем время и стоимость проверки гипотезы. И в этой области происходит качественный переход: такой прототип или MVP может создать человек без технических скилов, раньше была нужна помощь разработчика или инфраструктура. И это меняет рынок, вместо того, чтобы приспосабливаться к ограничениям промышленных CRM и платить подписку, люди смогут использовать небольшие собственные решения или дорабатывать чужие.

Впрочем, я бы это рассматривал просто как очередной такт по снижению точки входа: раньше и для создания сайта нужна была помощь разработчика, а теперь люди сами справляются. Ну а теперь они еще будут создавать простую CRM или таск-трекер для своих конкретных задач. Или даже собственную систему обработки заказов – на панели был пример.

Принципиальная разница в том, что ты не должен менять процессы под коробку, а можешь сделать решение под свои процессы. И даже когда привлекаешь разработку, а не делаешь сам, стоимость снижается: «нужна система управления заказами» теперь не 20 бэков и 10 фронтов, а 2-3 разработчика для руководства агентами. Кстати, аналогичный кейс рассказывали на курглом столе по вайбкодингу на Merge: три года назад некоторую систему пришлось заказывать студии разработки, они делали год и до конца оно не взлетело, а осенью 2025 аналогичную систему на новых технологиях один разработчик сделал за пару месяцев с помощью вайбкодинга. Правда, система была аналогичной, то есть было представление о требуемом решении, менялась технология – это сильно упрощает задачу.

То, что написано с помощью вайбкодинга, можно развивать и поддерживать. Тут нужны технические скилы, но не для того, чтобы что-то сделать руками, а чтобы грамотно поставить задачу на вайбкодинг – чтобы было покрытие тестами, мониторинг, логирование, разворачивание продукта и так далее. ИИ это умеет, но ему надо грамотно ставить задачу. Так что это получается и без прямого участия человека в конкретном проекте, может быть платформа-настройка. Именно поэтому cloud не просто GPU сдают в аренду, а делают AI-factor.

Отмечу, что это тренд этого года Андрей Карапатый в 2025 придумал термин «вайбкодинг», а теперь говорит про agentic engineering.

При этом понятно, что так создавать будут относительно небольшие продукты, увязывая их скриптами, встраивая Excel или боты для взаимодействия с человеком, помимо простых форм и так далее. Такой следующий этап микросервисов, когда они не только в бэке, но и на фронте получаются. Это тоже меняет рынок.

При этом с вендорскими продуктами с этой точки зрения далеко не превосходно, многие из них не имеют обвязки, позволяющей их подключить к современным средствам мониторинга или развертывания, надо ковырять для этого дырочки, и это – недешево. Так что свежий вайбкодинг может быть и лучше старого legacy. Более того, ИИ хорошо анализируют легаси, есть кейсы, когда анализ нашел «несущие швабры», которые люди могли бы и пропустить.

Стоимость ИИ-разработки – разная, зависит от того, разворачиваешь ли на своем железе или арендуешь его в облаке, или арендуешь платишь за токены. В целом это аналогично расчету для инфраструктуры, которая тоже может быть своя или в облаке и с разной оплатой, просто там появились дополнительные развилки и новый вид расхода – токены для арендуемых моделей. За год стоимость токена упала в 50 раз.

И это – не только на этапе разработки, важно сводить стоимость при эксплуатации. Если ты встроил LLM в CJM и он что-то делает для клиента – дает ли это экономический эффект или просто дополнительную статью расходов для тебя? И бывает, что делаешь пилот на Gemini, вдохновляешься, а на простой модели фигня получается.

Я тут отмечу, что ИИ на минималках тоже работает, на ArchDays был доклад при использовании ИИ как части облачного решения для сайтов интернет-магазинов, и там прод обеспечивают 2 арендованных full time GPU с простыми моделями, которые учат с помощью Qwen и других более сложных, арендуя под них свободные мощности GPU по необходимости.

При этом качество моделей постоянно повышается, успешный пилот на топовых моделях может через полгода стать реальностью на простых.

Ответственность при использовании ИИ – на человеке. Когда встраиваем в продукт – фильтр информации, цензура адекватности, контроль данных пользователей, защита от промпт-инъекций. Претензии-то будут к продукту. А когда используешь копилот, то ответственность на разработчике, мало ли что он тебе посоветовал. Когда с помощью ИИ пишешь письма или презентации – тоже самое. Это не значит, что нельзя использовать, наоборот, используешь, потому что эффективно, но проверяешь с его же помощью. При этом только ты понимаешь, насколько качественно нужно проверять, или достаточно посмотреть по диагонали – собственно, как с драфтом, который написал новичок.

ИИ усиливает сотрудника и в плохом и хорошем. Тут интересная модель, сотрудников при работе со смыслами можно представить как призмы: рассеивающая, фокусирующая и прямая. И вот '''усиление ИИ рассеивания смыслов сотрудником приводит к тому, что сотрудник становится не пригоден''', реально с некоторыми пришлось расстаться. Раньше это не так проявлялось. К разработчикам появились дополнительные требования по взаимодействию ИИ, включая ответственность. Поэтому конверсия найма уменьшилась.

По проектам – разработчики побежали быстрее, а как ускорить всех. Генеративную часть – дизайн, код – ускорилась, а согласование с бизнесом или безопасность – нет, и надо перестраивать процессы. И меняются ожидания каждой роли, включая использование ИИ. ИИ является акселератором, тупых делает тупее, а умных – умнее. Есть проекты, которые делают без аналитика – руководителя с ИИ достаточно, есть продукты без дизайнера, вопрос тестирования не решен, и непонятно, больше их будет или меньше. Есть проекты, где вместо 5 – 2, и есть большие, где вместо 5+5+5 сидит 1+1+1.

Изменения идут очень быстро, сильно меняется норма и какой она станет – неизвестно. Однако, ИИ – интересно, и это драйвит людей, тут плюс. Вообще есть три аспекта организации: принуждение (нормы, регламенты), поощрение (культура, интересные задачи) и поддержка (менторство). Нужны все три, два дают ленивых котов или выжженное поле.

Полтора года назад поставили практику: если кто-то уходит, не открываем вакансию, а пробуем заместить ИИ. И еще ИИ – обязательно для роста, есть 2 часа в пятницу на ИИ. При этом HR – передовики, они больше кандидатов отсматривают.

'''Что будет самым важным изменением в 3-6 месяцев?''' Это кажется короткий срок, но смотришь, что было осенью, и понимаешь, что изменения велики.

* В отдельных отраслях наступит похолодание и разочарование – вложенные средства не дают отдачи. Но где-то он будет показывать эффект: кодинг с помощью ИИ качественно меняет эффективность. И еще в каких-то увидим изменения.
* В России не очень хорошо в экономике, и это будет идти. Сокращать будут тех, кто рассеивает. Можно попробовать использовать ИИ для удержания своего табурета.
* Токены – еще подешевеют, подтянутся открытые модели к фронтирным. Все будет обвешено агентами для решения рабочих и личных задач. 

* Увидим рост в продуктах, где ИИ направят на сокращение пользовательского пути. От «хочу сайт» до «есть сайт». А хочется – чтобы научились считать профит.

В командах интересные изменения: появился контекст-инженер, его задача – взаимодействие с бизнесом, а дальше он заказывает в разработке отдельные ручки, а результат собирает сам. Я бы лично назвал эту позицию аналитиком, и я помню времена, когда были мечты о полном конструировании приложения аналитиком или даже бизнесом в каком-6нибудь дизайнере. Недавно на той же волне пришел low-code/no-code, а сейчас получается следующая волна.

== Александр Панов. Жизнь научной статьи по ИИ: от идеи до A* ==

Александр – из института искусственного интеллекта AIRI. В выступлении – рассказ о том, как сейчас устроено написание статей. У него перавя статья была в 2002 на школьную конференцию про реальный эксперимент, потом – во время учебы в Новосибирске (2009), а с 2016 он кандидат, и уровень журналов и конференций, на которых он выступает, все время повышается. Основной тезис: можно активно публиковаться, если поставить это своей задачей и научиться это делать.

При этом понимать, что публикации влияют на твою репутацию как ученого, и как именно. Тут Александр говорил, что будущее науки определяют люди, которые выбирают путь серьезного исследования, а не быстрой публикации. Может, это и так, но у меня из выступления сложилось впечатление, что репутация в научном мире сейчас ничем не отличается от журналистов или писателей: большинство смотрят на список публикаций, и не читает дальше названия, иногда заглядывают в аннотацию, а читать дальше – большая редкость. И, кстати, ИИ тоже так делает.

Итак, рекомендации Александра.

* Есть типовая структура, ее надо придерживаться: постановка задачи, метод, результаты, выводы, будущая работа.
* Цель публикации: идеи для широкого круга и детали результатов для тех, кто разбирается, поэтому детали часто уносят в Приложения (и там часто фигня, которую даже рецензенты не смотрят) .
* Название суперважно. Даже абстракт не читают.
* '''Очень важна первая картинка''', это visual abstract, и она должна быть недалеко от начала.
* Our contribution в конце абстракта – три фразы, для людей, на них смотрят, принимая решение – читать или нет. 

* Аффиляция автора – указание места работы или учебы, оно важно с учетом нынешней ситуации, поэтому используют псевдонимы – как выступленяи под белым флагом.
* В начале хороший маленький кусочек про теорию – мы подумали. Но не слишком длинный, много думать – вредно, а читать – скучно.
* Псевдокод, если речь идет про разработку или что-то похожее.
* Эксперименты – подтверждает, что все проверили, с бенчами сравнились и так далее.

Как создавать? Конечно, с помощью ИИ.

* Сначала – генерация идей. Здесь ИИ ускоряет процесс. Агенты ускоряют, но не делают сами. И в малой группе делаем прототип статьи.
* LLM – есть сервисы, что не пропустили. Так все работают, сначала – спроси LLM, потом уже люди смотреть будут.
* Работа с коллегами – прожарка с внутренними. Пусть прорецензируют.
* Выложить препринт на arXiv – застолбить место. Там тоже проблемы с санкциями, но есть способы. В принципе, на препринт можно выкладывать любую фигню, сгенерированную LLM, так реально делают. На него не ссылаются, кроме случаев известных авторов или институтов. Но он уже индексируется и попадает в обзоры LLM, так что есть вероятность, что про тебя узнают. 

* Дальше подаем на workshop – это малые сессии на больших конференциях. Там ниже требования, и там будет обратная связь.
* Дальше – дорабатываем и полноценно на конференцию.

Отказ – обновили и отправили. Получили отказ на большую статью – сделали на ее основе маленькую демо-статью на другую конфу, там приняли. И параллельно можно доработать и запустить полную на еще одну конфу. Надо следить, чтобы пересечений не было. Одна из статей у них крутилась три года на 6 конференциях и была принята.

Рецензия: о чем статья, сильные стороны и слабые в большом количестве. На большинстве конференций есть возможность один раз ответить рецензенту, убедить, что конфетка. И есть сеньор рецензент – он пишет итоговое решение.

Цикл публикации – 9 месяцев.

'''Сейчас никто не говорит про новизну'''. Полезности для сообщества – достаточно. Если старую идею оформили так, что на нее ссылаются – этого достаточно.

Репозиторий с кодом и звездочки – важно. Страница проекта и статьи – обязательно, можно сделать инструментами. И можно сделать публикацию на habr или где-еще, популярным языком изложить сложные идеи – это не мешает.

Разница между конференциями и журналами. У конференции понятные сроки, ограниченный объем публикации, и надо обязательно приехать. Зато можно продвигать статью, чтобы цитировали через постеры и общение. Презентация на конференции – постер. 1.5 часа идет сессия постеров: авторы стоят у своих постеров и общаются. Так 90-95% выступлений. Есть еще доклады на 5 минут, мини-сессия, но туда мало проходят. У некоторых конференций есть демо-треки, туда вообще почти всех берут. Короткое видео некоторые требуют, но их никто не смотрит.

В журналах – большой объем (хотя сейчас ограничивают до 7 страниц), но сроки рецензирования не ограничены, до 2 лет. Зато возможна переработка, и ездить никуда не нужно.

'''AIscientist'''. Идея была 5 лет назад, тогда не взлетело. Сейчас китайцы не стесняются использовать LLM, есть целая линейка инструментов. Есть DeepReviwer – и он точно лучше человека. Есть полный цикл: DeepScientist и CycleResearcher. Без человека КПД – низкое, супер-идей они не создают. Но человеку – помогают. В презентации – список инструментов, которые они используют. В том числе генерация кода – ИИ пишет лучше студента. А презентация – notebookLLM.

Как у них устроен процесс? Есть семинары для генерации идей. ИИ-суммаризатор обсуждения и набор экспериментов – из него идет бэклог. Через неделю – обсуждаем, повторяем цикл.

Что будет в будущем? Он думает, что будет площадка обмена snippet-идеями, через которую общаются ИИ-агенты, чтобы отслеживать пересечения с другими исследователями, и можно кооперироваться. Насколько я понимаю, сейчас ArXiv и другие площадки препринтов можно примерно так рассматривать и использовать, просто пока никто не делает – предпочитают вариться в собственном соку в знакомой среде.

'''Вопрос'''. Как понять, что LLM сделала хороший обзор? Ответ. Это как с поиском: вы доверяете Google, что он поиск правильно выдал? Надо смотреть, читать, проверять.

== Андрей Гетманов из ИТМО. Как мы разработали и внедрили систему проверки кода в научных статьях и дипломных работах ==

Рассказ о попытке с помощью ИИ решить проблемы защиты проектов и дипломных работ, которые студенты на халяву – когда есть красивый отчет, за которым нет ни кода ни экспериментов. На формальное требование «приложить код или исходные данные» студенты отвечают столь же формально – кладут в репозиторий что-нибудь, что может не соответствовать содержанию диплома или отчета. И они попробовали решить задачу с помощью LLM, которой передается отчет и код: она выделяет главные тезисы из текста и пробует найти им соответствие в коде, а также проверяет текст и код на соответствие набору критериев.

В целом работа понятная, но до «разработали и внедрили» тут еще далеко. Пока получено, что на тестовых примерах, в качестве которых используются накопленные в архиве работы, LLM дает какие-то разумные результаты. Но, наверное, совсем фигню отсекает. Детали – в презентации и выступлении.

А мне тут не понятно следующее. В теории отсекать халяву – задача научного руководителя. Похоже практика такова, что они это реально игнорируют, и никаких санкций за это не получают, раз явление носит массовый характер. А если так, то LLM – не поможет. Ну, напряжет студентов побольше поработать генератором, чтобы получить более правдоподобный фейк. Отмечу, что саму работу по прорыве ведут в отрыве от научных руководителей. Было бы, наверное, логично, если бы именно они первыми использовали такие проверки, и не на дипломе, а гораздо раньше, на проектах. И не с целью отсечь фейки, а с целью повысить качество самих студенческих проектов, дать рекомендации. Но нет, с преподавателями группа не взаимодействует, и нацелена именно на контроль – что подтверждает мою гипотезу про саботаж.

[[Категория:ИИ-агенты]]
{{wl-publish: 2026-04-27 13:59:04 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2026-04-30: SQAdays - ожидаемо, хорошие выступления и много нетворкинга

2026-07-24T14:47:59Z

MaksTsepkov:

{{Conf-Ref}}
Участвовал 24-25 апреля в очередной SQAdays. Впечатления и темы конференции – ожидаемые. Интересно, что встраивание ИИ-агентов в пайплайн обработки задач приводит к тому, что для реализации пайплайна доски уже недостаточно, требуется более формализованное описание в системах типа n8n, в котором можно увязывать между собой шаги, выполняемый человеком и ИИ-агентами, а также интегрироваться с внешними системами. Об этом было несколько докладов. Кстати, на этой конференции я впервые заметил, говоря про выполнение задачи перестали использовать термин «workflow», а начали говорить «pipeline» – после включения ИИ в исполнение конвейер поставки распространился на весь путь, начиная от создания новой задачи.

Еще, слушая выступления, поймал себя на следующей мысли: сейчас все активно разбираются с ИИ и ее ошибками, и, в зависимости от позиции, работают над их предотвращением или громко утверждают, что с таким ИИ работать нельзя. В любом случае, ошибки – на слуху, поэтому, слушая людей, их тоже ловишь. И уже хочется, чтобы '''люди тоже не совершали таких ошибок в рассуждениях и выступлениях''', с которыми мы боремся с ИИ, чтобы они '''рассуждали не хуже ИИ'''. По факту, это '''поднимает планку требований к человеку: он должен быть не хуже ИИ''', а в чем-то лучше, иначе зачем нам человек в конкретной позиции? При этом человек может и должен использовать ИИ. Просто чтобы его использовать хорошо, надо самому обладать соответствующим уровнем, уже четко подмечено, что ИИ – усилитель, он может усиливать структурное мышление, а может – генерацию потока слабо связанного текста и зависит это от того, кто к нему обращается.

И еще одна штука, подметил гримасы современного инфополя. Термин «владение софтскилл» из описания компетенций, не связанных с конкретной специализацией (там – hard skill), а имеющих общий характер – хорошая коммуникация и мышление, понимание организации работ и тому подобного, превратили в требование ненасильственного общения, в том числе с теми, кто на вас наезжает, а также соглашательства на любые требования, отсутствие возражений и безропотное принятие обременений со стороны руководства. Такая трактовка была в выступлении Ксении Сергеевой, который занял второе место на конференции, но не только у нее – это было контекстом многих реплик на круглых столах и обсуждениях в кулуарах, где под «хорошими софтскилл» подразумевали именно это.

В общем, дрейф понятия вполне понятен: начальство и общество в целом берет удобную ему часть и начинает направлять людей в эту сторону, удерживая их в детской управляемой позиции. Вообще проблема современного общества состоит в том, что подростковый бунт, который служит этапом формирования взрослой позиции самостоятельного члена общества, начал продолжаться во времени неопределенно долго, вплоть до старости. Раньше ты либо преодолевал его и становился самостоятельно принимающим решение взрослым, способным к конструктивному сотрудничеству с другими, а не постоянным конфликтам, либо откатывался назад в позицию управляемого ребенка, подчиняющегося установленному порядку. А теперь гуманность, вернее, слабость школьного принуждения, приводит к тому, что остаются вечные подростки, отстаивающие свои границы и конфликтующие со всеми, а общество изобретает все новые способы принудить их к комфортному взаимодействию. Пропаганда ненасильственного общения и толерантности – один из них, но под капотом «так поступают взрослые» скрывается «стань безропотно принимающим социальные требования ребенком».

Впрочем, это я отвлекся, возвращаюсь к конференции. Общие впечатления на этом завершены, переходим к выступлениям. Начну я со своего, дальше будут выступления про ИИ, затем – технические выступления, а затем – про все остальное.

== Сергей Атрощенков, Максим Цепков, Андрей Бровко. Круглый стол по Инженерной культуре ==

Это был интерактив с залом. Основные тезис: инженерная культура – не набор процессов, а часть мышления, mindset. Процессы тоже важны, но с ними как раз все понятно. На круглом столе не было цели придти к единому мнению, идея как раз была в обмене разными практиками как ответ на проблемы. И это, замечу, тоже часть инженерной культуры: инженера не интересует точность формулировок, его интересует практический результат.

Поэтому определений культуры были разные, у выступающих и из зала. Я тут приведу свое. '''Инженерная культура – стремление к практическому применению результата в сочетании с опорой на знания, и инженера беспокоит, когда это не видно'''. Важны обе части: опора на знания без заботы о результате – ученый-исследователь, а только забота о результате приводит к изобретению велосипедов – расходу энергии на давно решенные задачи.

Конспекта не будет – я активно участвовал и не записывал, так что смотрите запись. На второй день обсуждение было продолжено на баркемпе, и его запись тоже есть.

Интересный вопрос, который разбирали: каков механизм, с помощью которого культура ест стратегию на завтрак. Пришли к выводу, что это всегда касается изменений, смысл которых неясен или вызывает скепсис, при этом процесс (и культура) компании таковы, что это не становится предметом открытого обсуждения, а проявляется через тихий саботаж. Иногда – с неожиданными последствиями, я знаю историю (старую) как в одной инженерной компании в ответ на жесткое введение начальства метрик по обработке инцидентов команды устроили неофициальную игру «слака», задача – перебросить инцидент смежникам так, чтобы твой SLA был выполнен, а они свой выполнить не смогли. При чем отношение было именно как к прикольной игре, с неофициальными обсуждениями в чатах, как ловко вчера одни сделали других.

Изменение культуры – возможно, и это – не очень долго. Серьезное изменение процессов – не сильно быстрее, и оно часто тоже должно затрагивать культуру. Ведь и то и другое – изменение привычного поведения на иное. Изменять культуру надо делать технологично, это хорошо описано у Марка Розина в книге «Успех без стратегии», второе издание вышло под другим названием – «Стратегия чистого листа». Есть [[Rozin-NoneStrategy|мой конспект]], одобренный автором.

На этом я заканчиваю заметки про круглый стол, смотрите запись.

== Максим Цепков. Эксперименты и опыт – часть пути к успеху: mindset китайских tech-гигантов ==

Мое выступление '''[[Эксперименты и опыт - часть пути к успеху: mindset китайских tech-гигантов (SQAdays-2026)|Эксперименты и опыт - часть пути к успеху: mindset китайских tech-гигантов]]''' было посвящено осмыслению опыта моей осенней поездки по китайским технологическим компаниям: Baidu, Xiaomi, Little Red Book, SenseTime и другим, и последующем осмыслению темы.

Фокус выступления был именно на корпоративную культуру ИТ-компаний и на те практики, которые были бы уместны для тестировщиков. Я пробовал приземлить рассказ о ценностях компании, автономности команд, отношении к ошибкам и другим темам на конкретные аспекты работы команд. Потому что такие вещи, как быстрая проверка гипотез, инициатива в продвижении к цели или уважение к знаниям актуальны не только для Китая.

И про ИИ в выступлении тоже было: оно в Китае сильно отличается от нашего. Там в инфополе отсутствует тема замены человека на ИИ и связанных с этим страхах, и разработчики тоже думают не о том, как заменить человека, а о том, как ему помочь, повысить его производительность. И, отмечу, такие задачи решать гораздо проще, чем полную замену, что позитивно влияет на скорость прогресса в целом. И возмущения глупостью LLM тоже нет: недостаточную сообразительность воспринимают как естественное в период обучения, и полагают, что роль человека как раз в том, чтобы поскорее научить ИИ, чтобы он мог лучше помогал людям. В общем, ИИ – партнер, а не конкурент.

Подробности – на слайдах презентации и в других моих статьях. И в моей новой книге: я надеялся успеть выпустить ее к конференции, но не успел, выйдет в мае. А еще можно смотреть вебинар [[Влияние технологий на изменение мирового порядка и глобальную конкуренцию (Вебинар СШЭ)|'''Влияние технологий на изменение мирового порядка и глобальную конкуренцию''']], там, правда, меньше ИТ-фокуса, зато больше раскрыта тема развития мира в целом ходе технологических революций.

== Александр Ткачев. No-code/Low-code в тестировании: ускоряем процессы с помощью n8n ==

[https://sqadays.com/ru/talk/144886 No-code/Low-code в тестировании: ускоряем процессы с помощью n8n]

Это был рассказ о встройке ИИ-агентов pipeline обработки задач.

Не только выполнения тестирования, это обеспечивают автотесты, но и для других активностей тестировщика: анализ прогонов, подготовка тестовых данных, доработка автотестов, общение в чатах и так далее. Где-то ИИ может помочь больше, где-то – меньше, но область использования будет расширяться, и нужно обобщенное решение, которое позволит подключать агентов, где необходимо.

Чтобы работа агента была релевантна, ему нужен контекст, который получается из разных систем, и свои результаты он тоже уметь доставлять в системы. И для этого процессы были описаны с помощью n8n, что позволило подключить необходимые интеграции и сочетать шаги человека с шагами ИИ.

Платформ для описаняи процессов много, они смотрели zapier, n8n, workauto, make. Их требованиям – развернуть локально, бесплатно и открытые исходники удовлетворил только n8n. Это визуальный конструктор процессов, low-code и много интеграций с приложениями и api и ИИ внутри. Workflow состоит из node, информация подается на вход и выдается на выход, json. Зоопарк нод большой, более 1000 интеграций.

Типы нод:

* flow – управление потоком и триггеры
* взаимодействие с пользователем: выбор варианта, одобрения – почта, мессенджеры
* AI
* action in app – slack и прочее
* core – http и код
* data transform – работа с данными

Пример процесса: получить данные с сайта, записать в БД и отправить в телегу, все обеспечивают стандартные ноды с настройкой. Можно еще встроить jscript прямо в настройке (например, дату получить из текущего времени), или специальную ноду code.

Первым автоматизирован такой процесс: есть тест-кейсы в jira с шагами (test step), это надо превратить в сценарий BDD на Gherkin, и приложить результат к той же задаче. В Jira делаем кнопку, которая запустит процесс – web-hook. Запуск – получение данных http-запросом из jira → ИИ-магия локальной LLM для создания BDD-сценария → приложить результат к Jira → отправить инфо в телеграм.

Для генерации сценария BDD – Qwen: промпт на английском, векторизация, извлечение эталона, обогащение запроса, блокировка творчества – только заданные шаги и приложение результата.

* Если в тест-кейсах фигня – LLM не напишет сценарий, поэтому их причесывают вручную
* Запрос без шума – никаких лишних слов и выражений
* JS лучше – без коробки
* RAG отдает весь контекст. Модель настроена на 20 значений – 20 эталонных тест-кейсов, и они должны быть со всеми шагами – иначе она выдумает. Для качественной генерации 20 эталонных сценариев и промпты дорабатывали.
* Обработка ошибок – процессы падают, об этом надо знать и предусматривать

Можно не только BDD, а любые процессы: автоматическая проверка pull request, генерация тестовых данных, мониторинг стендов и управление, синхронизация статусов, создать баг из чата, анализ логов и так дал..

По процессу BDD метрик нет. А вот анализ pull request полностью автоматизирован и сейчас полностью полагаются на ИИ: если она одобрила – ОК, разбираются только там, где проблемы нашла.

== Ариадна Букатина из Райффайзен. AI для коробочного решения ==

[https://sqadays.com/ru/talk/144999 AI для коробочного решения]

Рассказ об использовании ИИ для тестирования коробочного решения: генерация тестовых данных, загрузка данных через API на Lua вместо UI (решена без знания Lua), агенты для написания автотестов и анализа результатов. Успешно, двигаются дальше.

А теперь подробнее. Коробочное решение – готовый инструмент, который внедряется за день. У него есть жесткие правила валидации, частые релизы и черный ящик для тестирования. В нем есть фронт и бэк, 15 java-сервисов и около 100 интеграций.

Задачи – постоянный регресс релизов: проверка межкоробочного взаимодействия и сервисов, работа с тестовыми данными там, где не автоматизировано, проверка соответствия данных в справочниках между фронтом и бэком – могут быть отличия по настройкам, написание быстрых автотестов и проверка покрытия.

Ручное тестирование долго и трудозатратно, автоматизация тестов и генерации данных требует опыта разработки. ИИ смягчает требования к опыту разработки, и это быстро. У них следующие кейсы.

# Нужно собрать тестовый json тестовых данных по формату. Надо сгенерить, при этом проверить, что они не дублируют существующие. С помощью ИИ создали генератор, который решает эти задачи.
# Проверка межкоробочного взаимодействия. Ко фронту доступ к UI, через него создавать данные долго, хотим скрипт. Коробка позволяет загрузить файл на Lua, чтобы загрузить данные, но тестировщики не знают Lua. А ИИ – знает, и с его помощью сделали.
# Написали агента для написания автотестов, и написали агентов для анализа. В результате автотестов могут писать любой человек в команде. Планируют создавать агентов для сборки проекта, unit-тестов, end-to-end тестов.

Три месяца назад они не поверили бы, что это возможно. А тут – успешно освоили.

Вопрос. Что скармливаете для генерации данных? Ответ. По критериям формирования полей описывали форматы – и он создает данные. ФИО ИИ сама знает, как выглядит, для счетов даем маски – она порождает и проверяет, что этого нет.

LLM развернуто локально, его поддерживают отдельная команда, и оно – не только для них. Промпты пишут сами по-английски и по-русски. Есть интеграция с jira и testops, агенты подключаются, видят задачи и описания, Агенты пишут тесты, но пока не обновляют сами, это делают вручную, проверяя результат агента.

== Владислав Григорьев из X5 Tech. Встраиваем Ай-Ай в автоматизированное тестирование добровольно-принудительно ==

[https://sqadays.com/ru/talk/144671 Встраиваем Ай-Ай в автоматизированное тестирование добровольно-принудительно]

Задача – внедрить Ай-ай в процессы тестирования, не сильно ломая уклад. И чтобы это было масштабируемо. Генерить тесты по API или UI можно без подготовки на любой модели, и это у них работает 1.5 года. Рассказ про следующий шаг – включение в процессы. Для этого нужно много частных решений, получаемых вайб-кодингом и объединяемых в процессы с помощью n8n. А для качественного вайб-кодинга используют Spec Driven Development (SDD).

Нужны несколько вещей.

* RAG – чтобы артефакты были адекватны нашей системе. Важно добавить контекст в минимальном объеме – чтобы работало, но не выжирало токены.
* MCP – чтобы было максимально автоматизировано, не требовало копирования из чатиков.
* Агентские скилы – есть, но они локальные и прикладные, в выступлении их не будет.

MCP-сервер с помощью вайб-кодинга может сделать любой. Он любит python. Не отличается от любого микросервиса. И важно описать, что именно каждая ручка делает, иначе его не будут использовать.

Но есть проблемы, с которыми надо разбираться. Пример – mcp-сервера kaiten. Основное – теряется контекст, сервер возвращает слишком много данных. Kaiten любит возвращать жирные ответы с громадным количеством данных (до 2 млн – и нейронка уйдет в нирвану) за неприличное время – 5сек.

Для описания процесса используют n8n. В презентации Flow ACE – конкретный пример, куча блоков, от входа чата до выхода. Его можно использовать через чаты или API. При этом возможен гибрид, например, в MCP-wiki получение отчета – автомат, а перенос в wiki – вручную.

В чем проблемы vibe coding?

* Гниение контекста: у любой LLM он ограничен, и чем меньше вкладывать – тем больше вероятности, что будет хорошо.
* Черный ящик. ИИ может придумать по-разному, он любит усложнять задачи.
* Следствие – архитектурный дрейф: 10 человек в проекте вайбкодят, ИИ им предлагает разные решения – и архитектура разъезжается. Будет не проект, а свалка.

Что предлагает SDD.

* Четкое понимание требований и целей. Говорим нейронке как делать можно и как нельзя.
* Прозрачность и контроль заинтересованных сторон.
* Оптимизация работы с ИИ
* Масштабируемость и поддерживаемость.

Как внедрять в новый проект? Команды – очень разные. Но суть – одна. Смотрим, что есть в компании, на что можно опереться.

Если проект – старый с кучей документации, то скормить 10М в один промпт – не получится, и это не нужно. Надо сделать минимальный RAG, и это – ручной стартовый труд. Получилось 11 страниц на старте, сейчас – 15. И еще кастомизация для подзадач.

'''Заведение багов в kaiten'''. Сделали Flow, web-морда с минимальным количеством текста, приложен RAG, на выходе – задача.

Берем маленькую часть проекта, и пробуем сделать агента. Например, параметры для автотестов. Их можно использовать как образцы, и LLM по нему сможет сделать код. Но есть ограничение локальной модели – и там надо сделать план – развернутый промпт: роль (разработчик python), Задача, Контекст, Форматы данных – примерами кода, да еще с комментариями на русском или английском. И получается хороший результат.

Если с нуля – требования, specification (spec.md) определение как писать (техническая архитектура), операционная декомпозиция, исполнение.

ИИ может усложнять задачу: вместо скрипта, который запускает cron, делает обработку через rabbitMQ – облачное окружение, работа фоном и так далее – это надо отсекать, описывать как не надо, и что именно можно делать по шагам. В презентации пример – правила генерации кода. И надо говорить, какие правила для каких задач использовать. А дальше – как надо проверить результат – linter, проверить у других, запустить автотест, ожидаемый результат, создание merge request. Задача по linter – тоже самое, роль, контекст, входные данные – команды, надо взять лог и посмотреть, что было затронуто.

Когда все это написали – просим написать новые автотесты. Агент работает и порождается автотест, учитывающий специфику проекта и стиль. Например, не просто вызвать end point и проверить результат – а еще посмотреть в базу. И получается достаточно хорошо структурированный и комментированный код. Но вайбкодят не все, есть что пишут руками, код после LLM тоже правят, но мало.

'''Позиция инженера изменилась, мы не сами делаем руками, а посредством ИИ-эльфов. И это становится требованием к инженеру. Понимание кода – тоже нужно.'''

Цель внедрения: 90% автоматизации и бесшовный релизный процесс. Метрики считают именно такие – сколько артефактов прошли через нейронки, смотрят через графану. Правда, на мой взгляд, это метрики по объему, а не по эффективности – как формальное покрытие юнит-тестами. Но, с этим тоже разберутся, как и с юнит-тестами разбирались: там тоже сначала обеспечивали хорошее покрытие, а потом доводили качество. Или 6не доводили, и оставались юнит-тесты формальными, так тоже бывает.

== Владимир Кочегаров. От хайпа к хаосу: провалы ИИ в больших компаниях, и чему они учат ==

[https://sqadays.com/ru/talk/144387 От хайпа к хаосу: провалы ИИ в больших компаниях, и чему они учат]

В выступлении – несколько разных кейсов, когда системы с ИИ давали какие-то проблемы. По мнению автора, они учат тому что ИИ не совершенен. На мой взгляд, ИИ как технология тут совершенно не при чем. Это – инструмент, и в большинстве случаев его применяли вполне осознанно для достижения конкретных целей. А еще разгон подобных историй в инфополе – часть большого процесса, призванного сеять недоверие к любой новой технологии, и страх жизни в нынешнем мире в целом для остановки научно-технического прогресса. Начат на Западе в начале 1970-х как составная часть концепта «управляемого развития». Китай тут оградился, там страха перед технологиями нет – поэтому он быстро идет вперед. Там отношение «ИИ пока учится, поэтому совершает ошибки – давайте учить вместе, чтобы было быстрее».

Теперь кейсы из выступления, некоторые – с моими комментариями. Один из кейсов – фейковый, Владимир с самого начала предупредил, что так будет, предложил подумать над этим, а в конце – раскрыл интригу.

* Deloitte (это консалтеры) с помощью ИИ от Antropic сделал проект для правительства Австралии. В процессе нагенерили столько фейков, что у них потребовали назад деньги. Мой комментарий. По мнению Владимира это учит, что надо проверять, что там ИИ нам выдал. Думаю, консалтеры это знали, но были уверены, что прокатит, потому что всем без разницы, что написано, деньги не за это платят. Таких проекты распространены, просто раньше для генерации использовали студентов-стажеров, а тут сократили затраты. А дальше что-то пошло не так в политических играх. 

* AstraOps. Инженер дал запрос ИИ «составь расписание встречи, как если бы ты был исполнительным директором» – система запрос приняла, а поскольку у нее был доступ к реальным календарям исполнительного директора – отменила 47 встреч, 23 перенесла, отменила задачи в Jira без всяким подтверждений. На мой взгляд, так тоже бывает, это вопрос прав. Хотя в конце Владимир сказал, что именно этот кейс был фейком.
* Taco Bell – внедрили голосовой помощник. Клиент через него заказал 18 тысяч стаканов воды. А еще людям было прикольно, они издевались надо помощником. Мой комментарий: люди – разные, чего бы не поиздеваться над беззащитным существом. А что неопытный сотрудник на линии поддержки плохо понял клиента и сотворил фигню – сплошь и рядом. ИИ тут не лучше и не хуже.
* Интернет-магазин внедрил AI-бота, который мог дать скидку – он дал, а потом заказ увеличили, так что скидка стала недопустимой. Владелец попробовал отменить заказ – заказчик побежал в суд. Был кейс, когда топовую модель автомобиля попробовали купить за 1$. Мой комментарий: да, ИИ не очень хорошо понимает реальный мир, но при этом во всех случаях покупатели сознательно пытались его обмануть, и им удавалось. Он пока более простодушный чем люди – но массовое мошенничество по телефону в последнее время показывает, что люди тут тоже уязвимы.
* ChatGPT попробовал работать как психолог, и посоветовал подросткам совершить самоубийство – AI* сейчас отбивается от исков матерей. И роботы, которые делали простые операции, а привели к инсульту. Мой комментарий. Эти материалы я не смотрел, но IBM Watson в свое время сдал квалификационный экзамен для врачей и начал участвовать в консилиумах. И когда консилиум принял неудачное решение, врачи-участники свалили вину на него «он нам неверно посоветовал». Ну, IBM закрыл проект. Сколько консилиумов в результате сработали хуже, чем могли бы – неизвестно. И с роботами тоже самое: есть количество доступных врачей, роботы – увеличивают это количество, но обладают дополнительными рисками. Как со стажерами: им же тоже доверяют какие-то операции впервые после обучения. Так что это все – нормальный процесс обучения. 

* Карибский кризис. Станислав Евграфович Петров – получил на пульт сигнал о запуске ракет со стороны США. Первая, вторая. Но он решил оценить систему подтверждения – не увидел, и решил не докладывать. Причина оказалась солнечный зайчик.

== Денис Кияница и Илья Голос из Т-Банк. E2E-тестирование BPMN-процессов ==

[https://sqadays.com/ru/talk/144514 E2E-тестирование BPMN-процессов]

Рассказ про тестирование бизнес-процессов на сложном кейсе – когда каждый процесс сам по себе работают, а проблемы возникают на стыках процессов, логически связанных друг с другом.

Для автоматизации процессов применяют Comunda. Процессы в ней живут неделями: банк обрабатывает запросы не мгновенно, а если от клиента требуются документы – он тоже предоставляет не сразу.

Конкретный кейс. Клиент меняет вид деятельности, если для нового нужна лицензия, то на клиента ставят запрос лицензии. Если во-время лицензию не принесли – накладывают блокировку в филиалах. И бывает ситуация, когда клиент принес разрешение, уже после того, как по задаче блокировки пошел свой процесс. Основной процесс проверки видит, что лицензию представили, отменяет задачу блокировки. Но процесс блокировки – не в курсе, что его задачу отменили, он получается в зависшем состоянии. Понятно, что тут дырка: отмена задачи должна как-то подействовать на связанный с ней процесс, но ошибки – бывают.

Изолированные тесты этот баг не поймали – каждый кусочек корректен, и даже каждый процесс целиком в тестах работает – там смежные процессы поменяли на заглушки. Баг на стыке процессов – подпроцесс блокировки не знает, что задача отменена и ждет бесконечно.

Средства Comunda недостаточны: bpmn-assert: там проверяем шаг, а не маршрут. Embeded-comunda – там мокают делегаты, так что идет заглушка. Проверка на реальном стенде звучит отлично, но там 13 точек отказа, невоспроизводимость и нельзя параллелить много тестов.

Тесты QA – отдельный Cradle-проект. Поднимают Kafka и Comunda со всеми топиками, и еще mini-S3. B отдельный Waremock сервис в отдельном контейнере для внешних сервисов. Они не меняют движок, и не меняют таймеры. Приложение не знает, что общается с заглушками, изоляция через данные, через уникальный ключ теста. В презентации было подробнее, с примерами тестов.

С таймерами работают так: в Comunda таймер – этот специальный процесс, который ждет запуска в некоторое время. Они инициируют запуск, меняют blockDate – дату ожидания и dueDate в таблице джобов, при этом время сервера не меняют. Понятно, что при таком подходе может быть искажение бизнес-логики, если она как-то завязана на время, например, рассчитана на то, что процесс поднимают каждый рабочий день, и в нем есть отдельная логика, если от предыдущего запуска были выходные, то есть прошло больше одного дня – эта логика не сработает. Но с такими случаями они не сталкивались.

Как устроена синхронизация с асинхронным движком? Тест отправляет событие в Kafka, Comunda запускает процесс. Тест не знает, на каком шаге процесс. Но тест должен знать, что процесс уже готов к принятию – проблема event-driven системы. Sleep – долго, особенно когда 200 тестов. Можно встроить callback в движок для тестов – но мы ломаем границу. Как решение – pull состояний: Comunda дает rest api проверки, ждет ли кто события, с фильтром execution id и state id. И включили ошибку ignoreExceptionByDefault. Прежде, чем исследовать процесс – убедись, что он готов.

Обработка ошибок. Comunda, когда делегат падает с ошибкой, делает – то идет retry, а только потом ставит инцидент. Они делают промотку, и потом проверяют, что поставлен инцидент.

Как запускать несколько потоков параллельно, в том числе – когда идет несколько тестов на один процесс, чтобы моки не перепутались? Они делают id тестов, по которым Wiremock опознает нужный тест, и использует его данные. И в комунде тоже фильтрация процессов по нужным id.

И дальше подробности выполнения. 249 тестов в 2 потока за 20 минут, при этом каждый прогоняет bpmn-процесс. Дало много профита. В частности – ловят баги по зависанию процессов.

На чем спотыкаются.

* Как проверить, что событие не отправлено в Кафка. Надо подождать и посмотреть, что нет события – 500мс
* 90 секунд – awailability. Им больно
* Бесконечно растущая мапа событий. Пока не стрельнуло, но архитектурно – хрупко.

== Эдуард Ермолов из X5 Tech. Чистая архитектура и метапрограммирование в рамках AT ==

[https://sqadays.com/ru/talk/144818 Чистая архитектура и метапрограммирование в рамках AT]

Выступление – про применение принципов чистой архитектуры к архитектуре тестов. В целом понятный рассказ. Но вот почему для тестов чистая архитектура – благо, то есть какие проблемы ее применение убирает, показано не было. Известно, что выделение слоев или абстракций усложняет код. И сначала кто-то декларирует, что обращаться напрямую к атрибутам в бизнес-логике – плохо, надо каждый атрибут обернуть методами get и set, а затем делают синтаксический сахар, чтобы оборачивание было автоматическим и автору кода не приходилось об этом думать, и все хорошо, пока это не приводит к сложным багами и накладным расходам.

Или декларируется, что core не должен вызывать бизнес-уровень, поэтому на него невозможно вынести содержательную обработку ошибок и сделать обобщенные методы, которые умеют, когда надо, делать retry и тому подобное, поэтому для обработки ошибок делают шаблоны, используемые на прикладном уровне. И так далее. В общем, когда архитектурные ограничения переносишь в другую область, то хорошо бы все это показывать, а не просто говорить о том, как бы нам соблюсти постулированные принципы. Это было мое отступление, а теперь вернемся к самому выступлению.

Что такое – архитектура тестов? Это ответ на вопросы: где лежат тесты; где инфраструктура для запуска; как тест обращается к api, напрямую или через прослойку; что меняется, когда меняется end point, как быстро въехать в проект. Цель архитектуры – сократить количество тестов и уменьшить количество изменяемых файлов, чтобы изменение модели затрагивало 1 файл, а не 40 тестов.

Принципы

* Фреймворки и драйверы – внешний слой, знает о всех зависимостях Кафка и т.п.
* Интерфейсы – перевод http в бизнес-моделей, зависят от интерфейсов, не знают про зависимости.
* Сценарии исопльзования – знают про домен, не знают фреймворки и интерфейсы.
* Доменная область не знает ни про кого, там маленький кусок.
* SRP – каждый модуль отвечает за свою зону
* DIP – тесты от абстракций, а не реализаций

Дальше было приземление на тесты с примерами, это сложно пересказывать, смотрите в вступлении. А затем – основная идея выступления: '''метапрограммирование''' – разработка обобщенного кода с помощью декораторов. В результате мы пишем общая логика – в одном месте, а методы генерируем автоматически. Код читается как спецификация. Новый компонент – без изменений во фреймворке. '''Чистая архитектура задает задачи, а метарограммирование их решает'''.

Как это делать – были примеры, текст надо смотреть в презентации, а здесь я поясню подход. Например, retry – принимает число попыток и варианты exception. Определяем decorator, и внутри wrapper, который делает цикл попыток вызова функции. Есть функция upload_file – и ее оборачиваем в decorator, чтобы было с повторениями ошибок. И типы ошибок тоже передаем. Аналогично – логирование и другие общие штуки. Код сильно сокращается.

Можно использовать init_subclass – он контролирует порождение элементов класса. Как для франчайзи: есть правила, которые диктует владелец франшизы, и есть вариации внутри этого. И там пример, BaseAPI – чтобы всю обвязку сделать.

И можно динамически порождать REST API – оборачиваем все в get, post, put, delete.

Тестирование – тоже можно писать обобщенно, делая минимум по атрибутному представлению.

Естественно, есть оборотная сторона: сложность отладки, неявное вызов и поведение. Это требует определенной культуры разработчиков. И точно не стоит использовать для того, что сделано в одном месте – тут как с выделением процедур, начинаем при повторении кода, а не заранее.

== Павел Саенко. Как мы создали систему интеграционного тестирования ==

Павел – из Инфотекс, средства защиты. Много продуктов, которые объединяются в комплексы, и у которых много внешней интеграции. Пример комплекса – несколько продуктов по отражению атак, там 3-4 продукта – хостевой сенсор, сетевой сенсор, аналитический центр, сервис обновлений (в презентации была диаграмма).

Продуктам требуется сертификация ФСТЭК и ФСБ. А еще надо уметь на стенде воспроизвести конфигурацию клиента, которая может быть достаточно специфическая, чтобы разобраться в проблеме.

Для всего этого они сделали генератор тестовых стендов, который по клику может сделать нужную конфигурацию. Тут сразу несколько идей.

* Если есть тесты и стенды – хорошо бы объединять в сложные сценарии
* Собрать из готовых сценариев сложный о запросу дизайнера
* Хаос заказчика – проверять отказы оборудования.

В результате получилась полноценная среда для тестирования. Назвали Tern – крачка. Планируют выложить в open source.

Компоненты.

* Редактор тестовых сценариев
* Наработанная библиотека написанных тестов для переиспользования
* Редактор сетевой топологии, сети – чтобы там развернуть
* Библиотека активов – настроенные машины, или конфигурируемые – генератор трафика и угроз
* Система деплоя для разворачивания продуктов
* Механизм исполнения сценариев, движок.
* Подсистема мониторинга
* Генератор отчетов

Основа – Camunda. Отлично подошла для сценариев. Редактор сценариев bpmn.io из нее. Библиотеку активов – сами, и деплой тоже. А исполнение – через комунду. Мониторинг – стандартные, генератор – свой, allure не используют – отчеты простые. Переиспользование сценариев – не так сложно, но не бесплатно. В презентации были конкретные диаграммы как примеры.

Режимы работы системы.

* Свободная практика – запуск произвольного теста в нужной конфигурации и нужной сети – эмулируем проблему заказчика, чтобы разобраться, что сломалось.
* Квалификация – тестирование релиза, несколько продуктов совместно в комплексе. Проверка релиз-кандидата. Максимально быстро базовые сценарии.
* Гонка – запускаем длительные тесты, включаем режим хаоса, делаем неверные действия пользователя и так далее – то, что будет у заказчика. Может месяцы крутиться.

С осени работает на одном из комплексов. Что достигли?

* 4 бага в продуктах, которые до этого не было выявлено, за счет длительных тестов.
* Смоделировано 6 сложных проблем от заказчиков, нашли причины
* Перевели часть проверок релизного тестирования, сократив регресс

Удалось совместить несколько вещей, которые изначально хотели – автоматическое выстраивание нового окружения, переиспользование тестов, облегчили жизнь по подготовке инфраструктуры. И получилось запускать длительные тесты с приближением к реальной эксплуатации, вплоть до нескольких месяцев.

Систему делали 2 года, 5 человеко-лет – сравнимо со стоимостью релиза продукта.

Дальше – довести до целевой архитектуры. Пока там не все есть по работе с сетью, там сложно. И подключить другие продукты – масштабирование. Планы по agentic AI – тоже есть. И выложить в open source – тоже есть.

== Анна Покровская из СБЕР. Тестируем обратную связь: как QA превращает жалобы пользователей в UX-гипотезы ==

[https://sqadays.com/ru/talk/144764 Тестируем обратную связь: как QA превращает жалобы пользователей в UX-гипотезы]

Идея доклада понятная: побудить инженеров поддержки, в роли которых часто работают тестировщики, разбирая и воспроизводя инциденты, еще и порождать из этого опыта идеи усовершенствования продукта. Но для этого надо сначала поднять уровень мышления, перейти от уровня описания функционала по шагам, к уровню решения проблем пользователя. Надо воспринимать CJM на двух уровнях: какие кнопки пользователь нажимает, и какую ценность он получает, решая свои проблемы.

Каждую фичу придумывают для решения каких-то проблем и рассчитывают, что CJM изменится, но часто бывает, что CJM не меняется или меняется не так, как ожидали. А бывает, что фичу решили скопировать из других решений, вообще не думая о CJM – а он у ваших пользователей отличается

Это было в замысле выступления. В выступлении – много разной практики, но, на мой взгляд, ясно и структурировано донести замысел не очень удалось, получился больше поток абстрактной информации про все хорошее и правильное, например, обратную связь, без детального приземления на практику. Впрочем, это – мое мнение, вполне возможно у вас будет иное восприятие.

Когда надо менять? Когда пользователям неудобно или когда пользователи не делают то, что вы от них ожидаете.

Зачем QA выдвигать гипотезы? Меньше интуитивных решений, больше влияния на продукт – реальный инженер пользовательского опыта.

Как можно узнать про пользовательский путь?

* Обратная связь – то, что пишут и думают пользователи о том, что вы делаете.
* Опросы. Но они коварны, пользователи любят искажать в хорошую сторону, им лень обосновывать.
* Оценка. «Насколько вы довольны?» Это суперпримитивно, все ставят оценку как в школе.
* Геймификация – Яндекс очень любит. «Что особенно понравилось» – и варианты, что именно (забота, вежливость, комфортное вождение, …). И это увеличивает обратную связь.
* Реакции: лайк/дизлайк/эмоции/абстрактные реакции. Что значит смайлик клоуна – могут быть очень разные штуки, и оно зависит от настроения.

На что влияет обратная связь? На качество продукта, помогает приоритизировать задач, что важно. Что доработать, убрать, изменить… Коммуникация, которая помогает изменяться по живому опыту.

Саму обратную связь надо протестировать. Все нормально, Ужас, Плюс – неясно к чему относится. Она очень субъективна и эмоциональна.

Обратная связь – симптом болезни. Болит горло – что за этим? Так же как «не смогла оформить заявку».

Тестировщик – тестирует не код, а весь продукт. Есть тестировщики, которые смотрят детально, смотрят на продукт глазами пользователей – не по инструкции, а по интуитивному пользовательскому пути и найти не очевидное.

Вы можете работать с обратной связью, вы знаете пользовательский путь, есть логи, куда пользователи фактически нажимают и как идут.

Вам написали «Новый дизайн улучшит пользовательский опыт». Надо понять: что должно улучшиться и как именно изменится опыт.

Есть раздел Faq и он был грустным – просто очень длинный список каких-то типовых запросов. Это не работает – пользователям трудно найти вопрос. Проверили, что если разбить на блоке по тематикам – будет лучше, классно. И будет не 100500 вопросов большим списком, а 5-10. Что должно улучшиться? Пользователям станет проще искать ответы. И дальше надо определить метрики – как поймем, что им стало легче. Метрика – будет меньше вопросов к продукту, меньше комментариев «мы не понимаем». Но оказалось, что пользователям вместо классификации нужен поиск.

Дальше была россыпь примеров косяков UI, некоторые из которых – следствие того, что не учли региональные и языковые особенности. Классный пример, когда в диалоге обратной связи крестик «закрыть окно» поставили на 5-ю звездочку, ты хотел отказываться от оценки, а реально оценивал на 5.

Тут был тезис про то, что главное «много воздуха» и контрпример китайского маркетплейса. На мой взгляд – притянуто за уши, потому что маркетплейс-то в Китае успешно работает, а что он россиянам кажется перегруженным, китайцам наплевать – они на свой рынок делают, и это – правильно. Да и наши маркетплейсы и интернет-магазины не сильно отличаются от примера, на мой взгляд. Вообще у маркетплейса может быть две задачи: показать больше рекламы, чтобы получить доход от нее, или сделать удобный поиск нужного. Разные маркетплейсы ищут баланс по-разному, а люди – пользуются разными, идет конкуренция. И если рассказывать такие примеры, то надо все эти механизмы показывать в комплексе, а не говорить кратко «нет воздуха».

Дальше был пример википедии, и к ней оказалась претензия не в том, что много букв (этого как бы ожидают), а в том, что ссылки плохо подсвечены на черно-белом экране, поэтмоу дальтоники не увидят. Я тут верну, что в википедии – много тем, и достаточно логично, когда «по умолчанию» стоит то, что удобно большинству, а кому не удобно – могут переключиться. Вот если проблемы на первом экране регистрации из-за слабой контрастности, как было в следующем примере, то да, фигня получается. Вообще дизайнеры любят пастельные тона с малыми градациями цвета, так что в яркий день ничего не видно, это проблема.

Важно, что такую проблему надо решать не технически, а организационно – согласовать и утвердить чек-лист проверок, который должен быть удовлетворен. Потому что каждая проверка стоит времени. Об этом Анна не говорила. А то, что у Google Chrome есть тула «отрисовка», с помощью которой все это можно эмулировать на обычном мониторе, показать с точки зрения пользователей с разными нарушениями – да, полезно.

Что надо проверять, когда меняется функционал? Влияние на основной сценарий: сломает она его, или улучшит? А что с альтернативными сценариями? А если сломается – насколько сильные потери? И проверка граничных сценариев. Проверить старых пользователей – что они подумают про новый релиз. Проверить наоборот, новых пользователей. Проверить разные языки интерфейса. Длинные тексты – на мегашироком мониторе, или на маленьком, экраны разных размеров. Это все правильно, но каждая проверка стоит затрат, и надо искать компромисс. Было бы интересно, если бы СБЕР поделился чек-листом: что именно они проверяют в своих приложениях, а если бы еще рассказал логику формирования (например, почему именно такие размеры экрана проверяют) – вообще круто.

Инструменты Feature toggle – можно тестировать в проде, раздавать фичи на разные группы, в том числе измерять различие в CJM. Пользовательская аналитика – клики активности пользователей, в том числе по дням недели. И можно строить фактический пользовательский путь. И проводить канареечное тестирование – смотреть использование фич.

Вопрос. Что делать с умирающими фичами, ведь их жалко выкинуть? Ответ. Надо смотреть, фича же была для какого-то сценария, надо понять, что с ним случилось, и докуручивать, чтобы сценарий выстрелил, или согласиться, что умерло.

Вопрос. Мы собираем, доносим до продактов, а они не смотрят. Ответ – надо показывать профит – время пользователей, бюджеты, повышение лояльности. Не просто «пользователи жалуются», а что изменится у пользователей.

Вопрос. А с противоречиями: 55% говорит «поиск классный», а 45% «поиск ужасный». Ответ. Надо понимать, что пишут. Больше смотреть на негатив – выявлять реальные неудобства пользователей. Многие просто смирились, не все пишут. Я бы ответ дополнил: возможно, пользователи приходят на поиск с сильно разными задачами, и для решения одних он удобен, а для других – нет. Например, при поиске мебели одним надо заполнить большую комнату, а другим – точечно купить один шкаф, который поместиться в заданный простенок. И надо разбираться со сценариями, важно, дорабатывая для одних, не сломать удобный поиск другим.

Вопрос. Как собирать обратную связь от операторов? Ответ. Есть наблюдение, как работает пользователь (Анна назвала это гемба, но гемба, все-таки, это самому поработать за пользователя).

Вопрос. Как убедить бизнес, что новая идея будет вредна? Я знаю, как работают пользователи, и я знаю, что пользователям не понравится? Ответ. Кратко – никак. Надо понимать идею бизнеса. Бизнесу может хотеть поменять продукт специально, чтобы изменить пользовательский путь. Я бы сам так резко не отвечал, потому что у бизнеса могут быть неверные представления о пользователях. Но надо действительно для начала понять его идею на уровне изменения CJM, а не создания фичи, а дальше можно проблематизировать, что вот этим не понравится настолько, что они уйдут, и быть готовым защищать это.

== Дмитрий Пуртов. QA-отдел, который слышат: как выстроить архитектуру взаимодействия QA со всеми ==

[https://sqadays.com/ru/talk/144815 QA-отдел, который слышат: как выстроить архитектуру взаимодействия QA со всеми]

Рассказ о том, как QA перестать быть островом, который просто проверяет фичи, а начать активно взаимодействовать с бизнесом, чтобы к нему прислушивались.

Они разрабатывают HotelTech платформу – автоматизация гостиничного бизнеса. Бронь отеля, управление отелем, цены конкурентов, гибкое управление ценами, работа с отзывами и так далее.

Многим знакомо, когда QA видит проблему и предлагает решение, и его не слышат. Вопрос: это разовая или регулярная ситуация. Если разово – нормально, все бывает. А если из квартала в квартал – то проблема.

Софты тут полезны, но это по конкретному случаю. А надо менять ситуацию системно, '''наращивать влияние и внедряться в контур принятия решений компании'''. И они это сделали, об этом – рассказ. А про софты – в конце.

'''Сначала – разберитесь внутри''', если у вас бардак – вас не будут слушать. У них 52 продукта, 28 тестировщиков на 150 разработчиков, команды живут по-разному, и вечно перегруженный руководитель. Была сильная команда и историческая память – на этом жило. Но потом пошел бурный рост, пришло много новых, люди поменяли позиции – и система начала сбоить. А он как руководитель пришел на частные вопросы и ручное управление.

Решение – отдать тактические решения лидам. В компании была неформальная система наставничества, и они ее институализировали не только для обучения, но и для решения вопросов, поделив области между лидами.

Область – это группа проектов, определенная контекстом: гости, платежи и так далее – воспроизвели у себя деление бизнеса. В каждом контексте – свои требования. Head – стратегия, лиды – тактика, qa в командах – операционка. И если не работает смежный сервис – начали идти к лидам, а не к head, чтобы договаривались по связям.

Что делали?

* Релиз менеджмент. Был хаос, когда команды катят когда хотят. Лиды посидели, написали процесс, потом в рамках команд – адаптировали, но без противоречий верхнему регламенту.
* Дежурство в команда. Сделали в одной команде, заработало – распространилось через лидов.
* Процессная группа – лиды и опытные тестировщики. Их задача – взять практики из команд, изучить, и раздать всем, возможно, поддержав стандартами.
* Метрики тестирования. В одной команде тестировщик заинтересовался, дальше лиды подхватили и потом ушло в процессную группу – там метрики описали, и потом еще dashboard сделали.

Система стала управляемой. Для него – 80% операционки ушло, обработали инициативы и внедрили. И у них – самый высокий happy job, выше среднего о компании и индустрии.

Порядок у себя навели, теперь – в компанию. Есть OKR, за CTO – техстратегия. Его задача как руководителя QA – встроиться в стратегию инициативами. Три цели на разных уровнях: процессы, инструменты и глобально на тех.отдел. Примеры: взаимозаменяемость внутри области, работа с метриками, quality-гейт. Лиды берут 2 цели общие, а третья – локальная на область, в зависимости от контекста. Где-то закладывать тестирование в планирование, где-то мерить план-факт, где-то автоматизация. Был период, когда активно работали с DevCycleTime. Увидели по метрикам, что качество стало падать. И сделали метрику качества, и надо держать обе.

Что на уровне спринта команды? Спринт – можно сделать ценности, и это можно сделать через OKR. Был негативный опыт – провалили, потому что API отстали и тестирование отстало – поправили рабочий процесс.

Как итог – качество начало входить в общее направление компании, наши инициативы получилось привязать к общим метрикам. Снизилось количество инцидентов, появились quality gate.

Каждый день работают к PM, разработчиками и остальными. Что обычно говорят QA: много багов, страдает качество, нестабильный стенд, все горит. Для ПМ, разработки или SRE это информация, он сочувствует, но не понимает, что делать. Надо заходить через язык и зоны интереса. Рост багов – увеличивает TTM и бьет по пользователям – они страдают. Это ПМ и SRE уже волнует. SRE у них теперь важный партнер.

Тестировщик заходил «не учли тестирование смежных продуктов» – это просто претензия и конфликт. Если это перевести на метрики – у них появилось 3 amigos для обсуждения, и ответственный подпинывания других для больших эпиков. Или разработчик пишет «сделано» без пояснений – надо сформулировать претензию, что будут лишние созвоны, и дать решение – шаблон. Иначе будет обсуждение про претензию, а не про способ решения.

«Много багов, повысим качество» – ни о чем. Если баги подвязать на инциденты, и съеденное время – то тогда появляется понимание. Эффект виден в поседении всей системы. QA зашел в SRE, появляются задачи для тестировщиков и так далее.

'''Важно не говорить громче, а говорить правильным языком'''.

Итого, что делаем.

* Порядок у себя
* Формализовать то, что есть
* Держать поток практик снизу вверх и сверху вниз
* Метрики – на понятный снаружи язык, а не число багов
* Войти в управление компанией.

Вопрос. А вот все сделал, а людям и так хорошо? Ответ. Скорее всего, вас не услышали про профит. А еще – надо быть векторе и залететь через целеполагание.

Вопрос в развитие предыдущего: ты понимаешь, что снижаем качество и уйдут с другим. А вам говорят «принимаем риск». Ответ: смотришь на бизнесовые метрики. Может и нормально – надо смириться, хотя обидно.

Вопрос: а кто стейкхолдеры метрик, кто подписывается и мониторит, и принимает решение: отдать фичу или подождать? Ответ. Они сформировали связь, так что QA-метрика триггерит более высокоуровневую. А решение сейчас или потестировать – Продакт вместе с Инженер-менеджером, и они принимают решение по месту, в том числе – что качество пострадает, это через три недели – не далекое будущее.

Вопрос: дожимать ли процессы у себя до идеала, или идти в ширь. Ответ: идеал не достижим, определяешь некоторый baseline, до которого надо дойти, до того как идти вширь.

Вопрос. А в стартапе, когда ты один, и всего 10? Ответ – там главное – включить качество в общие цели. В первое время хватало excel, и раз в месяц. '''Но главное – приносить не просто метрики и проблемы, а решение, проблемы никому не нужны'''.

У них – матрица, продуктовые команды, а QA – центр компетенций, который предоставляет тестировщиков. В основном тестировщики постоянные в команде, но на уровне областей стараются ротацию вести.

Вопрос. А как сопротивление изменениям? Ответ – есть, убеждаем в командах, а если нет – заходят сверху. А глобальные изменения обычно делает не только QA, где рабочая группа, не соло-QA.

== Ксения Сергеева из Lamoda. Обратная сторона софт-скиллов ==

[https://sqadays.com/ru/talk/144520 Обратная сторона софт-скиллов]

Очень любопытное для меня выступление. Оказывается «хороший софт-скилл» трактуют как умение подстраиваться под любого без конфликтов, быть для всех хорошим, и безропотно принимать для себя любую нагрузку. И если у тебя хорошие софт-скиллы, то нагрузки будет больше, тебя будут просить фасилитировать и договариваться, помимо основных обязанностей. И это даже не было сказано, а подразумевалось. При чем место – явно больное, выступление заняло второе место.

Вообще для меня это – новость, я как-то жил в мире, где ненасильственное общение означает не то, что ты подстраиваешься и делаешь, что скажешь, а что можешь взаимодействовать с другим без агрессии, добиваясь при этом необходимого и удерживая границы. Но, наверное, если подумать, то в корпоративных тренингах может быть иначе, ведь умение хорошо коммуницировать или фасилитировать встречи, а также принимать для себя ответственность компании выгодно, а вот когда сотрудник умеет держать границы – нет. Вот и вычеркивают это из программы тренингов. Вряд ли явно, просто тренер знает, что если в результате сотрудники станут более неуживчивыми по отношению к выполнению руководящих указаний начальства, то тренинг ему больше не закажут. И он учитывает это.

А вообще софт-скилл – часть взрослой самостоятельности и уверенности в жизни, набор умений, которые для этого нужны. И если ты – уверенный взрослый, то ты не отстраиваешь жесткие границы, это – подростковое поведение, а управляешь границами и их проницаемостью, выстраивая сотрудничество с теми, с кем хочешь и с кем это эффективно получается, и отвергая с теми, кто просто забирает твою энергию. Но вернемся к выступлению.

Софт-скиллы – не серебряная пуля.

* Если собеседник не умеет планировать – будет частая смена контекста.
* Если собеседник не умеет работать с ожиданиями, «когда придет на тестирование» – вместо этого рассказывают про планы, и там неясно.
* Если вы хороши в софтах и умеете договариваться – то вас будут посылать договариваться, перекладывать ответственность.
* Если хорошо планируете – планируете за всех.
* Если умеете фасилитировать – проводишь все встречи.
* И это все – не вместо рабочих задач, а сверху, на это идет переработка.

Общение с активно-агрессивным токсиком коллегой. Человек – биосоциальное животное. На агрессию – бей-беги-замри, на конструктивное выруливание надо осознать, остановить, проанализировать варианты и озвучить оппоненту. И нам прилетит обратно. Правда, каждый следующий цикл будет меньше.

Вместо облегчения жизни у вас получается '''техдолг от софт-скилов''': не прожитый негатив, дополнительная ответственность и тревожность, и это начинает стрелять в ногу.

Чек лист: устали от общения и пугаетесь сообщений, мысль “я же могу разговаривать, почему они не могут”, желание жестко ответить, трудно принимать решения – ступор, рассеянное внимание, перестаете получать удовольствие.

Первый звоночек: это мысль “я же могу, почему они не могут”. Надо быть адекватным уровню компании. Если вкладываете больше, чем компания.

Что делать?

* Совет «снизить стресс и больше двигаться» – работать не будут
* Реально – диагностируете уровень зрелости окружения, и разрыв между ним и вами
* Если вас не принимают – они не доросли, выровнять ожидания по уровню зрелости
* Не брать на себя ответственность за окружение
* Соблюдать личные границы
* Научиться говорить «нет»

Я бы тут заметил, что тезис «если вас не принимают – они не доросли» напомнил мне историю про Незнайку, когда он писал стихи, высмеивая других, а на возвращенный негатив решил для себя «не доросли они до моих стихов». А вообще, повторю что писал в начале. Надо становиться взрослым и уверенным в себе человеком. К сожалению, в нынешнем обществе это – личное дело каждого, школа растит послушных учеников, выполняющих инструкции, хотя и делает это все хуже – времена меняются. Взрослый выстраивает кооперации совместной деятельности, границы там нужны, но нет ценности. И он понимает, что для работы в долгую у него должен быть хороший энергобаланс, высокий уровень текущей энергии – и работает в этом направлении.

А эти советы – лишь часть, в одних ситуациях они уместны, в других – нет. И еще это зависит от вас самих, потому что одним людям для снятия стресса нужны долгие прогулки, другим – общение и обнимашки, третьим еще что-то. Давая советы, это часто не учитывают. Про стресс и выгорание есть много выступлений Анны Обуховой, ищите на youtube. Для части из них у меня [[Анна Обухова и другие про нейрофизиологию в работе|есть конспекты]].

== Руслан Остропольский. Системный подход в работе лида/хеда QA ==

[https://sqadays.com/ru/talk/145005 Системный подход в работе лида/хеда QA]

Люди очень по-разному понимают, что такое – системный подход. Одни под этим подразумевают взгляд, при котором ты выделяешь в окружающем мире многоуровеневые системы и отношения между ними, и дальше используешь общие принципы работы с системами, которые не зависят от предметной области. А другие подразумевают более простую вещь – рассмотрение какой-то области в определенном порядке, по той или иной системе, а не ad hoc, подобно тому, как Станиславский разрабатывал свою систему для актеров.

B Руслан в выступлении говорил именно об этом – о порядке выстраивания работы лида QA. Это тоже важно, выстроить системность – так проще, чем жить в хаосе. По факту в выступлении такой иерархический список, mind map топиков, из которых складывается работа лида или хеда, с комментариями и примерами.

Позиция лида – правильный старт. И тут есть типичные ошибки, не все очевидные.

* Твоя экспертность как QA тебя тормозит: вместо управления делаешь работу за всех и всем помогаешь, и на управление не остается времени
* Незавершенные дела – новому лиду часто дают пару проектов доделать, и на тебя обрушивается большое количество задач, структуры которых ты не понимаешь
* Попытка сделать везде все и сразу, потому что «предыдущий тупил»
* Непонимание своей роли, особенно если ты пришел из другой компании: у роли очень большая вариативность, и далеко не всегда объясняют, что именно от тебя ждут
* Проблема принятия командой – это отдельное дело
* Прилетающие темы, с которыми надо быстро разбираться
* Новые обстоятельства: надо было нанять +30, а потом бюджет дали только на 5, но с тем же скоупом

Со всем этим надо разбираться системно. Он выделяет следующие области.

* Стратегия и цели
* Команда
* Коммуникация
* Процессы и инструменты, многие думают, что это – главное, а это – один из кусков
* Метрики
* Культура и принципы – одни строят неосознанно, а у других само не получается и надо делать
* Домен QA в мире – он развивается, за этим надо следить

Стратегия и цели: куда мы идем – цель, как идем (способ, почему получится); как поймем, что дошли (ускоримся с помощью ИИ на 30%)

TMMI Maturity model – 5 уровней. Но над не просто взять модель, а выделить блоки: Команда, процессы, метрики, коммуникации. Дальше рисуем в миро.

Режим целей.

* Измеримость – метрики и дашборды
* Цели – помогают стратегии
* Долгосрочная картинка – хотя бы год
* Зажечь звезду – великая цель, которая зажигает

Пример цели: у нас регресс 2 недели, а нам нужно дойти до ежедневного релиза. Понятно, что это не сразу, но надо держать направление и понимать текущий шаг и его вклад в продвижение.

Мотивация достижения целей

* Давно болит – облегчаем
* Избавляться от рутины
* Новое-интересное
* Возможность заработать – не забывайте о бонусах

ИИ не заменит человека, а избавит от рутины, и в этом его фишка.

Режим целей – подход

* Отделять операционку от целей. Тестировать задачи – не цель
* Автоматизация рутины – время на развитие
* Повышаем зрелость maturity model, учитывая, что команды – разные на входе и по задачам,
* Изучил новое – поделись и научи других

'''Команда'''. Орг.дизайн:

* проектирование структуры
* принципы взаимодействия и зоны ответственности
* кто, зачем и почему
* какие функции есть, откуда возьмем

Он рисует как иерархию, и в разрезе команд. И может жить годами – актуализируем.

Команда – что есть.

* Резюме, 360 и ревью – достаем историю
* Зарплаты и изменения – история
* Бюджеты на команду
* Матрицы компетенций, с историей – если они есть
* Проводим 1:1 со всеми – надо понять, с кем работаем.
* Личные отношения – кто готов работать со стратегией и целями.
* Работа с недоверием, сработаться, кого-то поменять.

Принципы работы

* Информируй, не зажимай важное. Есть много историй, когда не рассказывают про причины решений, это неправильно
* Делегировать – ответственный за каждую тему
* Быть доступным. Не ждут встречи 2 недели – а то перестанут ходить
* Нет плохих людей, есть неподходящие задачи. Надо разбираться,
* Баланс доброты. Пробовать и ошибаться – нормально. А если косячит, например, на каждую встречу приходит неподготовленный – фигня

'''Коммуникация'''. Связи

* Выровнять ожидания с руководством
* Выстроить отношения со смежниками
* Системные встречи с целями и правилами – что регулярно происходит, и проверять осмысленность, бывает перевод ежедневной встречи в еженедельную не портит

Коммуникация. Звучать регулярно

* Планы и цели
* Результаты
* Над чем работаем
* Опыт индустрии: сходили на конфу – поделитесь
* Выходить в мир

Коммуникация. Быстрые победы.

* Слушать и вникать
* Не ломать историческое
* Не критиковать прошлое (все плохо, сейчас я сделаю хорошо)

Быстрые победы – действия.

* '''В любой теме можно сделать быстрый результат за 2 недели. Если проект на полгода – найдите видный первый шаг'''
* Мышление гипотезами. Пробуем, не бетонируем процессы
* Любая идея – ценная, не душить непонятное. Записываем, даем возможность попробовать
* Быть экспертом – некоторые темы копать самому

Нельзя

* Автоматизировать проблемные процессы – проблемы останутся
* Перемены ради перемен, потому что не нравится, или потому что так было в прошлой команде

В заключении.

* Менеджмент – делать результат стратегический и тактический параллельно
* Коммуникация – скрытая сила побед
* Системность – области движения, а не везде все подряд
* Достижение команды – это ваши успехи

Базовые книги

* Умение слушать осознанно
* Первые 90 дней
* Системное мышление для руководителя

[[Категория:ИИ-агенты]]
{{wl-publish: 2026-04-30 14:03:05 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2026-05-25: AnalystDays – хорошие выступления и нетворкинг

2026-07-24T14:47:20Z

MaksTsepkov:

{{Conf-Ref}}
Прошла 22 конференция [https://analystdays.ru/ru/program/144288 '''AnalystDays''']. Я хочу с удовлетворением отменить, что организаторам удалось собрать вау-программу с замечательными выступлениями. Во всяком случае, такими оказались многие из выступлений, которые я слушал. При этом у меня не получилось попасть на мастер-классы Димы Безуглого, Анны Обуховой, которых я знаю как крутых спикеров, и, наверняка были другие качественные выступления, на которые я не попал. Как обычно, было много интересного нетворкинга, и поэтому в отчете – всего 7 выступлений, кроме моего. И, в отличие от других недавних конференций, я практически не был на выступлениях про ИИ – не потому, что их не было, просто я выбирал альтернативы.

Мой конспект с конференции был [https://habr.com/ru/articles/1039166/ '''опубликован на habr'''] 25.05, а 16.06 я перенес копию сюда, чтобы на моем сайте тоже был отчет.

----

Прошла 22 конференция [https://analystdays.ru/ru/program/144288 AnalystDays]. Я хочу с удовлетворением отменить, что организаторам удалось собрать вау-программу с замечательными выступлениями. Во всяком случае, такими оказались многие из выступлений, которые я слушал. При этом у меня не получилось попасть на мастер-классы Димы Безуглого, Анны Обуховой, которых я знаю как крутых спикеров, и, наверняка были другие качественные выступления, на которые я не попал. Как обычно, было много интересного нетворкинга, и поэтому в отчете – всего 7 выступлений, кроме моего. И, в отличие от других недавних конференций, я практически не был на выступлениях про ИИ – не потому, что их не было, просто я выбирал альтернативы.

Дальше – мои конспекты выступлений. Многие с дополнениями – ссылками на разные материалы прошлых лет, которые относятся к теме выступления. Думаю, они будут полезны и самим выступающим, и тем, кто заинтересуется темой.

Я впервые публикую мой конспект с конференции на habr. До этого они были на [https://mtsepkov.org/Conf моем сайте]. Хочу посмотреть на реакцию и понять, насколько это уместно здесь делать, так что к читателям – просьба реагировать.

== Максим Цепков. Эпоха быстрых изменений – возможность, а не проклятие: опыт китайских tech-гигантов ==

[https://analystdays.ru/ru/talk/144627 Эпоха быстрых изменений – возможность, а не проклятие: опыт китайских tech-гигантов]

Мое выступление [https://mtsepkov.org/China-AD Эпоха быстрых изменений – возможность, а не проклятие: опыт китайских tech-гигантов] было посвящено осмыслению опыта моей осенней поездки по китайским технологическим компаниям: Baidu, Xiaomi, Little Red Book, SenseTime и другим, и последующем осмыслению темы.

Фокус выступления был именно на корпоративную культуру ИТ-компаний и на те практики, которые были бы уместны для аналитиков. Я пробовал приземлить рассказ о ценностях компании, автономности команд, отношении к ошибкам и другим темам на конкретные аспекты работы команд. Потому что такие вещи, как быстрая проверка гипотез, инициатива в продвижении к цели или уважение к знаниям актуальны не только для Китая.

И про ИИ в выступлении тоже было: оно в Китае сильно отличается от нашего. Там в инфополе отсутствует тема замены человека на ИИ и связанных с этим страхах, и разработчики тоже думают не о том, как заменить человека, а о том, как ему помочь, повысить его производительность. И, отмечу, такие задачи решать гораздо проще, чем полную замену, что позитивно влияет на скорость прогресса в целом. И возмущения глупостью LLM тоже нет: недостаточную сообразительность воспринимают как естественное в период обучения, и полагают, что роль человека как раз в том, чтобы поскорее научить ИИ, чтобы он мог лучше помогал людям. В общем, ИИ – партнер, а не конкурент.

Подробности – на слайдах презентации, в других моих статьях и моей новой книге [https://ridero.ru/books/kitai_dao_menedzhmenta_i_kulturnyi_kod_budushego_lidera_mira/ '''«Китай: дао менеджмента и культурный код будущего лидера мира»''']. А еще можно смотреть вебинар [https://mtsepkov.org/ChinaLeaderNSE Влияние технологий на изменение мирового порядка и глобальную конкуренцию], там, правда, меньше ИТ-фокуса, зато больше раскрыта тема развития мира в целом ходе технологических революций.

== Анастасия Динерштейн. Рецепты зелий продуктивности ==

[https://analystdays.ru/ru/talk/144336 Рецепты зелий продуктивности]

Я настороженно шел на это выступление, потому что в анонс был сделан в метафоре заклинаний и алхимии зельеварения. И было неясно, будет ли там прагматичное содержание, или рассказ будет исключительно на метафорах. К счастью, оказалось, что это лишь рамка выступления – введение и заключение, прочитанное ровным голосом. А внутри – вполне практичный набор методов работы с тайм-менеджментом и мотивацией, о котором я расскажу.

Но мне интересно про метафорическую рамку алхимии: привлекает ли метафорическая рамка алхимии поколение времен Гарри Поттера и деградации образования, которое перестало показывать разницу между наукой и магией, или они тоже отнесутся настороженно? Мои дети разницу точно понимают, и их такой бы анонс тоже насторожил, а вот каково восприятие других? Обращение к читателям конспекта: если не лень – сходите по ссылке на анонс выступления и оцените, какие впечатления он вызывает у вас, а потом поделитесь со мной.

А сейчас – к содержанию выступления.

Про тайм-менеджмент для организации своей продуктивности слышали все, но у многих он не работает. И у этого есть следующие причины.

# Не знание тайм-менеджмента
# Прокрастинация и стресс
# Проблемы концентрации внимания (только не ставьте диагноз себе СДВГ самостоятельно)
# Проблемы с мотивацией и внутренними стимулами

В чем проблема у вас? '''Мини-тест''' – ставьте галочки, если согласны с утверждениями (записано с голоса в сокращении).

# Я часто чувствую, что работаю много, но не продвигаюсь
# Я знаю что делать, но откладываю
# Трудно сосредоточиться на одной задаче
# Мне не интересно, нет вдохновения
# Я не знаю, с чего начать и не понимаю, как структурировать
# Даже когда я отдохнувший – нет энергии изнутри

Пункты 1 и 5 – не знаем базу тайм-менеджмента, 2 – прокрастинация, 3 – концентрация внимания, 4 и 6 – нет внутренних стимулов.

Какими методами это можно поправить? Не все методы подходят любому, подбирайте набор методов для себя, а если какой-то метод у вас не работает – не используйте.

'''Простые методы тайм-менеджмента'''.

# '''Собери портфель с вечера'''. У детей – часто. А во взрослом? План на день с вечера – попробуйте! Я только хочу отметить, что если вас драйвит мышление, то составление плана потом может помешать заснуть – вы начнете сразу решать запланированные задачи.
# '''Блокировка времени''', три вида: (а) блоки по типам задач (созвоны – работа – отдых), (б) таймбоксы на типы задач (аналитика, техдолг, док) и (в) просто слот “не беспокоить” – окна концентрации. Но! так не каждый день, и лучше согласовать с руководителем.
# '''Метод Помодоро''': таймер на 25 минут работы, 5 минут отдыха после 4 повторений 20-30 минут перерыва
# '''Матрица Эйзенхауэра: Срочно и Важно'''. Делаем Срочно+Важно, делегируем Важно-Не срочно, Не срочно+Не важно – удаляем.
# '''Бумажный планер со структурой'''. Фишка в том, что '''он дает WIP-лимит''': ячейка ограничена, 13 задач помещается. Да еще там структура: главную цель на день просят написать, и туда только 1 помещается. Пытаешься заполнить – а туда 3 цели и 20 задач не лезут – и это правильно. Правила Миллера 7+-2, сейчас 4+-1. Ограничение когнитивной нагрузки, при перегрузе падает внимание и концентрация.
# '''Контроль когнитивной нагрузки''': делить большие задачи на маленькие, использовать привычные схемы и шаблоны, убрать отвлечение, понятность действий.

'''Прокрастинация и стресс'''

* '''Правило 10 минут''': начни и 10 минут поработай
* '''Лягушка на завтрак''' – делать сложную и неприятную задачу самой первой.
* '''Намеренное выполнение'''. Формируем план действий в варианте “если-то”. Ты не начинаешь, а пишешь такой план в диалоге с собой – сценарии под разные ситуации. «Если открою ноут – проверю список задач»

'''Концентрация внимания'''.

* '''Парное присутствие''': работа в присутствии другого физически или онлайн: офис, коворкинг, кофейня – даже если там другие люди занимаются другим. Я: да-да, эффект «пойди в библиотеку».
* '''Дробление задач''': разбиваешь на маленькие выполнимые действия. Есть слона по частям. Это отдельный метод от просто декомпозиции – ты уже знаешь декомпозицию, но дальше оформляешь пункты как отдельные задачи, '''и за каждую «я – молодец»'''.

Отмечу, что «я – молодец» надо говорить за каждую задачу, и для того, чтобы это делать эффективно, у Анны Обуховой есть '''протокол авторизации результата''', о котором можно прочитать, например, в моей статье [https://vc.ru/hr/1018029 '''Механизмы драйва и мотивации'''], там же есть ссылки на выступления Анны из которых я это узнал. Он – короткий, при тренировке занимает минуту-полторы на небольшую задачу.

'''Мотивация и внутренние стимулы''': ответ на вопрос «а кому это надо?».

* Есть '''факторы самодетерминации''': компетенция (у меня получается и я расту), автономия (сам выбираю, как делаю) и причастность (работа в команде и поддержка других). В работе это действует так: выбор способа задач, отношения с коллегами. Атмосфера доверия, обратная связь…
* '''Визуализация цели''': Для кого, Зачем, как изменится ситуация – для себя и для команды. Можно текстом, можно mind map. Сделал – классно (пусть не очень со смыслом)
* '''Геймификация'''. Делаем игру, где даем баллы за сделанные задачи. И придумываем награды по баллам. 10-20-30. Повышает дофаминовую стимуляцию и вовлеченность людей
* '''Прогрессивная нагрузка'''. Начинаем с простого и выполнимого и постепенно повышаем сложность. Как при онбординге (нацеленном на рост, а не на вызов). Начинаем задачу с мелочей – план, док, потом к анализу и так далее. Чувство контроля и компетентности.

У автора '''Tg @Ne_Ranshe''', на нем скоро выложат Excel для планирования и геймификации.

Про последний блок я хочу отметить, что в нем описаны технические приемы, как именно обеспечить свою мотивацию, и создать себе внутренние стимулы. Но за рамками остался важный вопрос: '''а нужно ли это делать?''' Потому что крепостное право отменено полтора века назад, и всегда есть альтернатива сменить команду, проект или место работы. Конечно, на волевых усилиях и с помощью приемов манипуляции,которые применяешь к себе, можно научиться терпеть, и вопрос – ради чего. Тут ситуация с работой принципиально не отличается от ситуации с семьей: ради чего терпеть жену или мужа, убеждая себя, что все нормально, как у всех? Работу сменить даже легче. Диагностику ситуации я разбираю в книге [https://ridero.ru/books/samoopredelenie_chto_ya_khochu_ot_zhizni_i_raboty/ '''«Самоопределение: что я хочу от жизни и работы»''']. Эта часть появилась впервые в выступлении '''[https://mtsepkov.org/SelfDetSQA23 Самоопределение: чего я хочу от жизни и работы (SQAdays-2023)]''', а частично это есть в статье [https://vc.ru/hr/2203386 '''Самоопределение: пора ли идти к светлому будущему?''']. Дело в том, что все мы разные, и получаем драйв и энергию от разных типов задач. И надо разбираться, есть ли в вашей работе задачи, которые вас драйвят. А иначе вы продолжаете работать ценой своего здоровья.

'''Вопросы после выступления''' (я записал не все).

* '''Вопрос'''. А как быть с руководством, которое считает, что может беспокоить когда угодно? '''Ответ'''. Надо все-таки согласовать с руководителей.
* '''Вопрос'''. А вдруг руководитель считает палочкой-выручалочкой? '''Ответ'''. 1-2 раза в неделю.
* '''Вопрос'''. Ехать в офис – падает продуктивность 1.5 часа в дороги. А дома – не отвлекаюсь. '''Ответ''': не ездите.
* '''Вопрос''', Как подготовиться с поеданию лягушки? Ответ – никак, идея в том, чтобы просто начать, пока не загружен, ты самый первый.
* '''Вопрос'''. А коллега забирает время до 50%, предпочитает делать с кем-то. '''Ответ'''. Цените свое время и продуктивность.

Я тут отмечу, что во многих вопросах звучало «я пробовал, этот метод не работает». Анастасия отвечала «тогда не используйте». Она с самого начала сказала, что методы надо выбирать индивидуально. Так что не очень понятно, зачем люди спрашивают. Может, это самооправдание…

А еще в нескольких вопросах про блокировку времени предметно говорили «а ведь руководитель может позвонить в любое время, может быть форс-мажор». Анастасия делала фокус на том, что надо договариваться, а я бы сказал, что стоит проанализировать ситуацию. Потому что форс-мажоры, включая срочные звонки руководителя, должны случаться редко, и если вас раз в квартал выдернут из слота концентрации, то и ладно. А вот если это происходит каждую неделю или чаще, то надо разобраться, с чего бы оторвать вас от работы стало основной задачей руководителя, по идее вы у него не единственный подчиненный. А если пожары случаются каждый день, то в системе есть проблема, которую стоит решить. Хотя да, есть люди с mindset «пожарник», и если таков ваш руководитель – то он может специально организовать работу так, чтобы пожары были ежедневно, а он звал подчиненных их тушить. И если вам не нравится быть пожарником, то руководителя надо менять.

== Александра Брызгалова. Решение уже принесли. А где проблема? ==

[https://analystdays.ru/ru/talk/148728 Решение уже принесли. А где проблема?]

В выступлении очень изящно обыгран заголовок: ведь требовать проблемы вместо решений – решение само по себе, так что появляется логический парадокс. А вообще выступление показывало, как применять инструменты теории ограничений – описание нежелательных явлений и тучу для работы конфликтами, включая неявные конфликты, когда заказчик или кто-то еще делает что-то неправильное, а мы не обсуждаем, а просто на это злимся. Инструменты позволяют рационализировать конфликт.

Сами инструменты детально не раскрыты, их использование иллюстрировано краткими примерами, и даны ссылки, по которым можно познакомиться подробнее. Они – сложные, и хорошее изложение превышает возможности одного выступления. То же касается самой теории ограничений: Саша не рассказывала, что это такое, а знают это не все – в начале доклада был вопрос-реплика. Но ее тоже не расскажешь в одном выступлении, можно лишь дать представление и побудить к изучению. Обычный способ для этого – сделать обзор возможностей теории, а Саша выбрала другой – оказать изящный пример применения инструментов теории. Для разных людей подойдут разные способы, и это каждый спикер решает сам.

Но некоторое введение про теорию ограничений было. Для Саши это не управленческий подход, а часть физики – как устроен мир. Но при этом теория говорит не просто про устройство, а еще и о том, как в этом мире достигать своих целей, учитывая физические законы. Огромная часть часть теории ограничений – о том, чтобы быстрее приближаться к цели. И надо понимать, что '''любые изменения приближают к цели или удаляют''', а не оставляют как было. И '''чтобы быстрее идти часто надо не начинать делать что-то новое правильное, а лишь отказаться от неправильного''', освободив для правильного больше времени. У вас не может быть главного приоритета и остальных, '''надо выделять главное, от остального – отказаться'''.

Итак, '''если у тебя решение, то в чем проблема?''' При этом есть куча призывов в разных книгах «не приходи с проблемой, а приходи с решением», и даже таблички такие для руководителей выпускают. А аналитики, наоборот, говорят заказчику «принеси проблему, а не решение». При этом, однако, сами очень часто '''озвучивают не проблему, а отсутствие любимого решения''': «не описаны бизнес-процессы», «не разделены зоны ответственности», «Я нашла проблему – я хочу еще одну кнопку». Но это все – не проблемы. Как с этим быть?

Для начала – что такое «проблема»? В теории ограничений есть понятие '''НЖЯ – нежелательного явления''', у которого должен быть ряд признаков.

* Очевиден негатив: когда формулировка не вызывает вопрос «И чо?»
* Не обвинение, проблема «Джонни – дурак» – это решение
* Мы можем повлиять на ситуацию, формулируем не чтобы поныть, а чтобы изменить
* Указано явление, а не наше оправдание.
* Оценка не субъективна, о ней можно договориться с другими.
* И это явление, которое происходит, а не решение.

«Заказчики продолжают приносить решение вместо проблем» – не звучит как проблема. В чем вред? Еще это звучит как обвинение заказчика и наше оправдание, субъективная оценка, а на сами действия мы не можем повлиять. Так что для начала надо сформулировать, в чем, собственно, проблема. Вы же что-то объясняете формулировкой, верите, что без этого было бы лучше. И надо это явно сформулировать.

Для этого есть инструмент '''туча – графическое представления конфликта'''. Каждая проблема – это конфликт.

Пользователь выбирает приносить решение, а мы иногда делаем эти решения и внедряем, не смотря на проблему. А иногда они приносят проблему или мы ее ищем. Почему они приносят решения? Потому что им надо быстро. А оказывается, что это – плохое решение, что-то отваливается, и '''глобально становится хуже'''. В этом конфликт: локальное решение против глобального.

Теория ограничений говорит: '''когда есть конфликт, то всегда возможно win-win решение'''. В это выгодно верить, если вы определили проблему как не решаемую – она не решится. '''Если не получается поделить пирог, чтобы каждому хватило – найдите пирог побольше'''.

Мы нарисовали конфликт (на слайде – схема, смотрите презентацию). В логике есть пробелы. И надо задавать вопросы. Как связаны «быстрые улучшения» и «приносить решения»? (а) Я верю, что поможет, (б) у меня горит.

А почему нужны проблемы? (а) Мы верим, что заказчик не все понимает, не смотрит целиком и (б) что готовые решения направлены на локальную оптимизацию. '''А если ты улучшаешь не место ограничения, то будет не лучше, а хуже – это TOC'''.

Но ведь с меня спрашивают работу моего отдела, и если мы сделаем лучше всем, не факт, что KPI моего отдела будет выше. Это – засада на пути глобальной оптимизации. А еще решение конфликта может быть чем-то осложнено. А еще всегда есть решение лучше (если подумать) – и тут можно делать вечный конфликт, препятствуя началу любых изменениям, требуя еще подумать.

'''Схема решения проблемы'''. Такие схемы можно строить при любой проблеме – если вам надо.

# '''Потребность''', которую проблема ставит под угрозу.
# Действия, которыми мы пытаемся спасти потребность, оказавшуюся под угрозой – '''костыль'''.
# Потребность, которая начинает страдать из-за костылей.
# Действия, которыми мы стараемся спасти вторую потребность.

Это описывает качели, которые раскачиваются. И можно сломать качели.

И дальше – '''(5) цель, которую можно достичь при удовлетворении обоих потребностей'''. Это и будет win-win

Вера, что всегда можно найти win-win, не заставляет его искать. Когда стоит? '''Когда текущие действия не подходят, вы хотите чего-то нового'''. Если проблема повторяется – надо взглянуть с другой стороны.

Чем чаще вы будете смотреть на конфликты через эти инструменты, то вам не придется думать. После тренировки тучи, один пришел: «Было три конфликта, во всех был win-win, тучу не строил. Но раньше win-win не было»

Если вам не дают ресурсы или постоянно меняют приоритеты – подумайте почему, что страдает. И на что влияет наши решения.

'''Ответы на вопросы'''.

* '''Вопрос'''. Что опаснее: решать не то, или долго понимать. '''Ответ'''. Я верю в фокус: если ты сделал не то, то ты, как минимум, можешь понять что не так и посмотреть. Если быстро действуешь – есть шанс двигаться.
* '''Вопрос'''. Как отличить локальную оптимизацию от глобальной? '''Ответ'''. Любая глобальная оптимизация, если мы возьмем систему побольше – будет локальной. Но все равно надо выглянуть вокруг. Мы играли в игру – симуляция производственного процесса, и тут первые решили оптимизировать выход за счет большого пакета – и это реально замедление. Надо сопоставлять амбиции и квалификацию. Любая оптимизация – локальная, но не надо замахиваться на все.
* '''Вопрос'''. Чем туча и НЖЯ лучше классического подхода анализа стейкхолдеров? '''Ответ'''. Есть люди, которые интуитивно разруливают конфликты, им не нужна туча. А есть те, кто рисует тучи, и им плевать на других стейкхолдеров. Если нет проблем, то туча не нужна. Риск – не из инструмента, а из того, есть ли в голове другие стейкхолдеры.
* '''Вопрос'''. А про развитие бизнеса – теория ограничений. '''Ответ'''. Если про проектирование нового – не сюда. А если у нас разрыв между имеющейся ситуацией и желаемой – то есть. «Мы говорим-говорим, а еще не там» – это нужная. А в ситуации «мы сегодня решили и еще вообще не пробовали» – надо попробовать, а не рисовать тучу. И очень часто выясняется, что очень много проблем – следствие одного системного противоречия.

== Нурия Хамидуллина из Умскул. Как сделать процесс анализа управляемым: опыт работы с метриками ==

[https://analystdays.ru/ru/talk/145184 Как сделать процесс анализа управляемым: опыт работы с метриками]

В выступлении – разобрано несколько кейсов работы с метриками. Но начали его с важного тезиса, что метрики по всему потоку задач смотреть бесполезно, надо выделять отдельные кластеры. У них 4 кластера по размеру: XS-L.

'''Кейс-1''': у аналитиков одной команды растет cycle time по М-задачам. Начали смотреть статистику – обнаружили review time 8 дней а не 2. Метрика изменилась, когда начали жестче контролировать согласование с заказчиком. Посмотрели – там не отлажен процесс, есть чек-бокс в jira, который фиксирует согласование, а делают его аналитики через мессенджеры или почту, по задаче может требоваться согласование нескольких стейкхолдеров и все это тяжело вести вручную. Поэтому сделали ревью стейкхолдеров в Jira – чтобы были уведомления в мессенджерах, откуда сразу идешь – и быстро делаешь. Была проблема, когда стейкхолдеров несколько: отдельное поле для каждого стейкхолдера – не масштабируемо. Сделали решение с общим полем, где накапливается от всех. И cycle time сократился, идет лучше.

'''Кейс-2''' для L-задач: слишком долгое выполнение, при этом review time нормальный. Смотрят active time и flow efficiency, и поняли, что flow efficiency меньше 50% – долго ждем. Анализируем флаги блокировки, и обнаруживаем, что discovery-часть перекочевала в этап анализа. Процесс discovery предполагает задержку: мы запустили гипотезу на проверку и ждем результат. Выделили discovery в отдельный процесс работы с гипотезами – flow efficiency поднялся до 80%.

Метрики – классно, но считали их вручную. Так стало жить невозможно – начали передавать в хранилище и визуализация в metabase. Дашборд. Разбивка cycle time по классам и аналитикам и так далее. Метрики добавляются быстро – пара дней.

Метрики потока, метрики процесса и метрики качества – на слайде выписано. И операционная доска, где ловят отклонения: какая-то задача зависла в одном статусе. И еще нагрузка на систему – WIP. Закон Литла – lead time определяется пропускной способностью и числом задач в работе. lead time – из active time, review time, и временем блокировок, . Качество требований – смотрим по Rework, доработка требований. B это позволяет отслеживать динамику, смотреть проблемные точки. А при изменениях – смотреть на их эффект, есть улучшения, или наоборот деградация.

'''Вопрос'''. Как выделяли классы задач? Потому что задача интеграции – зависит от того, внутренняя или внешняя, есть док или нет. '''Ответ'''. Смотрели статистику за год, кластер шел на них, а дальше пробовали выявить признаки, чтобы кластер определять на входе. В разных командах признаки различны, и это надо постоянно поддерживать – поток задач меняется.

Я тут хочу дополнить. Статистика говорит, что у однородных задач должно быть гладкое распределение, например, нормальное для отклонения от среднего, пуассоново или логнормальное для времени выполнения и так далее. А если вы смотрите распределение задач по времени выполнения, и у вас там несколько пиков – то значит у вас несколько классов задач. А дальше – надо анализировать признаки, чтобы понять, как одно отличать т другого на входе.

'''Вопрос'''. Процесс discovery вынесли – и что с ним? '''Ответ'''. Это сейчас в процессе. Раньше время на A/B тесты и анализ гипотез не смотрели, сейчас набирают статистику, потому что важно считать как раз от идеи до завершения.

== Александр Котиков из ГНИВЦ. ГГ: Геймификация в госсекторе и экспертное сообщество процессной аналитики ==

[https://analystdays.ru/ru/talk/144888 ГГ: Геймификация в госсекторе и экспертное сообщество процессной аналитики]

ГНИВЦ работает на ФНС, и одна из его задач – оптимизация процессов. Есть проблема: 1100 технологических процессов, а скорость анализа 20 процессов в год уже 5 лет. И они пытаются набрать скорость, Они ищут людей в бизнесе, '''инспекторов налоговой службы, которые могут помочь в улучшении процессов'''. И используют process mining – анализ цифрового следа процесса в больших данных.

Process mining – обработка цифровых следов для восстановления схемы процесса или сопоставления с регламентом. Саша сказал, что появилось это в 2016, в 2018 пришла в Россию (ФНС, ГПБ и другие). Я тут не согласен, потому что еще в 2013 году слушал на SECR выступление Вила ван дер Аалста (Университет Эйндховена и НИУ ВШЭ) как раз про это, так что методу гораздо больше лет ([http://SECR-2013 мой конспект]).

Они используют манифест ФНС как целеполагание, а там написано: мы доверяем данным и стремимся к изменениям, это позволяет совершенствовать безболезненно. Но важно поддерживать желание людей. Он реально увлекся игровых механик. Вообще это стало много во всех продуктах. Лидерборд, статусы, бейджи. Еще начали вставлять игры, но про них он пока не понимает – что они дают кроме времени сидения в продукте.

У них сделана '''биржа совершенствования процессов'''. Совершенствуют процессы, отдают результаты и получают свои плюшечки.

'''Шаг 1'''. Обучение людей процессной аналитике. Обучать, заинтересовать, отправить в биржу. У них конверсия 18% – люди стали приносить пользу после обучения.Но надо не просто генерить идеи изменений, но и считать эффект улучшения.

'''Шаг 2'''. Игровые механики. Бейджи, лидерборд, соревнование. 800 сотрудников вовлеклись. Процесс непрерывного совершенствования – BPM-цикл.

Делает управление процессной аналитики. Они делают анализ и строят софт для анализа, от заказчика – отделы модернизации и внедрения технологических процессов.

* '''Вопрос'''. Максимальный объем знаний – у людей постарше. Они считают несерьезным. Как выманиваете? '''Ответ'''. Если человек не вовлекается – он уходит из компании. Если не можешь меняться – до свидания.
* '''Вопрос'''. Не перегрузим ли людей этими штуками? '''Ответ'''. В рыночных продуктах к этому идет, и напрягает. Но у себя они пока видят потенциал роста. Но будет на это смотреть, потому что на рыночные кейсы видят.
* '''Вопрос'''. А что с читерами? '''Ответ'''. Они об этом реально думают, дырки для накрутки есть, а на рейтинг идет премиальная составляющая. С этим работают.
* '''Вопрос'''. Process mining является ли альтернативой аудиту экспертов? '''Ответ'''. Кончено, да!

Я в заключение хочу поделиться ссылками, потому что слушал довольно много качественных выступлений на темы, затронутые Сашей. Думаю, может оказаться полезным.

Про биржу изменений. В 2010-2011 годах на KM Russia я слушал выступления '''Валентина Матохина''' о системе Текоры для биржи изменений (кажется, в Сбербанке, но это не точно). Их опыт говорит, что для придумывания идеи и ее реализации нужны разные компетенции, поэтому этим часто занимаются разные люди, есть те, у кого получается придумывать, и те, у кого получается организовать реализацию. И они делали механику для такой передачи, и делили плюшки между автором идеи и тем, кто реализовывал. Детали можно посмотреть в моих заметках [https://mtsepkov.org/KMrussia-2010 KM Russia-2010] и [https://mtsepkov.org/KMrussia-2011 KM Russia-2011]

Про геймификацию я слушал ряд выступлений в 2012-2014 годах, и у меня есть статья [https://vc.ru/hr/120843 Игрофикация — технологии online-игр в бизнесе], где я разбираю этот метод, там есть ссылки на конкретные кейсы и выступления. Тут важно, во-первых, понимать, что людей драйвит разное и нужно в игровую механику закладывать альтернативы, а, во-вторых, должна быть опция отказа от игры, что вовсе не означает отказа от изменений, иначе может появиться скрытый негатив, который уничтожит эффект игрофикации.

== Татьяна Маркина и Тарас Шевченко. PROvoke: Системный анализ между соблазнением, манипуляцией и властью ==

[https://analystdays.ru/ru/talk/144792 PROvoke: Системный анализ между соблазнением, манипуляцией и властью] – парный перформанс-диалог. Выступление – реальный перформанс, как и было обещано в названии, и показывает разные техники манипуляции и влияния, а также типизацию людей, которая позволяет манипулировать ими или влиять на них, используя желания и страхи.

'''Но тема границы допустимой манипуляции – не раскрыта''', спикеры подходили к ней несколько раз, но ничего достаточно внятного о «тонкой линии границы» между манипуляцией и влиянием, на мой взгляд, не сказали, и свою позицию не заявили. Рассуждения сводились к тому, что хорошее – хорошо, а плохое – плохо.

Это не случайно, потому что весь 20 век многие сильные умы человечества посвятили деконструкции различных общественно-признанных систем, показывая их выгодополучателей, краткую историю можно прочитать [https://ivanov-petrov.livejournal.com/2287616.html в этом тексте].

Поэтому приходится признать, что '''границу между добром и злом каждый проводит самостоятельно, строя собственную этическую систему'''. И эти системы могут различаться очень сильно, '''Владимир Лефевр''' '''«Алгебра совести»''' показывает, насколько различны решения людей и общество в целом в зависимости от ответа на вопрос «Допустимо для движения к добру к использовать злые средства?». Подробности можно посмотреть в [https://mtsepkov.org/ConscienceAlgebra моем разборе] или прочитать книгу. Отмечу, что основная фишка модели Лефевра как раз в положении, что представления о добре и зле индивидуальны, границу каждый проводит сам.

Учитывая все это, при обсуждении подобных вопросов необходимо, как минимум, четко предъявить собственную границу. Следуя этому, предъявляю свою. В свое время формулировал в статье «[https://vc.ru/hr/648132 '''Надо ли идти к светлому будущему?''']» по частному вопросу: надо ли проблематизировать другого человека и побуждать его к развитию, если он вполне удовлетворен существующей ситуацией. А это выступление побудило меня вернуться к осмыслению и обобщить.

Я исхожу из того, что самостоятельный взрослый человек способен ответственно принимать решения о своем поведении во взаимодействии с другими людьми, включая распознавание различных механик влияния, с помощью которых на него действуют в коммуникации. Естественно, не каждый конкретный человек достиг этого уровня. Так вот, препятствовать любыми методами повышению самостоятельности – точно зло. А раз так, то воздействуя на кого-либо ты должен принимать во внимание, что рано или поздно этот человек может достичь уровня, когда он осознает способы влияния, которые ты к нему применял, и '''тебе прилетят последствия в соответствии с его собственной этической системой''', а не твоей. Как прилетает она родителям от взрослых детей, только во взрослом мире это может произойти быстро. Принимай решения, исходя из этого.

А теперь – вернемся к самому выступлению. Я его стенографировал с голоса и вот что получилось.

'''Акт 1'''.

* '''Тарас'''. Вы пришли не за знаниями, а за разрешением: вы уже умеете, но теперь будете ссылаться – они рассказали. Рецепт как получить разрешение на рефакторинг, на новые фичи и так далее.
* '''Татьяна'''. Но! под рецептом яд, который убивает нас всех. И когда мы думаем, что за этим рецептом верх профессионализма – нас разрушает. Под оберткой эффективности – яд для доверия и самоуважения.
* '''Тарас'''. Мы все кровавый энтерпрайз, и пока мы думаем про этику – у нас не будет премии. У вас есть ручки – будем дергать
* '''Татьяна'''. Но. Давай назовем шпионаж активной разведкой, а воровство нецелевым распределением средств. Ты составляешь досье на коллег и точки приложения усилий.
* '''Тарас'''. О точках влияния – говорят. Если человек – художник, то я даю творить, и проект идет. Кому плохо?

'''Акт 2'''.

* '''Татьяна'''. Синергия по-тарасовски. 5 кнопок, нажми – будет результат
* '''Тарас'''. Валюта – мотивация, страх подергать, рычаг..
* '''Татьяна'''. Рычаг для своей выгоды – манипуляция. Но граница между общением и манипуляцией – сильно размыта.
* '''Тарас'''. Как понять архетип? Три простых признака: речь, поведение, социальные сигналы (в обществе). За минуту можно прогнать архетип, понять валюту – использовать.
* '''Татьяна'''. Дальше поговорим, как распознать архетип, как распознать, что тобой манипулируют.

'''Типы'''.

* '''Художник'''. Валюта – признание, Страх – быть посредственным. Я продумал архитектуру, и только твой взгляд наполнит ее жизнью, покажет – и человек счастлив. И Вася вместо критического мышления бросается делать, и борется за звание гения. Тарас подменяет цель.
* '''Прагматик'''. Валюта – избегание потерь, Страх потратить время впустую. Ты потратила 4 часа на баги, потому что спагетти-код, а мы сделаем на микросервисах! При этом ты раздуваешь мизерную проблему, не используешь во благо, повторно травмируешь, кладешь пластырь.
* '''Властелин'''. Валюта – контроль, страх – потеря власти. Даем властелину иллюзию контроля, чтобы он сам выбрал правильный путь. Но! по факту это иллюзия выбора, партия А или Б – не важно, власть одинакова. Цветные игры псевдовыбора. Ты идешь в канве, но тебе приятно.
* '''Модник'''. Валюта – статус в обществе, главное – речь. Страх FOMO – быть отстающим. Следует за трендами, Но! надо не брать менталитет, культурный код.
* '''Бизнес'''. Валюта – рост, метрики. Страх – конкуренты съедят. Месяц на решение или нас съедят. Доля выручки, метрики – всегда, даже когда культура. И конкуренты и бенчмарки, паника. Не дают вдохнуть-выдохнуть.

'''Матрица желаний'''. Получили валюту. Манипуляция – для своей выгоды, для общей – как бы влияние. Вы кого-то можете пнуть, но и вам может прилететь.

Тарас не дал ссылок, откуда получены именно такие пять архетипов. Отмечу, что отличие этой классификации от большинства ценностных и мотивационных типологий в том, что она основана '''на страхах, а не на стремлениях или желаниях'''. Что логично для предмета выступления: страх – гораздо более сильный драйвер, чем желания.

'''Триггеры''' – проговариваете себе

* Художник – меня недооценивают
* Прагматик – меня снова заставляют идти без цели
* Властелин – страх что меня обойдут, это мнимое чувство власти. Шея или голова
* Модник – вы опоздаете, устареете, в теле паника от того, что «все внедрили, а я – нет»
* Бизнес – уводят обсуждения от денег и рисков, опять говорят без KPI

'''Техники'''.

* Вопрос-ловушка, вы говорите человеку, и в нем есть ответ, который человек выдаст. «Ты действительно считаешь, что монолит выдержит два года?». Прием дурных менеджеров.
* Боль и спасение. «Помнишь, мы с тобой разбирали, и увидели». Создать общую эмоциональную боль и показать спасение.
* Конспирация. «Я тебе как другу расскажу – все уже смотрят на аутсорсинг» – создать принадлежность к избранным, к секретному сообществу. Но это напоминает подростковую травму, а оно продолжается.
* Информационный туман. Я – куратор правды: «Амазон разбил монолиты на 10к сервисов и деплой – секунды» – и это правда, но не доносит, как много времени это занято – и мы идем делать микросервисы. Не знала, что есть старшая сестра, у папы второй брак, на вопрос «почему» – а меня не спрашивали.

Если вы умеете все распознать – вы можете защититься. Зная свой архетип, ты видишь вопросы-ловушки и другие примеры – и умеешь защищаться. Слушать слова, слушать свое тело и простыми техниками возвращать контроль. Если зовут в конспирацию: «если так важно – почему не обсуждаем на всех?»

'''Акт 3'''. Лицом к лицу.

* '''Татьяна'''. Инструмент всегда с вами.
* Образ Тараса: костюм без пиджака, часы, прямая спина – все детали дают образ.
* Образ Татьяны: серьезная, длинная юбка и так далее. Но! оборонительная позиция, мне сложно быть в мире мужчин женщиной. И надо серьезно вкладываться, чтобы слушали.
* Двойной стандарт в действии. Повышение голоса: у мужчины – харизма, у женщины – подавление лидерства. Мужчина может играть патронами и это плюс в карму, а у женщины – один патрон.
* Тарас – отдал демо. «У меня тоже такая боль» – и человек счастлив, хотя делает работу.
* Смена образа – Татьяна. В девочку – шорты и заправленная блузка. Я: по-моему, не получилось.
* Татьяна – Тарасу: ты уверен, что ты уверен забыть про доверие, отказаться от части эффективности, что поймешь, что дорого? Готов ли отказаться от токсичных техник? Если согласишься – похлопаете, и ты не будешь касаться человеком, который цепляется за власть. И ответ будет такой, что вы решите что чудовище. Она умеет нажимать на кнопки, но не хочет.
* Главное: замечаем ли мы, что нажимаем мы и нажимают на нас. Есть роли, которые мы хотим или не хотим играть.

'''Вопросы'''.

* '''Вопрос'''. Есть ли истина? '''Ответ'''. Истины – разные, но если вы выбираете в команду похожих – у вас будет одна истина.
* '''Вопрос'''. Есть борьба за ресурсы, и если другие продукты пользуются – то вам тоже пользоваться. '''Ответ'''. Да, но у вас есть выбор места работы, вы сами выбрали компанию, где так надо.
* '''Реплика''' Если бы все манипулировали – то нас бы окружали мерзкие манипуляторы, а это – не так. Значит в долгую выгоднее не манипулировать.
* '''Вопрос'''. Что происходит, если встречаются два манипулятора? '''Ответ'''. Разошлись в жизни. И вообще есть контекст, важно – участвуешь, не важно – нет.
* '''Вопрос'''. Стоит ли внести в матрицу аналитика умение манипулировать? '''Ответ'''. Да, можно, вносите в матрицу и оценивайте.

== Вадим Герасимов. От хаоса к системе: Почему LLM не отменяет анализ, а требует его эволюции ==

[https://analystdays.ru/ru/talk/145281 От хаоса к системе: Почему LLM не отменяет анализ, а требует его эволюции]

Это был рассказ о pet-проекте – сайтик и CRM для преподавателя йоги: блоги, комментарии, расписания и так далее. Набросок сделал в loveable.dev, потом загнал в git и дальше в Cursor AI + opus, Vibe Coding. Первая версия была сделана быстро, и развитие шло без архитектуры, документации и тестов. И проект закономерно начал рушится под собственной тяжестью, довольно быстро. Так что пришлось все это завести, чтобы исправить ситуацию. А теперь – подробнее.

Первый месяц – кайф. Добавить базу данных, сделать админку и так далее. Без диаграмм, user story, ТЗ – творец. Проект рос – 50+ компонентов, много api/ B он начал себя плохо вести: добавляешь email для рассылки – а он вместо добавления таблицы sqllite ставит postgreSQL. Запускает в продакшн – там все сломалось, потому что переменные хранения пути БД заменил на прямые пути, а они на тесте и проде разные. Добавление поля – день. Причина – ограниченный контекст, перестал помещаться.

Страх выкатки в прод: нет требований, чтобы проверить, нет тестов, потому что быстро пишем. А вручную – полчаса минимум все кликать. От vibe coding к fear coding – страх внесения изменений.

Шаги исправления.

# Архитектура: SQL lite, environment переменные и так далее – в отдельном файле.
# User stories. До этого – промпт, проверка – проверка и исправление результата. User story позволяют проверить намерение – что он будет делать.
# Тест-кейсы – чтобы все проверять.

Немного цифр. Первая стадия – быстрая разработка. 160 коммитов – новых. Кризис – 83 багфикса из 147. А потом – всего 40 из 140. Но 120 md-файлов аналитики.

Артефакты – не такие как для человека. Требования к ним более жесткие, ИИ нужен качественный структурный текст. Для всех артефактов он с помощью ИИ создал шаблоны: посмотри лучшие практики, сделай шаблон, положи в папку, и дальше используй. А после обсуждения фич – команда: сделай story и сценарии, он их проверяет.

ИИ будет развиваться, а человек будет общего характера с навыками разработчика-аналитика-архитектора. Работы меньше не станет, увеличиться интенсивность работы – растут желания. Роли появятся. skill.md тоже кто-то должен писать и так далее.

== Татьяна Белова из ГНИВЦ. Быстрое погружение или как получить максимальную эффективность ==

[https://analystdays.ru/ru/talk/145169 Быстрое погружение или как получить максимальную эффективность]

Это рассказ о различных сценариях погружения в проект, в зависимости от его сложности, К сожалению, первая половина была о том, что быстрое погружение – хорошо, а медленное – плохо, с подробным рассказом. А ведь эта мысль, с которой никто спорить не будет, так что было бы лучше сократить, и за счет этого подробнее показать методы погружения на конкретных примерах, а не просто рассказать о них голосом. Но все равно, то, что было рассказано – полезно.

Татьяна – эксперт-техлид команды аналитиков. Через нее проходит много новых специалистов – аналитики, тестировщики, дизайнеры, разработчики.

Тренд на усложнение систем – не только код, но и архитектура, точки интеграции и так далее. А погрузиться надо за месяц. При дефиците качественной документации, устаревание и фрагментарность до 70%. Частота ротация 6-12 месяцев, люди меняют компании и проекты – каждый раз погружаешь новых.

Аналитик – ключевое звено между бизнесом и командой, и чем дольше – тем дольше разработка, больше затраты. Четкий план адаптации снижают стресс сотрудников, сотрудник остается. А быстрый вход – дает маневр ресурсами.

Я: В общем, очень длинна вводная про то, что быстро погружаться хорошо, а долго – плохо. Как будто кто-то с этим спорит.

4 категории проекта: простые, средние, сложные и очень сложные.

'''Простые проекты''': понятные цели и минимальная неопределенность. - Быстрое погружение – описание методов - Работа в паре - Самостоятельное изучение – только если есть документация

'''Средние проекты'''

* Наблюдение и подражание рядом с экспертом
* Погружение через задачи с нарастанием сложности
* Передача внутреннего опыта – сессии обмена знаниями. Например, знания про классификации ЮЛ или постановки на учет.

'''Сложные проекты''' – нужны детализированные методы

* Детализированное исследование под руководством эксперта – не наблюдение, а ты делаешь задачу под руководством
* Симулирование рабочей среды. Проект, где много интеграций и зависимости влияют на поведение. Описанные 100 кейсов не дают понимание, надо потрогать саму систему, swagger помогает.
* Направляемое обучение лучшими в областях экспертизы – для контекста, где нет опыта, например, если не работал с data lake или bpmn, тут возможны внешние курсы.

'''Очень сложные''' – высокий уровень неопределенности и большой масштаб. Здесь нужен индивидуализированный план погружения с учетом характера проекта и будущей задачи сотрудника (например для витрин данных): знакомство с компанией, с проектом заказчика, интеграцией, бизнес-процессами.

И в конце выступления – матрица погружения: сложность проектов против уровня сотрудника.

Результат технологии – сокращение времени погружения новичков, стресса и адаптации, времени команды и подсветка отсутствия документации.

[[Категория:ИИ-агенты]]

{{wl-publish: 2026-05-25 17:36:13 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2026-06-18: Летний аналитический фестиваль: ИИ у аналитиков и другие темы

2026-07-24T14:46:17Z

MaksTsepkov:

{{Conf-Ref}}
Прошел очередной [https://lafest.ru/program2026/ '''Летний аналитический фестиваль''']. В этом году он проходил в Иваново: в связи с тяжелой ситуацией на рынке ЛАФ вернулся из Подмосковья на ту площадку, на которой начинался в далеком 2010 году. И к тому же формату: суббота – в офисе Консультанта, вечером – переезд за город, на турбазу, там шашлыки и движуха, а в воскресенье – продолжение мастер-классов уже на турбазе. И громадная благодарность организаторам, что провели фестиваль! Было много нетворкинга и интересные доклады, два трека выступлений и два – мастер-классов. [https://habr.com/ru/articles/1048838/ '''Мой отчет на habr'''], там выступления '''Евгения Виноградова, Игоря Рыбакова, Дмитрия Семчука, Николая Поташникова, Анастасии Кайновой, Альбины Бикбулатовой, Юлии Литвинюк, Тани Паловинкиной и мое, а также круглый стол по применению ИИ'''.

Вообще, применение LLM было основной темой фестиваля. Освоение LLM идет быстро, и, как обычно это бывает, есть лидеры и те, кто следует за ними. Лидеры уже не просто используют ИИ в качестве личного помощника, а встраивают в рабочие процессы, и это требует их реорганизации. Новых шаблонов еще не выработано, люди действуют эмпирически, опытным путем. Этот процесс проходил в ИТ много раз: появление персональных компьютеров, массовой потребности в сайтах, потом мобилок. Поэтому хорошо бы, проектируя такую реорганизацию, знать соответствующие подходы и методологии, об этом у меня недавно статья [https://habr.com/ru/articles/1035522/ '''Об организации труда ИИ-агентов'''].

Впрочем, и без теории получается неплохо, новая система разделения труда проявляется. Помимо позиции ИИ-технолога, который организует включение ИИ-агентов в пайплайн обработки задач, уже можно говорить о выделении позиции контекст-инженера, который организует снабжение ИИ-моделей необходимым контекстом для выполнения задачи, определяя недостающий и излишний контекст для моделей, а также ИИ-исследователя, который экспериментирует с новыми версиями выявляет потенциал использования. А позиция промпт-инженера, наоборот, уже исчезла – это с помощью ИИ может выполнять любой. Но вот принципиальное изменение, которое несет вайбкодинг – это '''переход от традиционного цикла разработки, начинающегося с тщательного проектирования, к быстрой разработки через прототипы и MVP, которое может делать сам бизнес'''. Это еще впереди, хотя некоторые компании уже так делают.

----
Переношу с habr

Прошел очередной [https://lafest.ru/program2026/ Летний аналитический фестиваль]. В этом году он проходил в Иваново: в связи с тяжелой ситуацией на рынке ЛАФ вернулся из Подмосковья на ту площадку, на которой начинался в далеком 2010 году. И к тому же формату: суббота – в офисе Консультанта, вечером – переезд за город, на турбазу, там шашлыки и движуха, а в воскресенье – продолжение мастер-классов уже на турбазе. И громадная благодарность организаторам, что провели фестиваль! Было много нетворкинга и интересные доклады, два трека выступлений и два – мастер-классов. А относительно камерный формат, в котором было всего 120 человек, многие из которых были на фестивале многократно, создал прекрасную атмосферу. Обсуждения многих насущных тем продолжались практически всю ночь до утра. А началось это на препати, который был еще в пятницу вечером.

== LLM – основная тема ==

Естественно, основной темой фестиваля было применение LLM, об этом были выступления и мастер-классы. Освоение LLM идет быстро, и, как обычно это бывает, есть лидеры и те, кто следует за ними. Лидеры уже не просто используют ИИ в качестве личного помощника, а встраивают в рабочие процессы. При этом повышение эффективности получается от 30% до нескольких раз. Эффективность меряют по возрастанию производительности на потоке задач. Иногда это еще и сопровождается сокращением числа сотрудников, но чаще обходится без этого – работы много, и ее просто быстрее делают, что дает новые возможности бизнесу.

Возможности LLM – очень велики. Один из повторяющихся сюжетов круглого стола по ИИ – вопрос из зала «как вы думаете, сможет ли ИИ когда-нибудь делать это», и ответ «он уже это делает». Например, '''обучает джунов''': Татьяна Половинкина из Неофлекс рассказала, что у них новичков созданию хранилищ данных и работе с ними учит виртуальный '''DWH-ментор'''.

'''Применение ИИ требует реорганизации рабочих процессов'''. При этом новых шаблонов еще не выработано, люди действуют эмпирически, опытным путем. Если говорить методологическим языком, то речь идет о '''реорганизации системы разделения труда'''. Этот процесс проходил в ИТ много раз при появлении новых технологий или управленческих практик. Так, появление персональных компьютеров и массовая потребность в разработке привело к созданию Agile-методов, а развитие интернет – к появлению web-мастера, который разрабатывал сайты, а позднее – к разделению его позиции на несколько специализаций. Поэтому хорошо бы, проектируя такую реорганизацию, знать соответствующие подходы и методологии. В частности чтобы не забывать про то, что всякая новая позиция, в том числе позиция ИИ-агента, должна быть спроектирована в окружении: снабжена необходимыми знаниями, определены критерии допустимого входа для задачи (DoR) и успешного завершения (DoD) и так далее. И думать об этом сразу на этапе проектирования, а не наступив на соответствующие грабли. О методологиях организации системы разделения труда у меня недавно статья [https://habr.com/ru/articles/1035522/ '''Об организации труда ИИ-агентов'''].

Впрочем, и без теории получается неплохо, люди успешно продвигаются, новая система разделения труда проявляется. Помимо позиции ИИ-технолога, который организует включение ИИ-агентов в пайплайн обработки задач, уже можно говорить о выделении позиции контекст-инженера, который организует снабжение ИИ-моделей необходимым контекстом для выполнения задачи, в том числе – определяет недостающий и излишний контекст для моделей, а также ИИ-исследователя, который экспериментирует с новыми версиями выявляет потенциал использования. Впрочем, эти позиции пока явно не называются, и неизвестно, сохранятся или они именно в таком варианте, или отомрут, подобно позиции промпт-инженера, которая перестала быть нужной после того, как ИИ начал хорошо помогать в создании промптов.

Но вот принципиальное изменение, которое несет вайбкодинг – это '''переход от традиционного цикла разработки, начинающегося с тщательного проектирования, к быстрой разработки через прототипы и MVP, которое может делать сам бизнес'''. Раньше разработка через прототипы тоже была, но применялась очень ограничено, для новых экспериментальных фич и проектов. А сейчас может стать основным способом. И дальше надо так организовать процесс, чтобы к большому продукту, находящемуся в эксплуатации, с помощью вайбкодинга можно было примешать новый функционал или поправить существующий, не снижая устойчивость. То, что раньше делали ограниченно, позволяя, например, декларативно описать новый тарифный план или промо-акцию. Вайбкодинг позволяет много больше.

И в практике это тоже активно происходит. Один из кейсов на круглом столе: из 5 аналитиков остались двое, один сеньор, а другой – джун, потому что '''у них было открыто сознание для перестройки''', а трое ушли, не захотели или не смогли перестроиться. Потому что изменения сильные: '''ты не документы пишешь, а систему вайбкодишь и приносишь ее заказчику''', огребая при этом обратную связь. Что интересно, пятнадцать лет назад я слушал выступление Paul Turner на ReqLabs-2011, он там рассказывал модель, в которой аналитик не только снимает требования заказчика и пишет постановку, но и принимает результат от команды разработки и несет ее заказчику – потому что именно он формировал ожидания в ходе первоначальной коммуникации. Эта часть роли аналитика – отнести результат – ушла в тень. И вот оно вернулось, только вместо команды разработки у вас могут быть вайбкодинг и ИИ-агенты.

Ну а теперь перейдем к отдельным выступлениям, в том порядке, в котором я их слушал. Среди них я хочу особо отметить выступление Юлии Литвинюк – там интересный кейс работы над повышением устойчивости системы. Напоминаю, что здесь далеко не все, потому что на конференции было четыре параллельных трека. Видео выступления будет выложено.

== Максим Цепков. Опора в эпоху перемен: логика и культура лидерства Китая и опыт китайских tech-гигантов ==

Начну я со своего выступления, так как оно реально стояло в первой линейке. И мне очень приятно, что был полный зал, хотя параллельно было интереснейшее выступление про ИИ. Впрочем, в моем выступлении про ИИ тоже было – не столько про технические успехи Китая, которые общеизвестны, сколько про иное культурное отношение к ИИ. Когда я в октябре 2025 года поехал в Китай, то контраст был очень сильным. Впрочем, сейчас у нас отношение меняется в конструктивном направлении.

А в целом я очередной раз рассказывал про менеджмент и корпоративную культуру китайских компаний и ро происходящие в мире изменения, связанные с перехватом Китаем технологического и политического лидерства у Штатов. Основой – личный опыт поездки по китайским технологическим компаниям (Baidu, Xiaomi, SenseTime, Little Red Book и других), и последующее углубление в тему. Презентация выложена [https://mtsepkov.org/China-LAF на странице выступления] на моем сайте. Видео будет опубликовано, а пока можно читать мою книга '''«[https://ridero.ru/books/kitai_dao_menedzhmenta_i_kulturnyi_kod_budushego_lidera_mira/ Китай: дао менеджмента и культурный код будущего лидера мира]»''' или смотреть вебинар [https://mtsepkov.org/ChinaLeaderNSE '''Влияние технологий на изменение мирового порядка и глобальную конкуренцию'''], который я проводил в январе. Отмечу, что этой весной у меня много выступлений на эту тему, однако они не являются повторением: я меняю логику рассказа и адаптирую рассказ под аудиторию. Хотя, конечно, в них много общего.

== Евгений Виноградов. Выбор модели для построения AI-агента ==

Основной тезис выступления в том, что сейчас выбор модели – не главное, что определяет успех внедрения, хотя, конечно, модель должна быть адекватна задаче. '''Главное – это обеспечить модель необходимым контекстом'''. И надо уметь отделять работу с контекстом от самой модели, в том числе – для того, чтобы можно было проверять и сравнивать разные модели. И Евгений рассказывал о средствах для этого, которые, в том числе, позволяют организовать автотесты работы с контекстом, а не просто управлять им.

И перед тем, как рассказать про вступление подробнее, я хочу дать ссылку на другое выступление: [https://aiconf.ru/2026/abstracts/id10704551 Дарья Шатько. Как мы внедрили 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. Про карту гипотез есть книги автора, подробнее вы можете посмотреть [https://mtsepkov.org/ByndyuHypo-2 мою рецензию].

Однако, фокусом выступления был не рассказ о методе как таковом, а практический вопрос: как вести себя в ситуации, когда бизнес пришел с готовым решением, а у вас есть опасения, что это решение окажется не адекватным и будет выброшено в корзину, а вы окажетесь виноватыми, потому что «сделали не то и не так». Основания для таких опасений могут быть разные, например, предыдущий опыт взаимодействия. И это – актуальный вопрос, независимо от метода, применяемого для решения. Итак, про содержание выступления подробнее.

Кейс – программа лояльности. Бизнес часто приносит готовое решение: нужна программа лояльности – надо поднять повторные покупки. Задача имеет несколько уровней и не факт, что проработано. При этом даже когда заказывают исследование и оно показывает, что решение не работает, бизнес говорит «мы лучше знаем». Но в том, что не работает по-любому виноват подрядчик: он сделал не то и не так. Бизнес -не виноват.

Логическая цепочка должна быть построена следующим образом.

# Что мы хотим сделать
# Через кого сделать – люди
# Как поменяется поведение
# Какой инструмент изменения.

Этот путь надо пройти самим.

Impact mapping – метод, который позволяет перевести вопрос с уровня «что надо сделать» на «что должно измениться и зачем», связать ожидания по каждой фиче с конкретными метриками, автор – Гойко Аджич. До impact mapping они пробовали плоский бэклог, user story mapping – в нем не всегда есть ценность, и Feature Slice Design (FSD)/ТЗ – не всегда есть связь.

Кейс подробнее. Есть магазин одежды, первая покупка есть, а вторая проседает – клиент не возвращается. Магазин посмотрел у конкурентов – есть программа лояльности, и говорит: давайте внедрим. Очень популярный путь, хотя обычно не работает, потому что формальный перенос без понимания механик оказывается недостаточным.

Прямые возражения или вопросы, «а почему вы решили, что так будет работать» срабатывают плохо и вызывают ненужный конфликт, ведь бизнес уже решил, что делать. Поэтому действуем сложнее, по такому сценарию.

# Принять решение в том виде, как предлагает бизнес
# Спросить и согласовать: как мы поймем, что цель достигнута, какие будут метрики
# Подумать над рисками и ограничения предложенного варианта
# Если есть возможность – утрируем риски или потери возможностей
# Переформулируем запрос через цели и метрики
# Переходим в пространство решений – предлагаем альтернативы
# Выбираем приоритетный вариант

На втором этапе нужно 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
* '''Мультиагентные системы''' – сборка многих агентов под комплексные задачи.

'''Почему агенты не работают?''' Ошибки и заблуждения проектирования. Сложности – не технические, а бизнесовые и архитектурные.

# '''Концепт «агент решит все сам»''', это волшебная кнопка, он сам сделает. Нет, его надо проектировать и настраивать. Иначе он не работает, делает не то. Спецификация – карточка агента, там набор типовых задач, контекст и так далее. Дальше делаем реестр и публикацию через него.
# '''Отсутствие обработки ошибок'''. Агент стучится в API, и не всегда не всегда получает ожидаемое. Обработка, retry, сохранение состояния. Иначе они могут сожрать все ресурсы, стучась в сервис, который лег.
# '''Нет логирования и наблюдаемости'''. Каждое действие складываем в файлы. Есть инструменты – Chain-of-Through, LongFuse.
# '''Игнорирование контекстного окна'''. Оно переполняется, над чистить или утрамбовывать, иначе он забывает, что делал и что просили. Минимум – есть плугин, который показывает контекстное окно, и смотрите. Цепочка суммаризации – по мере наполнения контекстного окна, суммаризуем. RAG – классный концепт, как можно работать с большими базами данных, но это сложно.
# '''Слепое доверие к LLM'''. Почему-то многие дают все права, вместо того, чтобы дать ограниченные – как джуну. Валидайия результата. Структурированный результат – json вместо текста.
# '''Переусложнение архитектуры'''. В большинстве случаев агенты не нужны, идити от минимального к максимального, а до этого посмотрите, что у вас уже есть.

'''Куда идти осторожно?'''

* Сложные LLM-workflow. Если больше 10-15 вызовов – упрощайте, передумывайте процесс.
* RAG для простых решений. Он – для сложных, в большинстве он не нужен.
* Агенты на frontier-моделей без НФТ. Поставьте ограничения и мониторинг бюджетов.
* Мультиагентные системы без LLMOps – не забегайте вперед, сначала освойте использование отдельных.

'''Итого'''.

* Идем от простого к сложному, нужна бизнесовая зрелость (описание процессов, наличие данных), архитектура и процессы важнее конкретных моделей.
* '''Используйте агентов уже сейчас, как получается.'''
* Не надо упарываться в технологии. Prompt-engineering, который казался профессией будущего – сдох, LLM сами это делают.

И был слайд с вариантами агентского стека под разные цели.

Еще есть сложность, если агентами начинает заниматься data scientist. Дело в том, что data science – про дообучение, обработку данных. А LLM – это коробка, сама работает, и ее надо использовать с учетом ее ограничений, дообучение слабо реально. Data scientist часто усложняет.

Перестройка процессов – отдельная тема. Были классические команды: аналитик, бэк, фронт, data scientist. Сейчас есть проекты, где аналитик с разработчиком совместно в Claude работают в тройках. B scrum – он для людей, а с агентами процесс меняется.

== Николай Поташников. LLM как независимый аудитор: от генерации к оценке артефактов ==

Основная проблема архитектора – обеспечить такую архитектуру, чтобы система не деградировала. Как это проверить и чем тут может помочь LLM?

В выступлении были такие кейсы.

# Несоответствие пользовательской документации продукту.
# Несоответствие архитектурных диаграмм проекту.
# Оценка качества данного доклада – релевантность ЛАФ, ценность и так далее

'''Работу делает человек, а 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, включая не только типы руководителей и исполнителей, но и способы работы с идеями, что для ИТ принципиально важно.

Подробнее про эти и другие можно почитать в моей книге [https://ridero.ru/books/inzhenernaya_model_lichnosti/ '''«Инженерная модель личности: Меняя себя и других — понимай устройство»'''], а также отдельных [https://mtsepkov.org/SoftSkills статьях и выступлениях на моем сайте].

== Юлия Литвинюк. Как мы подружили 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, гильдии, онбординг и так далее – туда добавилась новая тема. А сделали антипаттерны, чек-листы, аттестации, практикумы парного проектирования (создание – человеко-месяц, дальше затраты на проведение) и шаблоны кода.

Как повторить?

# Одно жизненно-важное изменение
# Начните с боли, а не теории
# Минимальный набор изменений
# Микропрактикум
# Найдите лидера мнений и привлеките его
# Встройте в процессы
# Свяжите с профессиональной ценностью.

Изменения пошли по мере накопления критической массы – в практиках. А началось все в OKR – снизить количество критических инцидентов, антипаттерны – лишь средство достижения.

== Круглый стол по ИИ ==

Круглый стол был структурирован на отдельный такты по вопросам. На нем обменивались мнениями и делились практиками, не было цели выработать мнение и придти к общему решению. На мой взгляд, основная функция – как раз показать, что LLM уже мощно работает, и может не только решать задачи вайбкодинга, но и, например, обучать новичков.

Дальше – тезисное изложение содержания, которое я успел пунктиром записать. Реплики – от разных авторов, и я это не фиксировал. Кроме того, при записи неизбежна интерпретация, а когда я дорабатывал в текст для публикации, интерпретировал еще раз. Съемки не было, но была запись на диктофон, обещали транскрибировать и выложить.

# '''Что можно делегировать ИИ'''

Два принципиальных подхода: аналитик пишет, ИИ проверяет, или наоборот. Пока вырулить в то, что ИИ пишет, удается плохо. Аналитик ведет интервью, задает контекст, базовые вопросы. И это сильно зависит от опыта, есть кейсы, когда у сеньора получается прояснить ситуацию, а миддл – запутался. Дальше человек пишет документ. Они сравнивали, человек обгоняет Claude, потому что тот опирается на усредненное знание, а человек – на конкретный контекст, а передать в Claude контекст – это как создать документ с результатом. А вот дальше ИИ проверяет результат, это он делает хорошо.

Но это – работа в существующем процессе, а он будет перестраиваться. Так уже было: первые сайты делали из каталогов документов, а первые мобильные приложения – на основе веб, подобно сайтам – и они были ужасны, но постепенно новые практики нарабатывали. Сейчас создают ИИ-натив, новое. Как именно перестроится процесс – неясно, крутимся как умеем и подстраиваемся на ходу.

Я тут отмечу, что и в существующем процессе много точек включения ИИ. Да, начальные интервью – человек. А транскрибация – ИИ. Заготовка концептуального документа – оглавление, тезисы, основное содержание тоже человек. А вот проверить, соотнести с записью интервью, зафиксировать, что упущено и предложить доработки вполне может ИИ. А если помимо 2-3 основных интервью планируется широкий опрос, чтобы увидеть разнообразие практических кейсов, то ИИ может помочь и в подготовке списка вопросов и в обработке результатов.

Когда-то была история: приложение для диспетчеров такси. На входе был ад – громадное количество информации, которая показывала все заказы, и диспетчера плохо успевали в них увидеть те точки, куда надо вмешаться. Сделали чистый экран, где только инциденты. Казалось бы, хорошо, но диспетчеры говорят: нет ощущения, что система работает, не видно динамики. Так и с ИИ: если агенты делают все сами, все равно нужна наблюдаемость. Я с этим согласен, но это не значит, что нужны все детали, наблюдаемость умеют делать через мониторинг – графана и прочее. Правда не все умеют работать через показатели, а не доску задач, но это – старая проблема, ИИ тут интенсифицирует процесс.

Была история – баттл комиков. Первое – шутки ИИ против ваших, второй – продолжить, третий – диалог с залом. ИИ проиграла, но с очень небольшим отрывом. Домашние – один голос, а продолжение шутки – было хорошо. Да, шутки смешные, но этот – наш, а этот – не наш. Человеку нужен человек и он будет нужен еще долго.

Генерировать технические решения – можно, но это – длинный текст, который человек не дочитывает, хотя он – хороший. Надо перестраивать процесс.

Уже сейчас понятно, что где-то преимуществом может стать разделегирование: наняли джуна, и он делает дешевле и лучше модели. И конкретный пример тут. Как только начали ставить ИИ массово на скоринг резюме, то спецы не могут составить резюме, не получается нормальных кандидатов.

С моей точки зрения, все это означает, что делегировали неумело, проблемы всех кейсов, в которых ИИ что-то делал дорого и долго были в том, что ИИ воспринимали, как «волшебную кнопку, которая сама все сделает», и не подумали о том, как он должен работать, каким контекстом его надо снабдить и так далее. Впрочем, с джунами тоже так часто поступают, а потом говорят, что глупый и неспособный попался. При этом ИИ может помочь подумать о том, чем его надо снабдить для решения задачи.

И к скорингу резюме это тоже относится, я еще год назад на Merge слушал доклад про ИИ-рекрутера полного цикла – от интервью с руководителем о требованиях и создания описания вакансии до первичного взаимодействия с каждым кандидатом в переписке, а затем скоринга для отбора на собеседование. Так там люди подбирали три разных способа оценки кандидата, и на их основе – итоговую оценку, так – работало. И да, это думать надо.

Вся административная и техническая рутина уходит на ИИ: транскрибирование и резюме интервью и совещаний, выделение решений и формирование задач.

Когда человек начинает работать с ИИ, то есть две проблемы: (а) восприятие конкурента, и в самом вопросе «что могу делегировать» – про конкурента, (б) восприятие как автомата, а там нет автомата. С этим надо работать.

ИИ работает. Два дискавери за две недели, каждое по-старому требовало 160 часов. А в феврале мобильное приложение разработали и вывели в store за 60 часов. Коэффициент ускорения 2-4 раза.

Разобраться с легаси ИИ тоже хорошо помогает. Отмечу, что на Merge я слышал интересный кейс. У человека наработан навык погружения в проект с помощью ИИ. Человек пришел на работу в компанию, где позволен только GigaChat (по безопасности), но тот разборки с проектом не потянул. Зато научил, как развернуть себе на рабочую машину локальный DeepSeek – и тот смог разораться, хотя думал над ответом по 40 минут, в отличие от сетевого. Но в результате за вечер погрузиться получилось, в то время как погружение без ИИ по оценкам из прошлого опыта требовало бы неделю.

<ol start="2" style="list-style-type: decimal;">
<li>'''Как образовываться, работать с ИИ мидлам и сеньорам.'''</li></ol>

Хотя новый вопрос был объявлен, часть тезисов относится к предыдущему.

Кейс. Спросили ИИ, чтобы разобраться с легаси. Первый ответ был хороший, по делу. Потом пошли вглубь – и он начал фантазировать, на третьей итерации – стоп. Это – опыт. А как опыт тренировать у новичков? Неясно. Я бы сказал, что так же как раньше: наступаем на грабли, ревью с объяснениями, наставничество, помощь старших. В принципе, ничего не изменилось.

Про работу – метафора. Есть лето, простор. Мы огородили площадку, собираем грибы, пять человек. Вдруг новая технология сбора, теперь это двое делают. Остальные идут вокруг – лес большой, мы раньше просто не могли столько собрать. Так и тут – задач много, хотелки безграничны.

Если говорить про легаси, то ИИ может обвязать легаси тестами, и будет безопасно менять. Раньше обвязка тестами была сильно дороже.

Про сеньорность. Хороший лыжник с некоторой вероятностью станешь биатлонистом- освоение смежных. И теперь ИИ позволяет быть сеньором в большом количестве областей. Развивайтесь, осваивайте их с помощью ИИ. У него сотрудник был миддл-минус, а с за счет ИИ он стал сеньор-минус – он может отвечать за задачу. Но это не само происходит – надо освоить ИИ.

Концентрация на инструменте – вредит, а обучение – вечный вопрос. Есть задача, выписал инструменты, в их числе ИИ, который нужен не всегда. И делаешь. И open claude – можно скилы под себя настраивать и это – мейнстрим. Инструмент свежий, и появляются короткие курсы.

'''Эксперт – тот, кто продолжает спорить ИИ'''. Надо подняться. Захватить контекст и процесс. Управление – на себя, а реализация – на LLM. B надо расширять рамки, перенастраивать.

Ольга Подолина. ИИ в сельском хозяйстве ставят на тракторы – автоводители, Россия тут впереди многих стран. И надо придумывать новое.

Ирина Гертовская. В 60-х такие машины работали на горнорудных фабриках. И это не новое. ИТ сейчас везде. И его становится больше, надо быть на фронтире.

Не надо учиться писать доку. Аналитик был спецом, который видел общую картинку, и с ней работал. Прокачка – умение видеть картинку, спроектировать новое, джобами и смыслами. Профессия становится сложной. Нужны софты. Задачу плохо ставят, ее надо переварить.

Есть разные сеньоры. Бывают, что человек 5 лет на одном проекте, набрает опыт, который с ним связан, и дают сеньора, потому что надо поднимать зарплату. Или ты успешно освоил процессы компании. И это не значит, что в другой компании или другом проекте ты тоже будешь сеньором. Надо взглянуть на себя, свои компетенции, и переоценить – это может быть больно. С другой стороны, мидлы бывают недооцененные, у них перспективы.

<ol start="3" style="list-style-type: decimal;">
<li>'''Обучение джунов'''.</li></ol>

Татьяна Половинкина. Потребность в джунах уменьшается, хотят мидлов с ИИ, которые на следующий день станут сеньорами. Но это – в короткую. Мы берем джунов с дальним прицелом, и '''у них наставничество для джунов, и они его активно переводят на ИИ. У них есть DWH-ментор'''. Но некоторые менти говорят: ваш ментор сюсюкает, я его переделал, мне жесткий нужен. Ннужны джуны, которые смогут управлять системой. Есть процесс, который выковыривает таких людей и учит их.

Реплика. Ситуация страшная, видел появление отделов и обучение промптам, а потом обесценивание и способность выгнать. Технологии меняются, не привязывайтесь Поэтому софты первичны: умение видеть проблему, находить решение проблемы, применять новые технологии для решения проблем.

Процесс обучения был выстроен по принципы «делай как я» в древних временах. И сейчас так же: мы умеем классно писать требования, пишите так же. Сейчас обучение разбивается на две вещи. Крупная большая компания – рисуем карту процесса, чтобы разобраться. Копалась две недели – фигня, загружаем в ИИ – за два часа карта процессов. Нужен человек, который объяснит задачу простым языком – что именно надо сделать. И сейчас это – новый джун. Как входить в профессию? Понимать проблемы и пробовать объяснить простым языком.

Реплика. Вы говорите об идеальном джуне. А как обучить, чтобы он мог это сделать? Ответы. Как начинал я: мне дали проект и отправили делать. И сделал. А еще наши дети сами обучались пользоваться мобилками. И сами научатся ИИ.

Реплика. Компетенции меняются, через пять лет будет нейроинтерфейс.

Делать обучение надо самим, университеты не смогут обучать, они на такую быструю смену программ не ориентированы.

Основа мотивации – любопытство, инициатива и тяга к новому. А учиться – на кошечках, тех проектах, где фейлы не критичны. И огораживать безопасные места.

Реплика. Черчение в университете руками, а не в автокаде – чтобы развить пространственное мышление. Ответ. А Демокрит думал, что письменность убьет мышление – они не будут запоминать, а будут читать.

Татьяна Половинкина. Уже сейчас ИИ учит джунов. Не когда-нибудь. Виртуальный DWH-ментор.

Есть разные джуны. Есть талантливые, которые за несколько месяцев становятся как архитекторы. А он не хочет – надо погрузиться.

'''Вопрос'''. Про HR. Мы меняем навыки компетенций. А потом они сталкиваются с нашими HR – и что? А это проблемы HR.

Новые позиции: архитектор контекста, управляющим процессом devops.

Из 5 аналитиков остались двое, один сеньор, а другой – джун – потому что у него было открыто сознание для перестройки. Изменения сильные: ты не доку пишешь, а систему вайбкодишь и приносишь заказчику и огребаешь.

Осознанность надо иметь. Но еще кругозор – он не всегда есть. И бывает ребята после ВУЗа – не понимают область. И выстраивание процесса, чтобы они могли расти и выстраиваться.

== Татьяна Половинкина. DMBOK-рулетка: Архитектура данных на выживание ==

Это был очень интересный workshop чтобы почувствовать, как работает pipeline DWH. D оригинале он в электронной форме, но на второй день на площадках не было интернета (только через WiFi в основном здании). Поэтому был собран процесс из людей и движущихся бумажек.

<blockquote>'''(CRM, ERP, Log) → Streaming → Raw → ODS → DDS → (Mart → User)xN'''
</blockquote>
* ODS – трансформация
* DDS – хранение данных '''со всей историей изменений и версий'''
* Mart – витрина
* '''MDM''' – отдельно встроен, он делает золотую запись. И она пополняется отдельно от основного потока, а в потоке она фильтрует и идет соответствие.

Этот процесс несколько раз прошли, а дальше было такое упражнение: из участников один выбирался как аудитор, остальные договаривались, кто допустит ошибку (типовые ошибки у каждого были), а аудитор должен был это поймать.

На этом я завершаю свой отчет.

[[Категория:ИИ-агенты]]
{{wl-publish: 2026-06-18 10:23:10 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2026-07-02: Saint Highload-2026: как крупный ИТ осваивает ИИ

2026-07-24T14:42:02Z

MaksTsepkov:

{{Conf-Ref}}
Опубликован [https://habr.com/ru/companies/oleg-bunin/articles/1053550/ '''мой отчет с Saint Highload'''] в Питере. Превалировала тема ИИ, ей был посвящен отдельный трек, и еще ряд выступлений и много мастер-классов на других треках. Отмечу новое хайповое слово: '''harness''' – им называют обвязку вокруг ИИ – получение контекста, настройку скилов для агентов других правил работы, и так далее. Еще из хайпа следует отметить ai-native и ai-first – ярлыки, которые стремятся на себя повесить, как 10 лет назад вешали лейбл Agile чтобы выглядеть модно, молодежно и прогрессивно. Как и тогда, содержание может быть самое разное.

А в целом конференция дала мне инсайт: инженеры используют тему ИИ, чтобы воплотить давние мечты. Одни – чтобы собрать-таки правильный водопад, пусть на агентах, раз на людях не получается, Spec Driven Development – об этом. То есть слова об изменении процессов остаются словами, инженеры верят, что классический водопад – самый правильный процесс. Другие – вообще реализовать давнюю мечту писать платформы вместо того, чтобы заниматься бизнес-задачами, которые отдать бизнесу, переложив разработку на агентов полностью. Обе – не реалистичны по системным причинам, но корпорации ведутся: там любят мегапроекты, которые сулят большие выигрыши, надеются получить высокую скорость и избавиться от зависимости от ИТ-шнков. При этом корпорации ждут готовых фреймворков, они не готовы реально экспериментировать с радикальным изменениям процесса, сложившаяся оргструктура сопротивляется. Это четно видно. А вот небольшие компании – реально экспериментируют и меняются, это я видел и на Highload, и на других конференциях.

Отчет опубликован на habr, через некоторое время перенесу на сайт, а пока читайте там.

[https://t.me/mtsepkov/1183 Пост на моем канале] [https://t.me/HighLoadChannel/5377 Пост на канале конференции] [https://t.me/HighLoadTalks/95087 Пост в чате конференции]

----
Переношу на свой сайт

Прошел очередной [https://highload.ru/spb/2026/schedule Saint Highload]. Онтико поменял формат, на конференции было три трека выступлений и два – мастер-классов. Превалировала тема ИИ, ей был посвящен отдельный трек, и еще ряд выступлений и много мастер-классов на других треках. Отмечу новое хайповое слово: '''harness''' – им называют обвязку вокруг ИИ – получение контекста, настройку скилов для агентов других правил работы, и так далее. Естественно, это делали и раньше, но на highload появилось модное название, которое на других конференциях не звучит или звучит гораздо меньше. Еще из хайпа следует отметить ai-native и ai-first – ярлыки, которые стремятся на себя повесить, как 10 лет назад вешали лейбл Agile чтобы выглядеть модно, молодежно и прогрессивно. Как и тогда, содержание может быть самое разное.

Выступления по ИИ дали мне инсайты – что же кроется за Spec Driven Development на уровне идеалов. Это – сохранение нынешних представлений об идеальном процессе, и на это же ориентированы модели зрелости, в которых ИИ-агенты просто заменяют человека. При этом уже понятно, что процессы будут принципиально перестраиваться. Об этом выступающие тоже говорят. И совершенно не видят противоречий: '''говорят, что процессы изменятся, и транслируют модели, основанные на его сохранении'''. Инсайты надо было зафиксировать сразу, и я публиковал посты в ходе конференции. Ими и начинаю свой отчет, а затем будут конспекты выступлений в том порядке, в котором я слышал. Интересные выступления отмечены в общих впечатлениях. Презентации выложены на сайте конференции, можно смотреть. Видео – для участников и есть опция купить видео.

Еще я хочу отметить, что корпорации – консервативны и ждут готовых решений, фреймворков и методик. Они не готовы сами быть драйвером, они готовы лишь догонять. Мелкие компании – готовы, и энтузиасты в корпорациях тоже, потому что тренд ясный. А еще топы банков помнят успех Тинькова, который ворвался на рынок, пока остальные крупные сидели и ждали, и поэтому не ждут. Парадокс в том, что без появления нового игрока больше всего шансов у удачливого второго, потому что первопроходец огребает максимум ошибок, при этом в нынешней открытой информационной среде спрятать свои методы первый не может. Впрочем, вырвавшись вперед второй становится первопроходцем, роли меняются, а путь – из многих этапов.

Комментируя выступления, я ссылаюсь на материалы других конференций, на которых я был этой весной. Там как раз более мелкие компании и гибкие делились своими успехами. На Highload и Teamlead они тоже были, и на Teamlead их было больше. Детали можно посмотреть в соответствующих отчетах: [https://mtsepkov.org/TechWriterDays-2026 TechWriterDays-2026], [https://mtsepkov.org/MergeConf-2026 Merge-2026], [https://mtsepkov.org/AIconf-2026 AIconf], [https://mtsepkov.org/SQAdays-2026a SQAdays] [https://mtsepkov.org/AnalystDays-2026a AnalystDays], [https://habr.com/ru/articles/1048838/ ЛАФ-2026].

== Впечатления первого дня ==

Первый день #Highload в Питере. Я был на треке, посвященном ИИ, выступлений на эту тему было больше одного трека. Многое из услышанного заслуживает подробного разбора, и он будет в моем отчете позднее. А сейчас я хочу по горячим следам зафиксировать несколько тезисов. В том числе для того, чтобы если позднее впечатление изменится, эти следы остались. Ну и чтобы, возможно, обсудить это завтра и на Teamlead.

# '''Spec Driven Development – это попытка инженеров построить водопад. Хотя бы на ИИ-агентах, если уж на людях не получилось'''. Не потому, что родился Agile, причина обратная: Agile родился именно потому, что классический подход (водопад, RUP и так далее) – не сработал. И SDD не сработает по тем же системным причинам, так что картинка, которую вы видите в посте по-прежнему актуальна.
# Внедрение ИИ-агентов (а не ИИ-помощников) не совместимо с привычными способами работы. Даже в варианте SDD. '''Чтобы внедрить не формально, а получить реальный эффект, надо существенно перестраивать процессы'''.
# Что такое «привычный способ работы» – вопрос отдельный. О них был роскошное выступление Даниила Подольского, где он назвал этот метод '''«колхозный скрам»''' и очень едко описал. Это когда разработчики делают непонятно что, потому что бизнес описал это невнятно, бесконечно это переделывают и правят ошибки. И да, показал, что ему точно придет конец. Замечу, что этот метод от скрама получил только лейбл в то время, когда скрам стал модным. А исторически сложился он задолго до, и в agile-сообществе его называли '''Code-and-fix'''. Впрочем, реальный скрам ИИ-агентам тоже не подойдет, потому что он сконструирован для людей, и там команда держит в голове громадный контекст не документируя, в этом есть свои профиты, но ИИ так не может, а выгрузка в артефакты требует переборки метода.
# По агентской разработки (agentic engineering) Highload не дает фронтира. Там сломались на том, что разработчики стали писать много кода, а как делать review как бы непонятно. '''Реальный фронтир я слышал на других конференциях, у аналитиков, тестировщиков и других. Там технологично: раскладываем pipeline на операции, выясняем, какие из них и для каких задач уже хорошо делают агенты, выносим на них, следим за процессом метриками, совершенствуем агентов.''' В результате одни агенты пишут по текстовой задаче acceptance criteria (которые человек проверят), другие – по ним делают тест-кейсы, третьи – делают их ревью, четвертые – по тест-кейсами пишут автотесты или проверяют вручную через mcp-плугин к броузеру и так далее. При этом для разных типов задач – разный уровень вмешательства человека, так что есть агенты или правила классификации задач и выбора pipeline. B надзор качества через мониторинг и выборочные проверки. На уровне общих слов в выступлениях об агентах это было, но вот конкретных кейсов – нет, так что выступления, скорее, об общих представлениях, чем об уже сделанном.
# '''О главном изменении в будущем – изменении границы, которую SDD по-прежнему выстраивает по требованиям – никто не говорит'''. А она – меняется, при этом она кое-где изменилась давно, когда на команду сваливают задачу «наш продукт плохо идет на таком-то рынке, а есть потенциал – проведите анализ, найдите проблемы и решите», вместо классики «сделайте фичу». И бизнес начинает разбираться сам, вайбкодит приложения, а потом приносит команде, иногда со словами «я тут за вечер сделал то, на что вы хотели две недели, забирайте». В общем, это было раньше – разработка через прототипы и MVP, которые сразу идут в прод, если проверка дала успех, а потом развиваются. ИИ в это вдохнул новую жизнь. Это обсуждают в кулуарах в негативном залоге, а то, что именно в этом будет будущее – не видят. Впрочем, через полгода-год – увидят.

На этом пока все. До встречи на втором дне!

== Впечатления второго дня ==

Второй день принес развитие впечатлениям первого. Выступление '''Андрей Неведин из Райфайзен «Context is a must: как мы системно управляем контекстом»''' корректирует мой тезис первого дня о том, что SDD (Spec Driven Development) – это давняя мечта инженеров построить водопад, пусть на ИИ-агентах, раз уж на людях не получилось. Все-таки, '''мечты у инженеров разные, одни мечтали построить совершенный метод разработки на основе тщательного проектирования, а другие – писать платформы вместо бизнес-задач'''. Для этого в свое время создавались системы, в которых, по задумке, бизнес сам должен был настраивать бизнес-процессы и все остальное, что требуется для них, а на долю разработчиков оставалось бы совершенствование этих систем. Теперь эта мечта переосмыслена: раз отдать бизнесу не получилось, давайте отдадим ИИ-агентам, а мы будем их настраивать, создавать harness, обеспечивая, чтобы они решали эти задачи сами.

И Андрей рассказывал о движении по этому пути. В эксперименте 5 команд, обеспечивающих большие сегменты бизнеса: кредиты, платежи и другие, у каждой такой команды есть команды агентов для discovery задачи, которая пишет спецификации и delivery для реализации, а люди не только подключаются к процессу там, где не получается, но и анализируют – чего не хватило агентам, чтобы сделать задачу. При этом '''люди не проверяют спецификацию''', в отличие от классического SDD, а обсуждают ее с агентами при необходимости. Они в начале пути, агенты активно участвовали в 25% задач, а 4% сделано агентами без людей, при этом ряд областей кода, относящихся к критическим подсистемам, таких как процессинг и риски, агентов сейчас не допускают. И они полны оптимизма, и четко декларируют цель: 100% задач без агентов.

Я этот оптимизм не разделяю, это опыт ИТ показывает: несмотря на богатые возможности генерации сайтов, дизайнеры и разработчики сайтов остаются, а описание бизнес-процессов не позволяет покрыть их полностью, так как процессы содержат множество точек с особыми ситуациями, разруливание которых не описывается языком процессов. Аналогично и здесь, агенты смогут взять значительную часть разработки, но не все. Возможно, соотношение будет описываться правилом Парето 80/20, почему бы и нет, только надо понимать, '''что из тех 80%, подвластным агентам, значительная часть уже сделана людьми без них''', до появления этих агентов, так что на текущем потоке будет значительно меньше. При этом при надлежащей организации, которую постоянно поддерживает человек, агенты с нуля разрабатывают весьма сложные приложения, это факт.

Принципиальным вопросом является та часть процесса, которая обеспечивает выполнение задачи агентами. Андрей назвал два фокуса внимания создание контекста и тестирование, в которое они много вкладывают. Но выступление было с фокусом на контекст, про тестирование не говорили. Уже в кулуарах я услышал про выступление '''Виталия Левченко на Codefest''', где он говорил именно о таком переосмыслении SDD: вместо проверки спецификации, которая все равно нечитаема, мы проверяем тестовые сценарии и критерии приемки, это гораздо легче и быстрее, для них можно обеспечить читаемость. И тогда процесс едет. Идея понятная и рабочая. Понятно, что она не сработает для задач, в которых соль – в реализации, например, в сложной алгоритмике или декларативных описаниях, где надо сделать гибрид автомата и особых случаев, но доля таких задач в общем потоке не слишком велика.

Во второй день было много практических выступлений, этим он, на мой взгляд, позитивно отличался от первого. Это выступление '''Александра Иванова про ast-index''' – средство для быстрого формирования компактного контекста проекта, передаваемого агентам, техническое, со многими деталями и метриками. Были рассказы про конкретные кейсы: '''Никита Круглов''' рассказывал про text2sql, а Михаил Кацуба про разработку приложения для распознавания выкладки фруктов и овощей на витрину, впрочем, модельного, а не реального.

'''Алексей Гладков''' рассказывал про организацию '''harness''', это была хороший обзор, хотя и без know-how. Вообще интересно: люди уже признают, что '''harness, который включает в себя контекст, набор агентов и правила их организации для обработки задач – важнее моделей''', в кулуарах многие делятся тем, как круто у них получилось его организовать для собственной команды агентов, но вот рефлексии этого, описания устройства в выступлениях нет. Отчасти это понятно, тоже можно сказать про высокопроизводительные или масштабируемые решения: очень редко есть выступления, где показывают, за счет применения каких шаблонов и техник был достигнут успех. А тут область еще молодая, все это in-progress, интереснее доделать, а не рассказать другим.

Ну и в заключение обзора я хочу написать про выступление '''Леонида Новожилова и Яны Венериной из Сбера про сдвиг идентичности инженера, связанный с ИИ-разработкой'''. Я увидел в нем очень много внутренних противоречий, характерных для корпоративной культуры. Началось все с теории самодетерминации: для человека важны компетентность, автономность и сопричастность, а появление ИИ обнуляет компетентность, а также разрушает сопричастность, отменяя живой code review и наставничество. И задача потому компании – восстановить это, дав новое представление о компетенции «разработчика с ИИ» – новый взгляд на карьерную лестницу, по которой можно двигаться, обретая идентичность: 6 координат, три уровня.

Выглядит логично. Если не обратить внимание на то, что компетентность разрушил вовсе не ИИ, который никому не скажет «вы больше не компетентны». Ее разрушила корпорация, обнулив, введя еще один грейд и обязав всех разработчиков до конца года его достигнуть. Весьма жесткими методами: ты обязан пройти обучение, далее корпорация будет снимать твои метрики использования GigaCode, и если за 3 месяца они достигнут целевых величин – ты молодец. А если нет – с тобой проведут разбор ошибок и дадут еще месяц. А не справишься – включат запись экрана с автоматическим распознаванием твоих действий и начнут указывать на ошибки. При этом обучение обеспечивает уровень джуна, и по двум направлениям – мидла. То есть подтвердить мидла, не говоря о сеньоре, за счет обучения – не получится. Что для корпорации логично: надо карабкаться к своим вершинам на специфическом снаряжении: GigaCode отстает от топов, а использовать надо его. В выступлении было о том, что многие сеньоры сопротивляются потому, что заботятся о качестве своего продукта, и видят, что GigaCode его разрушит. Так что автономность тут тоже очень сильно нарушена, и тоже корпорацией.

И сопричастность тоже – люди чувствовали себя сопричастным к полезному делу, когда создавали свой продукт и заботились о качестве. А им, фактически, перенаправили на другое дело – соучастие в создании GigaCode в роли группы подопытных пользователей. Не давая выбора и поставив жесткие цели до конца года. Сбер как корпорацию, у которой доведение GigaCode до высокого уровня – одна из существенных целей, можно понять. Конечно, методы достижения цели мобилизацией всех в подопытные вызываю вопросы, но Сбер хорошо платит своим сотрудникам. Так что разработчики done, на очереди – аналитики и тестировщики. И оба выступающих понимают задачу смягчить восприятие таких изменений, чтобы ни не были красным насилием, потому что нынче времена другие, и мобилизация ученых на создание ракетно-ядерного щита родины организацией шарашек сейчас не пройдет. Впрочем, думаю, под «красным насилием» подразумевали не это, а красный уровень спиральной динамики.

Конечно, все написанное – моя интерпретация, я могу ошибаться. Но отчасти ее подтверждает дискуссия после выступления, когда к выступающим подошел разработчик Сбера и рассказал, как все это выглядит снизу. Они были удивлены и говорили, что ничего подобного себе не представляли и не хотели.

На этом я заканчиваю впечатление второго дня. Подробный конспект выступлений будет, но позднее – я пишу его сам, чтобы заново осмыслить и поставить нужные акценты, а это – не быстро.

Про Сбер есть дополнение. В презентации они показывали схемы из документа '''«AI-Disrupt PDLC»''' – концепции Сбера по трансформации. Он ищется поиском (я проверил), а на конференции мне его переслали еще в первый день – о нем говорили в кулуарах, и я быстро посмотрел. С моей точки зрения, проблем у документа несколько: (1) он концептуально сохраняет существующий SDLC, а не меняет процессы, (2) он делает ставку на полный автомат исполнения по спецификации, а не на совместную работу человека и ИИ на этом этапе, что не реалистично и (3) он основан на убеждении, что с помощью спецификации можно качественно поставить задачу для гарантированного исполнения – то, на чем сломался RUP и PMBoK, то есть собрать гарантированный водопад на агентах.

== Круглый стол Битва за бюджет: интеграция AI должна была сэкономить, а где? ==

'''Участники: Вячеслав Тарасов, Кирилл Адещенко РСХБ, Алексей Гладков, Эдвард Сипки'''. Дальше тезисы без авторства, в некоторых мои замечания, они помечены от первого лица «замечу, что…» или «на мой взгляд…».

# '''Где бюджеты?'''
#* Стартапы. Ускорилось, за 2 недели можно сделать то, что выпустили или даже анонсировали конкуренты, если это мониторить. У корпоратов – не так, там большой цикл согласования.
#* Сотрудников – не меньше, и добавились подписки.
#* '''Бизнес стал быстрее работать. Но не факт, что больше зарабатывать'''. Я замечу, что это вопрос к бизнесу: если у него норма прибыли сохранилась, то стал зарабатывать больше. Или он мог уронить цены, чтобы заработать на обороте. 

#* Была задача начала года: сократить штат на 20-30%, не потерять в качестве и еще ускориться. Прошло полгода. Не видит ускорения и оптимизации.
#* А другие – видят. В операционке люди начали решать задачи быстрее – в 3 раза отдел комплайнс, им хорошо заходит агентская аналитика. Цифры очень разуют, не ожидали. Сокращение – не планируется, просто работы делают больше. SDLC – пытаются внедрить, но пока не внедрили, вопрос второго полугодия. QA нравится автотесты генерить, а разрабы – осторожно, ревью – сложнее.
#* Чем ближе к физику, тем хуже в реальных кейсах это работает. Много крупных компаний «давайте совершать финансовые транзакции с помощью ИИ». Регуляторнка и риски относятся негативно: как докажете? Возражения «люди тоже не ошибаются» – не принимается. Закона от регуляторов нет, но есть куча рекомендаций разных служб – и они приходят с проверками. И закон тоже.
#* Агенты имеют ограниченное окно контекста. У людей тоже ограниченное, но лучше. На ChatGPT поддержку не построить. Но Human in the loop работает. Замечу, что на '''AIconf''' было выступление Яндекса о том, как на смеси людей и агентов собирать поддержку для бизнеса. Много уровней, каждого агента отдельно настраивают и мониторят качество. И все работает, агенты дают реальные деньги компенсации при проблемах, и не более щедро, чем люди.
#* Стартап. Агенты, которые парсят конкурентов – блог, github и так далее. И это дает офигенное ускорение по придумыванию новых фич. А разработка – на людях, которые действуют с ко-пилотами. Написание кода ускорилось в 1.5-2 раза.
#* Угорели больше всего как раз на кодинге – потому что запускали на ночь и агенты жрали все тикеты. Так не надо.
#* Много успехов в операционке, генерации контента – персонализировнные предложения с картинками и видео, дизайнеры.
#* У банков есть разграничение по персональным данным – их не выложишь в отрытые модели.
# '''Все будет по-другому.'''
#* 5-10% команд, где все хорошо, 60% – немного Qwen и так далее. И остальные – ИИ-диссиденты, бред. У всех performance review. Как будете делать performance?
#* Пока performance – по-старому. И если ты за счет ИИ делаешь в 2-3 раза больше – у тебя все хорошо.
#* Дмитрий. Тех.директор стал генеральным. И финдир спрашивает: у вас ИИ – расходы или инвестиции?
#* Есть льготная подписка opus, которая по полной цене 6к долларов – вопрос когда придет. Поэтому был эксперимент – выдать современные макбуки и на них локальные модели – так тоже работает.
#* Нужно изменение mindset!
#* Процессы – они же мешают. Мы знаем, как было раньше, умеем прогнозировать (пообещаешь месяц – накинем два). Люди привыкли. А как в новой парадигме сделать процесс прозрачным и прогнозируемым – непонятно. На мой взгляд, вполне понятно – через метрики: если процесс по-прежнему пережевывает задачи или проверяет гипотезы, то метрики не меняются, если у него другой предмет – надо придумывать, но все равно понятно. С прогнозом может быть хуже, но он и раньщше был плохой, если исполнители специально не докручивали.
#* Технология – новая. Но мы почему-то обязательно пытаемся выстроить фреймворк, при этом внешний и готовый. Возможно, основная проблема с бюджетами в том, что не пробуют что-то делать, а пытаются фреймворк сделать. Кейс. Надо было сделать рефакторинг, выдали подписки по 200 баксов, придумали миллиард скиллов и так далее – сделали что угодно, только не код переписывали. Делаем скилл, вместо того, чтобы отрефакторить.
#* Вопрос: не проще ли подождать, а другие пусть ломают дрова. А мы будем пока по классике? Я замечу, что, может, и проще, но есть риск, что конкуренты съедят твой кусок рынка, банки помнят пример Тинькова. При этом статистически больше выигрывает удачливый последователь, следуя по следам первопроходца, но не совершая его ошибок. Впрочем, вырвавшись вперед второй становится первопроходцем, роли меняются, а путь – из многих этапов.
#* '''Очень важно держать фокус на продукте. Но люди вместо это развивают инфраструктуру'''. Запретить инженерам оверинжиниирить. Не строить космолет, когда нужна тележка.
# '''Как защищать стратегию на год, когда все быстро меняется?'''
#* Убер и MS защищали бюджеты на год, сожгли за квартал и начали переносить на инфраструктуру или как-то еще. Можно лимитировать. Идея – покупать свое железо. Но оно тоже ограничено, это тоже лимиты.
#* Можно представлять ИИ как R&D тему. Отмечу, что это самый простой способ – можно просто осваивать бюджет и не думать про эффект, но руководство уже хочет результатов – в виде сокращений или ускорения.
#* У нас в компании Claude-first, и те, кто не умеет – не по пути. А внутри обсуждение, реально используется, проекты ускорились в разы, и люди – сокращаются.
#* Да, в маленьких и средних командах это так – а мы отыгрывали, что происходит в больших компаниях.
#* '''Реплика'''. Да, мы работаем в секторе с регуляторами, нет проблем.

'''Вопрос'''. Тут фокус на кодирование, а есть еще этап требований. Используете ли для сбора и валидации, и как оно работает? '''Ответ'''. Был эксперимент собрать продукт через ИИ. Это было ужасно, комплексно начал ехать кукухой.

Отмечу, что на Highload, Teamlead и других конференциях были рассказы о том, что продукт вполне собирается, особенно с нуля, только надо настроить контекст и правила и присматривать, а не рассчитывать, что ИИ все сделает сам, он – не джинн.

== Дмитрий Антипов из Сбер. AI-команда будущего: как меняется разработка продуктов и какие навыки нам нужны ==

С моей точки зрения, это не про команду будущего, а про ситуацию конца прошлого года: разработку делаем с помощью ИИ-помощников, называя их агентами. Но одни ее достигли в прошлом году, а другие еще туда идут, и для них актуально. Для успешной работы ИИ надо снабдить контекстом. А еще важно, чтобы у вас был хороший нейминг, потому что когда вы ставите задачу, агент предполагает, как искать это место в коде, используя для поиска названия, которых догадался, и если он ошибся в догадках, то он сожрет все окно контекста и все токены зря. И при этом остальная команда еще работает по-старому, и это – проблема, потому что скорость обработки задач в SDLC не увеличилась. Я тут отмечу, что на конференциях аналитиков и тестировщиков рассказывают, как с помощью ИИ успешно ускоряются их части SDLC, и, более того, есть команды, где отказываются от разработчиков – вайбкодят аналитики. Да и на Highload и Teamlead были выступления про разработку полного цикла. Это было мое резюме, а теперь – содержание выступления.

Почему ИИ дает в разных командах разный результат? Есть даже две школы: одни говорят, что ИИ галлюцинацинирует и не справляется на нашей специфике, а другие – что программисты больше не нужны, ИИ ускоряет разработку в 100 раз. Разница в том, получается ли у команды правильно подготовить ИИ.

Аналогия «ИИ – армия джунов» уже неверна. ИИ – не джун, его не надо учить разработке, он знает языке. С джунами ты не поднимешься выше своих возможностей. Правильная метафора не джун, а «сеньор с амнезией»: каждое утро – с чистого листа. Он может все, но не знает, как устроена наша работа. LLM – stateless. Нужен harness – обвязка, контекст, в котором мы описываем нашу команду, проект и культуру – метод, которым команда работает над проектом). Эффект того, что получим от ИИ – функция от всего этого.

Между задачей на вход и мерже в прод есть процесс, и он сейчас перестраивается.

LLM видит все в виде токенов. Постоянство нейминга и форматирования – очень важная вещь. Понятный и емкий нейминг и отсутствие мусора в коде – это очень важно.

Столица России: Москва (83%) и Санкт-Петербург (12%) и 5% остального. Тут просто. А в других текстах, включая код – гораздо сложнее. Детерминизма нет.

Запрос «сделай фичу» проходит workflow: намерение → сбор кода вокруг → генерация → валидация. По намерению надо собрать harness: окружение, контекст, образцы, паттерны, которые обеспечат ИИ необходимым знанием. Недостаток или избыток ведут к проблемам: недостаток ИИ закрывает «из среднего знания», избыток ведет к использованию лишнего, а дальше он выдает такой результат, что вы говорите «ИИ – тупой». А он – не тупой, вы его не снабдили знанием.

ИИ дали запрос подвинуть кнопку и группу объектов рядом на 50px. LLM потратило 250к контекста и ничего не сделала. Потому что она подумала, что раз мы говорим про группу объектов, то в коде должен быть объект group, в ожидаемом месте его не нашла и пошла искать с помощью grep по всей кодовой базе. А у нас вообще никакой группы нет, мы просто имели ввиду объекты, визуально расположенные рядом с кнопкой.

Claude code ищет интересующие его места в тексте именно с помощью grep: оказалось, что в кодовой базе среднего качества и размера именно этот способ эффективен. Когда что-то нужно, порождает слова-кандидаты, потом ищет и анализирует, что нашел, идет по дереву – это модель умеет. Если у вас авторизация называется магическими словами, которые не про авторизацию – он ее не найдет.

Поэтому лучший подход – вместо grep использовать другие способы доступа к коду. Можно кодовую базу резать на чанки, и делать векторную базу, но тогда изменение любого файла меняет структуру и это дорого. Вообще способов найти код много, надо смотреть, какие у вас работают. Надо сделать систему такой, чтобы она могла по намерению выделить необходимый контекст.

Я тут, забегая по отчету вперед, отмечу что во второй день было очень хорошее '''выступление Александра Иванова про ast-index''', который как раз решает эту задачу.

Мы даем сигнал в LLM, и дальше вопрос – сколько сигнала (содержания) в сообщении. Идея «закинем все, модель разберется» – работает плохо и дорого. Огромный контекст не значит, что он эффективный. Но все, чего не положили – модель не знает не видит. Есть компактизация. И там потеря смысла, надо не терять сигнал, не замещать шумом. А картина, которую claude code вытащил по grep может быть достаточно произвольной. И очень важно удалять неиспользуемый код – он попадает в grep и индексы. А вот паттерны архитектуры и другие правила разработки вашего проекта важно класть в контекст.

'''Что делать с SDLC и командой?''' Мы можем писать гораздо больше кода. А остальные процессы остались. Узкое место – ревью. Путь: Бизнес → Продукт → Разработка. Покрасили кнопку, посмотрели, вернули старый цвет – это быстро.

Раньше разработка была сложной. Теперь разработку может вести агент. Только ему надо больше передать – нужный контекст: почему, точки входа, бюджет, что не трогать; правила, стек, безопасность, конвенции, доступы. ИИ тоже может помогать в сборке контекста. Но не все, и спецификация важная, и ее надо ревьюить.

А еще код – если мы пишем в 10 раз больше, то тест-машина тоже должна работать в 10 раз быстрее. И там надо декомпозировать и все что можно делать автоматикой – автотесты, сборка кода и так далее. Как только это загорелось зеленым – второй слой, AI Review – свои гейты с оценкой. На смысл – соответствие задаче, безопасность, галлюцинации, risk-tier и так далее. И каждая оценка – отдельная. И там может еще отсекать и что-то отправлять человеку.

LLM не только используют при разработке, но и встраивают в приложения. И для их тестирования надо делать Evals, чтобы проверять вероятностное поведение. А если мы используем ИИ-агентов в разработке, то для них тоже нужны Evals? которые проверяют их эффективность, оценивают траекторию решения и его бюджет. Для этого надо собирать логи и анализировать. И отсекать, например, ситуации, когда агент что-то пытался поднять в докере, а докер был просто занят – чтобы не тратился бюджет на бесконечные retry.

А гейты человека надо отодвигать в конец SDLC. Вот с этим тезисом я не согласен: агенты работают не бесплатно, при этом с энтузиазмом решат как нужные задачи, так и идут по неверному пути, поэтому на SDLC должны быть спроектированы места проверки, при этом важно обеспечить реальный объем для проверки. Например, уже понятно, что агенты пишут много кода и проводить review не реалистично, а вот архитектурные решения и acceptance criteria проверять можно – они компактны.

Итого. Надо знать свой harness и устройство LLM, оцифровать работу, иметь core-компетенцию проекта но уметь все, system design, думать про бизнес и экономику, нарабатывать инженерный вкус, писать на языке документации. К этому слайду была реплика: если на нем harness и LLM заменить на любую технологию – то это слайд про инженерную культуру, там нет специфики.

'''Harness и набирание кода в контекст – важнее, чем конкретные модели'''.

Надо жить в эпоху изменений – технологии меняются быстро. Новая команда – из функций и навыков, а не привычных ролей. Вплоть до того, что один человек делает многое. Все летает, но работать больше, а спать меньше.

'''Вопрос'''. Часть контекста – они в головах команды, вне документации. Что с этим делать? '''Ответ'''. Важно собирать артефакты, чтобы контролировать следующие задачи.

Замечу, что это – реальная проблема, потому что множество практик agile ориентированы на то, чтобы поддерживать и синхронизировать контекст именно в головах у всей команды. Агенту тут сложно. Впрочем, поскольку при удаленной работе синхронизация происходит через созвоны, а их можно легко транскрибировать, то задача не является неразрешимой, этот контекст агенту потенциально доступен. Но это надо организовать, в том числе обеспечить суммаризацию без потери важных деталей.

== Александр Поломодов из Т-банк. State of AI4SDLC ==

Массовое использование ИИ наступило, технология стала стандартом де-факто. '''На уровне инженера – эффект большой, с командой – вопросы, а организации – уже сомнительно. Надо менять процессы.''' Создание кода – исследовали, а остальные – менее понятно. Adoption высокий, но есть вопросы с доверием. Как ревьюить, тестировать, релизить. '''Gitlab готовит редизайн своей системы CI/CD.'''

В прошлом году – помощники, сейчас – автономные агенты. Узкое место переехало.

SDLC – гейтовый, по этапам, с каждым связана своя роль. И каждая профессия пыталась ускорить свои внутренние циклы. Каждый этап внутри создает работу, а передача – по-прежнему сложная. Хотели ускорить, и уменьшить количество людей на своем этапе. Когда про это думаешь, вспоминаешь RUP и V-модель. Spec-driven-development – там контракт для агента, который проверяет результат задачи.

Как выглядят изменения в крупном финтехе? У них все разнообразно.

* Масштаб: 10к инженеров, бесконечно репозиториев, библиотек, строк кода.
* Безопасность: банк, деньги, требования к инфраструктуре.
* Экономика: все инициативы требуют обоснования.

В прошлом году – добавляли помощников. В этом году – история с агентами. И тут метрики. Для бизнеса – скорость, пропускная способность и cycle time. И стабильность поставляемого на прод. И еще история не про сгенерированный код, а экономику в целом, оценить бизнес-эффект. Как считать ROI. Я отмечу, что смена парадигмы требует смены учета, в свое время это показал TOC, потребовав свой набор метрик, и тут надо делать тоже самое.

Пользовательский сценарий уезжает в агента, но платформа не становится тупой базой данных. IDP не умер, умерла монополия на GUI.

Три слоя agent-first-платформы.

* Шлюз для доступа к моделям. Агент не ходит напрямую, там шлюз с анонимизацией информации
* Инструментальный шлюз – чтобы агент достучался к LLM
* Реестр возможностей – что агент может попросить.

Уровни доверия read → recommend → act. Мы не доверяем внешней модели, что он сможет качественно запросить. Например, посмотреть данные по roi при том, что там 10к дашбордов.

Уровни зрелости. agent-first: GUI-only, API+GUI, Read для агентов, Recomend+Act, Governance at Scale (раскатка на компанию).

Модель угроз для агентской разработки. Prompt injection, Tool poisoning (многие устанавливаются локально и сливают дофига наружу), Data exfiltration, Overboard retrieval (как сделать, чтобы поиск не выдавал закрытую инфу), Secrets in context (утекание секретов), Confused deputy (агент действует от твоего имени, но с ограниченными полномочиями – надо настраивать).

Что у них есть.

* LLM-шлюз
* Инструментальный шлюз, часть зашита в платформу, есть MCP-hub, ролевая структура, делегация в ide и внутренние инструменты, ответы опираются на актуальное состояние системы, а не на общие знания модели.
* Spirit – агентский режим на платформе разработки.
* Общие агенты в SDLC-цикле. В тестировании, AI-ревьюер, дизайнер, агенты у безопасников, SRE-агенты для эксплуатации и разборки с инцидентами, и в инфраструткуре. Что-то – в общем использовании, что-то пилотируется на нескольких командах.

'''Метрики'''.

Доля AI-кода – соблазнительно, но вредно. Потому что количество кода вообще не влияет на бизнес-результат. Плюс надо ревьюить и так далее. И метрику легко накручивать.

Как измерить влияние AI на SDLC? '''Выступление Анны Громовой''' – они использовали для разработке с помощниками, для агентской – докрутили. И это измерение про пайплайну – скорость, качество, инциденты. Ребята смотрят, идут инсайты, например, по сравнению разных языков. Меряем сценарий целиком, и там смесь людей и агентов. Evals и telemetry вместо mau-портала.

'''Как влияет на работу инженера?'''

Результаты в разных командах отличается в разы. И '''хорошо работает там, где люди готовы менять процесс разработки'''. Часто стимул – жесткие сроки. Платформа их помогает, чем является необходимым условиям – дает инфраструктуру. А не получается – у тех, кто поставил плугин в IDE и работает как раньше – ускорение, если есть, то локально.

Продуктовые требования – в git, задача – merge request и так далее. Инструментальное изменение. Многие люди сопротивляются, но это – стандартная часть change management: снимаем страхи, показываем быстрые победы и так далее. Те, у кого получается – им нравится, потому что результатов больше и они быстрее. И качественнее – больше тестов, качественнее сформулированы и проверены критерии приемки и так далее. Рутина уходит, больше времени на дизайн и сложные вещи – и усталость больше от когнитивной нагрузки.

Агенты разные: в локальные редакторе; встройка в CI/CD, например, code review или обработка merge request и так далее.

'''Инженер: постановка, оркестарция, валидация'''. Навыки контекст-инжиниринга, оркестрация, умение оценить качество работы агента. Инженеры не исчезают. Те, кто только писал код, не думая про домен – те исчезают. Джуны – нужны, но меняется траектория обучения.

'''Вопрос не в том, что разрешить ИИ, а как управлять новой физикой разработки'''.

Материалы выложены на телеграм-канале «Книжный куб».

== Иван Поддубный. Уровни зрелости внедрения AI в процессе разработки ==

В выступлении – модель зрелости, основанная на '''сценарии постепенной замены человека на ИИ-агента в стандартном процессе SDLC'''. С моей точки зрения, '''модель бесполезная''', потому что '''предстоит кардинальная перестройка процессов''', а не их сохранение. И человек тоже останется, в том числе на стадии исполнения и будет совместно с агентами решать сложные задачи. То же самое касается моделей от Gartner и Stanford: они преимущественно говорят об интеграции модели в процессы, хотя и только Gartner на 5 уровне говорит о трансформации, а в Stanford на 4 уровне, говорит об оркестрации агентов так, что можно предположить изменение процесса. И '''SDD тоже разработан в рамках существующей модели процессов и гейты на ней'''.

Но это не означает, что все выступление бесполезно. '''В нем очень много полезного о том, как создать работающую систему агентов, как оценивать работу агентов и строить процесс и инфраструктуру'''. Это – важно. Просто не надо прошивать существующий процесс.

ИВан – СТО вебпрактик, 150 человек. Путь fullstack – teamlead – СТО. И участник програмных комитетов многих конференций , где курирует ИИ.

На конец 2025 – 80% кода с помощью ИИ. Ландшафт – разный, есть начинающие, есть те, кто в космосе. Поэтому много шума. Выступление – попытка задать систему ориентиров.

Модели – Gartner и Stanford. С моей точки зрения, ничего интересного, консультантский флейм. Гартнер дает пять стандартных уровней освоения технологии: не знают, экспериментируют, эксперименты выводят в продакшн, затем интегрируют в процессы, и затем – трансформация. Стэнфорд – описывает распространение управленческой технологии в терминах покрытия процессов: точечное использование, системное использование, отчуждение агентов от людей в репозитории и оркестрация процессов агентами. Если так смотреть, то куча компаний фрагментарно прорвались на последние уровни, не освоив предыдущие потому что уже активно меняют свои процессы. Иван так резко модели не оценивал, но подробно в них не углублялся.

Процессная модель – уровень автономности, ориентирована на процесс и связана с инженерным уровнем.

* 0 уровень: аналитик – разработчик – QA, и артефакты: требования, код, тесты.
* 1 уровень: каждому дали чатик. И он в чатике работает, перенос в артефакты – вручную.
* 2 уровень – локальные агенты на свою машину, они работают с артефактами. claude, codex и прочее. Экзоскелет – усиливают роль. Насколько используют – ответственность человека.
* 3 уровень. ai-native, agent-first, background-agents – агентов переносят на свои сервера. Какие-то блоки или все задачи без человека, человек подключается по требованию human-in-the-loop. Можно масштабировать, за счет запуска большого количества агентов. В конце 2025 на podlodka crew рассказывали про 70% задач через второй уровень, а 30% – на третьем.
* 4 уровень – полная автономность, e2e-решение, бизнес решает задачу через все роли, не привлекая эти роли. Темная фабрика. Некоторые компании говорят, что достигли. AI-фабрика.

С моей точки зрения, уровни 0-3 – реальны. А вот 4 – путь в никуда. На третьем уровне появляется много агентов, и начинает выстраиваться гибридная команда людей и агентов. И следующий такт – кардинальная перестройка процессов, работа этой гибридной команды, которая и обрабатывает задачи и совершенствует себя, свой метод работы.

'''Можно ли остановиться на втором уровне? Тезис: третий уровень надо развивать параллельно'''. Сейчас есть инструменты, которые гвоздями прибьют ко второму уровню и вы не сможете перейти в принципе. Поэтому надо выбирать гибкие инструменты – отложенный архитектурный выбор.

Можно ли идти сразу в третий уровень? Нет, слишком много рисков.

Практики: сквозной SDD, quality gate перед merge, observation трейсов, изоляция sandbox, evals – автотесты агентов и так далее – там большой список. Я тут отмечу, что их не надо внедрять по площади, а надо понимать, что уместно для вас и в каком объеме – как и с любыми практиками.

Типовая ошибка: внедрение агентов каждой роли без синхронизации. Получается у каждой роли – свои источники контекста, идет дублирование и рассогласование, и много граблей. И это не ускоряет вообще. Сами наступали, все сделали проекты и принесли – они полностью разнообразны.

Надо строить сквозной процесс, наример openspec – и настраиваем в нем. Аналитик дает спеку агенту, разработчик – ADR, запускает apply, и дальше делаем. Выступления: Подольский и Галкин. Отмечу, что '''это воспроизводства процесса, а не принципиальное изменение'''.

Практики.

* Полный тест-сьют зеленый, результат агента проверяет линтер, настроен контроль форматирования и типов
* LLM-judge – соответствие задачи, написаны ли тесты как надо, а не подогнаны под результат, потому что агенты часто подгоняют тесты под результат кода, а не наоборот.
* Observability – работа агентов логируется, логи анализируются, смотрим проблемы, улучшаем работу.
* Бэкенд – LangFuse, поиск, сравнение прогонов. Можно внедрять через личные подписки, а не корпоративными, Можно прикручивать плагин к локальным агентам, собирать со всех и анализировать статистику.
* Sandbox: эфемерное окружение и изоляция. Под каждую ветку, это давно было. Агент сам проверяет результат. И сеть закрыта, огранчиение доступа к критичным файлам
* Action policy – когда обязательно подключение человека. Когда агенты достаточно качественно делают определяем, когда все равно нужно review.
* Evals: покрываем автотестами AI-агентов. Проверяем агентов и пишем автотесты. Датасет ваших типовых задач, измеряем качество и регрессы на нем, и дальше – изменяем промпт, harness, skills – проверяем. Можно вносить изменения, не боясь деградации.
* Resource и cost limits. Лимиты на токены/задачу, тайм-лимит.
* Мультиагентная координация – чтобы не было гонок и переписывание. Не всегда они нужны, в один поток может быть лучше, потому nxj проще.
* Моделенезависимый harness – чтобы менять провайдера, и было не страшно. Антропик может взвинтить цены в произвольный момент итак далее. И сейчас китайцев для многих задач достаточно-. антропик не нужен.
* AI-gateway: LLM-прокси. Там есть нюансы с подписками. Их много, можешь использовать общие токены, а каждому выдавать.
* Кодовый агент с выходом на L3. Многие агенты встроены в IDE, их нельзя запустить автономно – а это блокирует L3. Есть агенты, где IDE и SDK разные и несовместимые. Agents SDK, Codex sdk, pi.dev, openhands …
* Agent-first IDP. Это впереди. Gitlab duo пытается сделать, может быть и другие. Но рассчитывать не стоит, надо делать самим.

'''Зайти можно с легких сценариев''': консультации по реализации (вопрос аналитика разработчику: а как это реализовано), первичное расследование инцидента, ревьюер, починка flaky-тестов, мелкие баги. Стратегически определите, куда идете. И будет ли L3 эволюция или революция.

'''Вопрос'''. Внедрили второй уровень, код порождают – но там очень много багов. '''Ответ'''. Есть много инженерных практик, внедрите evals. Отмечу, что тут работают все классические методы борьбы за качество: что делать, когда на проде слишком много инцидентов.

'''Вопрос'''. А на ком ответственность в L3? '''Ответ'''. На том, кто сделал harness.

И заключительный тезис: разработка стала быстрой, а тимлиды (и продукты) зашились. Это – актуальная проблема.

== Даниил Подольский из YADRO. Битва за урожай: внедряем SDD в процесс разработки без его разрушения ==

Как я писал во впечатлениях первого дня, которые вынесены в начало отчета, в этом выступлении совершенно замечательное стебное изложение описание «привычного способа работы» большинства компаний, которое Даниил называет '''«колхозный скрам»'''. Местами оно гиперболизировано, но не сильно. И этот процесс точно будет разрушен с приходом ИИ. А теперь – конспект выступления.

Внедряет ИИ в команде и частично в компании. Современным процессом ничего не сделаем, его надо перестраивать. Но для начала хорошо бы посмотреть на то что такое – современный процесс. Голосование: у кого в команде Waterfall, у кого итеративная разработка, у кого Kanban, у кого scrum – большинство. И во всем мире так, реально ничего кроме скрама не осталось.

Только везде это не скрам из руководства, а со множеством оговорок – '''колхозный скрам'''.

* '''Задача поступает как 1 строка в subject, критерии приемки (DoD) для них не описаны'''.
* '''Нет нормального цикла планирования''' – не декомпозируем на входе, оцениваем по той самой общей формулировке.
* '''Отказ от понимания задачи''' – нет того, кто знает как должно работать, то есть реальный Product Owner отсутствует.
* '''Отказ от понимания хода работ''' – фрагментация команд, разные люди занимаются разными задачами. В Scrum – полнофункциональная команда, по факту специализации и у большинства бас-фактор 1.
* '''Отказ от тестирования''' – потому что нет критериев приемки, тестируем собственный код.
* '''Нет понимания продукта'''. Есть только интуитивное понимание, что должно быть – а оно различается у разных людей – коллективное бессознательное.

Даниил ненавидит такой процесс всей душой, называет «колхозный скрам». Но '''у этого есть объективные причины'''. '''Методология скрам была придумана для автоматизации существующих бизнес-процессов''': они уже работают, надо поставить автоматизацию – именно эта задача стояла в в эпоху нулевых, когда методология развивалась. Если процесса нет, если мы делаем исследование в процессе задачи – скрам не для нас. Отмечу, что это верно лишь отчасти, есть много техник, что делать для продуктовой разработки и в других случаях, когда задачи включают discovery, они были выработаны в 2010-х, я слушал много выступлений на эту тему, и scrum guide был расширен и адаптирован под это. Хотя, это действительно была адаптация, и реально надо выходить за его пределы.

'''А еще Скрам – методология, которая снижает издержек неудачного планирования и проектирования за счет увеличения усилий по планированию и проектированию''', их коллективному проведению. Отмечу, то это тоже было актуально в нулевые: с появлением персоналок потребность в разработке возросла, а программистов больше не появилось, потому надо было работать неквалифицированными командами.

Но в результате этих усилий в скрам там столько, что лучше планировать неверно: лучше быстрое решение, чем запоздалое. И тут мы переходим к колхозному скраму. Это очень дорогой и хрупкий процесс. Он работал, пока был большой поток денег. Что будет сейчас – неясно. И что придет на смену – непонятно.

Человек – равнинный падальщик. Он живет просто: ходит и ищет падаль, найдя – жрет, пока не начнет болеть живот. Тогда идет искать следующую. Так и колхозный скрам: мозг не любит задумываться, он ходит по саванне и ищет падаль. Теперь придется думать.

А думать не хочется, поэтому SDD пробуют внедрять в колхозный скрам. Главный ужас: что-то внедрим, а разработка встанет, надо ничего не испортить.

Метрики реального процесса. Планирование: velocity, throughput flow, cycle time, lead time, WIP. Качество: escape defects, technical debt и другие. Team satisfation и customer satisfation. Но это – сложно. Реально колхозный скрам использует всего три вещи: (1) что можно вгрузить в команду, (2) что можно обещать руководству и (3) счастье разработчиков, обеспечивающую чтобы люди не разбегались и не саботировали, которую меряют через текучку разработчиков. '''Удовлетворенности клиента нет, потому что нет реального PO'''. Именно об этих метриках мы реально беспокоимся.

'''SDD – комбинация TDD и DbC – dev by contract'''. Родом из 1960-х, стандартизован в 2010 до ИИ – предсказуемый результат по критическим путям, '''и денег на это надо очень много'''. '''Скрам дает сравнимый по качеству и гораздо более дешевый результат'''.

Даниил говорил, что скрам – подходит лишь для некритичных вещей, но по факту его применяют повсеместно, на нем сделано не только ядро банковских систем, но и бортовой софт автомобилей – а в современном автомобиле софт управляет не только автопарковкой, но и тормозами runtime, выбирая тормозить двигателем или колодками, когда вы нажали на педаль тормоза. И в немецком автопроме весь этот софт пишут маленькие компании на подряде у концернов, и там скрам был еще в середине 2010-х, я слушал выступления людей, которые там работали.

Смысл SDD: для начала делаем спецификацию, а потом ее скармливаем ИИ, чтобы он сделал код. Много тулов: Spec-Kit, OpenSpec, GSD, BMAD, можно писать свое или обходиться без этого. '''Ключевой момент – review человеком спецификации'''. Двойной расход токенов и тройной расход времени по сравнению с вайбкодингом. Внедрять будем именно SDD. Чтобы был хоть сколько-нибудь управляемый процесс. Спецификации – следы того, как мы мыслим над задачей. Они компактнее кода. И это выгружает наше мышление из головы, оставляет артефакты.

Внедрение в существующий процесс натыкается на то, что коллеги отказываются читать спецификации. В наш колхоз этого не завозили 20 лет, это тогда по ТЗ работали. '''Рациональное зерно есть: это невозможно читать, потому что понимания задачи нет'''. Мы сразу начинаем программировать – чтобы изучить задачу и построить правильный план реализации.

Объяснить, почему user story такие странные, зачем они такие подробные и так далее. Люди читать не будут. Что можно с этим сделать? Можно взять архитектора и посадить клепать хорошие задачи из однословных задач, сделанных аналитиком. Но! Архитектор работать над такими спеками не захочет. Вместо этого – нужна архитектура и хорошая постановка: что надо сделать без как надо сделать.

Я тут смотрю несколько иначе: компактные спецификации, передаваемые на исполнение другим, возможны только для типовых задач. Для уникальных – надо строить прототипы и проверять, что задача решается таким способом, а просто писать спецификацию невозможно. Это как решать задачу аналитического интегрирования сложных функций через описание алгоритма: не работает, потому что по функции не видно, какой прием приведет к успеху. Для простых случаев – можно написать.

Когда задачу засунули в бэклог – надо оценить. Большинство не оценивает, работаем вслепую. Разработчики не умеют оценивать задачи, которые описаны без способа решения. Нежданчик. А это – декомпозиция.

Митигация – параллельная бухгалтерия, При наличии статистики, ИИ довольно точно оценивает задачи, разработчикам можно не показывать, они им не нужны. Оценки нужны, тем планирует спринты и докладывает наверх о планах. Отмечу, что раньше было все то же без ИИ: проджект просил нескольких опытных разрабов оценить бэклог в крупных задачах, как-то сводил результат, добавлял буфер, который никому не показывал, а потом – следил за его расходом.

У нейросети слишком гладкий слог, поэтому человеку скучно. ИИ так не умеет. Отмчу, что ИИ это умеет, просто из коробки не делает, а можно попросить. И на не-ИТ конференциях и воркшопах, рассказывая о правильном взаимодействии с ИИ, менеджеров и продуктов учат: если вы хотите получить критику, настройте жесткий стиль общения, и тогда получите реальный профит, ваши идеи ИИ будет критиковать, у вас будет спарринг-партнер.

Проблема. Набирают в спринт не то, что нужно сделать, а то, что знаем как сделать. А что не знаем – оседает в бэклоге.

'''ИИ не умеет планировать спринты, потому что не умеет понимать бизнес-задачу – она никогда не сформулирована так, чтобы ИИ ее мог понять'''. Поэтому ИИ может сделать рыбу спринта со случайными задачами. А дальше можно вручную. Как раньше. Только у задач будут оценки, и программисты будут спрашивать «какой идиот их поставил».

Разработка. ИИ прекрасно пишет код по спецификации. Ужас в том, что он делает это слишком быстро. Review превращается в каторгу, ИИ пишет не очень хороший код – только намного быстрее, это демотивирует. Решения у этой проблемы нет. Можно отказаться от ревью. Тем более, что '''в рамках колхозного скрама ревью – бесполезные придирки''', потому что нет явных критериев. Отмечу, кстати, что если критерии у вас есть, то для ревью можно использовать ИИ, о такой настройке говорили во выступлениях.

Тестирование. SDD – шанс сделать индустрию лучше. TDD, разработка интеграционных и e2e-тестов. Проблема: нельзя проверить качество тестов ИИ. Проверить тесты человека тоже нельзя, но он их медленнее пишет. Можно проверять выборочно.

Документирование: спецификация – готовый документ. В нем трудно вылавливать галлюцинации, в отличие от кода. Однако колхозном скраме никакой документации не было, так что можно жить без нее.

Итого. Попытка внедрения SDD трансформирует колхозный скрам в обычный – то есть ломает процесс. Можно наплевать на SDD и внедрить вайбкодинг – но он просто увеличит количество кода.

Колхозный скрам не спасем. Что будет – неясно. У нас поколения программистов, которые кроме колхозного скрама ничего не знают – это боль и слезы. Но немного повысить эффективность – можно.

И надо думать над кадровым вопросом. ИИ хорошо работает у программистов, которые и так бы справились. А если не справится – то и с ИИ – плохо. Я с этим тезисом не согласен: есть много кейсов, когда люди, не владеющие программированием или конкретными языками, но имеющие опыт постановки задач разработчикам, успешно решают задачи с помощью ИИ, взаимодействуя с ними так же, как с разработчиками.

== Игорь Дмитриев. DeepSeek и Qwen в enterprise-контуре: строим надежный Flow для классификации чувствительных данных ==

Это рассказ о применении ИИ для решения конкретных задач работы с данными. Во-первых, с его помощью с данными могут работать не технические пользователи, а не только аналитики, которые умеют писать запросы. Однако, для этого данные должны быть описаны в Каталоге, и там помечены чувствительные данные. И оперативное включение новых данных в Каталог тоже можно делать с помощью ИИ. А теперь – подробнее.

Базовый уровень работы с данными (rare) – безопасное предоставление доступа к данным, чтобы аналитик и могли с ними работать. А well-done – когда могут работать не технические пользователи через ИИ-агента.

Для этого нужна разметка в каталоге: есть таблицы и столбцы, надо назначить ответственных, этот этап автоматически не сделаешь, и надо понять, что в этих данных надо защищать – категории доступа. Почему процесс больной? Потому что бюджетов на разметку выделяют мало. А данных становится все больше, и где там персональные – и есть ли они – неясно.

Человек требует описать таблицу, ставим задачу агентам – многие каталоги данных умеют описывать из коробки, и дальше тем же протоколом mcp записывают в каталог. Завайбкодить такую схему – нет проблем.

Но агенты ошибаются и галлюцинируют. Для начала агент может просто взять не ту таблицу, о которой говорил человек. Может ошибиться при обогащении описания. Он не знает про ФЗ-152 и другие. А еще может потерять пару тегов при переносе описаний, или ошибитьсся другим образом.

Как с этим работать? Надо поставить процесс работы агента.

# Описать процесс
# Сделать методику – инструкции, как каждый шаг процесса выполняется
# Разработка агента
# Провести контроль качества
# Начать эксплуатацию
# Регулярно получать и обрабатывать обратную связь в ходе эксплуатации.

В начале процесса источник – каталог метаданных. Важно: не пропустить критического в данных, не пометить лишнего. Оценка – полнота, скорость, сравнение с ручной разметкой. Для классификации данных можно взять каталог чувствительных данных, порядка 270 пунктов – его можно взять за основу и доработать. И методику надо обсуждать с ИБ.

Получается Агент: системный промпт плюс перечень чувствительных данных плюс спецификация результата – формат Json. Агент делает бинарную классификацию: чувствительные и все остальные – это проще отладить, а потом уже наращивать категории. User prompt – просто таблица, которую надо описать. И '''при отладке температуру ставим в 0''', это дает детерминированные ответы, без этого мы не знаем: сработала галлюцинация или мы улучшили настройки.

Первая проверка задачи – на мощной облачной модели, это критерий, решаемая ли задача вообще. Потом запускаем на локальной модели и доводим их качество до требуемого. На конкретном кейсе Gemini 3.1 Pro выдала 4% ошибок – это хорошая полнота, сопоставимо с ошибкой человеком. Дальше замеряем локальные модели – на старте они работают плохо, но если тюнить промпт – то качество повышается. Для локальных моделей тюнинг промпта актуален, для облачных – уже нет.

Как тюнить промпт? Даем примеры граничных случаев, выделяем разметкой блоки, описываем рассуждение – рассмотри таблицу, там поле – имя, это чувствительные данные по таким-то причинам. Не надо запугивать модель «нам важно не пропустить критичность» – это сбивает рассуждение, вопреки распространенному мнению Надо именно давать примеры хороших рассуждений в системном промпте.

Качество существенно возросло. Но это – на хорошо описанных данных. А интересно, что будет без описаний. Они забывали описание человеком, просили восстановить, а потом сопоставляли. И оказалось, что из коробки описание LLM очень хорошее. И, более того, '''по описанию LLM гораздо лучше работает поиск, чем по человеческому'''.

Но у подхода есть предел – размер контекста, который прописываем в промпт – варианты обсуждений и так далее. Есть точка, где есть переполнение. Если повезло – то работает. А нет – разбиваем задачу на несколько, например, отдельно классификация чувствительных данных, а отдельно – другое. Можно доучить модель – для простых моделей fine tune – несложно.

И дальше встраиваем агента в процесс: вместо чата садимся на событие изменения описания таблицы. Тогда уже не надо искать таблицу, она точно известна. А pipeline запускаем через очередь событий. Циклы пропадают, может получиться retry, а если описание не получилось – можно записать в каталог «не смогли описать таблицу» для разбора человеком. Контракт – json, который вклинивается в процесс.

Результаты. - Трудозатраты по разметке сократили в 5 раз - Ошибку удалось выровнять: LLM ошибается не чаще человека. - Time to data сократилась в 5 раз до 1-2 дня. Когда новая таблица появилась – она появляется в каталоге. - Стоимость уменьшилась, работу людей переложили на железо. Работает это в закрытом контуре, где риски поменьше.

Выводы.

* С помощью локальных ИИ можно решать критичные задачи. Human in the loop остается, и не забывайте собирать обратную связь. Но метриками надо покрывать, особенно для критичных задач. И это хорошо, надежно и отказоустойчиво.
* Если проверяете гипотезу – проверьте сначала на топовых модельках. А потом уже локальную доводите.

== Баттл. AI в продуктовой команде: быстро или правильно? ==

Задача – определить, '''где красная линия для AI-агентов в продуктовой команде''' участники сыграли баттл. '''Алексей Шерченко''' защищал позицию, что ИИ дает скорость, поэтому летим быстрее везде, кроме принципиальных решений. '''Юрий Бабак''' подсвечивал проблемы: быстрое накопление техдолга и другие. '''Федор Васильев''' был модератором.

В целом было конструктивное обсуждение. Для меня там были очевидные вещи, но я – в контексте. А для тех. кто присматривается озвучивание позиций – полезно, судя по реакции зала. Дальше – краткие тезисы, некоторые – с комментериями.

# '''Появились новые названия ролей?'''

'''Алексей'''.

* Пока – не появились, будет performance review – там новые названия раздадим.
* Код мы писать умеем, замедляют коммуникации, ожидания и смена контекста. И '''ИИ закрывает большую часть проблем – он позволяет не отвлекать разработчиков для ответов на вопросы''': с ИИ код становится доступен для людей, которые раньше не могли писать и читать.
* Технический координатор, бывший QA – ходил по командам и просил добавить фичи. Сейчас он большую часть простых задач выполняет сам – новая валюта, конфиги и так далее. Или в мок-сервер добавить путь.
* Дизайнер – у него есть открытый репозитори, может сам собирать прототипы и отдать готовую штуку фронтендеру – и не надо ждать, пока фронтэндер сделает по описанию и сделанное пройдет пару дизайн-ревью.
* В европейской финтех-компании сделали бота, который знает, контекст проекта, и можно обращаться к нему.
* ИИ ускоряет коммуникацию и смену контекста.

'''Юра'''. Экспертиза никуда не девается. Дизайнер может сделать прототип или QA править код. Но у него есть знания про процесс и проект: человек должен понимать что делает. Иначе получается хаотическая фигня и эффект Даннинга-Крюгера.

Штампование прототипа – это хорошо, но когда у вас один прототип, о нем надо договориться, потому что у разных сеньоров свои мнения про хороший прототип. Когда размывается ownership и появляется много случайных контрибуторов – возрастает число ошибок, есть исследования на open source проектах. А это означет узкое горло ответственного – единый ответственный остается. Только раньше ему приносил результат сеньор, а теперь – восторженный дизайнер, поэтому '''нагрузка на узкое горло возрастает'''.

'''Алексей'''. Да, согласен по ownership. Поэтому задача ответственного – настроить сервис – контекст, тесты и так далее, чтобы приходил хороший результат.

Я тут поддержку Алексея. До ИИ распространенная проблема архитектурных ревью – когда архитекторы просто становятся ступором процесса, потому что требуют, чтобы попали в его личные вкусы и бесконечно отправляют на переделку. Правильная организация без узкого горла – когда архитектор определяет политики и правила, а в сложных случаях – сотрудничает в выработке решений, затем дорабатывая политики на их основе. Теперь любой ответственный становится в роль такого архитектора.

<ol start="2" style="list-style-type: decimal;">
<li>'''Архитектура или прототипы.'''</li></ol>

'''Юра'''. Архитектура – важно. Цена написания кода упала, а цена ошибки – нет. И мы бездумным катанием всего подряд на прод сдвигаем ошибки вправо. А если там критический путь, реальный сектор, фарма? Сейчас модели могут содержать много сгенерированного кода. Тщательный анализ и проектирование. Деплой на живую – прекрасно. Агент удалил живую кодовую базу, и доказывал, что нельзя откатить. Работа с ИИ замедляет работу кода, активность выросла, а стабильность – упала, больше точек отказа и проблем.

'''Алексей'''. Согласен по многим пунктам, не надо вайбкодить прошивку ядерного реактора. Есть какое-то количество критических вещей, которые надо продумать хорошо. Но мы – преувеличиваем. И куча способов: фича-флаги, А-Б тесты, канареечные релизы и так далее. И переписывать мы тоже можем быстро.

'''Юра'''. Да, 80-20, но где гарантии, что ИИ правильно выберет 20 критичных. Переписывать одно и то же – играемся в инженерной песочнице, а не делаем задачи бизнеса.

Я тут хочу сказать, что все разговоры про критичные сегменты и закрытые данные обычно являются спекуляцией. Да, там где есть критичные участки – надо прописывать правила, обеспечивающие надежность, стабильность работы, и методики этого давно наработаны, потому что люди – тоже не надежный элемент инженерной системы, человек, в том числе опытный специалист тоже может удалить базу данных или таблицу на проде просто по ошибке – есть куча случаев. И уже есть много кейсов, что при правильной организации ИИ – не хуже человека, а лучше. Например, роботакси – ездят по улицам городов – миллионников с жестким движением в Китае и других странах, и аварийность ниже, чем у людей – за этим следят. А в поддержке Яндекс-такси ИИ раздает компенсации людям при инцидентах, и тоже действует сопоставимо с людьми.

<ol start="3" style="list-style-type: decimal;">
<li>'''Доступ к данным.'''</li></ol>

'''Юра'''. Замечательная идея – организовать с помощью ИИ доступ к данным, но она несет кучу рисков. Самсунг 2023 – инженеры слили в ChatGPT конфиденциальный код и протоколы совещаний. А это – чувствительное место, есть законы и оборотные штрафы.

А еще – вендор блокирует одним днем, и это – не обязательно политика, Антропик блокировал по лицензионным вопросам. Мы получаем кучу рисков остановки компании, как только доступ агентов по mcp включен в основной процесс.

'''Алексей'''. Дроп базы или деплой не туда – сплошь и рядом до ИИ было. У ИИ-агента должен быть такой же доступ, как у разработчика. Иначе просто удлинение петли, потому что разработчик делает copy-paste: тупо исполняет запросы, созданные агентом и копирует ему результат.

А еще агент может следить за агентом.

Доступ к логам и данным нужен, там много данных и способность найти в них трейс-ид у бага – сильно ускоряет и упрощает.

'''Юра'''. Так и разработчиков на прод не допускают. Агенты косячат больше людей и быстрее.

'''Алексей'''. Люди косячат, но мы не защищаем через отрубание доступа. И у агента надо так же как у разработчика.

'''Юра'''. Сегодня говорим про исследование инцидента, а дальше будет исправление последствий инцидента. И агент испортит данные прода.

'''Алексей'''. Но люди-то все равно могут.

Тут я тоже согласен с Алексеем, он логично все объясняет. И да, я работал на поддержке с двухуровневым кодом доступа, когда разработчиков до прода не допускают – за исключением разбора критичных инцидентов, на которых включают двойной контроль: ты запрашиваешь конкретные доступы и выгрузки, объясняя сотруднику ИБ, зачем это нужно, и тот это делает. Так работать можно, хотя это увеличивает время, но агенты в такой схеме тоже уместны. Кстати, в нескольких выступлениях и частных беседах я слышал, что безопасники агентов тоже освоили и используют в своих целях – контроль кода, анализ логов и так далее.

<ol start="4" style="list-style-type: decimal;">
<li>'''Косты. Кто за все это будет платить'''.</li></ol>

'''Алексей'''. ИИ – дорого и дорожает, многие вендоры отменяют модели для корпораций, все становится дороже. Но мы платим не просто так, а за ускорение и возможность делать то, что раньше делать не стали бы, было нерентабельно.

Например, был сервис, который должен был отправлять события в кафку, но не отправлял, потому что это повышало нагрузку. Есть решение для таких случаев – outbox, но его надо написать, это 2-3 дня разработки. А ИИ может за пару часов, по токенам это дешево. И таких задач масса. Тулзы, админки и так далее – все до чего не доходили руки.

'''Юра'''. Компании, которые внедряют ИИ – сжигают бюджеты мгновенно. Компания, которая хочет остаться не названной – забыла лимиты и сожгла полмиллиона баксов. И задача слабо предсказуемая в цене токенов.

Нет исследований, что продуктивность компании выросла. Отдача бизнеса не растет, а капитальные затраты влет улетают. Токены за месяц – это джун-аналитик назад в команду.

'''Алексей'''. Научились работать, сделали пет-сервис, и начали жечь токены – решается элементарно. Надо думать раньше. Если вводишь kpi инженерам по потраченным токенам, то зачем удивляться, что они их жгут.

'''Юра'''. А точно ли это место, где надо инвестировать в ИИ. Может, лучше подумать? Туда ли тратить бюджеты?

В конце они обсуждения вопросов вышли на конструктив: задача не воткнуть mcp или ИИ куда-нибудь, а разумно перестраивать процессы. И с этим я согласен.

Была еще реплика про рисковые и стратегические решения, которые точно останутся за человеком. Я тут хочу сказать, что в больших корпорациях многие решения принимаются на основе презентаций, которую топ получает секретарю, уровень квалификации которого часто оставляет желать лучшего. Делает в спешке с проверкой через просмотр по диагонали с кучей ошибок. И, естественно, ИИ в этом уже участвует: к нему точно обращается такой секретарь, а, возможно, и сам топ, решив, что он лучше секретаря. Так что это все тоже флейм.

'''Реплика'''. Токены – не дорогие, есть бесплатные чаты, есть подписка за 20$ и так далее – и она тоже помогает. '''Ответ'''. И надо экспериментировать, разным людям разные подписки, и где-то ставят Qwen, и большинство задач из разработки Qwen решает.

'''Реплика'''. Технологии ИИ меняются быстро. Когда-то так же менялись фреймворки фронта – фреймворки менялись, но методики вырабатывались. А скилы – это описание инструкций, их можно применять не только агентам, но и новичкам.

== Леонид Новожилов и Яна Венерина из Сбер. Тектонический сдвиг мышления инженера: профессиональная идентичность в эпоху ИИ-трансформации ==

.Это выступление вызвало во мне очень большой отклик, который я опубликовал сразу, он занял значительную часть впечатлений второго дня, опубликованных в начале отчета. Я не буду его здесь повторять, а сразу перейду к тезисному конспекту.

'''Ситуация'''.

* Год назад 44% считали, что от ИИ больше вреда, чем пользы, сейчас – наоборот. В мире цифры сопоставимы.
* Неопределенность: 80% людей не планируют будущее, 96% ИТ находятся в состоянии выгорания, 40% боятся, что их заменит ИИ, у 32% признаки депрессии.
* Лидеры мнений пророчат, что профессия разработчика канет в лету – идет обесценивание.

Опрос разработчиков проективными вопросами в Сбер. Что считают сверхспособностью, и что отнимает ИИ.

* Результат: ИИ подавляет все, что входит в самодетерминацию: компетеность, автономия, сопричастность. Про компетентность понятно, сопричасность уменьшается, потому что пропадает живой code review и наставничество. А автономия в большой корпорации и так сильно ограничена, а ИИ дает новые возможности следить. 

* Джуны должны сами ревьюить код, хотя не готовы.
* У мидлов теряется кайф от работы: ИИ – все придумал за себя, нет момента победы.
* Сеньоры – не саботаж, а проявление лояльности, они знают цену качества и отвергают ИИ, чтобы сохранить продукт. А еще джуны к ним не приходят.
* При этом сеньоры не хотят использовать инструменты, потому что боятся, что несовершенные внутренние инструменты (GigaCode) разрушат, а доступ к профи остановлен. Они знакомятся и тащат внутрь запросы фич.

'''У сотрудников кризис идентичности, они выгорают, надо пересобрать компетентностную модель, чтобы вернуть идентичность.''' Я тут замечу, что это – типичная трагедия корпоратов: корпорация, прежде всего, отбирает тех, кто готов ассоциировать себя с корпорацией, а значит не способен удерживать свою идентичность сам, а ожидает, когда ее дадут снаружи.

Они обратились к внутреннему сообществу и '''сделали группы компетенций''': prompting, prompt engineering, content management, создание инструментов, создание и использование skills, управление командой агентов. И по этим осям – розочки для ИИ-джунов, ИИ-мидлов и ИИ-сеньоров, в презентации они есть. '''Сейчас у всех компетенции сброшены в ноль, даже ИИ-джуна их надо подтвердить'''.

И дальше ведут мониторинг динамики проникновения инструментов и повышения продуктивности команд по цифровым следам и артефактам: GigaCode снимает метрики, смотрят lead time, качество кода, повышение производительности, input-output по токенам. Прохождение назначенных курсов тоже фиксируется, можно оценить слияние на изменение метрик. Есть целевая картинка на конец года и текущая картинка, и с июня начинает работать автомат метрик. Я вижу, что наконец-то сбылась мечта HR – полный автомат online меряет компетенции сотрудников, думать – не надо.

Дальше была резкая смена тему. Когда у нас неопределенность, стоит посмотреть как работают живые системы. Есть парадигма стимул – реакция, так строится работа клеток, людей, организация. Однако, при нем вы всегда будете в отстающих. А чтобы быть лидером, у живой системы есть внутренняя цель – образ того, к чему стремимся. И живая система идет туда, предвосхищает и прогнозирует будущее.

Черные лебеди – стимул чтобы все пересобирать. Но если есть образ результата и он представляется по-прежнему достижимым, то все не разрушено, мы просто идем другим путем.

Архитектура (нейрофизиология) намерений. Есть мотивация, у нас есть инструментарий, мы выбираем и получаем результат. Мозг сопоставляет полученное и ожидаемое, и дальше стратегия закрепляется или отвергается. И они так же строят путь в рамках организации.

И схема: Intent loop, где намерение на языке спецификации настолько детально, чтобы implemented loop реализовал его агентами без человека. Намерение → Спецификация → (Декомпозиция → Код → Тесты + self-review) → Валидация. Среда дает Контент + Политики + Evals. SDD становится кодом, с которым работаешь. И вместо pull request – намерение + evals.

Отмечу, что схема есть в презентации, она – из документа '''«AI-Disrupt PDLC»''' – концепции Сбера по трансформации. Он ищется поиском (я проверил), а на конференции мне его переслали, и я быстро посмотрел. С моей точки зрения, проблем у документа несколько: (1) он концептуально сохраняет существующий SDLC, а не меняет процессы, (2) он делает ставку на полный автомат исполнения по спецификации, а не на совместную работу человека и ИИ на этом этапе, что не реалистично и (3) он основан на убеждении, что с помощью спецификации можно качественно поставить задачу для гарантированного исполнения – то, на чем сломался RUP и PMBoK, то есть собрать гарантированный водопад на агентах. НО вернемся к выступлению.

Этапы: AI-augment SDLC → AI-Native DLC → Agentic development. У них стабильный рост 10-15% производительности команд, они хотят рывок 25-50% и 90% проявленность AI-навыков.

Но надо не просто поставить цели – надо обучить. Нельзя давить и подгонять, иначе будет стресс, который отключает мышление, доступны только автоматические реакции, и это приведет к выгоранию. Чем больше давить – тем больше сотрудников останутся на старых подходах. При этом взрослых учить сложно, поэтому берем зону ближайшего развития по Выготскому. Как в дайвинге – неосвоенная глубина. Могу и умею → могу с поддержкой → когда-нибудь смогу.

Был честный запуск обучения. О компетенциях договорились в середине мая. Сначала сделали гайд в мае, увидели, что разработчики им не пользуются – и раскатили обучение на 1000 разработчиков, в середине июня запустили метрики. Вообще надо наоборот – сначала метрики, а потом дать инструмент, провести обучение, чтобы люди понимали – что с них будут требовать. Аналитики и тестеры – следующий шаг.

15 марта запустили агента, на конец апреля 37% освоили самостоятельно. В конце апреля запустили два курса. Назначили курсы не всем 14 тыс, а только 7 тыс. И на конец мая прошли 67%, а на вчера – 69%. Похоже уперлись в потолок проникновения у разработчиков. Но метрику сбрасывают в начале месяца в ноль, поэтому сравнение не очень честное. При этом курсы назначили только на разработчиков, но аналитики и тестировщики – тоже проходят курс. И токены быстро тратят. Увеличилось число agentic-пользователей.

Но курсы игнорят. Они смотрели, как прохождение курсов продвигают по навыкам: на ИИ-джуна выходишь, по двум осям они выводят на ИИ-мидла, по другим тоже продвигают. В презентации была конкретная таблица. Но люди все равно ленятся.

Но лень – это экономия энергии. У коллег времени никогда нет, время получаешь сейчас, а результат не очевиден. Мозг будет сопротивляться действиям. Заставлять нельзя, играют мотивацией избегания неудачи и мотивация достижения. Избегание неудачи – там кортизол и низкая результативность. А достижение – растет тестостерон, любопытство. Вывод. Надо показывать реальную осязаемую выгоду.

Сбер может задать мерило актуальности, разрабатывают сертификацию и готовы отдать в рынок.

Они обучают, проверяют метрику – и сразу сертифицируют, получаешь kpi своего года автоматом. Если за три месяца после обучения нет уровня – то проводят с человеком беседу и дают попытку еще на месяц. Если автомат не получается – то будут включать запись экрана и анализ поведения с помощью ИИ-распознавания: применяешь ли надлежащие навыки в нужных точках.

B конце концов люди перейдут в новый рабочий процесс, и дальше Сбер-университет будет выводить это на рынок. Показывать целевое состояние и зону ближайшего развития.

Что с наймом? Сбер сократил число джунов, которых нанимает. Мидлов – точно нанимают. Будут менять мидлов с классическим скилсетом, и дальше адаптируют к агентскому кодингу. Кроме агентского кодинга – есть более широкий спектр скилсета, и там тоже идет развитие.

'''Вопрос'''. Как будет через год? И hard кандидаты против софтам не-ИТ. '''Ответ'''. Сейчас они требуют не ниже мидла по хардам – чтобы он мог ревью делать, а по агентик-кодинг они прокачают.

'''Вопрос для Яны'''. На какую биологическую систему разработчики похожи? '''Ответ''': часть большой системы.

'''Вопрос'''. Меня обложили курсами, смотрят за обучением и действиями. Как вы объясняете, что треть не сократят, ведь пул работ ограничен. '''Ответ'''. Вопрос в доверии, в большой корпорации не доверяют, пытаются работать и восстановить. Суть в построении персональной траектории, чтобы ты был актуален рынку – чтобы внутренний сертификат мог забрать с собой. И чтобы раннее большинство переросло в позднее большинство, помогает внутреннее коммьюнити – именно оно строило компетенции. Не инструмент красной угрозы, а инструмент развития. Кажется, удается.

== Александр Иванов. ast-index: как я ускорил агента в десятки раз и сократить расход токенов. ==

Хорошее, очень конкретное техническое выступление о подготовке кода для контекста ИИ-агентов – код структурируется и индексируется так, что поиск выдает сразу нужные фрагменты, имеющие отношения к решаемой задаче. При этом файлы выдаются не целиком, а тоже интересующий фрагмент и структура вокруг него в формате, которой агент может пользоваться, что существенно экономит токены. Решение выложено в open source. В выступлении было его сравнение с аналогами, там одна относительно долгая операция полной индексации, но далее можно достраивать по изменениям. Но при этом полная индексация все равно достаточно быстрая, чтобы строить индекс для конкретной ветке ,в которой работает агент и удалять его вместе с веткой: аналоги хранят индекс, и его строят только для основной ветки, а это означает, что локальные изменения ветки в нем не учитываются. А теперь подробнее.

Проблемы агентов: даешь простую задачу, он пошел искать контекст, полезного не нашел, залил контекст ненужной информацией и сделал не то или остановился. Агент в большом проекте ищет по площади – тысячи файлов. Надо для поиска навигировать агента по кодовой базе структурно – точечно, быстро, качественно.

Базовый поиск – grep, плоский текст. Человек смотрит начало выдачи, добавляет параметров в описание задачи – фокусирует поиск. Индексированный текстовый поиск – тоже самое, просто быстрее. Есть таговый поиск – он более структурный, но он не понимает структуру кода.

Есть инструменты поиска, которые используются в IDE – для подсветки кода, рефакторинга и других целей. Но они выдают тяжелый json именно для IDE. Еще есть code intelligence platform с индексацией – но там дорого держать все ветки. И есть структурный поиск ast-grep.

Агенты тратят большую часть токенов на поиск и чтение файлов. Они реально посмотрели трейсы, на это уходит 62% контекстного окна, а только 30% на кодирование – выполнение задачи. Поэтому надо фокусировать поиск. И инструмент должен выдавать сжатую информацию, а не json с кучей лишнего, быстро и стабильно, и выдавать не полный файл, а только нужный фрагмент.

Он начал разрабатывать с агентами в сентябре. И в декабрю пришла задача, где нужен архитектурный рефакторинг большого количества файлов. Сморит – агент ищет долго. Он полез в студию, там ищет классы и подсказывает агенту. И он задумался: почему он полез в студию, чтобы подсказать, где искать нужный класс. И тогда написал первую штуку, которая индексирует, агент вызывает ее с помощью mcp и ищет быстро. Потом mcp заменил на cli – и еще в 5-10 раз уменьшилось потребление токенов. Это было на python, поиск занимал полсекунды, и он переписал на rust – ускорение 100-200 раз, 8мс поиск. А дальше – развитие и масштабирование – добавление языков.

Архитектура

# Интерфейс – '''cli'''. mcp не может использовать человек – сложно отлаживать. А cli ты вызываешь из консоли, можешь посмотреть трейсы и отлаживать запросы.
# Контур поиска. Разбор команды, поиск в sql-lite базе, и дальше выдача ответа в компактном виде.
# Индексация. Проход дерева файлов, и дальше парсинг, свой для каждого языка и раскладывание в таблицы. Пакетами по 500 файлов.
# База – хранение индекса, она лежит отдельно, и можно индексировать отдельные ветки под задачу, с которой работает агент.

Проект 30к файлов индексирует за 30 секунд. А дальше – инкрементальное обновление по файлам, и это обновление можно включить в фоне, 8-10мс на файл. И там одна cli и около 30 сценариев-команд.

Внедрение в апреле, и сейчас около 3000 разработчиков, которые используют, распространяется по командам. Rebuild – недешевый, 10 сек 250к файлов и 2Гб памяти, но приемлемо. ast-grep – ближайший родственник, но дороже по времени и нагрузке – в презентации конкретные данные, ускорения в 1000 раз даже при прогретом кэше ast-grep. Был A/Б тест на одинаковых задачах. Получили, что на чтение и поиск затраты 22%, а 68% на реализацию, и сокращение токенов на 40%. Внутренняя телеметрия: что агент спрашивает на практике, 525к за месяц. Помимо поиска, агент читает файл структурно, а дальше вычитывает нужные строки точечно.

Куча позитивных комментов от команд. Агенты с таким поиском работают лучше с плохим кодом – за счет того, что лучше находят нужные места кода. Это помощь агенту с говнокодом людей. Полезно не только для поиска, но и для ревью кода.

Инструмент он делал почти месяц с агентом, а дальше с января – развивал и продолжает это делать. Rust выиграл за счет многопоточности – там эффективнее идти по дереву в разных направлениях, индексировать файлы и так далее. Но исходный питон был не оптимизирован, если бы его оптимизировать могло быть быстрее.

Выводы. Найдите боль агентов, делайте качественные инструменты, радуйтесь работе с агентом и рассказывайте другим.

'''Вопрос'''. А затем такие тысячи файлов, супер-монолит? '''Ответ'''. У них в Яндекс-Go 30к файлов, и еще бэк. А в финтехе – там по 170к файлов, а кто-то миллиона файлов выбрал. Фича – 50-150 файлов, которые не лежат в одной папочке, а распределены по разным веткам в дереве и связаны – такие микролиты….

== Алексей Гладков. Harness на стероидах ==

В докладе – сборка рекомендаций по организации агентов в систему и подготовка для них контекста: индексация самого проекта, профили ролей для агентов, описания workflow для разных типов задач, консилиумы агентов в реперных точках, чтобы сделать задание. При этом Алексей подготовил типовую конфигурацию, в презентации – ссылка, ее можно использовать как основу для своей, чтобы не писать с нуля.

Как перейти от 300$ за хаос к 30$ за систему? В октябре 2025 появился первый harness в claude и codex. Первые фичи успешно порождаются, но несовершенно. Ассистент пишет средний код, галлюцинирует зависимости и permission, не понимает контекст. Если вы не забили, то в декабре 2025 – первые циклы, 10-12 часов сессия, чтобы приносило value, автотесты, распределение нагрузки.

Harness – упряжка, у вас есть куча агентов, которую работают над задачей. И это – дорого, 12$ на среднюю стоимость одной задачи по api когда подписки уйдут. Дорого и неэффектино. Люди открывают один поток и там по всем ролям. Я тут замечу, что 12$ – это полчаса ставки разработчика, так что не слишком уж и дорого – если за это время реально делают задачу. Хотя, конечно, не ноль.

Агенты должны писать код, пока мы чем-то другим занимаемся. Но надо непрерывно дописывать промпты, дорабатывать harness. Что можно оптимизировать?

Токены. Основное – чтение файла и анализ контекста 50%. '''Caveman''' – нейронка многословная, это сжимает ее сообщение в фразу «я скачала логин» – в 5-7 раз меньше токенов. '''Ast-index''', был в прошлом выступлении было. Не 100 файлов, а 3. Примерно в 40 раз экономия входных данных и быстрее. Caveman + Ast-index дает огромную экономию.

'''Субагенты'''. Мы работаем с разными слоями – фронт, бэк, безопасность, данные. И контекст выталкивается. Делаем субагентов: роль, контекст, правила как делать, запрещения что не делать (не класть файлы не туда), структура папок, как называются файлы, критические файлы зависимостей, – как будто у вас исполнительный, но тупой сотрудник.

Нормальный агентам на запрос «добавь фичу» берет нужную структуру и шаблон, получаем правильные тесты и так далее.

Нейронка вариативна, может галлюцинировать на сжатых контекстах. И надо потребовать «напиши идеально» – это 7-8 волн. Чем больше образцов – тем лучше. Если что-то не предусмотрели, будет системная ошибка. И такие ошибки можно выявить и исправить.

Багфикс. Ты не пишешь сценарий по разбору с истории, хорошему агентом – кинул скрин, а дальше он сам разберет трейсы.

Один агент – одна роль. Это нарушают часто. На котлине можно написать что угодно, нужно ли три агента для бэка, фронта и мобилок? Если там один репозиторий – то можно один. А если три продукта – то точно три агента.

Специализация агентов повышает точность первого входа, почти нет исправлений.

'''Consilium''' – совет экспертов. Собирать можно в начале или в других реперных точках: api-designer, architect, devops, secirity и другие обсуждают задачу и дальше получается результат – задание, которое агенты делают индивидуально. Например, есть задача «добавь экран оплат» – собираете консилиум, они обсуждают и делают промпт – крутое ТЗ, план работы. Там будут покрыты кейсы. Один агент может ошибиться, а шесть – они лучше сработают. Аналогично можно обсуждать результаты, делать задание на доработку.

'''Workflow profiles'''. Есть разные задачи: багфиксы, новые фичи и так далее, составьте для каждой свой план работ по шагам. Бизнес-фича: исследование – план – выполнение – проверка. Вы можете свой составить. А если баг, сначала его надо воспроизвести, и там есть много деталей. Reproduse – diagnose – fix – validation – report. И вы собираете трейсы и метрики. И потом – консилиум и обсуждение. Таких профилей много – рефакторинг, end2end тесты и так далее… На каждую – делаете свой план. И тогда будет магия.

'''Execution scope'''. На каждый агент видит только свои файлы. Иначе они могут начать драться, особенно если консилиум.

Не пихайте профили в глобальный конфиг – это тратит токены при чтении. В конфиге надо там только селектор: под такие задачи выбирай такой профиль.

'''Модели'''. Очень часто пихают все в opus. Вершина – fable на промпт “Привет” съели 200$ лимита. Он оркестратор. И без настройки там фигня, драка агентов. Opus нужен для архитектуры и сложных решений, например, security audit, с ним надо разговаривать и штурмить. А большую часть работ выполняет Haiku – самый тупой, гоняет код, пропихивает экраны. Sonnet – пишет код. Opus по факту в 60 раз дороже Haiku. Haiku больше всех работает и меньше всего стоит.

Идея в том, что никакой магии нет. Это рутинный процесс. Но 10 агентов, профили, консилиумы. Проблема в том, что если вся эта конфигурация на личных ноутах команды, то технически это отнимает много времени. Еще все прописывают все в основном файле claude.md, он прогружается весь и жжет токены. Поэтому там пишем базовый набор и простые правила, что делать с промптом. Дальше – project-файл, там специфика проекта, и профили для разных деятельностей, тоже отдельные, в основном ты описал – он выбрал, если не знает – он тебя спросил.

Как работает? Запрос «добавь оплату» – идет загрузка профиля и проекта, «добавить» – признак, что нужна новая бизнес-фича – подгружаем нужный профиль. И в результате там готовый нужный контекст. Мы экономим токены и контекст – не сжимаем его.

Он собрал все в тулу, в презентации ссылка. Не факт, что вам подойдет, но как скелет точно можно использовать.

== Pablo Aguilar. Architecture of an Instant Payment System (by Brazil) ==

Это – единственное выступление не по теме ИИ, которое я слушал на конференции. Pablo рассказывал, про бразильский аналог СБП (системы быстрых платежей) – архитектуру, производительность, немного истории. Вполне на уровне, от старта разработки до запуска в эксплуатацию – два года, 2019-1020. При этом в Бразилии отличаются стартовые условия: это у нас ЦБ всегда обеспечивал межбанковские платежи, а там расчеты между банками шли напрямую или через SWIFT, и своей карточной платежной системы не было, так что первые разговоры были в 2016 году, а рабочую группу создали в 2018.

У системы два режима проведения платежей: DOC – платеж на следующий день, TED – мгновенно в рабочее время, instant payment (по португальски сокращение pix). Платежи полностью бесплатны для физиков, для компаний есть комиссии – как у нас. Нужен pix key – для передачи денег, есть 4 типа: телефон, taxid, random key и еще что-то.

Сложности платежей – множество банков, валют, счетов, регулируется большим количеством документов.

Технически платежи идут через ЦБ, от банка идет запросом «хочу послать деньги», ответ банка-получателя «готов принять» в ЦБ, и дальше ЦБ передает деньги, около 10 сообщений на платеж. Fraud and ledger в каждом банке, в ЦБ две подсистемы: spi – платежи and dict – справочники. Два канала: для быстрых ответов 40 с и для посылок по расписанию – там 45 минут.

Технически передача по национальной финансовой сети RSFN, в ней банки, и есть два провайдера, которые дают она соединяется в интернет для пользователей. протоколы mutual TLS, message signature – подписываем сообщения xml-signature. Сертификаты обновляются каждый год. Асинхронная коммуникация, не kafka или vpn, а какой-то собственный протокол. В презентации были SLA, они жесткие.

Надежность – через репликацию между датацентрами. Единое мето правды – ЦБ, есть сверка с банками.

Pix – успешен, как софт и продукт. Конкурирует с Visa/Mastercard – проще и дешевле. И со SWIFT тоже.

== Андрей Неведин из Райфайзен. Context is a must: как мы системно управляем контекстом ==

Это выступление я тоже комментировал во впечатлениях второго дня: я увидел в нем реализацию старой мечты инженеров писать платформу, а не прикладные задачи. В свое время так не вышло, оказалось, что через конфигурирование платформ слишком сложно для бизнеса и не дает решение с хорошей эргономикой, теперь пробуют обеспечить это за счет агентов: пусть бизнес-задачи решают агенты, а разработчики будут их достраивать. Мое мнение – так тоже не получится, для этого есть системные причины, надо ориентироваться на то, что решать задачи будет гибридная команда: агенты делают что могут, а в сложных случаях подключается человек.

Конечно, для начала надо научить агента решать простые типовые задачи от бизнеса, их много, и ребята сейчас именно на этом этапе. Но важно закладывать гибридную команду в архитектуру. Тут уместна аналогия с библиотекой компонентов для интерфейса: есть фреймворки, которые дают богатый набор компонентов, но при этом совершенно закрыты для реализации собственных компонентов с встройкой их в большую форму, и если вам нужна специфика. то всю форму надо собирать вручную. А есть те, где вы можете встроить свой компонент, например, умного ввода больших чисел или номеров счетов, или поиска по конкретным справочникам, и использовать его внутри формы, при этом обычно «из коробки» у них компонентов меньше, зато есть библиотека сторонних компонентов. Разница – в архитектуре, которую закладывали изначально.

Так и тут, если у тебя целевая картина – автономная работа агента, то ты можешь не предусмотреть в архитектуре точечное включение human in the loopс гибкими критериями. Впрочем, судя по выступлению, ребята реализуют именно гибридную команду, хотя целевая картина другая, а до точки ветвления им пока далеко, автомноно выполняется очень мало задач.

А теперь про выступление подробнее. Несмотря на мой скепсис по общему подходу, в выступлении много полезного.

Цель 100% кода пишут агенты, а люди их настраивают. В нашей команде мы туда идем, но не пришли. Возьмем Claude Code. Агент – disrupt индустрии разработки. Когда работает на ноуте, то останавливается, когда закрываешь крышку, а хочется автономно.

Я тут замечу, что это, на мой взгляд, ложная посылка: не закрывай крышку – и будет агент работать. Принципиально ограничение в мощности, доступной автономно, и это – другой системный уровень – что использовать локально, а что – в облаке. При этом есть системы, которые обеспечивают легкий перенос, разворачиваются в IDE или на сервере, а есть – где только одна версия или версии различаются, и это надо учитывать при выборе.

Claw-решения китайские гиганты обогащают. И их команда делает '''Raif Claw'''. Claude agent SDK/Codex/Opencode. У них есть внутренние модели, и есть гейт на внешние модели, где свой контроль запросов, фильтрация и анонимизация.

'''Vibe team Discovery''' и '''Vibe team Delivery''' – рои агентов для автономного SDLC. Первая – для автономных исследователей и генерации задач, вторая – для реализации.

Vibe Team живет в command center. Paper clip, linear, Claude manager. Они выбрали Multica – open source, его можно форкнуть и докручивать. Управлять: какие скилы у бэкэндера и других, как живут люди и агенты вместе.

Ставит задачу: доработай задачу на потребительский кредит в airline, добавь поле «есть ли субсидия». Агент-тимлид подхватывает, и первое – исследование контекста: где находится потребительский кредит, кто отвечает, где бэк, фронт и мобилки. Он использует это сам для того, чтобы составить спецификацию задачи. На основе спецификации он задает уточняющие вопросы: обязательное поле или нет, куда передается в бизнес-логике и как там учитывается и так далее. На основе ответов – дорабатывает спеку и далее нарезает задачу на агентов-исполнителей. И идет контроль, чтобы задача не грузила контент более, чем на 20% – тогда ее с большой вероятностью сделают за один раз. Если задача слишком большая – пробуют декомпозировать. После бэка работает фронт и мобилки, затем агент-тестировщикпроверяет результат. И когда результат достигнут – человеку идет нотификация на проверку. Так агенты разгребают бэклог.

Agent harness – чтобы обеспечить надежность и предсказуемость результата. Loop Engineering. Придет на смену Harness Engineering. Discover – Plan – Execute – Verify – Iterate. Чтобы работало – нужен Context и Test.

'''Context annotation platform''' – цифровой двойник банка: разрез по ответственности по value stream, описание бизнес и софтовой архитектуры в едином графе. Орг.структура, бизнес-контекст, технический контекст. Есть интерфейс для людей, и интерфейс для агентов с семантическим поиском для обогащения задачи. Агенты используют граф знаний для исследования контекста. Векторный поиск через mcp, формат графа – удобен для агента: команда владеет сервисом и так далее – семантика взаимосвязей.

Как поддерживать Context annotation platform? Агенты сами добавляют этот граф. А еще динамически через трейсинг и телеметрию дополняют контекст – есть разметка в коде.

'''Context memory platform''' – платформа долговременной памяти. Сделана на основе mem0 (на слайде – варианты). Задачи. (1) Персонализация под пользователя – будь прямолинеен или краток. Ты сообщаешь факты – он помнит. И не только про разработчиков, но и для пользователей – кто интересовался какими кредитами и какие каналы предпочитает для коммуникации. (2) Self-improvement – он смотрит трейсинг, реакции человека, чтобы совершенствоваться.

'''Developer Book MCP''' – стандарты написания кода в Банке. При этом не все rules нужны для конкретной задачи, надо загружать конкретные гайды с учетом контекста – экономия токенов. Context 7 MCP – дает доку о агентам нужной версии. И они по аналогии сделали: есть гайды, они размечены по категориям, например, по разработке API, и он делает поиск по договоренностям – как делать API, как работать с базой и так далее. И извлекается нужный кусочек.

Контекст – новое золото, пока есть ограничения – надо оптимизировать. И у каждой организации должен быть knowledge-слой. Про контекст поняли год назад, подняли систему и команды год загружали информацию.

Рои агентов сейчас пилотирует 5 бизнесовых команд: платежи, кредиты, данные, они большие, по 100+ разработчиков. И каждая команда имеет свою vibe team и примерно 25% бэклога сделаны командами вместе с агентами, а 4% сделано агентами автономно, без обращения к человеку. При этом есть зоны, которые агентам не доверяют: процессинг, рисковые движки, поэтому если задачи их касаются – то делают вручную. И люди в команде сами проводят исследования и улучшают harness каждый спринт. На слайде были метрики реальной команды.

Вопрос читаемости спецификаций не решали. Спеку, если надо, читаем с помощью агента – он отвечает на вопросы. Базово человек не ревьюит спеку, это будет узкое место. Но избирательно их проверяют, и разбираются при анализе качества работы агентов – почему получилась такая, что надо добавить в harness.

Очень много вкладывают в verify – там много разных агентов с оценками кода, получают evaluation score, интегрированная метрика. Но это – за рамками выступления

Прозрачность работы агентов есть: в командном центре видны все задачи и их состояние.

По расходам. Собирают метрики после каждого прогона – сколько токенов, где вмешивался человек. И пробуют улучшать, определяют причины: переполнил окно и загрузил лишнее, или задача была сложная, или что. Делают ретро и оптимизируют.

За контекст отвечают команды. Но отдельно контекст не тестируем, смотрим результат работы агентов. Если не хватило контекста – команды думают про обогащение. Но при этом между командами синхронизируют понимание терминов, чтобы не было противоречий. Был этап, когда команды описывали по-своему, это прошли.

== Никита Круглов из Альфа-банка. Как построить text2sql с нуля и собрать (почти) все шишки ==

Это рассказ про создание сервиса, которые обеспечивает работу пользователя с данными через диалог с агентом.Задачи: навигация пользователя по таблицам, генерация sql, там несколько моделей и визуализация результата через библиотеку создания графиков, вызовы которой тоже делает агент. В целом – успешно.

Сейчас в сервисе 300 таблиц, количество растет. Используют 4 подразделения, 2000 человек. Хотят перейти на общий каталог от Excel, интеграция с ML для обучения, эксперименты с архитектурой SQL, углубление в аналитику – дата-агент.

Надо проверять, хорошо ли агент вызывает тулы, хорошо ли ищет информацию, хороший ли получается идет SQL-запрос. Нужны примеры простых-средних-сложных запросов. Нужный документ попадает в топ-3 в 80% случаев. Качество генерации – когда результат совпадает с правильным – 80%. Надо проверять описания данных от владельцев. Маленький контекст – хорошо для генерации – они убирают описания ненужных колонок. Пользователи не умеют задавать вопросы – нужен модуль уточнения.

== Михаил Кацуба из Ленты. ИИ-код: от нуля до прода ==

Это был рассказ про конкретный кейс: как сделать приложение, которое бы распознавало и оценивало выкладку овощей и фруктов на витрины. Михаил его делал, сохраняя историю и в презентации ее рассказывал. Кейс, правда, не боевой, а модельный. А до рассказа про кейс была вводная про использование ИИ в обработке данных – профессиональной области МИхаила, и эта теория напрямую с кейсом не связана.

История Михаила – это история о том, как быстро в современном мире надо изменяться. Он был переводчиком – ИИ стал переводить. Пошел в ИТ делать отчеты – основной инструмент заблокировали. Тогда пошел в аналитику данных, ИИ помогает погружаться. И его опыт говорит, что '''изменения в жизни делают ее интересной, а тревога – не запоминается'''.

Claude Code, Codex, Antigravity. Но использование ограничено – блокировки, обход их несет риски, особенно в корпоративном мире, безопасность – серьезно. Поэтому используем отечественные средства, или разворачиваем свое. И важно уметь работать с разными моделями, быть готовым, что в рабочей среде будет не то, что привычно.

Смотрел отечественные (Yandex, Сбер) и китайские модели. В итоге – '''Yandex Source Craft'''. Облачная платформа с ИИ-кодированием, встройка в VS Code, основана на Qwen. Имеет обновляемый пробный доступ, доступен с корпоративными яндекс-сервисами.

Продуктовый код – важны архитектура, шаблоны, поддерживаемость, масштабируемость. А для бизнеса важно, чтобы работало и приносило деньги, качество кода – не важно, оно актуально, только если показываешь ,что качество как-то дает деньги. Сам по себе код деньги не приносит, '''к сгенерированному коду ценность не прилагается, ее надо создать'''.

Простой код в бизнес-отчетности: графики и расчетные показатели. Для ИИ – просто, и инструменты встравают ИИ для написаняи формул. Для отчетов – данные, SQL-запросы создаются – text2sql. B график тоже – создай радарную диаграмму – и он на java напишет. Т можно общаться с данными, ответом может быть график – это json.

ИИ хорошо справляется с простыми задачами, и если разбивать сложные на простые – ИИ их решит. ИИ может сделать прототипы. Может собрать данные из разных отчетов и свести в Excel. BB расширяет круг формализуемых задач, бизнес сможет делать сам, не заказывая разовый отчет. И сами решения тоже будут развиваться с ИИ.

Дата-инженирия: ETL простые части – подключение – получение данных – преобразование – сохранение. Тоже ИИ справляется. При этом для подключения, обработки и сохранения – библиотеки, там стандартные решения, и управляем конфигурацией. ИИ json тоже породит. Аналогично А/Б-тесты: данные на платформе, а тест – конфиг в json. Идея: не пишем с нуля, а используем готовое через конфигурации. И конфигурацией можно управлять руками, если точечные изменения.

'''Пример разработки. Распознавание овощей и фруктов на прилавке – оценка выкладки, а в перспективе – свежесть'''. Тестировать можно на глаз.

Начало разработки: регистрируем учетку, скачиваем плугин для vscode – и все готово.

Самое простое для распознавания – человеческое лицо. Дальше пишем промпт, для начала – как приходит мысль – так и пишем. Но надо ставить ограничения – простой сценарий. ИИ делает план и технологии. Ключевой выбор – модель распознавания, и компоненты. В результате – структура проекта. Дальше ИИ пишет код, можно смотреть. Внутренняя, визуальная – потом развертываем. И нейронка сама запускает – лица распознались. И это вообще без отладки. Это – очень важный шаг, когда осваиваешь новое: сделать простое приложение так, чтобы оно дало результат, пройти путь до конца. Пусть оно не совсем про целевую конструкцию.

Дальше – сложнее. Важно не писать промты, а провести исследование. Надо понимать, из каких кубиков строим приложение, не рассыплется ли конструкция. Описываешь задачу, спрашиваешь про способы решения, сравниваешь и обсуждаешь варианты. Начинаем с режима архитектора и используем думающую модель.

Он не удержался и выбрал микросервисы сразу. Дальше надо выбрать модель распознавания: нейронка их предлагает, он выбрал YOLOv8m по ее совету. ИИ хотел продать дообучение на фрукты и овощи, но ссылки оказались недоступны и он это пропустил.

Из-за сложной архитектуры посыпались ошибки при связывании компонентов. Логи ошибок нейронка подхватывает и предлагает решения, так что в результате приложение собралось и начало работать. Но дальше пошли ошибки в модели разпознавания.

Приложение массивное – он переключился на более простую архитектуру для теста модели. Первый опыт дает хорошее распознавание, но там из коробки всего 5 классов фруктов и овощей, и смесь не определяется. Он начал тестировать разные модели, наиболее удобной оказалсь YOLOe-26x-pf – у нее из коробки результаты лучше. Но все равно она достаточно шумная, ее надо донастраивать: выделять зоны, связывать с планограммами и так далее. И нужно дообучать.

Тестирование. Когда код доверен ИИ, то тесты – основной способ контроля. Их можно генерить с помощью ИИ. Работа тестов – черный ящик. При отладке было, когда картинка передается не на ту модель, или не передают тест на новую модель – переключение не работает. И чтобы работало – ломаем код, если тесты продолжают проходить – а них фейк.

Нейронка хорошо справляется с анализом отклонений в коде и review на merge. Протестировали – загрузку модели проверяли до его загрузки.

Важно грамотно разбивать попроще, и придется разобраться с тестами – везде ли настроены и грамотно ли проверяют функционал.

Розница – хорошее поле: небольшая экономика дает на масштабе большую прибавку к деньгам, и простая регуляторика.

'''Вопрос''': а если код пошел в прод, оно сломалось, а никто в компании не знает, что там под капотом. '''Ответ'''. Отлаживать ИИ умеет, указываешь на ошибки – она исправляет, смотришь. Я тут дополню, что это не отличается от ситуации, когда легаси сломалось, а разработчик ушел. А разбираться ИИ помогает, и построить для работающего кода тесты и документацию тоже. Так что это все уже не актуально.

== Андрей Давыдков. MWS автоматизация postmorten ==

Это рассказ про повышение качество кода и снижение количества инцидентов с помощью ИИ. Основной фокус – на автоматизацию postmorten разбора инцидентов, но реально рамка рассказа шире – Андрей рассказал как сложилась ситуация с качеством, и как для ее решения были предприняты организационные меры – был организован ситуационный центр МТС, и сделан процесс, который оставляет цифровые следы. Что и позволило автоматизировать postmorten с помощью ИИ, и далее – выявлять системные ошибки, инициировать работу над ними. А в будущих планах – использовать накопленные в ходе анализа знания еще и при работе над инцидентами для поиска причин и способов устранения.

С какими инцидентами имеют дело? Обычные – остановка отдельной службы или накопление очередей. Критичные – недоступность связи абонентов, отсутствие переводов СБП, недоступность приложения KOIN или оплаты заказов.

Postmorten – разбор инцидентов для предотвращения в будущем. Компания большая, каждый разбирал сам. И были проблемы: формальный анализ, поиск виноватых вместо причин, отсутствие системных решений. Например, бизнес замутил акцию для клиентов, сервис – сломался не выдержав нагрузки. И в разборе указали причину: перегруз CPU и придумали поставить CPU на мониторинг – до реальной причины не дошли. Последствия – повторяющиеся инциденты, влияние на бизнес, отсутствие системных улучшений.

Ситуация сложилась не сразу, причины – изменение ИТ-ландшафта: длинные цепочки зависимостей, переиспользование сервисов и так далее. Когда-то «Мой МТС» – один сервис с простой архитектурой, и инцидент – понятная зона ответственности. Сейчас – мобилки, витрина многих продуктов, куча интеграций под капотом, и инцидент моет возникнуть по любому сценарию, надо смотреть смежников, а те – идут на другие сервисы. Разбор стал сложным, долгим и дорогим.

Ключевые проблематики: формальные разборы без поиска коревых причин, отсутствие единого формата итогов – нельзя увидеть системные ошибки из-за разнообразия, каждая команда – свой бэклог и там дублирование, меры оставались на бумаге, много ручного труда.

Они сделали ситуационный центр МТС для координации работы над инцидентами, и приняли план изменений.

* Blameless-подход и SRE-практики
* Mission control center
* Единый инструментарий – RelyOps-платформа: автоматизация разбора инцидентов
* Дашборд метрик

Оргизменения:

* Команда мониторинга и координации круглосуточно.
* Команда product duty – первая линия, по желанию подключается продуктовым командам
* Команда развития ops-процессов – разбор кейсов с командами и доработка процессов
* Команда BI-аналитики

Формализация процесса на основе SRE-book – адаптировали, описали в confluence, сделали шаблон отчета. Начали проводить демо команд, встроились в онбординг и начали участвовать в разборе инцидентов – чтобы смотреть работу на практике.

После решения инцидента у команды 1-2 дня на разбор и заполнение черновика отчета. Дальше – митинг. Корневые причины, бизнес-импакт, меры предотвращения со сроками. И комитет по пятницам.

Результаты: сотрудничество вместо перекладывания ответственности, единая база знаний из отчетов и ее использование при инцидентах.

RelyOps платформа – экономически обоснованный уровень надежности. Архитектурная схема CMDB – Observability (vision scope + бизнес-сценарии, метрики и т.п.) – ITSM – Notification + emergency room.

B это позволило сделать автоматизацию постмортена.

События observability содержат трейсы, логи, метрика и влияние на смежные бизнес-процессы, и дальше он летит в команду, а если инцидент клиентский – то идет интеграция с базой, где идут обращения клиентов. Если критический – аварийная emergency room для обсуждения решений.

Когда инцидент решен – все артефакты упаковываются, команда разбора может еще довнести артефакты, заполнить причины и меры по предотвращению в таск-трекере. И дальше – отчет в конфлюенс.

Лайфхаки.

* Подход пяти почему. Выйти за рамки симптомов. Если сервер лег под нагрузкой – то узнать почему была нагрузка, потому что запустили рекламу без согласования с ИТ, значит надо согласовывать.
* Практика создания мер предотвращения, три типовых причины: (1) если не выявлено мониторингом – доработать для проактивного наблюдения; (2) если долго диагностировали – повышение наблюдаемости и средств диагностики; (3) если ошибка в релизе – повысить охват тестирования.
* Дашборд надежности: доступность, ремонтопригодность, количество критичных инцидентов и так далее.

Итого. Разбор критичных инцидентов ускорился с 4 часов до 1 часа. И еще ряд метрик – изменения есть в презентации.

В этом году вывели на прод Co-pilot. Зачем? Потому что смотрят на 5% инцидентов, а 95% в серой зоне, их команды разбирают внутри с неясным качеством. Но posmorten критичных инцидентов – дорогой, там 15 квалифицированных инженеров, все так разбирать дорого. Цель – создавать отчет за счет copilot, масштабировать на все инциденты, и увеличить базу для разборов.

Три сервиса: (1) поиск похожих инцидентов по ключевым атрибутам, (2) проверка точек мониторинга – выявлен ли сбой проактивно, (3) PromptBuilder + LLM – получает предыдущее и выдает основную причину, альтернативы, и предложения по устранению. Дальше инженер принимает или дорабатывает.

Для поиска похожих – Minhash+LSH – оценка похожести объектов и выдача кандидатов. Провели R&D по пороговому значению, нащупали порог сходства 0.7, 0.4 – много шума и потеря полезных совпадений, 0.9 – уменьшает число схожих и тоже увеличивает шум.

PromptBuilder + LLM. Поиск похожих – задает, дальше оптимальный промпт, и дальше выбор модели из локально развернутых – там 10+ моделей.

Берут из ретроспективных данных инцидент, делают внутренний генератор для черновика, дальше выделяем атрибуты, заполненные человеком, дальше судья сравнивает то, что породил генератор с тем, что сделал человек. Проводят бенчмарк моделей, оценивают по 4 бальной шкале. 0 – полностью не соответствует, 3 – полностью эквивалентно. Оптимально генератор Qwen-3, а судья – Codify.

Итого. Формальный разбор – тупик, изменения надо начинать с культуры, централизация дает эффект масштаба, автоматизация postmorten – инвестиция. И чем больше артефактов зафиксировали в ходе инцидента – тем лучше качество на выходе.

Как несут культуру? Когда начали внедрять, многие восприняли как бюрократию. Но когда с командами прошли путь – они поняли, что история приносит пользу. И они слышат обратную связь от команд – где они перегибают палку, где можно автоматизировать.

Второй этап – все эти подсказки postmorten вывести еще на этап разбора инцидента, сейчас делают пилоты.

[[Категория:ИИ-агенты]]
{{wl-publish: 2026-07-02 09:33:10 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2026-07-06: Нужен ли ИИ-помощнику системный подход и как его обеспечить?

2026-07-24T14:39:13Z

MaksTsepkov:

{{RightNote|[[:Категория:Системное мышление|Еще про системное мышление]]}}
Посмотрел '''семинар Анатолия Левенчука''' про очередное развитие его First Principle Framework – объяснение системного подхода для ИИ. Очередной этап – теперь можно одной командой создавать '''описания для конкретной предметной области''' – Domain Principle Framework ('''DPF'''). Семинар вызвал размышления, из которых получилась статья https://habr.com/ru/articles/1056178/, в ней же – ссылки. Читайте и оценивайте.

[https://t.me/mtsepkov/1184 Пост в Tg]

[[Категория:Системное мышление]][[Категория:Статьи]][[Категория:ИИ-агенты]]
{{wl-publish: 2026-07-06 18:46:26 +0300 | MaksTsepkov }}

Блог:Максима Цепкова/2026-07-09: Saint Teamlead-2026: ИИ-агенты меняют индустрию разработки

2026-07-24T14:37:11Z

MaksTsepkov:

{{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+ интеграций. Проводится анализ связей по монитору.
* Команда должна выигрывать по миграции – экспертиза, онбординг
* Должно быть покрытие функциональными тестами. Если его нет – то сначала надо сделать. '''Без тестов миграция – не ускорение, а перенос багов'''. При этом у них тесты изолированы от сервиса, так что они могут проверять сервис на любом стеке. 

* Нельзя переносить легаси, которые напрямую обращаются к чужим таблицам через 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, делает агентский пайплайн и инструкции по нему, готов посмотреть качество и починить его, готов помочь командам. Это все – компетенции руководителя, просто ИИ-лид применяет их не к людям, а к агентам.
* '''Принесите командам токенов''', если не безлимит, то квоты, например, внутренний безлимит и внешние.
* Полезен бюджет на премии тем, кто уже повнедрял – только надо смотреть на результат, а не на сожженные токены.
* Встройте в онбординг. Тем попробовал – очевидно, что нейронку можно спросить про взаимодействие с ней, а новых надо научить, что так можно.
* Регулярные встречи по достижениям и проблемам, и парное программирование с публикацией логов. 

* Важно не только порождать код, но и обустраивать другие процессы: ревью кода, тестирование, выкатка. Там много рутинных работ, которые можно превратить скилы. Это не сложно, но люди привыкли делать руками. '''Садимся рядом с человеком, спрашиваем, как он работает, пробуем сделать скил, не работает, докручиваем'''.
* '''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 тоже был для единственного проекта. 

* Бесконечная совместная работа команд – слияние, люди не понимают границы между платформой и разработкой на ней.
* Не упакованная экспертная сложность,

'''Главный вопрос: какие решения (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 }}