Доклады

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

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

Domain-Driven Design — набор подходов к разработке, который, с одной стороны, на слуху, а с другой, к нему очень сложно подступиться. Есть большие книги (Эванс, Вернон), но далеко не все их читают и еще меньше людей читают их до конца. А даже и дочитав, могут упустить суть за обилием деталей. Алексей в своем докладе раскроет основы DDD и даст рекомендации по погружению в тему.

Доклад исключительно практический, где на простых и понятных примерах разберем хитрые приёмы и шаблоны, которые могут использоваться при построении систем потоковой обработки информации (stream processing). В частности, разберем особенности Kafka и RabbitMQ. Это история о развитии нашего продукта, взлетах, а главное, падениях. Тут подробно разберем допущенные ошибки и принятые решения, как и почему они помогли устранить проблемы. Поговорим почему так важно выбрать наиболее подходящий инструмент, а не следовать трендам вслепую. Как оказалось, несмотря на всю специфику нашего проекта, история совсем не уникальна, чем и должна быть привлекательна для слушателя.

Хочу поделиться опытом, как мы в Garage Eight привнесли в команду Mob-programming и поддержали этой практикой экстремального программирования наш флип на Scrum. Расскажу, как заинтересовать команду погрузиться в такой подход разработки, какие болячки 100% вылезут и как с ними работать.
Ну и конечно же затронем тему почему мы пришли к этой практике, почему не бросили после первых болячек, и почему это стало нашей daily практикой.
В конце взглянем на сценарий, как можно начать культивировать mob-programming в вашей команде, и дадим пару типов как сделать этот процесс помягче)

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

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

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

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

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

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

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

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

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

В докладе я расскажу, как мы оказались в ситуации 3 витрин в Мой МТС, и как подошли к процессу их объединения для достижения консинстентной информации. Расскажу, как выстраивали архитектуру и процессы, с какими трудностями столкнулись, и как с этим работали. Поделюсь результатами сокращения TTM и экономии ресурсов.

VK Клипы – сервис коротких вертикальных видео, интегрированный в социальную сеть ВКонтакте. За 4 года его становления было все: от быстрого старта во времена пандемии и запуска отдельного приложения за три месяца после до интеграции с другими контентными сервисами ВКонтакте и 2 миллиардов просмотров клипов ежедневно. Каждый раз происходило изменение запроса бизнеса и под него необходима была адаптация.

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

Как не проспать, когда функция бизнеса поменялась и вовремя изменить процессы, адаптируя продукт? Как управлять продуктом в разные стадии его развития? Как понять, какой тимлид нужен в текущем контексте бизнеса? Об этом поговорим в докладе.

6 лет назад я основал свою компанию.
Мы разрабатываем ПО в сфере информационной безопасности.
Сейчас в компании работает 45 человек.
У нас около 50 клиентов из большого энтерпрайза и большие интересные проекты.

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

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

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

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

Высокая вовлеченность сотрудников невозможна без активного участия лидеров. Лидеры должны уделять время на общение и демонстрировать заинтересованность в своих сотрудниках. Без личной вовлеченности руководителей невозможно достичь значимых результатов.

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

Бывает и так. Но чаще дело не в лени, жадности, гордыне и прочих смертных грехах. И даже не в том, что люди так устроены, что всегда сопротивляются изменениям.

Чаще всего дело в нас. И хорошая новость в том, что раз дело в нас, то это можно изменить.

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

* Симптомы проблем с софт-скилами тимлида.
* Soft skills — недостаточно формализованные hard skills.
* Soft skills и взаимодействие с командой, бизнесом и собой.
* Алгоритм выявления проблем с софт-скилами и саморазвития.
* Метрики эффективности работы тимлида, связанные с soft skills.

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

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

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

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

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

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

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

Системное мышление — мощный инструмент построения моделей реального мира и проектирования его изменений. Но действительно ли такие мощные инструменты общего характера необходимы архитектору, разработчику в повседневной работе для проектирования или разработки? Ведь существует много прикладных моделей и подходов, таких как для с4 model и Archimate для архитектуры, или ООП и DDD для разработки кода, Event Storming чтобы разобраться с предметной областью и много других.

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

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

Тезисы:
1. Идеальное решение проблемы существует, но ты его не знаешь, пока не вступишь.
2. Команда, ты где?
3. От хаоса - к проду.

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

За 20 минут вы сможете получить ответ, что предпринять:
- когда цель есть
- команды нет
- путь не определён
- ресурсы не подвезли
- дедлайн скоро
Что делаем?

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

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

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

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

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

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

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

Ура! Я - тимлид! Должность есть, обязанности есть, знания есть. Но почему, когда я говорю, что надо делать, или даже предлагаю что-то дельное, вечно какие-то возражения, сомнения, не готовы меня воспринимать лидом, и вообще, меня надо слушаться!! Нет, не слушаются и не особо слышат. Почему?

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

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

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

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

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

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

Управленцев в IT не хватает, сильно не хватает. Казалось бы, почему бы не обучить нужное количество? Почему бы не научиться, благо курсов, программ, тренингов и конференций хватает!

Проблема в том, что управление – это ни личное желание, ни опыт, ни умение стратегировать и тем более ни набор практических навыков. Это все вместе и еще что-то! И в этом наборе вам может не хватить какого-то элемента, который вы не видите (или не хотите видеть!))

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

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

Я поделюсь научными исследованиями такого явления как zoom-выгорание и практическими методами, благодаря которым мне самой удается проводить более 20 онлайн-встреч в неделю и сохранять продуктивность

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

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

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

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

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

Старина Эдд был таки прав: если есть способ сделать что-то неправильно, человек именно так и сделает!

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

Я слышал от разных людей, в том числе на Teamlead Conf, что они пробовали Story Points и разочаровались в них.

Мне стала интересна причина. Что же людей не устраивает? В этом докладе я постараюсь дать ответ на этот вопрос. А конкретно мы разберем:

1. Зачем вообще оценивать задачи? Есть ли альтернативы? Спойлер: есть.
2. Способы оценки: человекочасы, футболки и Story Points. Плюсы и минусы.
3. Антипаттерны при использовании Story Points.
4. Мои рекомендации по тому, как внедрить Story Points, и нужно ли это делать.

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

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

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

Мы много говорим про отдельные инструменты: ИПР, обратную связь, оценку, встречи 1-to-1. Но как собрать из этого систему, которая будет помогать руководителю быстро принимать решения в меняющихся условиях, снижать текучку и помогать удерживать ценных сотрудников?
Я расскажу о комплексном подходе к решению этих задач и поделюсь своим опытом. Масштаб — 10 кросс-функциональных команд, общее количество сотрудников — 100+.
За основу беру Performance review, который задает цикличность и сроки. На него нанизываются все остальные процессы и инструменты: карта персонала (текущая картинка, траектория), карта рисков, ИПРы, план пересмотров и т.д.

Такой подход позволяет:
1. Повышать уровень осознанности тимлида и его понимание, что происходит в команде: баланс команды, Bus-фактор, заменяемость сотрудников, траектории развития сотрудников, подсвечивает потенциальные вакансии.
2. Планировать сложные траектории развития сотрудников, например «обмены» между командами.
3. Работать с групповыми рисками. Например, когда существуют различные невысокие риски, но у большого количества сотрудников. Либо один общий высокий риск, который затрагивает несколько человек в разных командах.
4. Отвечать на вопрос «из кого собирать новую команду», в первую очередь — её основное ядро, оценивая при этом последствий для «команды-донора».

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

А как быть, если я ошибся с выбором тимлида, но понял это слишком поздно?

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

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

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

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

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

Вместе мы разберемся:
1) Что такое 1:1 и какие обязательные правила его проведения существуют.
2) По какому плану может строиться любой 1:1.
3) Как выстраивать диалог с разными типами сотрудников и разными запросами: проактивными, новичками, желающими повышения и т.д.
4) Какие ошибки можно допустить при проведении 1:1 и как их избежать.

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

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

Поэтому в процессе мастер-класса хочется поговорить о том, как:
- устраивать нытинги, чтобы сотрудник смог свободно делиться своими проблемами, факапами и превратить их инструмент для усиления;
- заводить Small talk c коллегами, чтобы узнавать о личных и профессиональных способностях коллеги, которые повлияют на эффективную коммуникацию. работу и атмосферу в команде (здесь там пошаговый инструмент)
- проводить moment of glory - научить сотрудников хвалиться своими достижениями и мотивировать других на свершения. Здесь учимся замечать победы разного масштаба, чтобы сотрудник ощущал себя значимым, ведь часто, работая в команде мы не видим именно своих результатов.

На МК получиться ПОПРАКТИКОВАТЬ эти три формата и поделиться своим опытом в рамках обозначенных тем.

Это не лекция! Посидеть и “погреть ушки на контенте” не получится. Участники будут в малых группах работать в разных ролях. Они выполнят некоторые упражнения, которые помогут значительно глубже понять проделанную работу.

Мероприятия, которые посетили во время конференции статут темой нашей ретроспективы, а поэтому:

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

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

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

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

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

Если такие анти паттерны принятия решений вам знакомы, и вы хотите понять и попрактиковать:
- Как принимать рациональные решения быстро и эффективно,
- Как принимать решения в условиях неопределенности,
- Как перестать использовать голосование большинством - как основной метод принятия решения в команде,

Приходите на воркшоп, мы разберем 25+ техник принятия решений командой на кейсах и попрактикуемся в их применении.