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

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

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

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

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

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

Как общаешься сам с собой? Такими формулировками или нет? Ты даже не моешь встать рано замените на "предлагаю завтра встать пораньше".

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

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

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

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

В 16:20 встречаемся на следующих докладах и мастер-классах:
⠀
🔹Зал «Конгресс-холл». Задокументировать всё. Семён Факторович (documentat.io).
⠀
Если вы в очередной раз не смогли найти, как у вас что-то работает, и первой мыслью было «А давайте всё задокументируем!», то Семён поможет разобраться, какие задачи стоят за этой фразой на самом деле, как уметь эти задачи понимать, между собой различать и выбирать подходящее решение.
⠀
🔹Зал «Пекин+Шанхай». Как исцелять команду в кризисных ситуациях. Светлана Гончар (Neoflex).
⠀
В рамках доклада Светлана даст четкий алгоритм действий, как диагностировать психологическое состояние команды, как понять, какие инструменты и в каких случаях использовать, если команда оказалась в кризисной ситуации с повышенной неопределенностью.
⠀
🔹Зал «Дели+Калькутта». Воркшоп-игра «Галактика» от Екатерины Лисейчевой (Мандариновая лиса) и Александра Белякова (GAMIFY THIS): от проблемы до найденного решения.
⠀
Это формат нетворкинга по командам для решения своих задач. Комбинируем тимлидов с тимлидами, продактов с продактами, etc.
⠀
🔹Зал «Бангалор». Легкий старт: как мониторить инженерные практики с помощью данных. Павел Колосов (Qbigtech (ex Admitad)).
⠀
В своём докладе Павел расскажет о том, каким образом без ресурсных вложений в аналитическую работу выявить проблемы в работе инженерной команды и вовремя принять корректирующие решения, а также приведёт несколько живых примеров для подкрепления своих тезисов.
⠀
🔹Зал «Уфа». Результаты исследования российских IТ-решений по управлению знаниями KMS tools. Владимир Лещенко (KM talks).
⠀
Сейчас наблюдается возрастающий интерес к IТ-инструментам управления знаниями в связи с необходимостью перестройки бизнес-процессов и необходимостью импортозамещения. Владимир в своем докладе представит результаты независимого исследования современных IТ-решений как итогового каталога инструментов.

⤵️⤵️⤵️

🔹Зал «Сингапур». Автоматизация без бед. Когда "да", а когда "нет"? Александр Коротков (Тинькофф)
⠀
Часто можно услышать, что автоматизация — это, конечно, хорошо. Но всегда ли это так? Может ли автоматизация принести больше вреда, чем пользы, если применять ее несвоевременно? В докладе Александр расскажет, как определить наилучший момент для автоматизации и создать настоящую ценность.
⠀
🔹Зал «Рио». Встреча с Программным комитетом TeamLead Conf
⠀
🔹Зал «Кейптаун». Как руководителю не тратить время на информационный мусор? Алексей Морозов (Научные исследования социальных инноваций).
⠀
Карьерный рост и амбициозные цели вынуждают постоянно учиться, ставить навыки, входить в новую для себя область. Времени все меньше и потому его ценность выше. Нужны инструменты для быстрой оценки информации, для отсева информационного мусора, чтобы не тратить свое время на интеллектуальных клоунов.
⠀
🔹Зал «Найроби+Касабланка». Зачем разработчику LLM?
⠀
На круглом столе рассмотрим преимущества технологии Copilot в области кодирования. Обсудим возможности и подходы к использованию нейросетей при разработке архитектуры IT-систем и ответим на острый вопрос — сможет ли ИИ в будущем заменить человека в сфере программирования.

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

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

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

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

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

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

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

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

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

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

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

Как джуны оценивают лидов:
* Просто лид. Говорят, что лидом делают хорошего разработчика и он превращается в просто лида. И ничего не поменял.
* Душа компании. Весельчаки, заводные. Но если постоянно весело - пропадает серьезность, и подчиненные перестают всерьез работать, про задачи - отшучиваются
* Бабаушка. О тебе всегда заботятся, на 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, можно брать.

Друзья, в 17:30 ждём вас на последних докладах первого дня TeamLead++ Conf 2023:

🔹Зал «Конгресс-холл». Теряем доверие, а потом пробуем его вернуть. Серёжа Попов (Skillbox)

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

🔹Зал «Пекин+Шанхай». Неизбежное сопротивление без потери рассудка. Александр Крылов (Bimeister).

Есть ли варианты сделать все так, чтобы и изменения внедрить, и не разругаться с коллективом? Кажется, что варианты есть.

🔹Зал «Дели+Калькутта». Продолжение воркшоп-игры «Галактика» от Екатерины Лисейчевой (Мандариновая лиса) и Александра Белякова (GAMIFY THIS): от проблемы до найденного решения.

🔹Зал «Бангалор». Как правильно принимать неправильные решения. Дарья Рябченко (Холдинг Т1, Группа Иннотех).

Этот доклад отвечает на вопрос, что делать, если на «правильно» нет ни времени, ни остальных ресурсов? Можно ли с минимальной болью сделать «неправильно»?

🔹Зал «Уфа». База знаний — конструктор, или Как угодить всем. Анастасия Граф (Maxim Technology).

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

🔹Зал «Сингапур». Как мы ВКонтакте ускоряем t2m c помощью ML. Михаил Шваркунов (VK, ВКонтакте).

Михаил расскажет, как применять ML для ускорения работы с автотестами.

🔹Зал «Рио». Встреча с Программным комитетом TeamLead Conf

🔹Зал «Кейптаун». А что, если разделить команду? Елена Елизарова (СберЗдоровье).

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

🔹Зал «Найроби+Касабланка». Зачем разработчику LLM? Продолжение круглого стола

#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г - Ценность - для компании, для клиентов, для партнеров - тоже работа в группах.
В этой части можно использовать один формат или несколько, в зависимости от целей встречи.

Друзья, мы очень хотим делиться с вами в сторис атмосферой на площадке, но нам не хватает голосов ☹️

Проголосуйте, пожалуйста, за канал ☺️

https://t.iss.one/TeamLeadChannel?boost

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

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

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

Друзья, в 10:00 ждём вас на первые доклады:
⠀
🔹Зал «Конгресс-холл». Карьерные кризисы как тренд нового времени. Юлия Аравина.
⠀
Из доклада участники узнают о типичных карьерных кризисах, которые происходят сейчас в IT, о внутренних блокерах, которые мешают что-то менять, а также получат практические советы о том, как это можно побороть.
⠀
🔹Зал «Пекин+Шанхай». Практический алгоритм действий для начинающих тимлидов. Капитолина Кузнецова (СберМаркет).
⠀
Капитолина расскажет, как справляться с ощущением хаоса и потери контроля в первые месяцы работы руководителем.
⠀
🔹Зал «Бангалор». Мы не будем делать базу знаний, и как антропология помогла нам это понять. Рита Канис (Just AI).
⠀
Бывало у вас такое, что вы делали базу знаний, а потом поняли, что она не решает изначальную проблему? Рита расскажет о методах из корпоративной антропологии, которые вы можете применить, чтобы понаблюдать за своими коллегами, процессами и культурой и найти подходящее именно им решение.
⠀
🔹Зал «Уфа». Отвечаем осмысленно. Валентина Уржумова (Dominion).
⠀
Из доклада Валентины узнаем, как давать ответы так, чтобы стать источником ясности и вдохновения. Посмотрим, как ответы могут препятствовать обучению и обмену знаний между командами и как это исправить.
⠀
🔹Зал «Сингапур». Назад в будущее. Как мы выстраиваем процесс управления архитектурой ИС. Павел Мутовин (Иркутская нефтяная компания).
⠀
Павел поделится тем, как они выстраивали подходы, выбирали инструменты и адаптировали под свои нужды решения для управления архитектурой IT-экосистемы нефтяной компании. Доклад будет интересен работникам IT-подразделений корпораций, основная деятельность которых не связана с разработкой ПО.
⠀
🔹Зал «Кейптаун». Меняя себя и других — понимай устройство: инженерная модель личности. Максим Цепков (mtsepkov.org).
⠀
Максима надо просто приходить слушать — огромный кругозор в разных моделях и методологиях позволяет ему находить далеко не самые очевидные закономерности и выискивать новые нюансы там, где, казалось бы, все очевидно.