Доклады

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

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

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

Как TeamLead'у провести организационные изменения и не отправиться на костёр?
Плавно, нежно, но с перчинкой внедряем новые стандарты, Аgile-процессы и т.д.
Вот такая вот современная реальность.

В докладе будет:
* Что такое организационные изменения?
* Причины сопротивления (по Фролову, по Коттеру)? Какие действия усложняют процесс?
* Какие есть изменения? Какие типы изменения?
* Методы проведения изменения?
* Сравнение моделей изменения (Левин, Бира, Фишер, Коттер).
* Применение модели Коттера на практике.

Частое явление: когда разработчик становится руководителем даже небольшой команды, он начинает распыляться. Бесконечные созвоны, синки, встречи, общение, мотивация, контроль. Он перестаёт или почти перестаёт писать код, в глазах — тоска, в душе — апатия, а в мыслях — ностальгия.

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

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

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

В этом докладе я на своём опыте поделюсь проблемами и решением этих проблем.

Часто в разных компаниях системные аналитики занимаются совершенно различными задачами:
формированием требований, проектированием апи/баз/интерфейсов, техническим писательством и так далее.

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

Сейчас коучингом могут называть самые разные подходы к работе с людьми. На этом воркшопе мы оттолкнёмся от истоков — подходов Тимоти Голви и Джона Уитмора, которые привнесли коучинг из спорта в бизнес, примерим на себя понятие "внутренней игры", а затем применим это на практике.

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

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

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

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

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

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

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

У нас по плану будут:
1. Слои сопротивления по Э. Голдратту.
2. Буддийский принцип взаимозависимого происхождения.
3. Критерии проверки логических построений.
4. Интерактив и упражнение для более глубокого понимания.

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

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

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

* 3 тренда новой реальности.
* Смена фокуса с вопроса "Как нам дожить до стабильности?" на вопрос "Как нам быть успешными в постоянной нестабильности?".
* Принципы "пересборки" себя/команды/организации.
* Инструменты повышения уровня жизни в системах.
* Что является моей персональной точкой опоры в постоянной нестабильности.

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

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

Мы поговорим про работу с джунами.

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

Почему так случилось, кто виноват? А самое главное, что бизнесу с этим делать? Ответ очевиден — джуны!

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

1. Понимание смысла, отделение основных идей книги от второстепенных.
2. Превращение идей и мыслей автора в свои собственные (контекстуализация).
3. Создание системы взаимосвязанных заметок.

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

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

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

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

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

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

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

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

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

На докладе поговорим о том, чем концепция «играющего тренера» вредит разработке и как не забирать инженерные задачи у команды, сохраняя при этом свою техническую экспертизу :)

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

Обсудим эти вопросы и поймём, как лучше решать эту проблему.

* Измеряем плановый эффект от проектов до начала работ.
* Бизнес сам приоритизирует проекты.
* Прозрачно контролируем выполнение и управляем изменениями (скоупа, сроков) вместе с бизнесом.
* Завершили проект, но закончилась ли работа по нему? Проверяем достижение планового эффекта от проекта.

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

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

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

Уже почти 2 года я играю с друзьями в Dungeons & Dragons, причём полгода — в роли мастера.

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

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

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

Тем не менее у эмоций есть своя логика. Понимание этой «эмоциональной логики» позволит вам лучше понимать себя, свои потребности и цели, а значит — делать свою жизнь лучше, ориентируясь на этот внутренний компас.

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

Разберемся, что блокирует наши эмоции и почему, а также — как выражать эмоции, если уже накипело и кажется, что вот-вот «разорвёт».

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

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

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

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

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

Мне в трёх разных компаниях повезло изнутри наблюдать за подобными процессами и принять несколько важных решений, которые позволили мне не перестать себя уважать и остаться в хороших отношениях с коллегами. Хочу поделиться наблюдениями (переманивание целых команд, доносы, левые схемы заработка) и рассказать, почему в конечном счёте не стоит оставлять после себя выжженную землю ради лишнего повышения.

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

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

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

После моего доклада вы сможете взять готовые шаблоны и попробовать tech-retro у себя в компании.

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

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

Как минимизировать ошибки выбора, и только ли в выборе проблема? Какие сложности ждут нас после выбора?

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

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

Мы привычно делим программистов на примитивные группы: senior/middle/junior, backend/frontend/ops, java/perl/ansible, L3/L4/L5. Увы, не из любых букв можно составить слово "вечность", такое грубое деление не позволяет понять, получится ли команда, соберется ли из этих деталек наш космический шаттл.

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

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

* Разница внутренней мотивации и убеждений поколений.
* Особенности внешней мотивации 2-х поколений.
* Эффективное и позитивное взаимодействие в команде.

Разберём:
* что есть наставничество или менторинг, чем отличается от коучинга и других помогающих практик;
* как наставничество может выглядеть в организациях;
* зачем руководителям стоит применять наставничество внутри своих команд;
* с чего начать внедрение в команду;
* наставничество как способ развития самоходности (самостоятельности в принятии решений) у своих сотрудников.

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

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

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

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

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

Доклад о том, как микроменеджмент может нанести очень много вреда команде, компании и самому руководителю.

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

В последнее время можно обнаружить огромное количество вакансий на позиции руководителей RnD, но как можно нанять такого специалиста, если не очень ясна разница между продуктовыми командами и RnD?! И те и те работают по Agile и проверяют гипотезы!

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

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

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

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

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

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

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

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

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

В IТ-среде постоянное развитие является нормой. Развиваются технологии и инструменты, постоянно появляются новые вызовы в разработке продуктов, а значит, постоянное обучение — верный спутник любого IT-специалиста.

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

Почти три года назад я возглавил IТ в крупном федеральном банке, сейчас это юнит почти в 1000 человек, решающий сложные задачи и помогающий компании каждый день стать круче. Самое главное в работе топа — собрать команду, но как это сделать? Все долбят со стороны профилирования команд, MBTI, DISC и прочего, а что делать с чуйкой? И почему команда непременно умрет и родится заново, как птица Феникс?

Я поделюсь своим опытом из первых рук, никакой воды.

Наем инженеров обсуждается на конференциях довольно часто. Кто-то рассказывает про то, как нанимает за одну встречу, а другие говорят про свои многоэтапные интервью. А вот про наем технических руководителей (teamlead, engineering manager, director of engineering) рассказывают гораздо реже.

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

Начинающие руководители команд часто сталкиваются с проблемами развития команды.

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

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

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

За 20+ лет существования компании мы перепробовали много разных подходов к организации HR-функции, в итоге победила «маркетингово-продажная» модель. Это дало возможность кратно масштабировать компанию на протяжении нескольких лет, но не помогло изменить мир.

В докладе: удачные и неудачные кейсы по процессам, инструментам, мероприятиям, обучению.
А также мораль: что можно отдавать на откуп HR'ам (спойлер: немного), и кто должен выполнять HR-функции (спойлер: многие).

* Как связана роль дата-сайентистов в компании с развитием лидерских качеств: самоорганизуемости, самоуправляемости и нацеленности на практический результат команду?
* Зачем развивать бренд команды и как находить будущих звезд на рынке джунов?
* Почему руководителю DS-команды так необходим опыт работы руками?
* Зачем дата-сайентистам нужны софт-скилы и как их развивать?

Вы ведь всегда готовитесь к публичным выступлениям?
Пишете тезисы, рисуете слайды, продумываете структуру.
Но несмотря на всё это, гарантировать то, что выступление пройдет хорошо, вы не можете.
Потому что главные инструменты не настроены. А это — ваши голос, тело, психологическое состояние и энергетика.

То, как мы владеем своим телом и управляем голосом, публика считывает мгновенно.
И уже с самого начала верит или не верит вам.
* Как сделать так, чтобы верила?
* Как управлять своим состоянием и не дать стрессу победить?
* Как сделать так, чтобы приглашали еще и еще?

Мастер-класс «Выступай. Звучи. Убеждай» как раз про базовые настройки и практики, прокачивающие основные спикерские инструменты.

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

Шаблон включает в себя:
1. План встречи.
2. Итоги полугодия глазами сотрудника.
3. Обратная связь от команды.
4. План на следующее полугодие/год.

При помощи данного шаблона можно:
1. подготовиться ко встрече с сотрудником, собрать информацию из разных источников и визуализировать ее;
2. вместе с сотрудником поразмышлять и наполнить шаблон мыслями, идеями, фактами и выстроить план развития прямо во время встречи;
3. быстро сформировать и выгрузить итоги встречи, которыми можно пользоваться в течение года как сотруднику, так и вам, как руководителю.

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

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

8 примеров эмоционального интеллекта и 8 практических рекомендаций для прокачки себя для перехода с уровня на уровень.

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

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

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

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

Все эти вопросы можно собрать в один: что сейчас мешает нашим эффективным командным или групповым встречам? Или так: как сделать наши встречи еще эффективнее?

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

В результате воркшопа вы сможете:
1) провести диагностику эффективности ваших встреч по 65 маркерам-демонам;
2) попрактиковать конкретные приемы, как устранять и предотвращать появление "демонов" встреч;
3) используя силу группы, расширить картинку и увидеть, как можно реагировать на сложные, непродуктивные ситуации на встречах из разных ролей (тимлида/руководителя, фасилитатора, члена команды).

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

В психологии есть такое выражение — «Там, где разум, нет эмоций, и там, где эмоции, нет разума». Руководитель, конечно, тоже человек, но для работы руководителя надо уметь «выключать» эмоции при обсуждении любых тем. Будем исследовать, что для этого делать!

Все стадии работы команды от понимания задачи до демо.
В чем сила команды разработчиков, а где она проваливается.

Техлидирование DS-команд имеет свои особенности:
1. “Рутинизация” процессов разработки моделей и постоянное повышение уровня абстракции задач команды

Сервисы по автоматическому и полуавтоматическому обучению и внедрению моделей, стандартные пайплайны разработки моделей позволяют избавить моделистов от рутинных задач и однотипных моделей. Как только возникает задача по разработке второй похожей модели, требуется повысить уровень абстракции задачи и переходить на разработку обобщенного решения. Это позволяет не только повысить time2market, но и сохранять интерес команды к работе, выделить время на новые и интересные задачи, в том числе R&D.

2. Exploitation vs Exploration в развитии компетенций в команде

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

3. Soft skills и Business understanding как драйвер адаптации ml в компании

В DS-командах важно взаимодействие с заказчиком, от команды требуется умение работать в условиях нечеткой постановки задачи, способность погружаться в бизнес-процессы заказчика, стремление осознать, что скрывается за числами и функцией распределения данных, как влияют модели на итоговые бизнес-метрики end-to-end. Соответственно, процесс найма и развития сотрудников направлен на развитие soft skills в команде.

1. Что делать, когда команда новая? Что делать, когда ты новый лид? Несколько топовых советов.
2. Должен ли тимлид программировать? О необходимости трезвой оценки своих сил и возможностей: менеджмент против инженерки.
3. Определение уровня участия окружающей среды в жизни команды — тимлид-интерфейс? Может быть, менеджер? Может быть, вообще вся команда? Как правильно выставить акценты в коммуникациях и поискать нужные схемы взаимодействия?

IТ-академия МКБ — это платформа для подготовки IТ-специалистов от начального уровня до готовности к работе в команде, перепрофилирования специалистов внутри IТ и развитию новых навыков. IТ-специалистами в прогнозируемые сроки.

На текущий момент IТ-академия — это более 10 профилей подготовки специалистов.
За год свою работу в командах начинают более 50 IТ-специалистов уровня junior+, готовые к работе в кросс-функциональных командах развития продуктов.

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

Практически в каждом проекте Яндекса используется машинное обучение. В докладе на примере ML-технологий я расскажу о том, как управлять R&D. Что важнее — мотивировать себя или команду? Как сохранить баланс между бизнесом и научными исследованиями? Зачем управленцу насмотренность, и какую пользу он может дать команде инженеров?

Обо всем этом поговорим через призму разных проектов в истории Яндекса, а также разберем, какую роль в R&D играет культура компании.

Закон Холдейна: оценить труд инженера-исследователя может только другой инженер-исследователь. Не только оценить, но и дать критическую коммуникацию, подтолкнуть в правильном направлении, подсветить темные углы.

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

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

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

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

В докладе поговорим о том, что такое инновации (и всегда ли R&D — это инновации): можно ли управлять инновациями? Можно ли их планировать? Можно ли их измерять? Сколько стоят идеи (и стоят ли, вообще, они хоть что-то)?

Корпоративная культура — булшит или реальность? Можно ли на неё целенаправленно влиять или “что выросло, то выросло”? Все эти темы и вопросы мы рассмотрим через опыт разных компаний (Microsoft, Amazon, кровавый enterprise и гаражные стартапы), а также через строение мозга, биологию человека (и инженера).

Мы в Эрливидео выращиваем инженерную культуру и научились продавать её клиентам, даже если они об этом не знают.

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

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

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

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

Если посмотреть на портфель проектов крупных венчурных фондов, то доля hardware-стартапов очень небольшая, примерно 1% (1 из 100). Длинный период создания и проверки гипотез в hardware-продуктах, большие инвестиции в разработку и производство — все это останавливает венчурные фонды от инвестиций в такие стартапы. Среди Big Tech компаний Яндекс — одна из немногих, кто создал умные устройства, востребованные рынком.

В своем докладе я расскажу, как сделать успешный hardware-продукт в software-компании? Как сегодня планировать roadmap продукта, которым люди будут пользоваться через 2 года? Какие разработчики нужны для hardware-стартапов и как их искать на рынке? И почему у hardware-продуктов нет никаких физических ограничений?