Доклады

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

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

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

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

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

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

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

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

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

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

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

Расскажу, как эволюционировал подход к управлению и какие принципы Toyota адаптируются к IT. Покажу, почему классические подходы не работают в реальности команд. Расскажу, какие инструменты из TBP действительно применимы — 5W, RCA, Диаграмма Исикавы, A3 — и как ими пользоваться. Объясню, почему виноват не человек, а процесс, и что делать, если лидер «сходит с ума».

Как запустить новое подразделение без готового запроса и выстроенных процессов
- С чего начать: выявление реальных потребностей бизнеса и IT
- Договариваться со смежниками: цель, формат и распределение ролей
- Как перенести разрозненные знания в доступную систему (документация + AI-бот)
- Как убрать «лички» и настроить единый вход для запросов
- Как нанять и онбордить команду в условиях неопределённости
- Метрики, которые помогают доказать ценность и держать фокус
- Ревизия легаси-процессов: что оставить, что пересобрать
- База знаний для сотрудников и клиентов: ускорение и прозрачность
- Работа с сопротивлением и удержание собственной энергии руководителя
Результат: автономная функция, связавшая бизнес, продукт и IT

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

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

Как автоматизировать? Что? Расскажу.

Каждый из нас сталкивался с ситуацией, когда проект, система или какая-нибудь локальная доработка выполнены, а Заказчик работы не принимает. Или, например, требования сформулированы, тикеты заведены, обратный отсчет по срокам пошел, а исходные данные – не предоставляют. Кто-то скажет, что это же саботаж! И, возможно, будет даже прав… Но я скажу: «Подождите! Надо разобраться – возможно, что дело в политике».
Любой проект, продукт, компанию, коллектив и даже каждого отдельного индивидуума окружает политика. Это не хорошо и не плохо – так устроен мир. А потому гораздо разумнее принять этот факт и научиться с ним работать, чем отрицать и бороться.

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

Но так было не всегда…

Расскажу о своем опыте внедрения Scrum и Agile в большом анимационном сериальном производстве на примере проекта "Бум Земли".

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

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

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

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

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

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

1. Росатом – не только атом: десятки ИИ-разработок от NLP до LLM и выведенные на рынок продукты
2. Две вселенные: ИИ в производственной компании и производственной корпорации
3. Как все начиналось – корень будущих ошибок
4. Ключевые «грабли» и как мы их исправляем:
• Синхронизация стратегии корпорации и стратегии ИИ: к чему мы пришли за N лет
• Единый центр экспертизы
• Принцип 3 китов: новый подход к гипотезам и их скорингу
• Инфраструктура: это было больно
• «Свежая кровь»: почему Росатому не просто работать с набором и как мы это решили
5. Выводы и фокус на ближайшие годы, в том числе внедрение генеративного ИИ

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

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

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

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

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

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

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

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

В индустрии доминирует нарратив «будь громче, заметнее, активнее». Но что делать тем, чья сила — в глубине, а не в яркости? Как расти, когда твоя компания не выстраивает систему поддержки для «тихих профессионалов»?
В ИТ-командах 60% лидеров — интроверты, но корпоративные правила видимости написаны экстравертами. Результат: талантливые специалисты остаются «невидимками», их идеи игнорируют («это не моя работа»), а карьера упирается в потолок — потому что «нужно больше коммуницировать» или “просто выступай чаще!” (спасибо, Кэп).

Я предлагаю вам узнать про несколько работающих решений, которые применял и нащупал сам (в том числе расскажу про то что не сработало для меня):
- Практические стратегии карьерного роста для тех, кто предпочитает substance over style:
- Неформальное лидерство: как зарабатывать авторитет через менторство, внутренние инициативы, экспертную позицию и инициативу/ответственность.
- Стратегия «точечной видимости»: куда направлять усилия для максимального эффекта при минимальных «публичных» действиях.
- Работа с сопротивлением: как доносить идеи в организациях, где статус-кво сильнее инноваций.
Расскажу про мой путь: от технического специалиста до стратега — без «громких» заявлений, но с измеримым влиянием.

Что вы получите:
- Чек-лист понятных шагов для роста «тихого профессионала».
- Конкретные кейсы трансформации личного влияния.
- Инструменты для навигации в корпоративных реалиях.
- Бота для оценки своего профиля с рекомендациями прямо на докладе (идея в проработке)

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

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

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

Этот доклад - о том, что дальше. Что за следующим карьерным уровнем стоит не только компетентность и эмпатия, но и освоение качеств, которые часто кажутся “неправильными”: здоровый нарциссизм, умение вести жесткие переговоры и проявлять агрессию, ощущение одиночества. Мы поговорим о "тёмной стороне" лидерства, о том, как научиться её использовать для роста, сохраняя этичность и опору на ценности.

Что будет с зубами, если их не чистить? Недели, месяцы, годы.
Примерно то же происходит с психическим состоянием, за которым не ухаживают.
Зубам-то повезло, их видно.
С ментальной гигиеной есть одна маленькая проблемка: люди в теории соглашаются с тем, что это важно и nice to have, но им некогда и неохота выделять внимание и время, чтобы на постоянной основе заботиться о том, чтобы в голове было "проветрено", напряжение не накапливалось и был нормальный уровень энергии для работы и жизни.
Проблема замечается тогда, когда человек уже выгорел, его качество жизни на дне и никакой энергии и в помине нет.

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

Ментальная гигиена - это очень просто. Вы не знаете, с какой стороны к этому подступиться и что именно выбрать из сотен инструментов, которые "обязательно надо делать".
Я дам вам 5 простых, понятных, быстрых и научно доказанных инструментов, и вам хватит их на всю жизнь, чтобы поддерживать свою психику в прекрасном состоянии. Предложу алгоритм, как внедрить практики в свою жизнь на постоянной основе.
Также мы обязательно потренируемся физически управлять своим вниманием и вернем себе контроль над этим важнейшим психическим процессом, который в последние годы совершенно отбился от рук (СДВГ, привет!)

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

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

Первая часть этой серии докладов про прозрачную культуру коммуникаций “Игра в открытую” была про то, как уметь приносить плохие новости, особенно тем, кто для нас значим. Но что делать, если проблема на столе адресована лично тебе? Когда тебе задают неудобный вопрос на all-hands, прямо указывают на промах или нарушают границы?

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

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

Witherwill случается, когда вы истощены от необходимости постоянно принимать решения, когда усталость превращается в безразличие. Если вы хоть раз хотели всё бросить и уйти в горы - вы понимаете о чем речь!)

“Ничего не хочется делать, вы не делаете, а легче не становится” - это оно. Witherwill живет за две ступени до выгорания, если заметить первые признаки, можно не дойти до уголька.
Поговорим о том, как
*снять ответственность, чтобы вас не уволили;
*отдыхать без угрызений совести;
*реанимироваться, пока команда не заразилась вашим состоянием.

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

Разберемся, как работать с сопротивлением и придти к успеху)

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

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

Когда трава была зеленее, а тезисы к конференции писал не ИИ, слово «тимлид» часто означал просто самого сеньористого разработчика. Код быстрый, переменные цветные — а вот с людьми как получится. Но в реальности хороший тимлид — это не про код, а про лидерство, развитие команды и управление сложностью.
Мы в hh.ru захотели системного подхода: чтобы руководителями становились те, кто действительно хочет и может ими быть. Так появилась наша модель компетенций тимлида. Мы не просто набросали чек-лист — мы годами оттачивали модель, делали её живой, точной и применимой. Сейчас она используется для оценки, обратной связи, карьерных решений и развития.
В докладе расскажу, как мы подошли к разработке модели, как проходили путь от «давайте напишем» до внедрения в культуру, и как живём с ней сейчас.

Сейчас на рынке сильный тренд в бизнес ориентированную разработку, процессы дискавери становятся более понятными и формализованными, что действительно позволяет передавать все больше ответственности при принятии продуктовых решений в разработку. Это понятная и ожидаемая тенденция, которая на горизонте нескольких лет добавит пару пунктов в требования к тимлиду. Бигтех уже набирает тимлидов с учетом понимания продуктовой базы.
Такой подход сильно экономит ТТМ и улучшает качество продукта, поскольку именно разработчики могут увидеть картину целиком, предположить корнер кейсы и ограничения, предложить оптимизировать образ решения под более простую реализацию, и выпустить фичу раньше для тестирования продуктовой гипотезы
Понимание целей и задач продукта помогает расти по карьерной лестнице: чем выше грейд, тем больше влияние на продукт и количество около продуктовых решений
В докладе я расскажу как и когда подключаться к планированию и «придумыванию» фичей, как приносить бизнесу ценность и при чем здесь double diamond

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

Счастливый сотрудник эффективнее на 15%, посчитали ученые. Ок, хочу, дайте мне много счастливых команд, сейчас как рванем!! Эээ, а как? Что я, как тимлид или менеджер, могу сделать, чтобы повлиять на это неуловимое состояние. И себе хочу.
Мы рассмотрим 10 научно доказанных (двойное слепое вот это все) практик, которые усиливают счастье человека (а если не делать, усиливают несчастье). И это не так сложно, попробуем прямо сейчас.

Типичное ретро начинается с фраз «что было хорошо», «что пошло не так» — и заканчивается экшенами, которые на которые потом забивают. А что если анализировать работу команды не только на основе личных ощущений, но и смотреть на цифры?
В hh.ru мы стараемся принимать решения, опираясь на данные — будь то продуктовые, технические или процессные решения. Метрики есть почти у всех, но часто непонятно, как с ними работать. Мы расскажем, как сделать так, чтобы метрики начали работать на вас, помогали принимать решения и развивать команду.
В докладе поделимся, как мы проводим ревью работы команды с опорой на данные: какие метрики используем, какие не прижились, как формируем обсуждение так, чтобы никому не было больно, и как цифры помогают находить скрытые проблемы и расти. Будут реальные кейсы, примеры и формат, который можно унести с собой.

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

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

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

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

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

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

Мотивация — это не магия. Иногда достаточно перестать мешать людям хотеть работать.

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

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

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

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

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

Обо всём этом — на основе реального опыта, ошибок и работающих решений — поговорим в моём докладе.

Мы, тимлиды, мечтаем о командах без конфликтов: эти бесконечные "разборки" надо решать, они высасывают энергию на то, чтобы всех помирить или договориться до того, как жить дальше. Поэтому мы так гордимся фразой: “У меня дружная команда!”. А действительно настоящая человеческая дружба – это классно для команды? Или тут срабатывает своя “Big Friend Theory” – где дружба может и помогать, и взрывать рабочие процессы?
В докладе открою обратную сторону медали: когда и кому корпоративная дружба может быть полезна, а когда внезапно может привести к ещё большим проблемам, чем просто конфликты.
Поделюсь реальными кейсами и типичными граблями, по которым мы проходимся. А главное – разберёмся, что делать тимлиду, чтобы сохранить команду, но при этом вырастить взрослых сотрудников, умеющих строить границы между личным и рабочим.

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

О том, как сделать ее рабочим инструментом и не нанимать специального человека в команду, я расскажу в своем докладе.

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

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

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

В докладе разберу:

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

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

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

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

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

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

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

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

Часто ли вы замеряете связанность и связность (или прочность) на своих проектах и системах? А на энтерпрайз-архитектуре? :) Впервые начав измерять эти архитектурные параметры на разных архитектурных уровнях, мы приходим к тому, что связанность (coupling) и прочность (или связность, cohesion) — это про примерно одно и то же, и может возникнуть недоумение — почему тогда одно из этого — хорошо, а другое — почему-то плохо? :) Давайте разбираться.

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

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

Поделюсь ссылкой на свой OpenSource-репозиторий с инструментами для измерения архитектурных метрик и покрытия архитектуры тестами (и приглашу всех стать контрибутерами). И, надеюсь, добавлю в вашу копилку +1 принцип проектирования распределенных систем :)

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

В этом докладе я расскажу, как работает наша спецгруппа быстрого реагирования (SWAT/Tiger Team) в Авито:

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

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

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

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

Рассказ является логическим продолжением прошлого выступления SLI/SLO/SLA в микросервисном приложении.

Какие инженерные практики действительно экономят деньги, а какие — просто красиво звучат?
Как перевести инженерные решения в язык метрик, денег и эффектов?
Что говорят об этом DORA, SRE и Software Engineering at Google?
Покажу формулы, кейсы, реальные расчёты и антипаттерны — и помогу вам объяснить бизнесу, зачем нам вообще всё это нужно.

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

Техлиду на заметку — как встроить AI в каждый этап разработки
Расскажу как использовать искусственный интеллект при запуске MVP
Как автоматизировать автотесты, код-ревью, написание документации
Поделюсь инструментами которые реально работают в продакшене
Покажу как встроить AI в существующий процесс разработки без ломки пайплайна
Разберём что стоит автоматизировать в первую очередь
И какую роль должен сыграть техлид чтобы команда приняла эти изменения
В конце дам чеклист как начать внедрение AI в разработку

Тимлиды и команды часто сталкиваются с перегрузкой, хаосом в спринтах и невозможностью нормально планировать. Все вокруг говорят о каком-то потоке или процессе, но откуда их взять и с чего начать строить? Я покажу вам собственный, авторский метод декомпозиции, который я разработал в боевых условиях: без лишней теории, но с реальными результатами — сокращение времени на delivery, повышение предсказуемости, снижение переработок. Доклад подойдёт тем, кто хочет навести порядок в команде, но уже устал от книжных рекомендаций.
Будут реальные кейсы, примеры шаблонов и честные фейлы. Всё можно применить сразу на следующем планировании.

Почему этот доклад важен именно сейчас:
Все устали от поверхностных гайдов. Я дам вам свою методику, отработанную на реальных проектах в двух крупнейших банках нашей страны. В первом метод родился, во втором стал локомотивом построения того, что называют управляемый поток ценности.
Декомпозиция — на удивление, больная тема для большинства команд, а ведь от нее зависит адекватность оценок, правильный порядок выпуска функционала, сама возможность выпуска MVP и запуска инкрементального производства. Распределение ролей, velocity, capacity, предсказуемость и прочее бинго.
Команды часто перегружаются из-за плохой структуры задач, особенно когда тимлид не участвует в формировании задач или делает это «на глазок», а как результат страдает бизнес, получающий не то, не тогда и не в том качестве. И это не делает жизнь Тимлида и команды счастливой.

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

Чего достигли наши команды благодаря "Трём карандашам":
Сокращение ТТМ по бизнес эпикам с 9 до 1,5 месяцев
Точность оценки достигла требуемых 85-90% гарантии поставки.
У команд появился ритм.
Удовлетворённость участников команд поднялась на 25% (по результатам исследования CSI)
Удовлетворённость бизнеса поднялась на 43% (по результатам исследования CSI)

Про метод.
Я его создавал, как инженер для инженеров - просто и наглядно. На самых минималках вам потребуется лист бумаги и три карандаша: синий, зелёный и красный. Конечно, со временем метод обрел структуру, ритуал и теорию, но под ними таже простая инженерная база, что и в день рождения метода:
Канвас груминга - лист бумаги, разделенный по вертикали на три области:
- Чужой бэк (внешние зависимости)
- Фронт или бизнес-логика
- Наш бэк
Три принципа груминга:
- Трёхзвенная архитектура
- Принцип работы пользовательского интерфейса
- и собственно, сами "Три карандаша"

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

Что мы с вами обсудим ещё:
- Почему “Три карандаша” занял своё место в разработке и стал основой для разработки на большом предприятии?
- Как он решает проблемы кроссфункциональности разработчиков, согласования требований между командами, стримами, департаментами?
Как он помогает решать проблему онбординга новых разработчиков в команду?
- Где в “Трёх карандашах” место старым добрым и хорошо проверенным User Story Mapping, Customer Journey Mapping, Gherkin, INVEST, story slicing?

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

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

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

Обсудим, какая роль менеджера и административный флоу для организации, согласования и утверждения релиза. Ну и, конечно же поговорим про техническую сторону: различные Git-flow, стратегию версионирования, обязательные проверки, организацию CI/CD и выбор инструментов.

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

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

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

RAG один из самых популярных методов работы с LLM чтобы обогатить ее реальными и актуальными данными и уменьшить галлюцинации.

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

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

Кажется, неделя прошла. А что именно сделано — сформулировать сложно. На мастер-классе мы научимся превращать лог повседневной работы в инструмент самоанализа. Вместо контроля и учёта — работа с выводами, осмысленное резюмирование, привычка возвращать себе внимание и ясность. Итогом станет не просто журнал событий, а личная запись, в которой отражён опыт, мысли и следующее действие.

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

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

Воркшоп, где вы ощутите на себе, что ничегонеделание — это трудно.

Что нужно? Ничего! Просто приходите и будем вместе учиться отдыхать от ответственности, не избегая ее.

Креативная практика на создание вашего варианта никсен-слота, практическая часть доклада «Witherwill: тренд общества усталости, или как отдыхать от ответственности». Если вы не были на докладе, но устали от необходимости постоянно принимать решения — тоже добро пожаловать, в начале будет краткое интро о целях практики.

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

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

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

Пожалуйста, обратите внимание: видеотрансляция и запись мастер-класса вестись не будет.

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

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

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

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

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

В ИТ-командах, где всё постоянно меняется — сроки, задачи, заказчики — важно быстро ориентироваться и находить решения на ходу. Однако часто руководители и сотрудник сталкиваются с типичными затруднениями:
1. Не успеваешь подобрать нужные слова в моменте — нужные аргументы приходят, когда всё уже закончилось. Это классический «лестничный синдром».
2. Идеи повторяются — одни и те же шаблонные решения, которые не вдохновляют ни команду, ни клиентов.
3. Нестандартные ситуации вызывают ступор, особенно когда нет инструкции «как правильно».

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

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

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

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

Speed Networking — это нетворкинг для всех, кто хочет познакомиться с другими участниками конференции без особых усилий. Для участия необходима регистрация в месте проведения формата. Количество мест ограничено, запишитесь заранее❗️

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

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

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