Доклады

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

Что делать с адаптацией, если число людей в проекте выросло с 4 до 50, а систем на поддержке с 2 до 50+ ?
Что делать, когда понимаешь, что необходимые для сопровождения знания не успевают влезать в новичков в адекватные сроки и как сократить ТТМ инженеров сопровождения.
Расскажу пройденный нашей командой за 9 лет путь. Как мы адаптировали адаптации, внедряли проверки знаний, клонировали главных экспертов компании у себя в отделе и делили знания на «неважное» и «необходимое».

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

Создатььиз группы специалистов команду, осознанную и мотивированную, может помогать знание о пользователе

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

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

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

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

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

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

Эволюция процесса разработки в компании: почему мы вообще решили записывать, как нам работать

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

Описания этапов процесса VS критерии перехода: плюсы, минусы, сколько солить, подойдет ли базилик

Чем плохо, когда все хорошо описано: какие шишки можно набить, если вы опасно полюбили описывать процессы

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

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

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

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

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

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

1. Все больше задач технической поддержки внутренних и внешних клиентов уходит на ИИ-ассистентов.
Как сделать так, чтобы ИИ-ассистент приносил пользу и отвечал на вопросы по накопившейся базе знаний?

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

3. Как научить виртуального ассистента извлекать информацию из этой базы знаний и формулировать ответы на вопросы пользователей.
- Где хранить статьи
- Как по ним искать
- Как нарезать на тематические фрагменты и какие возникают при этом проблемы.

4. Как управлять затратами
- использовать ли LLM и платить за каждый ответ
- не использовать LLM (или использовать ограниченно).

5. Метрики и процесс дополнения базы знаний

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

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

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

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

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

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

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

1. История создания: внутренний CustDev, переход от waterfall к итеративному подходу
2. Создание живой Базы Знаний и процесса ее обновления.
3. Сложность: предметная область, перевод знаний экспертов в методологию доступную для всех, фасилитация методологических встреч. Необходимые компетенции.
4. Развитие продуктового подхода к созданию методологии.
5. Конфликт между отделами - что добавлять, что нет и в каком виде.
6. Аттестация по методологии внутри компании.
7. Перевод методологии на английский и поддержание нескольких версий документа. Сложности, решения.
8. Планы по развитию продукта.

За последние 10 лет я прошёл стандартную эволюцию личной базы знаний: конспектировал на бумаге, на карточках, вёл разные тетради, создавал структуру в Word, развивал базу знаний в Notion, OneNote, iPad и в конце концов познакомился с Obsidian и Zettelkasten. Наши отношения были разными: временами я любил свои заметки, а временами хотелось всё удалить и начать заново.

В докладе я расскажу про этапы отношений с базой знаний:

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

- Этап переосмысления. Это время, когда я начал честно отвечать себе на вопрос: “А зачем мне база знаний? Для чего?” Здесь я рассказываю, почему удалил 1500 из 4500 заметок, по каким принципам перестроил структуру базы знаний и какие привычки внедрил для эффективной работы с информацией.

- Этап использования базы знаний на 100% и усиления себя в разных сферах. Я расскажу о том, как в 2023 году начал экспериментировать с подключением LLM к базе знаний и как мой AI-ассистент помогает мне сегодня в личной жизни и работе.

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

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

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

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

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

А чтобы интегрировать ux-исследования в процесс работы с проудктами и проектами, нужно разобраться
1) в инструментах — как можно исследовать
2) стадии продукта — когда
3) потребности — зачем

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

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

Чаще всего в таких случаях начинают внедрять 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+ техник принятия решений командой на кейсах и попрактикуемся в их применении.