mtsepkov

Три дня был на конференции Живая компания и вчера весь день делал отчет https://mtsepkov.org/BiorgConf2025 с конспектами докладов - чтобы проработать по свежим следам, пока живы впечатления. Потому что много контента, включая блистательный доклад Гарретта Джонстона. А на самой конференции - замечательная атмосфера, много общения и механики, которые стимулируют интерактив и нетворкинг. Читайте!

Весны еще нет, а весенний сезон конференций уже начинается. Через две с небольшим недели, 22-23 февраля в Подмосковье будет Winter Analitical Weekend - WAW-2025. Конференция проходит второй год, фокус на мастер-классах, воркшопах и дискуссиях, традиционные доклады занимают меньшую часть программы. Но у меня будет именно выступление, в котором я развиваю тему прошлого года о будущем. Если в том году я говорил о развитии ИТ и, особенно, специализации аналитика, то в этом будет более широкая рамка - развитие общества в целом в нынешнюю эпоху развития технологий, включая ИИ. Я постараюсь дать helicopter view, который будет полезен для ориентации в долгую, а не сфокусирован на ситуативных новостях. А это - важно, по прогнозам турбулентное развитие будет идти еще 15-20 лет и все это время ориентироваться и принимать решения предстоит самостоятельно. Плыть по течению - тоже решение, и полезно представлять куда это течение может вынести.

От организаторов конференции подписчикам моего канала скидка 10%, надо связаться с менеджером и сообщить кодовое слово mtsepkov.

P.S. А на этой неделе, 6-8.02, я буду на первой весенней конференции "Живая компания", весна начинается раньше.

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

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

Весной на MergeConf я слушал рассказ Александра Бындю про карту гипотез, а недавно прочитал книгу "Карта гипотез", и хочу поделиться впечатлениями. Предложен простой и очень мощный инструмент, связывающий цели с задачами. Обычно эту связку строят неявно, или даже не строят, а просто постулируют "для достижения цели нам надо сделать задачи 1-2-3", вырабатывая план действий. В ходе обсуждения приводят 6некоторое обоснование, но его часто не фиксируют, а кроме того, оно обоснование часто имеет характер веры или экспертного мнения. Александр говорит о том, что достижение цели всегда заключается в изменении поведения каких-то внешних субъектов. Например, раньше люди не покупали туры у нашей компании (или покупали мало), а теперь станут покупать, и достаточно много. И надо этих людей описать. Например, это люди, которые раньше вообще не покупали туры, а организовывали отдых сами. Или покупали туры массового отдыха, а будут покупать индивидуальный, который мы предлагаем. Или покупали туры, но у наших конкурентов. А вот дальше как раз идет гипотеза: почему эти люди так изменят свое поведение, если мы выполним запланированные задачи. Например, мы придумали, как сделать индивидуальный отдых не сильно дороже, чем массовый, предлагаем это, но люди не знают, что такое возможно, и надо донести до них эту информацию разными способами, и мы ставим задачу по разным способам донесения - информационные статьи, рекламные баннеры, предложение попробовать такие туры популярным блогерам. Или люди вообще не понимают, в чем смысл покупки тура, когда можно все заказать самим - и тогда задачи будут другими. И вот это надо описать в жестком формате гипотезы: если мы сделаем А (и Б), то субъект <так-то> изменит поведение, потому что действие А на него повлияет <таким образом> (объяснение). Связь целей с задачами через гипотезы - ядро метода. А дальше мы собираем из наших целей, задач и связывающих и гипотез карту и с ней работаем.

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

Управление знаниями - одна из моих тем уже пятнадцать лет. Мне тема очень близка, потому что управление знаниями - существенная часть ИТ-разработки. И когда в 2019 Онтико решил организовать конференцию KnowledgeConf по управлению знаниями в ИТ, я присоединился к программному комитету и активно работал. В ковид конференция начала проходить в составе Teamlead, но с отдельной программой и интересными докладами. А в этом году организаторы пробуют снова сделать конференцию отдельной. 23 января в 17:00 мск будет online-встреча с ПК KnowledgeConf, я зову всех, кому близка эта тема, кто хочет поучаствовать в конференции присоединиться. Подробности - в посте https://t.me/KnowledgeConfChannel/357 на канале конференции.

Всех с Новым годом! Хороших праздников и продуктивного года! Пусть он несет драйв, энергию и радость!

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

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

Еще раз Всех с Новым годом!

Осенние конференции закончились в декабре, весенние начинаются в январе. И первая, 6-8 февраля - «Живая компания»" о самоуправлении в организациях. Самоуправление - давно уже не эксперимент, для него есть разные фреймворки организации и практический опыт применения.

В прошлом году я эту конференцию пропустил, а в этом буду не только участвовать, но и выступать, рассказывать про модели личности: «Быстро понять мышление, эмоции и мотивацию коллег? Есть модели!». И там будет много других интересных спикеров, часть из них - на фото.

Приходите! По кодовому слову МАКСИМЦЕПКОВ организаторы обещают специальные условия участия.
🔗 https://biorgconf.ru
🔗 https://t.me/biorgconf

Неделю назад был на #DevRelConf и публикую отчет https://mtsepkov.org/DevRel-2024 Деврелы в ИТ - это люди, которые отвечают не только за сообщества и общение сотрудников внутри, но и за связь с рынком персонала, в отличие от маркетринга и пиара, который ориентирован на потребителей. С ростом дефицита рынка персонала эти задачи становятся все более актуальными, и даже часть ресурсов пиара переориентируют в этом направлении. И деврел становится более зрелым. В этом году не было докладов про то, как организовать или продать бизнесу саму идею, рассказы были про зрелую конструкцию с метриками и мониторингом. Конференция ассоциирована с Онтико, но она открыта, а участие - бесплатно. В этом году было 450 участников и два трека.

В четверг 12.12 был на ежегодной встрече KM Alliance по управлению знаниями, темой года была ИИ. И услышал вау-рассказ Сергея Гевлича о технологии, позволяющей переносить умения тренера, коуча или другого специалиста помогающей профессии на ИИ-помощника: формируется сложный системный промпт, который по-сути создает из GPT специализированную лайт-версию тренера. Бонусом к рассказу была схема проактивного мышления, которая лежит в основе. Вот отчет https://mtsepkov.org/KM_Russia-2024, там конспект доклада Сергея и других докладов. Вообще первый раз на конференции по управлению знаниями KM Russia я был в 2010 году, и потом несколько лет я участвовал во встречах каждый год, а потом был большой перерыв. В этом году - снова участвовал, надеюсь продолжу.

Вчера был на лекции Марка Розина «Спасти и/или погубить компанию. Опыт управленческого и HR консультанта». И хочу быстро зафиксировать https://mtsepkov.org/RozinLecture2024-12, чтобы выгрузить контекст во внешнюю память. Сначала был история концептуализаций от Марка, самая свежая из которых - Дыхание команды (Teaming) - была рассказана накануне в Сенеже. Все концепции, кроме последней, мне были знакомы, но когда рассказ идет вместе, то возникает ощущение последовательности развития, и это дает дополнительный уровень видения. Затем Марк кратко рассказал об избранных кейсах - тех. которые можно назвать длинным романом между консультантом и компанией. А потом - длинный такт вопросов-ответов. По ссылке - мой рассказ, обогащенный комментариями, ссылками и дополнениями. По многим вопросам у меня есть материалы, ссылки ведут на них. А если у вас они тоже есть - вы пишите в комментариях к постам, думаю они тоже будут полезны.

Десять лет назад, в 2014, я прочел книгу Спиральная динамика, и она мне дала ответ на вопрос: почему в ИТ появился Agile как особый вид менеджмента, получилась комплексная картина, которую я тогда же рассказал на AgileDays. А через пару лет картину дополнили Бирюзовые организации Фредерика Лалу, об этом было следующее выступление. С тех пор я рассказывал ее много раз для разных аудиторий. Материала стало много, он не помещался даже в большую лекцию, и я написал серию из более 70 статей. А когда в 2022 году делал курс в Новгородском университете для Лидеров России, то собрал статьи в книгу «Менеджмент цифрового мира».

А в этом году меня позвали прочитать курс «Эффективная организация команды» по современному менеджменту для Бюро 1440, инженерной компании, которая создает низкоорбитальную спутниковую систему. И на курсе были не только студенты, но и действующие инженеры и руководители. Курс включал не только материалы книги, там был обзор классического менеджмента, а также модели soft skills, которые легли в основу моей книги «Инженерная модель личности», вышедшей в этом году. Для руководителей слушать было не обязательно, и для меня очень важно, что многие слушали его до конца, все 8 лекций. Слушатели говорили, что много материала было им известно из других курсов, но мой показал комплексную картину, взаимосвязь разных тем, и это дало новый уровень понимания.

Вот отзыв Анастасии Храмцовой, менеджера по развитию академических программ:

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

Как заказчик, я осталась довольна как работой с Максимом, так и его подходом к подготовке материалов. Слушая лекции, понимала, как переворачивается в голове то, что было когда-то усвоено мной и дополняется новыми знаниями. Хочу отметить глубину знаний Максима и практического опыта. В курсе были освещены многие темы управления, мягких навыков и командообразования:
* история ИТ-менеджмента;
* причины смены способов ведения проектов в ИТ;
* отличие Agile-мышления от классики.
* спиральная динамика, как модель работы с культурой и ценностями.
* промышленные революции и волны Тоффлера;
* подходы классического менеджмента
* система Тойоты, бережливое производство;
* промышленный lean, подход «Шесть сигм»;
* цифровые двойники
* модели организаций и команд в них;
* методология Agile
* сравнение Agile с методами классического подхода
* Agile-трансформация – кейсы и способы
* самоуправляемые команды и компании
* инженерная модель личности.
Максим охватил все факты, показав, как все связано и как все развивалось во времени, а также обратив внимание слушателей на все аспекты формирования команд через спиральную динамику.

Так что если кому-то интересно - обращайтесь!

Прочитал книгу Саши Бындю "Антихрупкость в ИТ", пару лет она лежала у меня в очереди. Это - очень полезная книга для тех, кто хочет и кому нужно разобраться в устройстве современных ИТ-проектов. А нужно это тем руководителям, которые выступают как заказчики ИТ-проектов или хотят завести у себя ИТ-разработку. Не факт, что они хотят в этом разбираться, но тогда это превращается в игру "повезет - не повезет", которая знакома почти всем, кто искал себе бригаду для ремонта или, что серьезнее, психолога или врача в не очевидном случае. Это не значит, что прочитав книгу, и разобравшись в ней ты сам сможешь делать ИТ-проекты. Но ты сможешь вести квалифицированный диалог с ИТ. При этом в книге - множество ссылок для тех, кто захочет разобраться глубже в конкретных вопросах. В книге описано множество граблей ведения ИТ-проектов и современные методы. Дальше - читайте у меня на сайте https://mtsepkov.org/ByndyuAntichrupkost, рецензия получилась довольно длинная. А от книги я получил истинное удовольствие, жалею, что так долго до нее добирался.

Завтра вечером, 10.12 в 19:00 я буду рассказывать о своей книге «Инженерная модель личности» на вебинаре в Книжном клубе проектной асcоциации. Это бесплатно, но только для членов ассоциации, в нее предварительно надо будет вступить. Ассоциация регулярно проводит различные мероприятия, книжный клуб - одно из них, подробности можно посмотреть на сайте.

Вслед за #Teamlead прошел #Highload. 3500 offline участников, 15+ треков интересных выступлений и много общения, так что публиковать заметки в ходе конференции не получалось. Собрал и публикую отчет https://mtsepkov.org/Highload-2024. Отмечу, что презентации всех докладов уже доступны на сайте конференции, надо зайти в конкретный доклад, так что подробности можно смотреть.

Самым интересным для меня докладом было выступление Наиль Миннахметов из МТС про архитектуру: это очень редкий случай, когда большая компания отдает решения по архитектуре на уровень команд, выстраивая федеративную конструкцию. А в целом в отчет попали следующие доклады.
* Наиль Миннахметов из МТС. Артефакты архитектуры. Какие, зачем и как их организовать
* Владимир Кочетков. Программировать как хакер, защищать — как программист
* Алексей Мерсон (Т-Банк). Надежность на масштабе в 45 млн клиентов — инструменты и практики цифрового банка
* Алексей Николаевский. Транзакционная работа с топиками. Архитектура и сравнение решений в Apache Kafka и YDB
* Григорий Петров. Красота кода глазами нейрофизиолога-программиста
* Эмир Вильданов. Движок распределенного SQL в СУБД Picodata: принцип его работы, принятые архитектурные решения и сравнение с аналогами
* Евгений Харченко из Райффайзен Банк. Инженерная культура на масштабе: как развивать и оценивать практики
* Виталий Исаев. Как объединять данные из разных СУБД и делать это эффективно
* Павел Велихов. Стоимостный оптимизатор в YDB — как, зачем и почему?
* Ольга Лукьянова. Моментальная навигация по коду для любого коммита. А так можно было?
* Екатерина Лысенко. Финтех: причины моей ненависти
* Виталий Левченко. Грейды Go-разработчика, или Что отличает сеньора-гофера от остальных
* Алексей Обыскалов. Как работать с легаси, чтобы ни вы, ни проект не сгорели
* Максим Мирошниченко. Оптимизация конкурентных приложений: паттерны, сравнение и микроархитектура

По горячим следам сделал отчет с #Teamlead https://mtsepkov.org/TeamLead-2024-Msk, пока Highload не стер контекст докладов. Часть заметок я выкладывал в ходе конференции, но доклады Александра Зизы и Анны Обуховой требуют осмысления, их выложить сразу не получилось. Всего в отчете 12 докладов. А еще общее наблюдение, в основном по TechTalks: крупные компании переходят от функциональных подразделений к кроссфункциональным командам, называя это продуктовым подходом, чтобы быть в тренде. Это прогресс, а вот зачем они строили функциональную организацию по учебникам 30-летней давности - неясно. Хотя психологически это понятно.

Вот список докладов в моем отчете.
* Максим Цепков. Системное мышление — нужно ли оно в IТ и зачем?
* Мария Щекочихина. Делаем происходящее с персоналом предсказуемым
* Альберт Степанцев. Законы Мерфи в повседневной работе руководителя
* Александра Брызгалова. Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас)
* Александр Зиза. 4 стратегии развития управленческого мастерства
* Анна Обухова. Как сделать так, чтобы команда наконец признала тебя лидом
* Рита Канис. Как убить всех зайцев: про управление знаниями исподтишка
* Алена Рыжкова. Как эффективно скоординировать работу 10 разношерстных команд.
* Алексей Макаров. Команда разработки за свой счет
* Евгений Идзиковский. Legacy-код в психике — как расплатиться со своим техдолгом
* Екатерина Шашкова. Как мы перестали говорить «у нас так принято» и стали описывать процесс разработки
* Руслан Карманов. Китайские методологии IT-управления

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

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

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

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

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

1б) Зоны ответственности. Тут могут быть всякие взгляды. Можно начать и пусть само сложится - но проявятся серые зоны, когда никто не ведет. Разработка и девопсы спорили, кто заполнит инвентори параметры, там 20 минут но каждый раз - а спорили 2 дня.

DevOps и сопровождение подключается сразу! А то они могут не принять готовую систему.

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

1в) Дорожная карта. Основной вектор развития, связи. Гант: дорожки с вехами. Важно не забыть работы по заказу оборудования и инфраструктурные работы - может быть долго. Не забыть не функциональные блоки - безопасность, надежность.

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

2) Процессы, которые позволят синхронизироваться, выявлять проблемы и решать. Точка коммуникации.

2а) Основное - статус проекта. 30 минут 2-4 раза в неделю. Прогресс движения к ближайшей контрольной точки.
И открытый микрофон после основной повестки. И надо явно драйвить: какие вопросы, замечания, проблемы.

2б) Рабочие группы по выявленным проблемам. На статусе это не эффективно. Сбор вариантов, проработка и итог. 30-60 минут 2-3 раза в день. Но недолго. Пример. Вендор задержал поставку, которая влияла на старт пилота. И нужен был план-Б, чтобы запустить функционал пилота.

2в) Чат в мессенджере. 20-30 сообщений в дел. Модерация, во-время предложить обсудить на встрече и написать результат.

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

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

Ее принципы: Открытость, Поддержка и Лидерство. И были слайды, где для каждого были паттерны и антипаттерны.

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

Открытость с руководством. Если пошли задержки - надо сразу говорить. Во-первых, они компетентны и заинтересованы и помогут. Во-вторых открытость рождает доверие, а оно критично при факапах.

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

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

В целом получился легкий фреймворк. На мой взгляд, очень напоминающий то адаптивное управление проектами, которое продвигает Павел Алферов из своего опыта, сократив классику до необходимого минимума. Кстати, как источники, где можно посмотреть, Алена указывала PMBOK - там есть все, можно брать элементы. И фреймворк p3.express/ru. А я бы дополнил этот список практиками Kanban и социократии. Вопреки распространенному мифу, Канбан - это не упрощенный скрам для потока задач, это способ работы и совершенствования методов организации работы. И там много различных практик, а также технология определения узких мест в ходе проекта. А социократия - еще один подход, который можно использовать как источник для полезных практик. И организация рабочих групп для решения вопросов, которую Алена описала - одна из них. Ее, кстати, можно применять для решения проблем, которые выявили ретро, только там время работы больше, был интересный доклад Ростелекома об этом.

Слайды моего доклада про системное мышление опубликованы на моем сайте https://mtsepkov.org/SysThinkTeamlead Там же ссылки на предыдущие доклады по теме, для которых есть записи.

#Teamlead Александра Брызгалова (bryzgalova.ru) Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас). Основной тезис доклада: если ваше замечательное решение отвергается, то причина обычно не в том, что люди глупы или ленивы, или преследуют какие-то личные цели. Обычно есть какие-то аспекты, которые в своем решении вы не учли: оно не решает проблемы, или решает не актуальную проблему, или создает дополнительный урон или риски, которые вы не видите. И надо расширить рамку рассуждения, понять логику тех, кого вы считаете противниками, найти общую цель - и тогда ситуация изменится. Инструмент, которым иллюстрированы кейсы - грозовая туча из TOC (Theory of Constraints) Голдратта. Но это - лишь один элемент теории. и, по сути, он дал понятную схематизацию, визуальный ряд.

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

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

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

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

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

4. Глупый начальник. Надо автоматизировать тестирование, а начальник не дает. Я хочу - потому что хочу повысить качество. А он - просто не хочет напрягаться. А реально: компания получала деньги за время, которая потратила. Автоматизация - уменьшение выручки. А затраты - меньше. Повышение качества тестирование - не факт, что повысит выручку. И надо менять модель.

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

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

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

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

Но увольнять можно. Даже хороших людей - они могут не соответствовать тому, что нужно.

#Teamlead Альберт Степанцев из Спринт-Ф. Законы Мерфи в повседневной работе руководителя. Это был рассказ о разнообразных рисках и способах работы с ними. В нем была очень интересная техника: три дня выхода на работу, чтобы проверить что сотрудник сработается с командой. Оплачиваемых, по договору.

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

Альберт - CTO напрокат, партнер по выстраиванию ИТ и его опыт работы включает много компаний. Доклад структурирован на три части: Люди, инструменты и система.

Люди. Мы нанимаем, работаем, увольняем.

Риски найма: найм неподходящего, завышенные ожидания; риск несовместимости; риск долгого (дорогого) найма.

Как парировать риски найма.
* Нанимаем первого подходящего, время - дорого
* Сократите плечо найма - сколько собеседований. Чем выше этапов - тем выше вероятность ошибки. У него 15 минут HR на общую адекватность. А потом - сразу на себя, и вместо идеального собеседования, где тесты, lifecoding и прочее - показывает экран с реальными задачами готов или нет. Затем - код проекта - совместно почитать. И тоже достаточно 15 минут.
* Если кажется - значит не кажется: если на каком-то этапе беседы показалось, что что-то не так - оно не так. Не игнорируйте подсказки подсознания.

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

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

На найме - показать экран с правилами, разными: как ветки делать, что ответ должен быть дан, если задан вопрос.

Второй закон Чизхолма: если дела идут хорошо - что-то случится в ближайщем будущем.
Закон Падлера: Все, что хорошо начинается - кончается плохо, а что начинается плохо - кончается еще хуже.

Рано или поздно все увольняются. Крепостное право отменено. Риски: неожиданное увольнение, отказ увольняться, негатив и так далее.

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

Техника три дня: приходи на три дня, возьми больничный в прежнем месте, а мы договор подпишем
1. Доступ получил, проект поднял
2. Учебная задача
3. Реальная задача, но короткая
Позволяет 90% рисков найма и увольнения снимает. И можно в любой момент разорвать.

2. Инструменты. Техника, офис, софт для работы. Людям надо дать инструменты. Инструменты выбирают люди - а люди ошибаются.

Проблемы с инструментами.
* Инструмент выглядит хорошо, но не решает задачи. gitlab вместо CI/CD или NetBeans вместо IDE
* Решает задачи, но никто его не знает. Как ExtJS
* Решает задачи, но крадет время. Кто-то вручную проталкивает задачи по gitflow вместо скриптов
* Известен но никому не нужен
* Неудобен до неприятия. Как Кибана для тестировщиков

Инструменты - экономят время. А время - деньги. Работа, которая делается зря - muda из Канбан. Инструменты должны время сокращать, а не красть.

Про инструменты.
* Запрещайте физически (merge в мастер)
* Автоматизация, которая экономит время
* Известное - лучше неизвестного
* Нужное - лучше известного

3. Работайте с надежностью системы. Люди - связи - процессы - изменение процессов во времени.

Проблема - степенная функция ненадежности. Надежность - что элемент работает. Например, что сотрудник приходит на работу. Если n элементов, то общая надежность - степенная функция от надежности.

Ракета М1 - 30 двигателей с надежностью 95% на первой ступени. Для неотработанной техники - прекрасно. Но общая надежность - 21%, только один из 5 - успешен. Запускали 4 раза и она 4 раза взорвалась.

10 человек, каждый из 20 рабочих дней приходит 19. Какова вероятность, что будет день, когда придут все - не высокая.

Связи. Ненадежность передачи информации, испорченный телефон.

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

Почему 5? Потому что в зоне произвольного внимания 7 элементов: ты, руководитель и 5 подчиненных.

Из ответов на вопросы.
* Проверка совместимости - еще до техскилов. Если он не на одной волне - не поработаешь. Способ - разговор, вживую, голосом, можно онлайн. Последний фильмы, книга, были ли американцы на Луне.
* Тимлиды и техлиды - там 3 дня не работает, испытательный срок. И там нужна обратная связь от команды, вплоть до ежедневной.
* Многоступенчатые системы найма - ломать. Даже в крупной компании. Это дисфункция. У него был опыт. Пришел в компанию - Кадровое агентство, Свои, Тхлид, Руководитель. Сказал "давайте рискнем, выводите на меня" - получилось.
* Техника три дня - это для тех, кого готовы взять. И это НЕ дороже, проверка совместимости эффективна, а затраты на РК и другие проверки - сложнее. 3 дня дешевле 20% дохода, который хочет кадровое агентство.
* Про увольнение - показываешь в 20 пунктах, среди которых как уйти в отпуск, получить больничный, уволится. Это нормально.
* Вопрос. ПСБ, служба безопасности - нельзя показывать код и применять 3 дня. Что делать? Ответ. Случаи есть, работает с банками.
Право зеркального NDA - может распространить на кандидата. И он на три дня подписывает договор. Код - несекретный, он в любом проекте есть. Еще внутренние проекты - там часто те же технологии.

#Teamlead Мария Щекочихина из CUSTIS. Делаем происходящее с персоналом предсказуемым. Это рассказ о том, что надо технически делать, чтобы происходящее на масштабе 10 команд и 100+ человек было предсказуемым. Если кратко - то надо сценировать будущее, траектории развития сотрудников и других изменений - и ты оказываешься готов к различным вариантам развития ситуации. Для этого есть два инструмента: карта команд и работа с рисками, и еще - фидбэчница, фиксация истории взаимодействия. Но рассказ был построен не от инструментов, а от кейсов, инструменты проявлялись как средство, помогающее с этими кейсами разбираться. Потому что инструмент - универсален, как база знаний, применять его можно по-разному. Дальше - краткий конспект.
* Кейс-1. Ваня приходит с офером x2. Столько платить не можем, а он нужен. Но не можем. И человек ушел. Что делать? Надо планировать рост ключевых сотрудников заранее. На замену ведущим готовить людей из middle.
* Кейс-2. Есть люди, которые мониторят рынок. И спрашивают "а почему моя зарплата не соответствует". Надо следить самим за рынком зарплат. При этом вилки и медианы надо адаптировать на ситуацию в компании - у всех разные возможности. А дальше держим в зеленой зоне в районе медианы. Если границы - сложно работать: сотрудник на низкой границе придет с офером с большим повышением, и удержать будет сложно, а для сотрудника на верхней границы нет возможностей роста и это - риск, он уйдет в другую команду и компанию на другую позицию.
* Кейс-3. Растим мидла Васю на позицию ведущего. Индивидуальный план развития: что мы ожидаем для роста, и сроки выхода на позицию, это не пара месяцев. А вам как руководителю - надо обеспечить позицию ведущего и бюджет для нее. И встречи. Раз в пару недель - прогресс роста.
* Кейс-4. Сотрудник не соответствует позиции, но не признает. Такого не был, это всего один раз, это не говорили. Важно - фиксировать все, что было на ревью. Что вы говорили и вам отвечали. Не хочу быть лидом, а проводить собеседования - хочу. Дальше мы можем поднимать историю во взаимодействии.
* Кейс-5. Аналитик переросла позицию. И внутри команды не решается. Нужен вышестоящий руководитель или HR. Есть ли подходящая позиция в соседнй команде? Если есть - идет туда. Но надо еще подготовить замену у себя - из соседней команды. Это надо делать заранее, но сотрудники в случае понятных перспектив обычно лояльно относятся к ситуации. Чтобы все это видеть - нужны карты персонала. Несколько команд, траектории и проблемы. Ведут в Miro, в презентации был пример.
* Кейс-6. В команде только один с конкретной специализацией. А второго нанять нельзя - нет денег и задач для него. Есть два варианта: (а) аналогичный специалист в другой команде и страховка друг друга и (б) рост кого-то во вторую специализацию. Помогают увидеть карты персонала. Они показывают дизайн команды: грейды внутри специализации и соотношение разных специализаций - балансировка мощности. Из карты видно, где проблемы - провалы и отсутствие возможности роста.
* Кейс-7. Два разработчика мидл активно развиваются. И у вас цепочка middle - senior - техлид. Все хорошо. Но приходит второй - а у вас нет третьей позиции senior, у вас она вообще одна. Надо заранее понимать - кого двигать. Карта рисков. Сотрудники: ценность и возможность развития. И Риски: как избегать и что делать в случае риска. Excel с раскраской.
* Кейс-8. 2022: 2 техлида и один ведущий ведущий уезжают, при чем ведущий страховал одного техлида. Смотрим на карту. Ищем других ведущих - не нашли. И открыла вакансию с перспективой роста, которую проговаривала на входе. За 2-3 месяца получилось подготовиться.
* Кейс-9. Тимлид Аня просит срочно согласовать вакансию аналитика в команду. Тут надо остановиться и подумать: много работы навсегда или это завал на 3 месяца? Должен быть фронт на год. А еще: есть ограничения. И нет ли кого-то, кто может получить новую компетенцию.

Кейсы 10-14.
* Больничные на 2-3 месяца. Редко, но внезапно. Надо заранее планировать замены ключевых. А если вышестоящий? Она в том году выпала, тимлиды справились за счет инструментов на горизонтальной связи..
* Многодетный мать/отец вышел из декрета и к работе есть вопросы. Надо восстанавливать - давать автономные задачи, чтобы он мог организовывать работу
* Тяжелые проблемы в семье - тоже нужно дать возможность восстановиться, на обособленных задачах. Но надо договориться про срок.
* Декрет ключевой сотрудницы. Он прост - потому что известно заранее. Инструменты помогут.
* Кланы: привел друга, хантит из соседнего подразделения, пришла команда, друзья тимлида. (а) группирующий риск - как привел - так и уведет. (б) увод между командами ухудшает отношения тимлидов.

Рисков - много, список будет дополняться. В презе - список. Работа с рисками. Вероятность наступления и тяжесть последствий. низкий-средний-тяжелый.
* Тяжелый-вероятный: архитектор, которого год искали - не проходит испытательный срок
* Легкий-вероятный: джун не проходит - не так страшно.
* маловероятный-тяжелый: Недовольный сотрудник и пишет гневное прощальное письмо

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

Основа работы Performance review: есть цикличность и сроки. Раз в полгода - зависит от динамики команды.
* ИПР стыкованы с performance review.
* Обратная связь после performance. И обязательно слушаем его ответ.
* Регулярные 1:1 - по ИПР.
* Планирование. годовое: зарплаты, должности, соотносим с рынком. И дальше по мере изменений - актуализируем.
* И не забываем все записывать. Это не только вам, но и тому, кто придет на смену. Преемственность в руководстве.

Что это дает? Для сотрудника: понятные правила, ИПР, нестандартная траектория - не замкнут в команде. Для тимлида - картинка сверху, проблемные места и планы по ним.

Набор инструментов - для 50+ Для 5-10 можно использовать отдельные инструменты. Важно - работа с рисками, сценарии "а что если". Могут помочь: руководитель и HR (они неплохо сценируют). И обязательно все записывать!

В конце недели прошла осенняя #AnalystDays. На ней было очень сильных докладов, и я желаю организаторам и ПК сохранить этот уровень. Я публиковал заметки в ходе конференции и сейчас собрал их в отчет https://mtsepkov.org/AnalystDays-2024b, дополнив еще несколькими докладами, заметки с которых сразу опубликовать не успел. А уже завтра начинается #Teamlead, в котором я тоже участвую и выступаю.

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

Был еще пятый аспект, но я не записал. Над будет посмотреть презентацию и запись...

#AnalystDays Григорий Печенкин. Пять граней мышления аналитика. Кто такое - хороший аналитик? Это человек с особым типом мышления, у которого есть 5 аспектов. Доклад был о них, на кейсе работы с обобщенным университетом по внедрению системы индивидуальных образовательных траекторий студентов. На первой встрече присутствуют трое: Проректор, который хочет модель, где студенты сами выбирают что изучать; руководитель учетно-методического отдела, который говорит, что для этого надо совсем немного: зафиксировать индивидуальные планы и сделать выбор нагрузки; и главный от ИТ, который поддерживает и говорит, что все данные есть - остались от предыдущего заказчика. Проректор слышит коллег и говорит: ОК, все поддерживают, договорились, работаем. Вопрос: о чем договорились, ко эти лица и что делать дальше? И тут нам как раз помогает способы мышления.

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

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

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

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

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

Фраза - гипотезы, что за ней - отсечение гипотез. Дальше - уточняющие вопросы. И верификация. Потом - вывод. Разветвляющийся конус гипотез, потом - схловываем. Главное - не пренебрегайте верификацией. В 9 из 10 проговорите то, что всем понятно. Но в 1 из 10 оказывается, что все неправильно.

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

3. Мир интересов. Его надо видеть.

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

Луковичная диаграмма. Рисуем стейкхолдеров по слоям подсистема-надсистема, и рисуем интересы.

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

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

#AnaystDays Галина Кореневская из ГК Самолет. Как мы изобрели Business and Data Flow Diagram. В 2022 Самолет решил стать лидером рынка за счет покупки крупной компании. Перед Ит поставили задачу поддержать быстрый переход компаний в однородное состояние, для чего сделать описание бизнес-процессов, которое бы соответствовало действительности. И разобраться с более, чем 350 ИТ-системами. Для описания бизнес-процессов надо выбрать нотацию. Они собрали цели бизнеса и ИТ. Бизнесу достаточно BPMN, а ИТ, помимо описания бизнес-процессов, хотели видеть его поддержку ИТ-системами, сущности и интеграцию систем. И они доработали BPMN-нотацию для описания. Рассказ был о доработках и о требованиях к описаниям.

* Нейминг - краткое наименование отражает смысл процесса. BPMN storm - тип asis/tobe. рейтинг качества, ниже 8 - надо переделать
* Границы. Старт - триггер, он должен быть подписан! А это - важно. И именно событие. Не "необходим пересмотр лимитов", а почему он необходим, например, увеличился объем работ
* Действия: гранулярность, кто выполняет и в какой системе. должен быть результат, роль которая выполняет и входящие параметры - документ. Могут быть подпроцессы.
* Стрелки - явные шлюзы, понимать: от процесса к документу - результат, от документа в задачу - параметр.
* Сущности делятся цифровые и нецифровые. Сканы - тоже нецифровые. Цифровые - с жизненным циклом. Если жизненный цикл в одной системе - фиолетовый, а много систем - зеленый. Клиент - живет в нескольких, задача - только в jira.
* Описания интеграций. Автоматическая задача передачи данных (шестеренка) - стрелка потока нужного цвета, входит в задачу принимающей системы, на выходе - ее документ. Зеленые стрелки - передача сущностей, а фиолетовая = передача событий, меняющих состояния документов. Например, из СРМ в учетную систему идут клиент и договор - зеленая стрелка, в учетной системе к договору привязываются платежи, они в CRM не отправляются, но после оплаты идет нотификация для смены состояния договора фиолетовой стрелкой.

Результаты.
* схемы стали объемнее. Увы.
* 40 воркшопов с бизнесом и ИТ. 15 команд, 4 ИТ-блока.
* Архитектор не участвует во встречах си бизнесом - егму оказывается достаточно документов.
* Повысили информативность для команд разработки
* Бизнес вовлекли в описание процессов. Они не отказывались от участия.

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

По концептуализации у Натальи был доклад на прошлой AnalystDays.

В конце было еще обсуждение с кейсами от участников.

#AnalystDays Наталья Семенова. Коллеги, мы тоже на одном языке говорим. Рассказ об известной всем аналитикам, и не только им, проблеме, что одни и те же слова в разных проектах могут означать совершенно разное. Потому что значение слов определяет контекст, к которому относится не только предметная область, но и способ ведения проекта, например, в заказной, продуктовой и inhouse-разработке работа с требованиями сильно отличается, хотя описывается одним и тем же выражением "собрать требования" или "выявить требования". Проблема как бы известна, но многие почему-то уверены, что это происходит потому, что люди неправильно употребляют слова. начинается холивар и апелляции к словарям. И это, в том числе, проявляется на собеседованиях: ответ отклоняют как неверный. А реально проблема в различии контекстов. Это даже в BABOK есть, правда очень кратко. И аналитик должен уметь распознавать контексты, и дальше вести коммуникацию с их учетом. А если подозревает, что контекст ему не знаком - то не стесняться спрашивать или иным образом уточнять значения слов. В докладе - много кейсов, а также подходы к прояснению контекста.

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

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

Мини сценка, разговор двух аналитиков:
- Стейкхолдеры у нас никакие...
- А ты что, ты же тоже стейкхолдер?
- Как я стейкхолдер. это же заказчики?

Собрать требования.
* Уточнить у ЛПР, поискать в документации требования и выявить заинтересованных лиц.
* Изучить бизнес-требования, запросить описания процессов, собрать у стейкхолдеров
* Сформировать гипотезы, сделать тестирование на фокус-группе, оценить стоимость и ROI.
Это различия внутренней, заказной и продуктовой разработки - требования собираем по-разному. И это - за рамками разговора.

Взаимодействие с командой.
* А что общаться, написал ТЗ и отдал, дальше на вопросы...
* У других - плотное взаимодействие: истории, DoD, сделал сторителлинг и так далее.
Разные методы работы команды. И отличия надо понимать, выяснять. что тебя ждет в проекте и действовать сообразно, или предлагать изменения, тоже осознанно.

А что делать до разработки?
* discovery и presale
* product market fit, анализ конкурентов
Тоже заказная и продуктовая разработка.

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

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

Как выявлять диференцииаторы контекста? Рассматривают 4 квадранта: Знать - Узнавать; Все просто - Все серьезно.
Все просто.
* Знаем: быстрая память и интуиция из насмотренности.
* Узнаем: спросить в разговоре или погуглить. Очень часто пытаемся угадать - а это неправильно.

Все серьезно.
* Надо знать про стандарты, метрики, модели и техники, инструменты, регламенты и заглядывать туда. по необходимости. Быстрая проверка через стандарты помогает.
* Модель IGOE: inputs - guides (как будем делать) - ouputs - enablers (что поможет выполнить).
* Кастомные модель 6 перспектив: люди, процессы, время, ресурсы, инструменты, скоуп. Применялась в EPAM, она делала доклад, можно посмотреть.

#AnalystDays Вера Бонарева из Сбербанк. Преодоление сложностей в интеллектуальном распознавании документов: инновационные подходы и роль LLM. Это блиц-рассказ о том, как усложнялась по мере реализации задача распознования документов, появлялись все новые кейсы и способы распознавания.
* Первоначально задача выглядела просто: приходят сканы и документы разных типов (xml, excel, word, pdf) - и надо опознать тип. Полный автомат, документы передает внешний сервис. ему же оправляют ответ. Настроили распознавание текста с изображений, парсеры xml и excel, систему правил, которая применяется после распознавания скана или парсера.
* Быстро выяснилось, что приходят архивы с большим количеством файлов, надо распаковать и каждый обрабатывать отдельно.
* Затем - что в архиве может приходить потоковый скан на сотни страниц, который надо разбить на отдельные документы.
* Затем - добавили верификацию пользователями того, что распозналось плохо или неуверенно - у системы появился GUI, а с документом приходят данные - кто должен подтвердить. Верификаторы - дефицитный ресурс, в пике потока получается задержка до пары дней, поэтому если в архиве документы, которые распознаются хорошо и которые плохо - то статус надо вести не у архива в целом. а по отдельным документам в нем. И еще специальные меры, чтобы документ, ожидающий верификации, не был сброшен из очереди по сроку.
* Из паспортов и некоторых других документов надо вытаскивать атрибуты - ФИО, серия, номер и так далее, для этого подключили ML, с паспортами и другими документами фиксированных форматов она справляется.
* Из договоров ML атрибуты вытаскивает плохо, там большие тексты - про них спрашивают LLM, GigaQuery и ответ сравнивают с тем, что дала система правил.
* Поскольку верификация - избирательная, то ошибки проскакивают, и пользователь может отправить на повторное распознавание, которое всегда с верификацией, даже для простых документов.
Такое вот усложнение системы в ходе разработки и эксплуатации - типичная история.

Как обычно, слайды моего доклада - сразу на моем сайте https://mtsepkov.org/SoftSkills-AD-2024

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

Для сокращения MVP - делайте быстро и малыми силами. Не 30 человек год, а три за месяц.

Шаг 5. Во-время останавливаемся. Discovery - продуктовая гипотеза. Весь продуктовый цикл не закрываете. Там маркетринг, юнит-экономика и много чего.

И в заключении. Иногда discovery - крик бизнеса о помощи, не игнорируйте. Бизнес-аналитик - может сделать.

#AnalystDays Ольга Кулапина из Red Collar. Куда приводит Discovery. Как работать с неопределенностью. Доклад был о том, как подружить продуктовые практики и заказную разработку. От аналитиков продуктового мышления ожидают в разных ситуациях, например когда компания делает pet-проект или когда средний оффлайн выходит в онлайн, или в других подобных случаях. Они обращаются к тем аналитикам, которые есть. Понятно, что на входе они под такую работу не подписывались, но на практике часто нет выбора. А еще это интересная задача. И, наконец, многое тут можно сделать, используя знакомые практики аналитика. Да, полностью задачи продукта ты не решишь, маркетринг, продвижение и unit-экономика останется за рамками, но провести discovery, подготовить первый шаг - вполне.

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

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

Шаг 2. Ищем знакомое в незнакомом, перешиваем и развиваем навыки. Cust Dev похож на бриф, исследуем конкурентов - как заказчика, на открытых данных, объемы рынка - по открытым данным конкурентов.

Cust Dev.
* Не знаете откуда взять аудиторию? Запросить у заказчика - нормально. Еще соцсети
* Не знаете сегментирование - JTBT. Поймите, какую работу выполняет продукт, напрмиер, йогурт с высоким содержанеим белка - когда его применяют. И это дает аудиторию и вопросу к ней - про
* Какую методику выбрать? Чем больше неопределенности - качественная, подробности - количественная.
* Интервью. Короткие - люди вам не должны. Но задавайте открытые вопросы. Не про ваши гипотезы, а про то, как они действуют. Узнаете новое. Но это - пользователям, а заказчику - гипотезы и сценарии, иначе он будет увеличивать MVP.

Исследование конкурентов.
Поле конкурентов и ответ - стоит ли лезть на это поле.
Фреймворков много. Ее любимый - магический квадрант Гартнера, Фичи и UX, кружок - объем рынка.

Объемы рынка. Зачем? Если пришли с идеей, а денег нет - люди не привыкли платить - то лучше не лезть, это трудно.
Фреймворков много, наиболее легкий - TAM-SAM-SOM.

Все эти фреймворки в пределе сводится к здравому смыслу и business view.

Неопределенности стало меньше, но появился хаос данных.

Шаг 3. Гипотезы - проводник через хаос данных. Научиться мыслить гипотезами. Верхнеуровневые рамочные - цифровые - улучшение продукта. Рамка - идея, например, всем будет полезен магазин готовых маршрутов. Цифровые про MVP, проверка продукта.

Шаг 4. MVP. Определились с составом продукта, теперь его надо обрезать. Все кивают на концепцию, но как только реально доходит до урезания - не режут. Не переживайте, что первый продукт бедный - будет возможность дополнить. HADI цикл. И есть лайфхак: у вас будет не бедный продукт, а сфокусированный или сконцентрированный, смена термина многое меняет в восприятии.

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

Размер декомпозиции. 5 историй в спринт. Ему такая цифра нравится. Реально идем итеративно от какого-то старта.

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

Все про MVP знают. Но не делат. Оправдания разные.
* Все равно релизить, зачем откладывать;
* Все на бэк, можем поставлять раз в месяц - про месяц правда, но можем или хотим
* Лень - когнитивная скупость.
* Еще ответ: наша ситуация уникальна.
Все это отмазки. И что будут слишком маленькая история, которая не приносит ценности - тоже, так получается редко.

Так что делите истории, чтобы они были ценными и маленькими. User story - микропроект, который можно сдать заказчику.

#AnalystDays Дмитрий Блинов, DBlinov.com. Декомпозируем истории и создаем User story map для фитнес-аппа. Хороший доклад о том, как декомпозировать и резать скоуп для MVP на примере кейса создания софта для фитнес-клуба. Agile и Scrum основаны на идее быстрой регулярной поставки инкремента ценности. Возможность поставки означает, что задача должна быть готова полностью, а не на 99%. В то время как практика ответа на вопрос - задача готова почти: сделал, но не смержил; протетсировал, но не везде. Мы работаем среди умных людей, и странно, если не найдет причину. Важно договориться: готова - это 100%.

Если наша задача - оставлять инкремент, то декомпозиция по слоям архитектуры или фазам разработки не подходит. Бэк без UI или требования без разработки никому не нужны. И был придуман иной способ - user story, рассказ о работе пользователя, который достигает какой-то цели. Придумал Кен Бек в XP. Основные книги: Майк Кон и Джеф Паттон. Главная фишка story - ценность, это и делает ее инкрементом. Появились шаблоны, в начале 2000-х. Потом ценность вперед переставили. История должна быть INVEST. Оцениваемая и ценная.

Рассказ - длинный, это эпик, а дальше мы его делим на кусочки и в user story map приоритизируем. Придумал Джеф Паттон: 2004 статья, 2007 термин, 2014 в книге. Кстати, в 2013 я был на тренинге Джефа Паттона, и он очень интересно рассказывал про user story map, у меня в блоге есть конспект.

В докладе - сквозной кейс: хочу открыть фитнес-клуб DomFit. QR-код на турникете, найти и записаться, оплатить на тренировку и многое другое. В списки появляются объекты - о клубе, о тренировке, о тренерах, профиль пользователя. Если так понятнее - делайте такие истории. Но помните, что хранение объектов не имеет ценности без их использования для других историй.

Расположили каркас в строку. Что делить? То, что не пролезает в спринт, и то, что включает несоклько приоритетов. Очень часто части истории имеют разную важность. Задача Product Owner - поделить истории, чобы можно было оставить наверху ценные части. Делим vertical valuable visible. Не всегда получается вертикально, они не будут ровными кусками - где-то UI больше, где-то - бэк. Но обязательно что-то в UI - история должна быть видима. В кейсе выделили: регистрация, пропуск по QR, записаться и оплатить.

Регистрация - куча вариантов как залогиниться. И для каждого - варианты, например через почту - много способов. Альтернативы по сценариям и данным. И надо найти 1-2 самого ценного вариант, а остальные - убрать. Опускаем вниз на user story map. Личный профиль. Делим: атрибуты объектов, типы, справочники, интеграция. В MVP берем малое: телефон, почта, QR.

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

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

Итого - что получилось из user story. суммарная визуализация, и в рассказе было 9 способов декомпозиции. Есть еще.
* Деление по глубине вывода данных - для банка увидеть остаток, операции недели, важные атрибуты и т.п.
* Админка и настройки - потом!
* Элементы управления: сложные - потом. Если нет разницы текст или календарь - сделайте календарь, если его сложнее - текст. А вообще с календарем - беда, когда надо скроллить до своего года рождения - сильно огорчаешься.
* UI. Внешний софт - простой функционал с красивым GUI, если внутренний - наоборот, просто бухгалтера хотят черные буквы на белом фоне, а не полутона.
* Производительность - можно позднее, если у вас не будет ее сразу. Но важно: когда поделили, то остаются обе истории, медленная и быстрая, а не забыли, что сделали медленно.

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

#AnalystDays Татьяна Половинкина из НЕОФЛЕКС. В чем смысл цели? Офигенно крутой доклад про работу с целеполаганием по X-матрице Стратегия - Тактика - Задачи (гипотезы) - Результаты. Матрица - потому что у тебя не обычное дерево, ты на каждом шаге заполняешь взаимную зависимость и отсекаешь то, что оказывается малозначимым. По каждому такту - лайфхаки, и иллюстрация сквозным примером.

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

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

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

Тактика - это вектор действия в направлении стратегической цели. Лайфхаки тактики.
* Проверка фокусировки. Хочу 1 млн прибыли - а что делать будешь сейчас? - буду путешествовать. Стоп. Или зарабатывать, или путешествовать. Ну или покажи связь.
* Тактика "от" и "к" - Чего хотите достигнуть и что сейчас мешает.
* Гибкость. Мелкие задачи, появляются новые возможности и ограничения. Нужен ли этот бой сейчас?

Лайфхаки задач.
* Цель - не средство. Не прочитать книгу, а стать книголюбом, или изучить и применять знания. Изучить курс - не цель.
* Помните, что задача - это гипотеза! Работайте по HADI циклу проверки гипотез
* Эффект Икеи или Брейнсторм. Когда хотите достичь цели - позвольте людям набросать гипотез, не давайте пути сами. Когда делаешь мебель своими руками - она чудесна. Так и с любыми путями.
* Людей, которые хотят знать алгоритмы, алгоритмы (ИИ) заменят в первую очередь.

Матрица: какие идеи на какие тактические вектора движения работают. Ставят баллы. И это отсекает гипотезы, которые в тактику не укладываются.

Лайфхаки результата.
* Проверка фокусировки. Метрики, которые мы будем измерять. Основанные на ценности, целе, результате, а не на исполнении задач. Но задачи тоже меряем - это оценивает затраченные ресурсы.
* Умение ошибаться. Это как отладка кода - мы же ошибаемся, и это не страшно. Так и со всем остальным. Надо извлекать выводы.

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

Кейс, на котором дальше был разбор - ее стратегическая цель. Была 2 года назад - максимально расширить компетенцию SQL у сотрудников - они data-аналитики. У нее: изучение навыка, применение навыка, трансляция навыка (это обязательно, синхронизация с другими). Шаги задач и результатов - в презентации были матрицы идей с конкретными баллами. Картинка оценки часто удивляла, оказывалось, что гипотеза, которая кажется перспективной, набирала меньше всего.

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

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

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

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

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

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

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

Собрал и опубликовал на сайте отчет по #MergoConf https://mtsepkov.org/MergeConf-2024-Msk Конференция впервые прошла в Москве. Два дня, 8 потоков, и среди докладов доклады были очень содержательные, конспект которых не поместился один комментарий. Я сам тоже выступал. А записей конференции не будет, так что пропущенные доклады пропали безвозвратно. Так что читайте мой конспект, хотя докладов в нем мало. А организаторам хочу пожелать успехов.

Публикую отчет по #EnterpriseAgile - https://mtsepkov.org/AgileEnterprise-2024 Общее впечатление от конференции таково: у крупных компаний, которые хотят использовать Agile-методы всерьез на масштабах компании - получается это делать, технологии набрали зрелость. Используется OKR для координации по целям и фокусировки на развитии, а из SAFe выделилось ядро полезное ядро: PI Planing для синхронизации и получения реалистичных планов на большом масштабе, до 10 тысяч человек и более, и value stream train - средство управление потоками создания ценности с трассировкой до стратегических целей вместо обычного управления потоками задач, где выполнение задачи еще не гарантирует получения ценности для компании и потребителя. И в целом получается, что компания - не механистичный исполнительный механизм, а конструкция со свободными элементами, обладающими собственной волей, но действующими скоординировано.

Отчет включает опубликованное в ходе конференции и три доклада, конспекты которых я опубликовать не успел. Это - меньше половины докладов конференции, так как параллельно шло два потока, а на части слотов нетворкинг я предпочел докладам. Вот список.
* Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только).
* Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка.
* Анна Аверьянова из Робофинанс. Как OKR помог закрыть бизнес!
* Марина Кубанина. Технологии Доверия (ex-PwC). Про лоскутные одеяла, развод и Agile.
* Сергей Паршиков. Оценка производительности команды в корпоративной среде
* Сергей Лебедев и Максим Матвеев из YADRO. Тернистый путь к звездам: как мышление меняет компанию
* Евгений Михин из Яндекса. Continuous budgeting в портфельном управлении Яндекса
* Алексей Грабарник из Газпромбанка. Lean-управление портфелем стримов в Газпромбанке

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

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

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

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

Что входит в квартальную оценку?
* Продуктовые и бизнес-метрики - это всем понятно
* Голос клиента - это тоже продуктовая, но это не предвзятый взгляд клиента. Клиенты ставят звездочки за функционал, и это транслируются.
* Эффективность производство - на прошлой конференции был отдельный доклад и в презентации есть QR код со ссылками.
* eNPS: Критика - нейтральное - промоутеры. Формула: Промоутеры - Критика.
* Visibility - публичные выступления. Когда ты подталкиваешь выступать - ты подталкиваешь к выбору интересных задач. А еще - писать в корпоративный час о запуске фич - внутренняя видимость. Это реально поменяло словарь - когда пишешь новости сам осознаешь что сделал, позиционируешь в других терминах.

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

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

#EnterpriseAgile Анастасия Заруднева из Райффайзен Банк. Continuous Big Systems Replacement. Банк меняет основную систему, которая обрабатывает 15м операций в день, над ней работает 250 команд. Проект идет три года, они в середине пути. При этом существенная часть нового в параллельной эксплуатации, а часть уже ведут в новых системах, так что есть уверенность в успехе. Важно: новую систему пишут те же команды, что и развивают старые, потому что надолго вырвать команды из создания реально работающего продукта противоречит agile-подходу. Дополнительно за счет этого команды понимают продукт, знают алгоритмику.

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

В направлении 3 стрима, 40 продуктов, примерно 15 в стриме. Пример продукта - депозиты ФЛ. На стрим - менеджер стрима, бизнес-аналитик и команды, которые пишут микросервисы. Переводят 4 продукта одновременно. Продукт-менеджеры сами решают, насоклько они проводят реинжиниринг при переносе в новую систему, будут ли они переписывать логику при переходе. Может быть выделена фича-команда или задачи помещены в общий бэклог. С бизнесом ежеквартально согласуется список продуктов, которые переносятся.

На слайде была архитектура: каналы -> продуктовая логика -> core -> главная книга -> распространение данных -> потребители (риски, отчетность и др.) Фича-команда - продуктовая умеет детать доработки для всех командах. Может параллельно работать старая и новая продуктовая логика. Новая главная книга работает параллельно со старой, но мастер пока старая.

Как управлять таким переносом?
* Делать на маленькие шаги
* Исследовать через поставку
* Ставить целью спринта приближение к target-архитектуре
* Находить возможность parallel run
* Работать с потребителем данных

#EnterpriseAgile Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка. Одна из существенных черт Agile-методов - прозрачность. И рассказ был о том, как обеспечивают прозрачность работы ИТ для топов банка через запуск value stream. На входе была ситуация, когда руководство неплохо представляет, что происходит в проектах, такая культура в банке есть, но там задействована примерна 1/3 ИТ. А 2/3 были через пулы распределены по подразделениям бизнеса и чем именно они занимаются, руководству не понятно. Более того, как выяснилось в ходе проекта, бизнесу тоже было не понятно, бизнес с ИТ не общался, и обе стороны имели не высокое мнение о другом, как это часто бывает. А еще бизнес с удивлением выяснял суммы, в которые ему обходится ИТ-пул - бухгалтерия это распределяла на общие расходы, а в управленческой отчетности это не светили.

Средство решения - реорганизация работы ИТ в value stream? как это описано в SAFe, в которых идет квартальное планирование от задач бизнеса. Каждый стрим - 10-15 команд. За 2024 запустили 13 value stream, на следующий год - еще столько же. Запуск - это определение границ, целей и задачи value stream, затем структурирование внутри. После этого идут циклы квартального планирования и реализации, и по результатам - актуализация целей и задач на следующий год.

Получили:
* Структурирование работ, и людей по направлением
* У всех - единая мотивация
* Управление достижением цели
* value stream - продуктовые, операционные, процессные.
* Связь между целями и результатами деятельности. Воронка продаж, экономика
* Метрики - cycle time, ttm, радар agile-здоровья и оценка зрелости

#EnterpriseAgile Марина Кубанина. Технологии Доверия (ex-PwC). Про лоскутные одеяла, развод и Agile. В PwC большое количество ИТ-системы были от головной компании. Поверх них кое-где были собственные решения с российской спецификой. Когда российская часть разводилась с головной, у него осталось лоскутное одеяло этих решений, а чтобы не допустить остановки бизнеса - перешли не Excel. А дальше надо было реанимировать ситуацию, и в компании создали центр продуктовой экспертизы, чтобы сделать это системно. Марина - его руководитель, в центре собраны архитекторы, devops, юридическое обеспечение и ряд других компетенций, а разработка идет отдельными командами, которую центр поддерживает. И еще просвещает в части продуктового подхода и unit-экономики. И у них получилось не просто разработать продукты, поддерживающие работу компании, но и начать выводить их на рыноК PwC этого вообще не делало. Такая вот success story. О конструкции разработки и функциях центра Марина рассказывала, но очень пунктиром, на слайдах подробности есть.

#EnterpriseAgile Анна Аверьянова из Робофинанс. Как OKR помог перезапустить бизнес! У Робофинанс с 2016 был бизнес в Испании - online выдача кредитов, в 2020 случился ковид, мораторий на платежи кредитов, с одной стороны, а с другой - поддержка ликвидности и онлайн. Они продолжили бизнес, но в 2021 выяснилось, что люди набирают кредиты и не платят. Поэтому по итогам года инвестор, он же владелец и ген.дир принял решения о закрытии бизнеса. Но такой бизнес нельзя закрыть одним днем, надо соблюсти требования регулятора, иначе можно лишиться лицензии и для других сегментов бизнеса. Поэтому был процесс на год, который решили вести по OKR, как и все остальное. Цель понятна - минимизация потерь. Было сделано 3 сценария от команды: реалистичный, негативный и позитивный. И в конце первого квартала увидели по метрикам, что развитие идет лучше даже оптимистичного сценария, и в принципе динамика позволяет предположить, что за год можно будет сохранить команду и выйти в плюс. Они пошли к владельцу, показали цифры, получили добро на попытку сохранения и поменяли цель. И у них получилось. У команды был стимул - им нравилось работать вместе и они точно хотели сохраниться. А пост-анализ показывает, что сыграли два внешних фактора: поменялся рынок потребления, то есть тех, кто брал кредиты, при этом часть конкурентов с рынка ушла. А OKR позволил во-время заметить изменение трендов, и пересобрать продукт под новый рынок.

#EnterpriseAgile Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только). Это был рассказ о работе с системой метрик, применяемый в hh, иллюстрированный конкретными примерами. Основная идея - метрики лишь показывают точки потенциальных проблем, и не автоматически, а после анализа показателей на предмет нежелательной динамики или соотношение метрик. А дальше нужно породить гипотезы - что может являться причинами, и проверить их через детальный анализ, погружение в реальную работу людей. При этом, если проблемы выявлены из общих метрик, то анализ ведут в каждом из сервисов, причины могут быть различны. Общие подтвержденные гипотезы становятся фокусом на уровне компании, частные - в сервисах, масштаб определяет приоритеты.

В докладе было конкретной дерево метрик из двух групп - ресурсы и поток.
1.1. ФОТ на доход или ключевую метрику сервиса (не для всех сервисов доход - целевая метрика)
1.2. Распределение ресурсов: стратегия, продукт, тех.налог, прочее. Классификация задач, дальше корректируется продуктом, так как большие задачи могут перекашивать.
2.1. 85% lead time feature. Полный - от discovery, постановки до АБ тест и пост-продакшн. 85 выбрано ретроспективно из анализа.
2.2. Эффективность потока - блокеры.
2.3. Средняя пропускная способность за неделю

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

И в конце - шаги работы с метриками.
1. Начать собирать метрики
2. анализ и генерацию гипотез
3. провести анализ сервиса - проверить гипотезы
4. фокусы для сервисов
5. общие гипотезы для всех сервисов
6. задачи для всех и для конкретных сервисов

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

Эту роль FSD выполняет: проект у мидлов с использованием FSD получается лучше, чем без этого. При этом шаблон - простой, без dependency injection, который сильно усложняет конструкции, и сделан для фронта, в то время, как большинство других - для бэка, а значит их примеры ты должен сначала переосмыслить, что сложно на начальном этапе. FSD делит код на слои:
* app - приложение в целом
* pages - экраны
* widgets - целостные компоненты интерфейса
* features - реализация действий пользователя, use case
* entities - бизнес-объекты проекта
* shared - библиотеки, не привязанные к объектам бизнеса

Каждый слой делится на срезы - slice, это модули. А slice делится на сегменты, тут типичный пример UI - model - api. Есть ограничение: реализация нижележащего слоя не должна обращаться ни к вышележащему, кроме того ни к смежным частям одного слоя, то есть один объект не может вызывать другой.

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

Первая проблема - слишком изменчивый shared. Это происходит не всегда, а только в случаях. когда проект опирается на активно развиваемые библиотеки. Типичный кейс - развиваемый UI kit. И в результате надо либо сохранять совместимость, и тогда в UI kit множатся объекты, появляется button1, button2, button3, либо нужен частый рефакторинг при изменении shared-уровня, либо возникают фасады вместо конкретных классов, и это усложняет использование.

Тут как альтернативу можно посмотреть на шаблон Clean Architecture. В отличие от FSD, по нему есть книжка, где подробно объяснен не только сам шаблон, но и его основания. В нем слои другие: WebUI - infrastracture - application - domain. То есть инфраструктура поднята выше приложений, и потому она может активно развиваться. Но там мы не можем в реализацию сущности (domain) включить UI,иначе чем через dependency injection, а это сложно и потому во фронте - не прижилось.

Вторая проблема: entities не позволяет описать бизнес-модель. Потому что модель - это не только объекты, но и связи между ними. И важно отделить бизнес-модель от всего остального. А тут объекты не могут вызывать друг друга, связи, следуя шаблону, приходится выносить на уровень features, где они смешиваются с действиями пользователя. В этом отличие слоя entities FSD от domain в Clean architecture.

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

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

Третья проблема. На уровнях Widgets + Features + Entites - слишком много связей между модулями. Там пример TodoList - он размазывается по всем уровням, на уровне features превращается в множество команд. А рядом UserList - тоже много классов и файлов. И это все путается.

Какие решения предлагает Евгений, чтобы уйти от недостатков? Он в целом сохраняет структуру слоев и их деления, но предлагает ряд изменений.
1. Entities - не объект, а группа связанных сущностей, например, user=user+session+profile
2. Features - не use case по действиям, а блоки связанной функциональности для бизнеса, например TodoList. Фичи получаются большие, их надо структурировать.
3. Для устойчивости приложения из сегмента domain, работы с бизнес-сущностью, запрещается импортировать shared.
4. Для связывания разных объектов используется dependency injection. Это самое сложное. Пример: UI TodoList требует календаря. И мы вызываем абстрактный render calendar. Его связывание с конкретной реализацией - на уровне page.
Вроде, проблемы решаются. Правда, у Евгения вопрос: это по-прежнему FSD, или уже другая архитектура?

Я хочу начать свой комментарий к докладу с ответа на этот вопрос. Но он будет длинным. Есть такая штука - парадигмы программирования: процедурная, объектная, реляционная, функциональная и другие. Процедурная восходит к книге Николаса Вирта "Алгоритмы + Структуры данных = Программы", это 1976. Позднее добавился UI. B весь старый enterprise - 1С, SAP и многое другое сделан именно в процедурной парадигме, хотя уже на объектных языках. Потому что объектные языки появились с C++, в 1980, объектно-ориентированное проектирование (OOAD) - только через 10-15 лет, а его окончательное оформление в DDD - вообще в 2003. И если почитать шаблоны корпоративного приложения Фаулера или другие книги, то он пишет, что шаблон RichObjects, объекты предметной области - он сложный, проще работать на DTO или использовать другие аналогичные шаблоны. Отличие объектного подхода - объединение данных и поведения в одном объекте с инкапсуляцией внутреннего устройства. А в FSD данные, слой entities, отделены от поведения. оно в features, подобно алгоритмам и структурам данных у Вирта. Отсюда и сложности, если мы пробуем использовать FSD, держа в голове еще и концепцию модели предметной области DDD - она-то сделана в объектной парадигме. А изменения, которые предлагает Евгений - в рамках этого направления. Так что, на мой взгляд, получилось нечто иное.

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

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

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

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

Как практически выяснять ценности сотрудников? Можно это делать в формате упражнений.
* Moving Motivators - выявление личных мотиваторов. Доска, сотрудники получают карточки и располагает по линии важности. Порядок, свобода, мастерство... А затем - насколько это удовлетворяю в работе, получаю ли.
* Culture design canvas. Картирование культурного кода команды. Как празднуем, как звучит в обучении, как лидерство на их основе. Netflix разработал документ по кольтуре - принципы работы, и сотрудники на них ориентируются.
* Командно-игровая сессия Ценности.
* Диагностика ценностей команды. Опираемся на историю, которая позволяет шкалировать.

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

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

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

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

У меня к материалу доклада есть следующие дополнения.

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

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

3. Если берешь чужую модель ценностей - надо понимать, в какой культуре она создавалась, какой смысл там вложен в слова, каковы представления про идеальную компанию и сотрудника. И сравнить это с вашей компанией. Я не знаю, какая модель заложена в книге "Потенциал команды", о которой говорила Эльвира, я ее не читал, но я анализировал многие известные модели ценностей - карту культур Хофстеде, модель Шнайдера, карту Инглхарта-Венцеля, и даже психологические модели DISC и Big Five, и они как раз показывают соответствие идеал, при чем выработанный на материале западной культуры. Об этом у меня тоже есть статьи (по ссылке - последняя).

#MergoConf Анастасия Валуйская из VK. Эффективный менеджер как им не быть или все же быть?! Если кратко, то доклад о том, что понятие "эффективный менеджер" сейчас имеет резко отрицательные коннотации, которые основаны на реальных фактах. И потому не надо таким менеджером становиться, а надо управлять иначе.

А если подробнее, то когда-то Питер Друкер характеризовал эффективного менеджера как того, кто создает стратегию, принмиает риски, погружается в команду и управляет ей. Из тех времен пришла квалификация основных стилей управления на авторитарных с жестким управлением, либералов, которые за общую дружбу, как кот Леопольд и демократов, которые полагаются на команду, но при необходимости приходят на помощь, как Гэндальф. Судя по всему, это классификация Курта Левина (1939), правда у него либеральный стиль назывался попустительским (laissez-faire в оригинале). От себя отмечу, что у Белбина есть роли Шейпера и Координатора, которые в целом соответствуют авторитарному и демократическому стилю, при этом Белбин выделял свои роли экспериментально. А попустительство получится, если руководителем назначить Душу компании, есть у Белбина такая роль, очень полезная, но не руководящая. Впрочем, Анастасия не разбирала детали этой классификации, так что в контексте доклада все это не важно.

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

Эффективным менеджером быть плохо, и Анастасия дала антипаттерны поведения в форме вредных советов.
* Заслуги - вам, провалы - подчиненным. Кейс - присвоили заслуги.
* Максимально нагружайте людей, особенно непонятными задачами. Чем больше загружен - тем эффективнее результат
* Усильте контроль, эффективный контроль - залог успеха, поставьте микроменеджемнт
* Никогда не рассказывайте команде планы, куда идет компания. Разработчик ведь перестанет писать код, узнав о целях, он будет думать о
* Не вникайте в предметную область. Кейс - человек в ИТ не знал, что есть фронт, бэк и дизайн. Отмечу, что этот вредный совет - основа английской управленческой практики 19 века: джентльмен может управлять чем угодно, ему не надо специально учиться. И именно такой подход лег в основу MBA. В отличие от немецкой традиции 19 века, воспринятой тогда же в России, где знание предмета считалось обязательным.

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

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

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

Техника
* три простых дела. Если запланирвоали 4 дела и 3 сделали, четвертое пойдет легко, мозг настроен
* fresh or fried - сложное утром, простое - вечером.
* smart. выучить китайский - но нет времени. Мобильное приложение и заниматься - и результат есть, смалтолки получились
* work life balance.

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

#MergeConf Андрей Гирин из Лидеры изменений. Болото операционки: чем больше шевелишься, тем сильнее увязаешь. Как реализовать стратегию и не утонуть в деталях. Проблема, что операционка кушает все врмя - распространенная. И доклад был про способ работы, методику OKR, чтобы так не происходило. Была методика, с шагами, иллюстрированная примерами. В конце был итог из 6 пунктов.
1. Сфокусировать компанию. Взять группы, которые про стратегию, и не засорять
2. Управлять целями, а не задачами. Задач - много, у них статусы и проблемы. Поэтому пусть люди идут
3. Отслеживать пульс - метрики, что компания не идет вразнос.
4. Выбирайте правильных людей, в зависимости от целей и задач.
5. Определите амбиции. Насколько можно инвестирвоать в конкретные направления в рамках стратегии.
6. Вовлекайте причастных. Их больше, чем ответственных, и они могут помочь или помешать. Никто не злой, но у причастных свои планы.

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

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

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

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

Шаги поиска.
1. Работа с заказчиком. Для чего нужен спец, что изменится, когда придет, что будет, если не придет. И главное - как будем встраивать, готов ли заказчик, часто - владелец или директор, тратить время на встройку.
2. Стратегия поиска. Их нет на сайтах, у них нет резюме, они не ищут работу. Используем РБК, Tadviser, habr. Авторы, блоги, подкасты, рекомендации.
3. Интервью и оценка. Люди работу не ищут. Но если пришли пообщаться - значит какой-то шанс есть. Вопрос - понять, за что можно зацепиться. Но и требования. Сulture fit. И что драйвит, обычно - не деньги. Амбиции, проекты, поднять направление с нуля, найти нового клиента и так далее. Третий не заканчиваем, пока не поймем, что интересно, и как соответствует.
4. Офер. Исходя из того, что узнали на 3.
5. Выход и адаптация. HR и собственник или другой заказчик должен быть рядом.

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

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

У технологии есть ограничения, она бесполезна, когда заказчик - не настоящий. Или когда хотят замаскировать проблему, например, в описании вакансии виден CTO, но СТО в компании есть и его не хотят менять. Надо быть готовым, что не будет большого потока резюме, проекты 4-12 месяцев. И будет требоваться много времени - у HR и у собственника.

#MergeConf Юлия Черемохова из Skyeng. Провоцировать нельзя валидировать. Основной фокус доклада - про провокацию как способ перевести сотрудника в состояние "делаю то, что нужно компании" из состояния "у меня все нормально". Но первая часть была о способах поддержки сотрудника и валидации взаимодействия по нескольким уровням, начиная с валидацией присутствия и понимания и заканчивая самореализацией. Потому что провокация как инструмент констркутивна только при условии хорошего взаимодействия, а если отношения с сотрудником конфликтны, то провокация лишь усугубит ситуацию. Когда уместна провокация? Когда диагностика показывает, что у сотрудника не хватает ответственности, он приходит без результата и у него есть какие-то объяснения, которые он считает нормальными. Эту ситуацию надо отличать от ситуации, когда ожидаемый результат был невозможен или сомнителен, например, по тому, что задача была некорректна поставлена, например, вас просто неверно поняли, и это не верифицировали в момент постановки.

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

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

#MergeConf Яна Шаклеина из @outlines_tech. Однажды в сказке: повышаем продуктивность команды через внедрение фантастических персонажей. Если отжать содержание доклада до сухого остатка, то он - о том, что есть три типа сотрудников, и руководителю надо быстро их диагностировать и вести себя соответственно. Вот они.

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

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

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

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

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

#MergeConf Илья Баксанов. Идеяспособность: как думать креативно, адаптивно и продуктивно? Доклад о том, что идеи может порождать каждый, и надо себе разрешить. Задача - не только уметь пользоваться идеями, но и идеи создавать. Креативность - одна из ключевых составляющих. Конечно, для нее могут быть блоки в команде или компании - не быть поддержки новому, когда среда сопротивляется. Но важно снять блок в себе, а дальше можно проявлять в разных областях или искать подходящее место.

В докладе множество тезисов и практик, они реально полезны. Только примеряя на себя, надо помнить, что все мы - разные, каждому нужно свое подходящее. Но при этом в списке много того, что вам подойдет, он большой. Так что - пробуйте.
Итак, что помогает быть креативным?
* Смотрю на мир через идеи.
* Мы живем в мире идей. MergeConf, выступления - все это было когда-то чьей-то идеей.
* Мы креативны по природе, вопрос лишь в том, насколько ярко мы проявляем эту креативность.
* Идеяспособность: состояние (в котором могу) + навыки и методы = образ мышления и свойство личности
* Идеи - не только на работе - идея занять ребенка тоже востребована. Заинтересовать.
* Установка: каждый может придумать идею
* Полюби процесс поиска идеи и решения задачи. Он сам не сразу к этому пришел
* толерантность к новому и неизвестному. Когда надо придумать - идей нет, и это нормально, я не тупой.
* Относится к проблеме как задаче, которая не решена. Или трудность не как препятствие, а как приглашение к поиску нового
* Знать свои творческие состояния. Коллекция состояний - у человека от 7 до 15 разных состояний. И среди них должны быть состояния, где можно придумывать идею. И надо понмиать, в каком состоянии ты можешь.
* Надо понимать, что тебя вводит в это состояние. Может быть метафора, например, печка, пекущая пирожки. Включать может место, обстановка, ритуал, атрибуты, действия. У него: душ, салон самолета, музыка на повторе, прогулка с вопросом, размышления на тему. * Очень влияет музыка. Спокойная и медитативная - надо подбирать под занятие.
* Может быть простое действие, например, сказать "Так!"
* Наблюдательность. Приглядеться к окружающему миру. Липучка на кроссовке - инженер отдирал репей с собаки.
* Находчивость и изобретательность. Умение находить выход из ситуации. В Игре престолов мантии делали из ковриков Икеа, костюмер в интервью сказал - Икеа тут же сделала мануалы и начало продавать.
* Воображение. Сны - они в голове, ты придумал, увидел - воображенеи есть у всех. Деньги из листиков, секретики.
* Сегодня меня ждет день, в котором я никогда не был! Это - уникальный день! Призма меняет восприятие.
* Путешествия. Если нет возможности уехать - с чемоданом по Москве, уехать на выходные, переночевать в отеле. Но с чемоданом, как путешествие - это меняет восприятие.
* Сказать себе Ещё! Не останавливайтесь!
* Взгляд внутрь себя. Что для меня море, что для меня закат.
* Копилка идей. В записи куча разных идей. Они не запомнятся, пусть будут.
* Насмотренность. Это ингредиенты для приготовления идей. Чтобы складывать мозаику. Посмотри 1-2 даже если не смотришь
* Вдохновляться другими.
* Идействуй! Чтобы копилка идей не превратилась в кладбище. Пробуй, делай первый шаг.
* Пробовать новое. Загружать, делать это постоянно.
* Взгляд ребенка. Почему так, почему гром гремит, почему снег белый.
* Поле идей. Обменивайтесь, не держите внутри
* Футурологические прогнозы. Там часто фигня, но она будит фантазию. И можно читать старые.
* дИИалог. Дружба и сотрудничество с нейросетью. Потмоу что способ для быстрого рождения идей.

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

И заключение.
* Креативность - это выбор. Выдайте себе патент на неограниченное творчество.
* Вдохновение от слова вдок. Не забывайте его делать.

#MergeConf Денис Цветцих из T-Bank. Эффективные DomainEvents из DDD. Денис начал с того, что механизм Domain Events - полезен, но в литературе упоминается вскользь и противоречиво: автор одновременно пишет, что событие локально принадлежит ограниченному контексту и тут же указывает, что события используются для связи контекстов. То же касается транзакций - пишут, что этот механизм аналогичен триггерам БД и обеспечивает консистентность, и тут же упоминают про асинхронную отправку через сообщения. И дальше Денис подробно рассказывает о шаблонах применения событий.

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

В основе - c4 model. В ней бизнес - это вообще контекст исполнения. А дальше есть уровни: контейнеры - компоненты - код. И все бизнес-содержание в этой модели опущено на уровне кода, DDD применяется именно там, и Domain Events - этого уровня. А для интеграции используются DTO и Application Events, они очищены от доменной специфики.

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

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

Слайды моего доклада на #MergeConf - на моем сайте https://mtsepkov.org/SysThinkMerge Системное мышление: что это и зачем нужно разработчику и аналитику?

#MergeConf Владимир Лазарев из AML Crypto. Криптовалюты под прицелом: Как защититься от угроз и предугадать новые правила. Если говорить коротко, то рассказ был о том, что в мире криптовалют все средства - меченные. И если к вам по длинной цепочке пришли грязные деньги - то все ваши деньги могут быть объявлены грязные и заблокированы на бирже, не только этот кусочек. И правоохранители тоже могут придти. Есть прецеденты, когда источник грязных денег был на расстоянии 7-10 узлов. При этом разметку делают ретроспективно, ты можешь проверить в моменте получения, и будет чисто - а потом будет судебное решение. Есть кейсы штрафов бирж в 2024 за операции 2018. И отсюда рекомендации: проверяйте поступающие деньги, если заранее невозможно - сделайте отдельный блокчейн адрес, документируйте все взаимодействия, лучше так, чтобы была доказательность. Для проверки есть скоринг, он работает по комбинации двух моделей: похожесть поведения владельца кошелька на заведомо преступные и история получения их средств. А еще используйте биржи и обменники которые идентифицируют контрагентов и их транзакции. Казалось бы, вы теряете анонимность. Но, оказывается, там, где анонимность формально есть, пользователь реально идентифицируется по сетевым следам, и правоохранители при нужде это устанавливают, есть прецеденты. А так в докладе - много фактуры.

Участвовал и выступал в конференции #ArchDays, которая посвящена работе с архитектурой в крупных корпорациях. Публикую отчет https://mtsepkov.org/ArchDays-2024, и у меня появилось несколько интересных тезисов:
1. Архитектор должен быть деятелем и созидателем, а не трусом, который борется со страхами.
2. Capability map - методика, по которой ты собираешь гардероб не под ситуации своей жизни, а опираясь на журналы о светской жизни.
3. Бизнес уверен, что ИТ - всемогуще, поэтому не зовет их обсуждать бизнес-инициативы: зачем, ведь они любую задачу выполнят.
В отчете - подробнее, вместе с конспектами докладов.

Сегодня - на #ArchDays. Слайды моего выступления на моем сайте https://mtsepkov.org/BusArch-ArchDays Есть вопросы - задавайте.

Не откладывая надолго, собрал заметки с #sqadays в отчет https://mtsepkov.org/SQAdays-2024b Конференция - стабильна, хорошие доклады и много общения, поэтому слушал доклады далеко не на всех слотах.

#sqadays Павел Владимиров. Meta-Prompting и агенты: выжимаем максимум из ChatGPT. Для начала было немного базовой терминологии, и тут для меня было интересен параметр вероятности, определяющий как GPT ищет ответ: перебором до достижения требуемой вероятности, или просто на заданную глубину. И параметр температуры, который задает креативность ответа, сводящуюся к тому, что для ответа выбирается не самый вероятный из вариантов продолжения разговора, а другой.

А дальше был рассказ про промпты, начиная с простых, когда в запросе дают один или несколько примеров ответа (one shot или few shots) к более сложным. В chain-of-thought ты просишь дать цепочку рассуждений, тем самым GPT разлагает сложную задачу на несоклько простых, ответ для которых находит с большей вероятностью. Contextual prompting задает контекст, который надо учитывать для ответа. Ask before answer явно просит задать дополнительные вопросы для уточнения ответа, в этом случае GPT сначала вытянет контекст у пользователя.

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

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

#sqadays Андрей Романюк из Okko. Релиз без сюрпризов: как мы уменьшили количество багов в проде. Основная идея доклада - переход от субъективно выставляемого приоритета бага к count - объективной оценке его влияния, которая получается как произведение охвата пользователей на барьерность бага и на 10000, чтобы получить целое число (охват и критичность считают в процентах). Охват зависит от сценария, в котором проявляется баг, для каждого из сценариев известна частота их использования пользователями: главную страницу открывает 90%, а авторизацию всего 11%, потому что авторизовались - и она запомнена. Охват обновляют раз в месяц. А барьерность варьируется от 1%, например, для всплывающего окна, которое повисит и исчезнет через 3 секунды, до 100% если блокируется запуск фильма, и еще один коэффициент - доля устройств, на которых баг проявляется, одни баги проявляются во всех версиях, а другие могут быть, например, только на телевизорах. Сount дает объективное влияние бага.

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

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

#sqadays Александр Кидяев и Дмитрий Сорокин из ГНИВЦ. ЕГР ЗАГС. Трансформация стратегии тестирования во время перехода системы с монолита на микросервисы. ЕГР ЗАГС - монолитная система, обеспечивающая работу ЗАГС о всей стране. внедренная вместо разрозненной автоматизации на местах. Развитие столкнулось с ограничениями и было решено сделать вторую версию на микросервисах. Но при этом обеспечить мягкий переход с параллельной эксплуатацией обоих систем. Разработку новой системы ведут несколько команд, у каждой - свой пул микросервисов. а команда тестирования - общая, и в ее ответственности и старая и новая системы. Рассказ был про изменение подходов, которое было призвано обеспечить качество. Вот новые практики.
* Встреча 5 амиго для обсуждения новых фич: разработчик, QA, аналитик, архитектор, заказчик. Из этих встреч - поток информации о том. что будет сделано.
* Тестирование требований, которые ведут в confluence
* Центр компетенций тестирования: поиск решений и лучших практик
* Сразу закладывают нагрузочное тестирование, в старой версии были только отчеты. И автоматизация тестирования.
* DoD и DoR для задач со стороны тестирования. Утверждены как регламенты, и это выручает по срокам - неподготовленные задачи не идут.
* Попарное тестирование - оно работает хорошо
* Начали смотреть изменения в законах. В одном проекте Минюста увидели изменения, которые сильно конфликтуют в текущим функционалом системы, дали обратную связь - и Минюст поменял проект.
* Участие в ПСИ и демо приносит практическую пользу

Про боли.
* Не стоит писать кейсы до реализации нового функционала. Потому что его выкатили, через неделю изменился, через неделю еще изменился, и ты несколько раз актуализируешь тесты.
* Пиковые нагрузки. Команды работают независимо, релиз ЗАГС-1 вышибает команду на неделю, и если в это время кончается спринт у ЗАГС-2 получается перенапряжение, это надо разруливать.

#sqadays Лариса Ковалевская из Авито. Как мы меняли процессы с помощью Team Maturity Model, чтобы максимально качать качество. Любопытный доклад. Рассказ был про команду Авито-путешествия, которая переходила из режима стартап-разработки, в котором критерием качества является совесть разработчиков, метрики не используются, а баги правятся на личном взаимодействии службы сопровождения и разработки, к регулярному процессу с мониторингом через метрики, разбором накопленных багов, покрытием тестами и другими регулярными практиками.

В чем особенность этого кейса? В авито есть модель зрелости команд, Team Maturity Model, определяемая через опросник, по которой каждый квартал команда проходит аудит. Там есть блок качества, и на входе показатели были 29% при baseline 80%, и было много других наблюдаемых проблем, например, накопившийся бэклог багов. Команда начала работу над качеством, не разбираясь детально с моделью зрелости, а, так сказать, из общих соображений. Внедрили практику оценки задач 3 амиго (обсуждение на входе аналитиком, разработчиком, тестировщиком), ручные и приемочные тесты, тест-дизайн и продакт-приемка, внедрение SLA по общению с пользователями и ревью бэклога багов. Ситуация улучшилась. Но TMM получился всего 60% вместо ожидаемых 80. И тогда команда пошла разбираться в структуре блока QA в TMM. И обнаружила там те практики, с которыми у них плохо: отсутствие DoD и DoR, низкое тестовое покрытие, неактуальная тестовая модель, отсутствие работы с рисками и другие. И поставила квартальные цели по обеспечению этих показателей - писать DoD и DoR в задачах, написать тестовое покрытие - оно было декомпозировано до конкретных задач по покрытию сценариев, и так далее. И выполнило задачи, получив TMM 80%.

TMM авито опубликован, в докладе была ссылка, а я нашел статью здесь.

Но вот вопрос, дало ли это что-то реально, пользователям продукта и компании - не раскрыт. Почему TMM по качеству именно такая, в чем ценность именно этих таких показателей? Об этом в докладе не было, TMM представлялся как абсолютный идеал. И вот у меня такой рассказ вызвал воспоминание о сборах в армии, когда наряду с полезными знаниями нас учили красиво и быстро заправлять кровати, а также готовили к маршу в ногу и с песней. И эта составляющая была не менее важная, чем содержательная подготовка. В армии это имеет давнюю традицию с Павла I, который это копировал у Фридриха Великого. При этом у Фридриха была содержательная цель, он использовал как часть боевой подготовки, а Павел - лишь для парадов. Чем достижение TMM в 80% отличается от требований идеально маршировать на параде? И ясно ли это команде, или они видят тут некоторый ритуал - непонятно. Из доклада это неясно.

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

1. Сохранить спокойствие

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

3. Использовать эти слова в своих интересах.

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

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

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

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

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

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

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

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

Эволюционный менеджмент - о том, как делать управляемую эволюцию в компании. Три такта: стрессор, рефлексия и лидерство.

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

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

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

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

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

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

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

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

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

1. Создание автотестов - техстек, особенности настройки драйвера, которому правильно передавать root, а не окно приложения чтобы иметь доступ к всяким нотификациям и служебным окнам windows, используемым, например, при сохранении. Они использовали python + behave (bdd на gherkin) + appium + allure report. gherkin выбран потоvу, что можно писать русские аннотации, а это позволило использовать готовые тест-кейсы. Для поиска элементов приложения по свойствам используется inspect, тут у windows свои особенности, с которыми надо разбираться, набор свойств? который разработчик видит в ide не слишком соответствует тому, что показывает inspect, так что даже там, где разработчики могут что-то добавить, получается не так просто. ActionChains аналогичны web и мобилкам, можно несколько объединять в одно действие, но нет простого скроллинга, можно скролить до элемента, что неудобно или pgup-pgdn.

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

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

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

#sqadays Владимир Техтилов из BelkaCar. Self-healing скриншот-тесты: тесты для ленивых. Идея - с помощью скриншот тестов можно достаточно просто автоматически проверять, что поведение UI не изменилось: берем сохраняем экраны и потом сравниваем. И они сделали первую версию тестов на python + playwrite + pixel match. Попробовали с ней жить - и выяснили, что есть проблема с обновлением эталонных экранов. Они меняются в ходе разработки, а для воспроизведения ты должен снять скриншот ровно в том же окружении, что будет при выполнении теста - разрешение экрана, модель браузера и так далее. Обновление оказалось трудоемким, и через некоторое время вернулись к функциональным тестам. Но через некоторое время проект обрел второе дыхание - сделали скрипт, который позволял одной кнопкой порождать весь набор скриншотов за счет запуска тестов в специальном режиме, когда изображения не сравниваются, а создаются новые. Это сделано на основе CI/CD, у них gitlab, но есть аналоги для других. Скриншоты красиво раскладываются по папкам, в зависимости от места в тесте, и дальше создается merge request на обновление тестов. В таком виде оно взлетело и летит.

В целом - понятно. Про аналогичную задачу был доклад год назад на SQAdays от 2GIS, где была задача получить скрины под все разрешения и версии браузеров, чтобы проверять работоспособность UI (мой конспект https://mtsepkov.org/SQAdays-2023b). А еще весной 2012 я слушал доклад, где тоже разбирали тестирование по изображениям. Там проблема была иной: desktop приложение запускалось через citrix, поэтому вместо элементов экрана, на которых опираются при тестировании, у тебя просто картинка. С этого доклада у меня тоже есть конспект https://mtsepkov.org/SQAdays-2012ab И можно сравнить - что поменялось в подходах за столько лет.

#sqadays Boris Moshnin из SM Lab. Долгосрочная стабильность vs. карьерная мобильность: что лучше для профессионального развития? Понятно, что однозначного ответа в докладе не было, но там был неплохой сравнительный анализ, плюсы и минусы каждой стратегии. Долгосрочная - ты погружаешься в технологию или продукт, который нравится, и стабильно работаешь с ним. Это уверенность в завтрашнем дне и много другого профита. Правда, в случае форс-мажоров можно оказаться на рынке труда с не нужными навыками. Потому что технологии стареют и могут умереть. А еще потенциально ограничение роста и возможности перемещения: ты занимаешь ценную нишу, из которой тебя не отпустят. Стратегия частых перемещений имеет свои плюcы - широкий кругозор, знакомство с новыми технологиями, наработку навыка быстрого погружения в проект, большое количество завершенных проектов, если для тебя это важно и ты выбираешь короткие проекты. Я тут хочу заметить, что деление на долгосрочную и мобильную стратегии похоже на деление дайверов и сканеров в модели Барбары Шер. Но это - типовые случаи, а жизнь разнообразнее, например, бывают стабильные стартап-команды, которые долго работают. Он сам собирался поступать на химфак, не получилось, пошел временно работать в ИТ и задержался на 8 лет, потом выучился на художника, но потом снова пошел в ИТ.

#sqadays Мой доклад - про системное мышление, презентация - на моем сайте https://mtsepkov.org/SysThink-SQA24

#sqadays Алсу Шайдуллина. Путеводитель по менторству в ИТ: роль, сценарии и вызовы. Общая часть доклада понятна. Менторы - помогают человеку идти своим путем, частое применение - на онбординге в компанию. Ментор отличается от коуча работой по предметным знаниям, а не только с мотивацией, а от наставника тем, что наставник ведет по пути, не адаптируя его. Мотивация самого ментора тоже понятна - обучая других - обучаешься сам, качаешь софтскиллы и так далее. Но вот дальше были интересные модели для разных форматов встреч. Ценность моделей в том, что они структурируют встречу, задают набор вопросов, ко которых надо подумать. Главное - относиться к ним не как к догме, которую надо соблюдать буквально, а как к рабочему инструменту. Дальше будут названия модели, содержание - гуглите, краткое можно будет посмотреть в презентации.
* Менторство начинается с первичной встречи и для нее подходит модель GROW. От себя отмечу, что модель - любопытное преломление коучами работы по целям, интересно сопоставить ее, например, с OKR и с конструкции SMART-целей.
* Для регулярных встреч есть модель OSCAR.
* В случае ситуативной встречи полезно попросить менти подготовиться по модели STAR, а ситуацию разбирать по модели SBI.

Если менторство не ограничивается испытательным сроком, то важно ставить цели и выделять этапы, а не просто рассматривать его как постоянный процесс.

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

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

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

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

Инструменты по коммуникации.
* Активное слушание. Заинтересованно слушаем собеседника, не решаем собственные задачи. Кивать, угукать, агакать.
* Фактичность. Мыслить фактами, а не эмоциями и субъективными оценками. Коучи любят вопрос "а что ты сейчас чувствуешь?" Очень важно разделять.
* Я-позиция. Не быть токсиком, не говорить что кто-то сделал неправильно, а передавать позицию из своего опыта: "Я закрываю таски за день, потому что если их закрывать дольше, это может сказаться на отношении заказчика, не стоит так делать" вместо "вы долго закрываете таски, надо быстрее". Высказывая мнение, не задевать чувства другого человека. Уметь воспринимать себя и свое мнение, при этом слышать других и понимать, что оно другое, а не неверное.
* Делегирование. Это проблема всех руководителей, а не только начинающих. Усталость "почему я за них всегда все делаю" - типичное.
* Групповые встречи и навыки фасилитации. Это - важно. Обозначить повестку, модерировать. Форматы - разные (master mind, обмен опытом, one2one в том числе групповой). Командная встреча - ведет к цели команды. Групповая встреча - общая тематика и личные цели.

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

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

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

Делегирование - процесс передачи ответственности (не функций), с постановкой целей для достижения.

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

Я тут хочу дополнить. Про делегирование есть модель ситуационного лидерства (надо смотреть первую версию модели, вторая - о другом). Если у вас команда джунов, которые пока не могут сделать самостоятельно, то по пути к делегированию надо пройти от режима поручений directing к режиму coaching, в котором ты учишь человека вырабатывать план действий и далее в режим supporting, когда ты учишь во-время звать на помощь при проблемах. А надежда, что делая задачу за задачей по поручениям сотрудник сам научится делать, конечно, имеет основания, но опыт средневекового обучения мастерству говорит, что на это нужно примерно 7-10 лет.

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

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

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

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

Коммуникация:
* вербальная: устная и письменная;
* невербальная - мимика и жесты;
* паравербальная - тон, интонации, темп, паузы, смех
Коммуникация важна, ее хотят перевести в хард-скиллы, включить в образование. Я тут замечу, что в Древнем Риме так уже было - риторика входила в базовое образование, а с тех пор куда-то потерялось.

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

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

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

Весной в Agile-сообществе России традиционно проходит самая крупная конференция AgileDays, но сообществу уже давно тесно в рамках одной конференции. Осенью проходит Enterprise Agile Russia, посвященная особенностям Agile-трансформации корпораций - на большом масштабе применение Agile-методов имеет очень большую специфику. Началась она еще в 2016 в более широкой рамке как Agile Business, а с 2019 сфокусировалась на корпорациях и поменяла название. В этом году она пройдет 18 ноября, и я планирую побывать на ней, чтобы как раз посмотреть на эти особенности. Например, в 2022 там был интересный доклад, как в ковид планировалось предсказуемое развитие госуслуг с помощью PI Planing из SAFe, которое в условиях эпидемии интенсифицировалось в несколько раз, и ряд других интересных докладов. И, судя по программе, я думаю, что в этом году будет не менее интересно на докладах и воркшопах.

Неделю назад был в Ижевске на UIC.dev и услышал ряд разноплановых интересных докладов. О них - в отчете http://mtsepkov.org/UICdev-2024 Жалею, что у меня получилось побывать только во второй день.

Вчера был на конференции UIC.dev в Ижевске, много интересных и разноплановых докладов. Отчет скоро будет, а пока - презентация моего выступления https://mtsepkov.org/Req-UICdev

7-8.10 в Ижевске пройдет конференция http://uic.dev - широкая конференция для всех специалистов в ИТ: разработчиков, аналитиков, дизайнеров, руководителей проектов, HR и всех остальных, на ней много направлений. Я тоже поеду, буду рассказывать про варианты и разделение ответственности при работе с постановками. И мне интересно посмотреть на это событие. По отзывам прошлого года - было круто, меня еще тогда конференция заинтересовала, но даты не попадали в мое мое расписание. А в этом - получилось.

P.S. Если решите идти - можно написать мне, у меня есть промокод на скидку.

Очень своевременно прочитал книгу Бердяева "Истоки и смысл русского коммунизма" - у меня в результате сложилась целостная картинка о том, что в мире происходит сейчас. В книге Бердяев объясняет, как именно марксизм был переосмыслен в России большевиками, и почему только такое переосмысление могло сработать. При этом изложение идет из широкой рамки, охватывающей весь 19 век и показывает течения русской революционной мысли, которые действовали - а их было много, раскрывает логику взаимодействия и смены этих движений. А конкретно про большевиков - то им удался синтез идей марксизма с глубинным народным течением "Москва - третий Рим", который был сформирован еще в Московском царстве Иванами III и развит Иваном Грозным. Петр I свернул с этого пути, повел Россию на запад, народом это было воспринято как предательство, Петра объявляли антихристом. Но традицию хранил не только народ, в ней мыслили и старообрядцы, а это - громадный слой русского купечества. И, наверное, это объясняет - почему купцы и фабриканты давали деньги на революцию и поддерживали идеи. Вообще, об этом много написано и у историков и в художественной литературе серебряного века, но Бердяев об этом пишет очень целостно и доказательно.

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

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

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

Прочитал книгу Дэвида Гребера «Долг. Первые 5000 лет истории». существенно расширяет представления об устройстве экономической деятельности человечества. Вернее, даже не экономической, а шире, хозяйственной деятельности и сопутствующей ей социальных аспектах, потому что Адам Смит выделил науку как экономику очень криво. А если посмотреть шире, то мы увидим три варианта хозяйственной деятельности, основанные на разных принципах, при этом, что рынок - только одна из них. А еще увидим дуализм между долговой и наличной формой расчетов, при этом долговая - более древняя, а деньги в ней носят исключительно учетную функцию. Книгу крайне полезно прочесть всем, кто самостоятельно строит картину развития мира, и сопрячь со своей моделью. А подробнее - в моем конспекте https://mtsepkov.org/GraeberDebt, надеюсь, будет полезно.

Вчера (19.09) был на митапе московского сообщества тестировщиков @moscowQA. Я рад, что сообщество возродилось, митапы проходят с начала года и это был пятый. При подготовке вспомнил. что 10 лет назад, летом 2014 я рассказывал на встрече московского сообщества тестировщиков про спиральную динамику. Это был мой второй доклад про нее и организаторы попросили не пересказывать книгу, а рассказать с позиции практического применения теории тестировщиком. И с тех пор я стараюсь выдерживать рамку практического применения во всех докладах.

Я рассказывал про модели soft skill по мотивам доклада весной на SQA, но презентация была пересобрана и акценты - другие, это - оригинальная версия.

Кроме меня выступал Григорий Окатов (X5 Tech) о том, как нейронные сети могут помочь в тестировании. С одной стороны, рассказ аналогичен тому, что я слышал в других докладах. Но детали отличаются и они приведены в докладе - конструкции промптов и цели. Первый шаг - использование GigaChat, его просят сделать описание бага по неформальному описанию, и прикручена утилита, которая разбирает его ответ сама заводит баг в трекере. Второй шаг - подавать диагностику от статического анализатора кода (flake для python) и получать понятное человеческое объяснение, здесь работает Mistral, он показался лучше, чем Llame. F в команде техписов у них обучают локально развернутую модель писать документы - чтобы не было проблем с безопасностью. Потому как для GigaChat они согласовывали с безопасностью промпты - что и как можно сообщать о системе.

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

Кстати, встреча сообщества происходила на площадке X5 Tech, были плюшки и неформальное общение, которое организовывало сообщество @reWorked. А еще на площадке было @KotoBuro - комбинация коворкинга и приюта котиков, там можно работать и с котиками общаться. а если кто понравится - взять себе. В общем реально организация - сложная сетевая активность.

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

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

Сон как недооцененный ресурс. Спать - важно, надо высыпаться. Сон считается не часами, а циклами: медленный-быстрый. Медленный - востановление организма, работы внутренних органов. Быстрый, 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 лет. И это - не единственный пример.

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

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

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

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

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

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

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

#festpir2024 Марк Розин. Личные и бизнес-стратегии в Шива мире – как жить в эпоху перемен. Я не успел опубликовать конспект, исправляюсь. Есть матрица стратегий 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

Вот как было у Гальчина, люди на полу и ещё полный балкон у меня за спиной

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-кратную стоимость. Шведы отказали продать, потому что у инвесторов безопасность не на первом месте.

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

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

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

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

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

Слайды моего доклада - на моем сайте https://mtsepkov.org/AI-future-PIR Конспекта не будет, но на слайдах там достаточно подробно написано содержание. Может быть, я напишу об этом статью, но это не точно. А если что интересует - спрашивайте.

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

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

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

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

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

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

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

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

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