#Teamlead Яна Фёдорова. ИмаДЖУНариум — представление джунов о лидах. Яна пришла в тестирование из преподавания английского. Она умеет работать с обратной связью от учеников, и применила это для джунов. Реальное исследование, анонимный опрос 100 джунов и обработка результата, именно этим доклад интересен. Джуны - актуальная тема: 120 курсов по 100 джунов в месяц - 12к новичков на рунке. В курсах рассказывают, что с руководителем легко и можно классно пообщаться, и новички из ВУЗов приходят с этим ожиданиями. Если меняют специализацию, то легче, уже есть понимание, что происходит.

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

В исследовании 100 джунов рассказали кейсы взаимодействия с руководителем в ответ на открытый вопрос.
* 17% - супер-тимлид
* 26% - не взаимодействую с тимлидом, созвоны раз в месяц
* 44% - работать невозможно, терплю ради стажа, избегаю взаимодействия
* 13% - прекратили сотрудничество, не сработались

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

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

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

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

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

Руководители про джунов
* Ботаник. Читает пользовательское соглашение, читает все требования, работают тщательно, но очень долго
* Проактивный. Первые в очереди на выгорание, давайте все, готовы работать все время. За ними надо следить - могут сгореть.
* Виноват не я! Так сложилось. Стремятся переложить не только ответственность, но и задачи.
* Младенец. Хотят прямой ответ на вопрос, не любят исследовать, пояснения, наставления, все показать.
* Память золотой рыбки: пришел-спросил-забыл. Спросил кого спросить - не спросил, забыл. Что делал вчера - не помнит.

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

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

Что делать? Общаться словами через рот. Коммуницируйте.

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

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

#Teamlead Сергей Яныкин из СберМаркет: Как и зачем тимлиду расти выше по карьере. Возможный путь из тимлида - в руководители многих команд и дальше в CTO/CPO/CFO и так далее. Для начала надо решить, стоит ли по нему идти?

Демотиваторы.
* Точно надо будет больше работать. Пример календаря - у него сихрон 2 часа, 2-3 часа с семьей, потом разгребает все что нужно.
* Вы всегда будете плохим. Вы вне команды, где-то начинаете закручивать гайки на перформанс, ребята видят, что вы поменялись - стали плохим. А если наоборот, комфортно для подчиненных, то плохой для руководителя.
* Неопределенность процессов. Для команды понятно - scrum, kanban, ретро, дейли. Выше фреймвоков обычно нет, есть большая специфика.
* Работа с зарплатами и бюджетом. И кейсы, когда подчиненные получает больше. Дали 50к на повышение зарплат на 10 человек - как поделить, и кто-то будет недоволен, скажет что так мало.

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

Как сделать level up?

1. Подготовить себя - будет больше переключений контекста и другие задачи, к этому надо готовиться.
* Управление проектами и командами. Где-то есть проджекты, а где-то нет - и надо вести проекты, делать арбитраж, искать бюджеты, фасилитация встреч и так далее. Книги: Larson An elegant puzzle. Том Демарко Deadline. Голдратт Цель.
* Многозадачность, и много входов по задачам: ИБ, инфра, HR, смежники. Книга - Максим Дорофеев Джедайские техники.
* Ситуационное руководство. Direct-Coaching-Support-Delegating
* Продукт. Цель миссия и стратегия компании. Если у компании нет - плохо. Понимание, какими метриками оперирует компания. Книги: Cagan Inspired. Румельт Хорошая стратегия, плохая стратегия.
* Техника. Алгоритмы и паттерны проектирования. Мартин Чистая архитектура.

2. Подготовить команду. Зачем: вас промоутят, команда без руководителя - она перестала так же перформить.
Метрики: velocity plan-fact; cumulative diagram - поиск bottleneck, predict lead time - предсказание поставок и срока ожидания.

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

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

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

3. Подготовить руководителя
* быть ответственным: брать обещания по задачам, делать в срок, задавать вопросы, если неясно
* брать инициативу и быть проактивным
* заявить о желании роста - могут не догадываться

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

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

#Teamlead проходит вместе с #KnowlegeConf и #Techlead, и этот доклад - про архитектуру. Руслан Сафин из Byndyusoft: Раз архитектура — as Code, почему бы её не покрыть тестами?! Такие тесты могут обеспечить актуальность архитектуры и проверить соблюдение принципов архитектуры. В докладе были примеры и инструменты, которые они выложили в open source.

Architecture As Code. Архитектура определяет принципы, на которых строится взаимодействие между сервисами. Это не просто картинка взаимодействующих сервисов. Картинка - наглядна, но принципов на ней нет. Картинка хороша для коммуникации, но у нее нет версионирования, и нельзя сделать сравнение. Поэтмоу и появился Architecture As Code: описываем схемы на языке, картинка строится автоматически. Распространенные инструменты: PlantUML и Structurizr, есть и другие. Когда описываем взаимодействие сервисов в PlantUML, описываем сервисы и их взаимодействие.

Проблемы архитектур:
* не актуальность - при чем часто еще сложно разобраться,
* декларативность: показывает, что есть business logic - repository - db. А можно ли напрямую?
* контроль - есть договоренность, что напрямую нельзя, но новичок не знал - и сделал

Решение проблем - через автоматизацию, тесты по архитектуре.
1. Актуальна ли архитектура проду?
2. Соблюдает ли архитектура выбранные принципы.

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

Откуда брать происходящее на проде
* Service mesh и реальный трафик. Действительно реальность. Но: (1) нет редких связей, сложно симулировать и потому долгая обратная связь - только с прода
* Infrastructura as code - она дает знания о возможных связях: конфиги кубера с обращениями, топики кафки и так далее. Информации там больше. Можно проверить надежность - сколько подов запущено, действительно ли они на разных нодах. Мы из обоих источников формируем списки сервисов и структуру связей и сравниваем. B в докладе - пример сравнения, он сделал open source реализацию такого сравнения.

Проверка принципов.
* anti corruption level - на границе есть адаптеры, и с внешними сервисами общение только через них. Помечаем адаптеры и внешние сервисы тегам, и проверяем, что внешние сервисы только через них.
* DB пассивна, а обращение к ней - только через репозитории - тоже разметка сервисов-репозиториев, и проверка, что из репозитория единственная исходящая связь через базу данных, а в базе данных - только входящая из репозитория.
* Внешние REST - только через API gateway - тип связи
* Операции записи - только через оркестратор бизнес-процессов, так как у него механизм компенсирующих транзакций - красим связи чтение-запись, и проверяем, что запись только у оркестратора.
Для проверки принципов мы раскрасили сервисы и атрибуты - важно, чтобы эта раскраска сопоставлялась с конфигами на проде и проверялась тестами соответствия проду. Иначе в архитектуре пометили связь read only, а в конфиге открыты любые обращение - контроля нет.

Тесты включаются в общую систему тестов. Если на этапе разработки поправили конфиг так, что архитектура нарушена, то при разворачивании на СI/CD тест упадет. Принципы архитектуры могут нарушаться случайно и сознательно. Тесты отсеют изменения по незнанию. А для соблюдения принципов нужно approve архитектора на изменения тестов.

Трудоемкость: 2 чел-нед архитектора + 2 чел-нед разработчика + 0.5 чел-нед девопса.

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

Бонус для монолита. Другая команда у них посмотрела доклад - и написала проверку для архитектуры модульного монолита. Тоже в open source, можно брать.

#Teamlead Наталия Смирнова. Как подготовить идеальную встречу в формате брейншторма. Метод известен давно, но попытка провести часто заканчивается без результата: появляется множество идей, с которыми непонятно что делать, или идут бесконечные споры без результата. Наталья рассказывала о формате, который позволяет получить результат.

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

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

Как действовать. (1) Организационный план: Цель, Продукт встречи, Люди, Возможные проблемы на встрече. (2) Фасилитационный план обсуждения.

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

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

1а. Формат 1-2-4-все или 1-3-6-все (если 12). Сначала каждый свое, потмо объединяет, кластеризует, комбинирует.
1б. World cafe. Сначала генерация по столикам, а потом - переход, знакомимся с идеями и порождаем новые. Зона стонов может быть уже здесь. В конце владельцы плакатов рассказывают всем.

2. Перевести из зоны стонов в сходящееся решение. Голосование как выбор предпочтительных идей. Без критики. В world cafe можно по разному правила, за что голосовать - за плакат или идеи на нем.

3. Выработать решение. У вас есть, например, 5 идей и надо почеленджить.
3а - Классифицируем. Разделить про ресурсам и ценности.
3б - Сценарии: что будет, если сделать, и что, если не сделать. Две группы, одна по позитивным сценариям, другая - по негативным
3в - Три направления мышления: оптимисты, пессимисты, и как сделать
3г - Ценность - для компании, для клиентов, для партнеров - тоже работа в группах.
В этой части можно использовать один формат или несколько, в зависимости от целей встречи.

#Teamlead Александр Коротков из Тинькофф. Автоматизация без бед. Когда "да", а когда "нет"? Основной тезис доклада: процессы важнее автоматизации, потому что автоматизация работает только при регулярных процессах, если у вас хаос, то автоматизация не поможет. Более того, побочные эффекты автоматизации могут нарушить отлаженный процесс, например, отвалить существенную часть. Например, при изменении автоматизации workflow задач случайно отвалили интеграцию с ботом, который напоминал о review - и время ревью выросло с нескольких часов до пары дней, потому что разработчики привыкли, что о review напоминает бот и эти задачи смотреть не надо. Для оценки упорядоченности процесса используется Кеневин фреймворк. Но хаос в процессе может быть скрытым, был пример, когда тестировщики массово скипали красные тесты, потому что они краснели из-за нехватки CPU.

И в конце - общий алгоритм работы.
1. Убедиться что мы в ordered-зоне - то есть процессы отлажены
2. Определить узкое место в процессе. Если можно расшить - расшиваем, если нет - болевую точку справа
3. Прикидываем профит и как оцениваем
4. Принимаем решение
5. Автоматизируем по возможности MVP
6. Оцениваем результат.
7. Переводим автоматизацию в complicated|obvious - чтобы не свалиться в chaotic.

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

Последний доклад первого дня #Teamlead я слушал на треке #KnowledgeConf. Анастасия Граф. База знаний — конструктор, или Как угодить всем. Практический доклад по созданию базы знаний в небольшой компании Maxim Technology - это разработка платформы для Taxi Maxim, третий агрегатор в России. У Анастасии команда 7 человек технических писателей, которые на входе все были джунами, сейчас каждый вырос. Задача - решить вопрос с документацией, создав базу знаний.

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

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

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

Как это реализовано технически?

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

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

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

Отчеты confluence - подборка по меткам и по свойствам страницы. Отчет по свойствам - метки и фильтры. Общий и тематический глоссарии делают из них. Три типа меток.
* Метка статуса - готовность документа: В работе - ревью - Опубликована - На корректировку.
* Тематические метки, для ограничения поиска
* Технический метки - классификация по назначению, например "термин"
Макроы: сделать подборку (поиск), сделать термин, отчет по свойствам страницы для сборки глоссария, содержимое по меткам.

У них нет секретов, смотреть можно все. Это особенность. Если права есть появляется сложность: вы готовить отчет, но коллега может не видеть. Переиспользование контента позволяет обновлять максимально быстро. А отчеты дают тематические выборки, поэтому можно обновлять или проверять по темам, когда что-то изменилось.

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

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

Ну а я в заключении зову всех завтра в 10 утра на свой доклад про модель личности.

#Teamlead Слайды моего доклада - на моем сайте https://mtsepkov.org/PersonalityModel-2023, там же другие материалы.

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

Обучение основано на цикле Колба. Теория - Эксперимент - Конкретный опыт - Рефлексия - Теория. В обучении часто с теории, но реально можно начинать с любой фазы. Важно замкнуть в цикл.

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

Workflow практикума: Теория - постановка задачи - самостоятельная проработка - практика. Обучение по группам, в которых несколько пар аналитик+разработчик, у каждой группы - куратор, он играет роль заказчика. Каждая группа представляет свое решение, и потом куратор показывает и объясняет эталонное. Для работы над разными кейсами группы миксуют, сохраняя пары, и меняют куратора, поэтому получается разное взаимодействие.

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

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

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

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

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

#Teamlead Евгений Идзиковский. Осознанность 2.0 — почему мы испытываем именно эти чувства и как полностью изменить нежелательное состояние. Это очень интересный доклад, который дает технику работы с эмоциями. Проще всего это описать в модели, которую Евгений не рассказывал, и которую я услышал от Вадима Демчога: спектакль жизни играется на двух сценах: в объективной реальности и на внутренней сцене у меня в голове, и поведением во многом управляет не реальность, а увиденное внутри. И в докладе речь шла о том, что многие эмоции обусловлены тем, что на внутренней сцене разворачивается ролик, не имеющий отношения к реальности, который призван вызвать переживание и направить поведение. Дальше была техника, как этот ролик можно увидеть и понять, что представленное в нем не имеет отношения к реальности, и дальше изменять реакцию. То есть мы можем повлиять на встроенную систему, чтобы мое поведение поменялось.

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

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

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

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

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

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

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

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

Но реакция меняется. Представьте. Утро. Текущие новости. Президент: времена тяжелые, выезд запрещен, счета заморожены, курс фиксированный 300 р и так далее. И тут внизу "вы смотрите трейлер сериала выживание" И вы "тьфу, фигня". Что изменилось? Ведь эмоция была, кортизол выработали. Но вы поняли: это не реальность, а реклама.

Все, что показывает мозг - не реальность, а реклама. Совпадает случайно. Хотя если перебежать МКАД с движением - то да, может совпасть.

У мозга нет цели предсказать будущее! Он не умеет. Вы думаете мозг реагирует на запрос "нарисуй реалистично" и он работает - это неправда, реально запрос "мозг, сделай ролик для эмоций".

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

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

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

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

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

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

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

Есть ли те, у кого видео отсутствует? За последний год было около 1000 клиентов, и для этого использовал вскрытие автопилота. Опыт показывает, что способны, она не всегда как в фильме, может быть смутной. Может, клиент лишь говорит, что видит картинку - в голову не залезешь. Но если он вскрывает образ и ему становится легче - то результат получен.

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

P.S. Конспект Анны Обуховой тоже будет, но, наверное, завтра.

Вау-докладом #Teamlead для меня был доклад Анны Обуховой, очень насыщенный и качественный по контенту. У Анны всегда превосходные доклады, но этот именно вау. Подготовка конспекта заняла много времени, поэтому публикую его вместе с отчетом о конференции https://mtsepkov.org/Teamlead-2023-automn Из других докладов хочу отметить доклад Евгения Идзиковского Яны Федоровой, Руслана Сафина и мой собственный, хотя это и нескромно. Как всегда, на конференции было много разнообразного общения, и это тоже очень ценно. До новых встреч!

В обсуждении докладов на конференции AnalystDays проявился вопрос о связи DDD и ООП. Для меня эта связь очевидна, и для Эрика Эванса она тоже была такой, это видно из его книги и вполне естественно: ООП в начале нулевых тогда был мейнстримом. А вот сейчас, когда основой архитектуры являются микросервисы, то фокус может быть на едином языке и структурировании предметной области через выделение ограниченных контекстов и сопряжение между ними, и в этом случае связь с ООП становится не столь явной. Однако, для использования всегда полезно представлять метод в целом, включая тот контекст, который был очевиден, когда метод создавался и потому не акцентирован явно. Поэтому родилась статья "Способы отображения: существует ли связь между DDD и ООП" в которой я не только рассказываю историю, но и говорю про современные практики применения.

Анна Обухова на #Teamlead, рассказывая про создание креативной команды, говорила о факт-картах Андрея Курпатова как инструменте фиксации поля фактов или поля смыслов, которые служат основой поиска креативных решений. При этом отдельно фиксировала, их принципиальное отличие от mindmap и аналогичных инструментов структурного упорядочивания области знаний. Я записал, что с ними неплохо бы разобраться, но неизвестно, когда до этого доберусь. Но, возможно, кого-то инструмент заинтересует и он сделает это раньше.

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

При подготовке доклада на Teamlead о модели личности Гриша Петров порекомендовал книгу Лизы Барретт "Как рождаются эмоции" как современный научный взгляд. Я прочитал, там изложена теория конструирования эмоций исключительно на основе социальных представлений. У меня к этой теории много вопросов и замечаний, так что отзыв о книге получился очень объемным https://mtsepkov.org/BarrettEmotion Работа со своими и чужими эмоциями - актуальная тема, так что, думаю, это многим будет интересным. А если это действительно состояние современной науки, то оно вызывает печальку. Впрочем, на мой взгляд, есть и более продвинутые, хотя и частичные исследования, об этом я тоже в отзыве говорю.

Вот уже неделю я отдыхаю в Шри-Ланка. И вчера был на экскурсии в Коломбо, опубликовал фотки и заметки https://maksiq.livejournal.com/147406.html - гид хороший, много рассказал

Отдых на Шри-Ланке подходит к концу, будет еще большая экскурсия, а пока публикую рассказ про отель, море, зоопарк и еще немного фоток из национального музея Коломбо https://maksiq.livejournal.com/147664.html Читайте!

Поехал на экскурсию по стране, https://maksiq.livejournal.com/147743.html - первый день.

Последний репортаж из Шри-Ланки публикую уже после возвращения https://maksiq.livejournal.com/148139.html это второй день экскурсии - Сигирия, ботанический сад и храм Зуба Будды в Канди.