Доклады

Важно создавать комфортные условия для сотрудников, но современный офис, печеньки, массажист - не гарант того, что сотрудник будет счастлив. Не менее важны интересные задачи. А что еще важно? Итак, что мы делаем, чтобы обеспечить комфорт в команде?
1) Проведение встреч 1:1. Беседуем не только о рабочих задачах, но и о сотруднике, его настроении, развитии.
2) Фиксация промежуточных итогов. Отметка достижений.
3) Мини-клубы и обмен опытом. Делимся новыми практиками и технологиями, разбавляем рутину и расширяем кругозор.
4) Совместные командировки, выезды на производство. Укрепляем связи между сотрудниками, выезды дают представление, ради чего сотрудник выполняет задачи.
5) Доверие и развитие. Плавное предоставление сотрудникам более сложных задач, эффект Пигмалиона: вера руководителя в сотрудника и поддержка его начинаний.

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

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

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

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

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

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

«Разработка - это круто, ну а менеджмент - отстой» - к сожалению, с таким пониманием в IT-мире приходится сталкиваться до сих пор.
Когда способный тимлид отмахивается от разговоров про дальнейший рост, а разработчики просят не рассказывать им «вот это всё» (менеджерское) невольно задаёшься вопросом - а ту ли дорогу я выбираю, когда решаю расти дальше…
Именно на этот вопрос я постараюсь ответить в своём докладе - расскажу про свой путь в миддл-менеджмент; поделюсь сложностями и инсайтами, которые встретил; подсвечу ловушки, в которые угодил сам.

Какие преимущества и риски в процессе стажировок? Мы выяснили опытным путем, когда создали проект “Нашкодим”.

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

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

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

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

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

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

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

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

Меня зовут Михаил Семенов, я лидер продукта Platform V Pangolin в СберТехе. Pangolin – это реляционная СУБД, созданная нами для высоконагруженных приложений. В 2019 году я пришел в СберТех создавать этот продукт с нуля – и с нуля же набирал себе команду. Сейчас Pangolin делает больше 100 человек, а к концу года нас должно стать 120.

Руководителям команд, которые растут очень быстро (а это часто происходит в IT ) неизбежно приходится менять подходы. И на этом пути можно собрать кучу грабель. Ведь в группе на 10-30 разработчиков – одни процессы, а в команде на 50-100+ человек – совсем другие. Расскажу о том, какие типичные грабли я успел собрать, перестраиваясь на управление большой командой, и какие решения оказались самыми работающими.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очень часто слышу среди знакомых историю о том, что они выполнили тестовое задание в компанию N и ... ничего, или просто отказ. Я считаю не оставлять кандидатов без обратной связи очень важно. Закрывая одну из позиций на разработчика мы проверили больше 100 работ за месяц и никого не оставили без фидбэка (ну почти). Я хочу рассказать как нам это удается, почему это важно и какие плюсы это дает. Как минимум это помогает оставаться с талантливыми кандидатами на связи и быстрее закрывать новые позиции. Разберу какие виды тестовых заданий втречались на моем пути: какие в них плюсы и минусы.

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

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

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

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

Увидимся на докладе!

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

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

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

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

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

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

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

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

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

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

1. Свобода воли - миф или реальность? Если реальность, почему мы бываем недовольны своим поведением
2. Психика как объект - зачем нужна, к чему стремится
3. Механизмы психики (которыми она пользуется чтобы достичь целей из пункта 2
4. Структура проблемы / травмы
5. Как современная терапия работает с этим, учитывая первые 4 пункта
6. Что можно сделать самостоятельно для изменения своего поведения или состояния
7. Почему другие себя так ведут? Можно ли повлиять на чужую мотивацию, чужое поведение? Как?
8. Как сделать так, чтобы ты и команда лучше перформили, был лучше климат в коллективе.

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

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

Я перепробовал разные инструменты и в итоге остановился на Obsidian. Рассмотрим, в чём его отличие от аналогов, как использовать папки, теги и ссылки для создания связей, фреймворк ACE для организации заметок и плагин excalidraw для визуализации информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Два года назад на Team Lead Conf я описал (https://www.youtube.com/watch?v=O8dnb_2jxpo) фреймворк построения взаимовыгодных отношений с руководителем.

Теперь же я его расширю новыми измерениями, факторами и сфокусируюсь на плане действий - как же полноценно реализовать свой потенциал, “управляя руководителем”?

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

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

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

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

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

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

А еще дам короткие упражнения для снятия стресса / повышения бодрости до и после встреч, чтобы были силы и на другие задачи!

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

Вместе с врачом и научным журналистом Алексеем Водовозовым разберемся:
— Что на самом деле скрывается за модным словом биохакинг, и что говорит об этом наука.
— Реально ли вручную настроить метаболизм.
— Можно ли сократить продолжительность сна и сохранить при этом его эффективность.
— Существуют ли качественные и проверенные исследования по биохакингу.
— Есть ли уже позитивные примеры.
— Когда можно начинать и стоит ли вообще.

• Мозг человека & компьютер – сходства и различия
• Грабли в общении, на которые все наступают
• Как доносить свои мысли, чтобы они заходили – модель SCARF
• Практическая отработка компонентов модели

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

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

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

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

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

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

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

Расскажу, как мы продуктовым и технологическим подходами объединили три разных витрины Мой МТС, ставя перед собой цели по:
- достижению консистентности данных;
- улучшению t2m;
- повышению надежности решений;
- снижению количества сотрудников.

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

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

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

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

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

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

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

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

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

Мы будем говорить:
- О рисках, об их вероятности и неизбежности, и о том, как риски ведут к ненадежности;
- О неубывающей неопределенности и эффекте "испорченного телефона" в управлении;
- О математических основах управления рисками и надежностью;
- О способах понижения локальной энтропии в коллективе через управление рисками и о методах такого управления;
- И, конечно же, о законах Мерфи!

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

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

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

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

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

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

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

- Автоматизация старых процессов дает только дорогие старые процессы, но не сокращает потери
- Разработчики против своего спасения, как работать с change management и негативом к любым трансформациям
- Итоги - на 20% быстрее. Где мы так тормозили?
- Вредные советы: хотите заруинить трансформацию - спроси меня как.

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

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

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

В своем докладе я расскажу, как переосмыслил четыре простых действия: поиск, найм, адаптацию и развитие. Как осознанность в них позволила мне на сложном и перегретом рынке 1С за один год вырастить команду управленцев в 7 (!) раз. И почему в долгосрочной перспективе мне не грозит текучка кадров.

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

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

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

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

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

Один из кризисов, который настигает практически каждого руководителя – это несоответствие вашего понимания того, что надо делать и того, что понимают и делают сотрудники. «Они все тупые!» - не раз такое приходилось слышать от некоторых руководителей… забывающих о том, что непонимание – это не проблема того, кто должен понять, а того, кто доносит.

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

Мы будет конструировать, общаться, соревноваться и делиться инсайтами

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

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

Если вы столкнулись с такими сложностями, попробовали с ними справиться, но не оч получилось —приходите на мастер-класс

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

- попрактикуем короткие разговоры с коллегами, позволяющие наладить контакт и разговорить;

- научимся «хвалиться» своими профессиональными заслугами так, чтобы уважали, а не стебали.

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

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

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

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

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

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

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

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

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

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

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

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

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

С другой стороны это поле для злоупотребления и манипуляций со стороны недобросовестных представителей инфобизнеса и доморощенных «коучей».

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

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

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

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

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

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

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

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

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

Главная точка роста любой команды — компетенции её руководителя. На мастер-классе вместе с вами пройдёмся по ключевым навыкам тимлида, используя мою авторскую карту компетенций. Вы сможете оценить свой текущий уровень по ключевым 10 навыкам с помощью опросника, обсудите результаты с другими участниками, и — это главное — составите план своего развития на 2025 год.

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

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

1) В вашей жизни внезапно появился project manager
2) Какие у него потребности?
3) Как его правильно кормить?
4) Как его правильно использовать в своих целях, не нарушая УК

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Продуктовый подход помогает определить, за какую Базу Знаний готовы платить.
2. Я пришел на место человека, которому не удалось запустить Базу Знаний. Расскажу о том, как я учел его опыт и смог запустить продажи на внешнюю аудиторию.
3. Для разработки продукта необходимо назначить владельца и наделить его соответствующими полномочиями. Поделюсь своими наблюдениями о месте владельца Базы Знаний в организационной структуре компании.
4. Сложности в разработке Базы Знаний: нужно продумать UI/UX-решения и провести отдельный Cust Dev для процесса обновления Базы Знаний. Расскажу, как сделать Базу Знаний «живой», какие знания сохраняются, кто является ЦА и какие задачи они решают.
5. Роли внутри команды, отвечающей за Базу Знаний.
6. Сложности роли “хранителя”: работа с предметной областью, перевод знаний экспертов в доступную для всех методологию, фасилитация методологических встреч. Необходимые компетенции.
7. Решение конфликта между отделами: что добавлять в Базу Знаний, что нет и в каком виде.
8. Планы по развитию продукта - работа с разными клиентскими сегментами.

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

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

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

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

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

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

В Додо и Дринкит большая команда поддержки клиентов, 500+ человек в 10+ командах. Все эти команды обрабатывают 750 000 обращений клиентов в чате, на горячей линии, соцсетях и практически любых источниках коммуникации, а помогают им менеджеры рекламаций, тренеры, тимлиды и другие команды.

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

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

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

Мы обсудим, как определить, какие знания и навыки имеют долгосрочную ценность и как их эффективно передавать. Мы рассмотрим как выбрать подходящие инструменты, каковы ограничения ИИ в передаче неявных знаний (tacit knowledge) и как оценивать эффективность использования ИИ в управлении знаниями.

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

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

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

Почему так происходит? Часто проблема в том, что исследования проводятся не в то время, не тем методом или не с той аудиторией.

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

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

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

Рассмотрим следующие аспекты
- Техдолг как динамичное явление, а не статичное состояние
- Приборы и метрики
- Источники его появления
- Меры по предотвращению нового на время раскопок
- Организация работ

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

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

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

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

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

Пришло время леденящих душу историй о кэшировании контента! Трафик уплыл невесть куда; картинка из кэша отдается втрое дольше, чем напрямую; в кэше ничего не оседает; с CDN-сети в источник прилетает DDoS-атака, а поставщик выставляет за нее счет... Список внезапных проблем можно продолжать долго. Но что, если мы с вами уже знаем, почему и в какой момент они могут возникнуть, и учитываем связанные с этим риски? Автор, который долгое время занимается темой защищенности сетей, а теперь помогает строить новую сеть доставки контента, разберет в докладе вопросы взаимодействия с CDN-сервисами, такие, как:
— Быстродействие. Как отслеживать, что вас ускоряют, и насколько значимо это ускорение? Сценарии задержек и потери трафика у сервисов на базе anycast и GeoDNS.
— Атаки на отказ (DoS, DDoS). Как злодей может использовать CDN для атаки на клиента? Выдержит ли CDN-сеть атаку — и что предпринять на своей стороне, если нет? Как мы решаем задачу защищенности своего сервиса.
— Потребление ресурсов и затраты. В какой ситуации может кратно вырасти чек? Какие настройки на стороне источника влияют на отданный объем, полосу пропускания и число запросов? Сигналы и метрики, которые помогут предотвратить проблему.
— Как держать яйца в разных корзинах? Использование нескольких CDN сразу. Или, может, пора поднять собственный распределенный кэш? В каких случаях такие подходы имеют смысл, и что для этого придется поменять в своей инфраструктуре?

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

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

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

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

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

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

Но можно добиться таких тестов, которые действительно будут проверять код, действительно будут показывать его работоспособность. Для этого нужно каждый тест увидеть красным. А для этого прежде чем писать функциональность, нужно написать тест. Это и есть разработка через тестирование, или TDD (test-driven development) — и именно этим мы займёмся на воркшопе.

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

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

Но работа с открытым кодом требует особых подходов и практик внутри компании. Поэтому для координации, наладки процессов и продвижения своих открытых проектов в зарубежных компаниях создают Open Source Program Office, OSPO.

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

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

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

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

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

Внутренние инструменты позволяют сокращать time-to-market в сотни раз, делать разработчиков счастливее и ускорять рост бизнеса. Тем не менее на практике часто сталкиваются с тем, что внутренние инструменты съедают ресурсы и не приносят пользы. Как результат, продать время на разработку таких инструментов — не так уж и просто.

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

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