Работаю над книгой. У меня просьба ко всем читателям: оставьте отзывы, они помогут ориентироваться тем, кто не знаком, плюс наличие отзывов учитывается в рекомендациях. Книга сделана на ridero, но доступна на многих площадках: litres, ozon, bookmate, wiliberries и других и отзывы полезны везде.

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

И снова про книгу https://ridero.ru/books/inzhenernaya_model_lichnosti/ - хотя читающих бумажный вариант - меньшинство, они есть и я доработал иллюстрации, чтобы они нормально получались в черно-белом варианте, а еще добавил QR-коды для ссылок в каждой главе. И опубликовал как обновление книги, у тех, кто уже купил электронную, обновление появится. Я должен извиниться перед теми, кто уже купил бумажную книгу, что не сделал так сразу. Но это - мой первый опыт издания бумажной книги, Менеджмент цифрового мира вышел только в электронной версии. Возможно, я его тоже теперь подготовлю для бумаги.

Сегодня на #lafest, одна из моих любимых конференций, в которой я участвую с 2010 года, хотя и с перерывами. И у меня открывающий доклад про модель личности, построенную на связке психологических моделей с нейрофизиологией. У меня об этом книга, но там модель изложена от базовых уровней к прикладным, а в докладе я буду рассказывать наоборот, от практических применений. Хотя в любом случае это будет краткий обзор. Презентация уже опубликована у меня на сайте https://mtsepkov.org/SoftSkillsLAF

#lafest Алексей Трошин. Инструменты командного планирования для тимлида. Рассказ о том, как получить оценки по новым задачам, когда еще даже непонятно что делать. С практиками ссылками на статьи и примерами. Четыре этапа: Декомпозиция - Оценка - Этапы - Сроки.

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

2. Оценка. Есть хорошая статья Андрей Летюшев. Путеводитель по оценкам задач и котики. https://habr.com/ru/articles/742364/ Оценка не является обязательством. Это предварительное представление. Они могут и должны изменяться. Программисты не любят оценки. Они отвечают "1 день", делая ввиду, что сделают какой-то прототип, который как-то заработает. А там - посмотрим. Этого менеджер не понимает.

Planing poker. Смысл карт в закрытую - чтобы зафиксировать разницу мнений. Если оценки близкие - значит есть понимание что надо делать. Если большие различия - значит разные представления. А если оценка большая - значит большая неопределенность, надо вынести исследовательскую задачу.

Механика story point - есть статья https://habr.com/ru/articles/489500 И пересчет sp в трудоемкости.

Риски не закладываются в оценку, они отдельно.

3. Этапы. user story mapping. Дальше делаем поэтпаное выполнение. Есть дополнительные активности, влияющие на сроки: найм, инфраструктура, доступы, лицензии, закупки. Это может двигать сроки, а в задачах на разработку этого нет.

Приоритизация Статья https://spark.ru/user/34904/blog/34748/20-tehnik-prioritizatsii-v-produkte-karta-i-rukovodstvo 20 техник приоритизации в продукте: карта и руководство

Техники MVP minimal viable product и MMF - minimal marketable feature. Примеры.
* Поиск - сначала по названию, посмотреть как используют.
* Новость - как есть, потом умный редактор, потом массовое.
* Поиск авиабилетов - сначала медленно с крутилкой, потом ускоряем.
* Оплаты - сначала 1 способ, потмо добавляем.
* Загрузка каталога в формате Яндекс-маркета: сначала вручную из файла командой, потом скрипты - уже можно наполнять массово, потом ui без обработки ошибок, потмо разбор ошибок.

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

Нетривиально: Пришпоренная лошадь бежит быстрее, а команды под давлением работают меленнее.

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

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

Команда соучаствует в оценке - и это важно. Это работает как эффект ИКЕА: The IKEA effect and how I screwed up https://www.jeremybrown.tech/the-ikea-effect/

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

#lafest Владимир Баймаков. С чего начать построение практики управления архитектурой и бизнес-анализа в компании. История о том, как в большой корпоративной структуре - МОЭК делали отдел бизнес-аналитиков под задачу импортозамещения. В ходе импортозамещения надо было поменять 10+ ключевых систем, между которыми исторически сложилось 150+ интеграций, и сделать это, не нарушив работу компании. Идея - сделать отдельный отдел бизнес-аналитиков, чтобы обеспечить целостное представление о бизнес-процессах компании. Идея получила поддержку руководства, и это был первый, самый простой этап. А дальше был рассказ о том, как эту идею реализовывали в корпоративной среде. Для начала пройти бюрократические процедуры определения места бизнес-аналитиков с требуемыми схемами и регламентами, написание должностных инструкций. Надо было обосновать, что будет отдельный отдел, а не распределение аналитиков по командам. К объему этой части, согласованием в корпоративной среде, они не слишком было готовы. Но прошли.

Дальше был найм сотрудников. Профиль: технические навыки - нотации и инструменты; компетенция аналитиков работы с информацией - доставать, формулировать, доносить; коммуникационные навыки. Нужно было 20 человек - 500 анкет, 100 собеседований. Решили давать кейс на 1-2 дня. Например, нарисовать бизнес-процесс по рассказу заказчика. Человек тратит пару часов, но за это понимаем можно ли сотрудничать. Сейчас рынок кандидатов, они диктуют условия и выбирают компании. Приняли решение закрыть часть потребностей через внутреннее совместительство. Взяли экспертов в функциональных областях, тех кто имеет компетенции - и доукомплектовали отдел. И еще запустили программу стажировок для студентов.

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

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

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

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

Максим зажигает про модели типов личности 🔥

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

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

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

Я считаю, что тут Дима ошибается. Просто 2-3 года назад пошло два тренда: (а) ИТ в производстве, не на основе собственных вендорских решений, а на собственной разработке и (б) импортозамещение, требуемое объективными обстоятельствами. Обе эти деятельности требуют аналитиков, много аналитиков.

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

Дальше была схема: бизнес-процесс - автоматизированная система - ручные операции. Классическая система: вендор - интегратор - бизнес. Прохождение цепи 6-24 месяцев, быстрее не бывает. И проектный подход: as is - to be и прописать переходный период. И работает классическая система не качественно: чем больше мы деливерим - тем больше запросов получаем. Глюки в элементарном софте - везде, в основном функционале. Яндекс, Сбер, ВТБ и далее по списку.

Я тут хочу заметить, что наезд - не по адресу. Дело не в подходе, он-то как раз более за качество. А вот бизнес-практика побуждает выпускать систему с приемлемым качеством, без перфекционизма - ибо быстрее и дешевле. И, опять-таки, тема - старая, смотри статью Ривза 1992 года "What is software design", кому интересно - у меня в статье https://vc.ru/hr/95754 "Развитие и провал регулярного менеджмента в IT" есть подробности.

Дальше был переход к современной digital-команде, которая владеет продуктом и сама, без участия бизнеса, выбирает путь его развития. Аналитик участвует в этом процессе, обеспечивая переход от product и feature discovery, исследований, к разработке и поставке, delivery. И это - конвейер, требования в такой команде не должны прокиснуть, разработчиков надо кормить свеженьким. Жизненного цикла требований - не существует, в отличие от классического подхода, где у Microsoft в Visual studio было 11 этапов преобразования требований с трассировками. Фича проходит 4 фазы: discovery + research, design, development, delivery.

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

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

Топ-5 ошибок продуктовой разработки.
1. Сделаем продукт по требованиям заинтересованных сторон - опросили пациентов как лечить
2. Сначала соберем все требования - аналитический паралич.
3. Сделаем требования по организации X, а остальным впарим как продукт.
4. Сначала запилим, потом измерим. Или даже не будем измерять - зачем расстраиваться.
5. Как-то плохо продается, давайте еще фич добавим, никому не было плохо. Реально надо выпилить лишнее - поддержка стоит денег.

Разные mindset: управление требованиями - разработка требований - создание продукта. Создание vision с ценностью ля бизнеса требует мышления, которого у многих аналитиков нет.

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

Переход в цифровой мир трансформация цепочки создания ценности. Раньше была пирамидка: процессы - проекты - автоматизированные системы - инфраструктура. А теперь команды, которые автоматизиуют, уменьшают взаимодействие людей. Сетевая структура вместо иерархической. И у каждой системы - своя траектория развития, которую определяет ее команда. Есть контракты на взаимодействие систем, но нет контракта по внешней границы компании, команда ее она двигает сама. Digital team: лаборатория research, product team, эксплуатация и управление, пользователи.

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

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

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

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

Прототип новой системы можно запустить в рамках хакатона, или один спринт, неделя. За следующий спринт можно переделать. За 3-4 итерации что-то заработает. И именно так надо запускать новые системы. А не два года разрабатывать то, что не взлетит. А такой old school по-прежнему местами практикуют. И по-прежнему живут длинными горизонтами планирования, недавно одна российская компания заказывала стратсессию на 10 лет со словами "на 5 лет у нас все спланировано". И половина изменений требований - со сменой настроения руководителей, а не объективные.

На этом - все.

#lafest Николай Поташников. Как мы с помощью собственных DSL и автотестов обеспечиваем единый язык описания домена и модели для всех стейкхолдеров. Хороший доклад с конкретными примерами о том, как применять вместо тяжелых и сложных промышленных языков простые DSL, создаваемые под ситуацию конкретного проекта: делать автотесты и автодоки без Gherkin, бизнес-процессы без BPMN и обмен данными без OpenAPI или SOAP. Потому что мощность, которую дает язык общего вида, в проекте не нужна, при этом, используя такой инструмент, ты платишь сложностью описаний. А простой DSL получается компактным, практически это инициализации данных JScript, которые интерпретируются, или конструкции на Kotlin DSL. При этом ты получаешь ряд преимуществ:
* Конструкции на таких DSL пишут аналитики
* Их можно показывать заказчику, хотя с объяснениями, и тот их согласует
* Работают в коде именно написанные аналитиком описания, нет этапа кодирования конкретных случаев, работает DSL
* По DSL-описанию можно порождать читаемую документацию простыми преобразованиями в asciidoc или markdown и она всегда будет соответствовать коду, а при изменении - сборка документа будет падать

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

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

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

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

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

Схема трассировки пользы, о которой я писал в предыдущем посте.

В выходные прошел Летний Аналитический #lafest. Заметки с первого дня я публиковал на канале, а сейчас дополнил их заметками второго дня и собрал отчет https://mtsepkov.org/LAF-2024 Программа фестиваля включала 5-7 параллельных треков, при этом почти половина активностей - воркшопы и мастер-классы. Так что я был лишь на малой части того, что было на конференции. В том числе - из-за активного нетворкинга. Увы, общаясь с участниками и отвечая на вопросы после своего доклада я пропустил доклад Татьяны Половинкиной HumanOps, о котором услышал много хороших отзывов. Мой доклад стоял параллельно с воркшопами Натальи Семеновой и Андрея Дмитриева, а доклад Димы Безуглого стоял параллельно с Максимом Шаломовичем, и их выступлений мне тоже жаль. Так что заметки заведомо неполные, но это ж лучше, чем ничего. И я хочу отдельно отметить воркшоп Анны Подолиной про юмор.

Управлением знаниями я впервые встретился в 2010 году на конференции KM Russia. Тогда я осознал, что об этом можно говорить не в контексте проектной документации и компетенций, есть отдельный набор методов, не привязанных к конкретной дисциплине. На первой TeamleadConf я делал доклад об управлении знаиями в ИТ, а позднее. когда онтико сделал отдельную конференцию KnowledgeConf - активно работал в ПК. Сейчас эта конференция живет в рамках TeamleadConf как отдельный трек, с отдельным отбором докладов, и набирает доклады на осеннюю конференцию 2-3.12 в Москве https://cfp.knowledgeconf.ru/ Заявку надо подать до 15 августа! Так что если есть чем поделиться по темам управления знаниями: коммуникации, онбординге, извлечении у экспертов, передаче между командами - присылайте заявки!

Получив свою книгу Инженерная модель личности в бумажном виде и порадовавшись, я решил аналогично доработать свою первую книгу Менеджмент цифрового мира. Прошел по тексту, актуализировал ссылки (часть из них теперь ведут на archive.org), и добавил QR-коды. Обновил некоторые иллюстрации, чтобы было контрастное черно-белое изображение, а в схемы спиральной динамики добавил названия цветов. Основной текст я не менял, кроме малого количества редакторских правок и нескольких примечаний. В целом содержание книги сохраняет актуальность, и хотя некоторые разделы я бы, конечно, сейчас доработал, это было бы более подробное раскрытие и иллюстрация новыми примерами, а не изменение содержания. Наверное, я это еще сделаю, а можно получить новый вариант. Правда, печатная версия получается дорогая, 1600 рублей, если заказывать на ridero. В общем, это объяснимо - там более 700 страниц. В Инженерной модели личности почти в 3 раза меньше, 260, и там цена бумажной книги более комфортная, чуть меньше 1000 рублей. На электронные версии я оставил прежнюю цену 380. А если у вас была электронная версия - можно скачать обновление, во всяком случае на ridero, про другие площадки - не знаю.

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

А дальше 19.09 - митап московского сообщества тестировщиков, оно возрождается и я этому рад, потом школа Щедровицкого в Бодруме? тоже по теме может ли машина мыслить, uic.dev в Ижевске, SQAdays, ArchDays, MergeConf в Сколково, AnalystDays, Teamlead и Highload. Тут конференции известны, так что в представлении не нуждаются. Я почти везде - с докладами, на разные темы. В основном - в развитие предыдущих и обычно это получается существенное развитие и переосмысление, а не просто повторение старого - мысль-то живет, а темы разных докладов интерферируют, так что картинка каждый раз новая.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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