Программа — TeamLead Conf

Секция: TechLead

Готовый код сам по себе не объясняет, за что бизнесу платить дальше. Разберу работу Forward Deployed Engineer: как понять процесс заказчика, согласовать нужный результат, выбрать решение и проверить, что им пользуются. Покажу, где эта работа пересекается с ролью техлида и Product Engineer, а также где в этой работе помогает AI.

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

• АГАлександр ГончаровГК Юзтех

Секция: Кругозор

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

Сначала люди. Мы первыми на российском рынке провели полную трансформацию в продакт-инженеров: в нашем бизнес-юните больше нет ролей SA/QA/Ops - продакт инженер владеет изменением целиком.

Потом агенты. С лета 2026 года типовой продуктовый код пишет только Atomic, наш автономный harness. Инженер отвечает за постановку, проверку результата и среду, в которой агент достигает успеха. Наш lead time за год сократился в 36 раз по медиане и в 44 раза по 85-му перцентилю.

Разберём:

— почему продакт-инженер оказался условием AI-native трансформации

— какие договорённости команды сделали новый способ работы основным, а не пилотом

— что, на наш взгляд, будет дальше

• АУАндрей УсенкоРайффайзен Банк

Секция: Оптимизируй свою команду

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

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

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

• АБАнастасия Бутова-НикишинаProLeadersLab®

Секция: Кругозор

Чем опытнее специалист, тем сложнее изменить его привычный способ работы. Просто рассказать senior-разработчику, как правильно делегировать, проводить 1:1, давать обратную связь или наставлять коллег, недостаточно: знание о правильном действии ещё не превращается в новую практику.

В докладе я не только расскажу, но и покажу образовательную модель КСТ³, как развивать сильных взрослых экспертов через цикл профессиональной пробы: первичная проба → наблюдение → обратная связь → перепроектирование → повторная проба.

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

• ДСДарья СальниковаЦДПО МГПУ

Секция: Митапы и мастер-классы

Формат: мастер-класс

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

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

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

• ЮБЮрий БариевНезависимый эксперт

Секция: TechLead

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

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

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

• ИПИван ПоддубныйCTO, Вебпрактик

Секция: Оптимизируй свою команду

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

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

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

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

• АААлександр Апазидиментор CIO/CTO, преподаватель Яндекс Практикума и Стратоплана, Независимый эксперт, ментор CTO (Apazidi IT)

Секция: Оптимизируй себя

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

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

• ВСВладислав СазоновАльфа-Банк

Секция: База

Формат: мастер-класс

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

На реальных кейсах участники узнают:

— как выбрать задачу для первого ИИ-пилота

— как работать с сопротивлением команд

— как не принять формальную активность за реальный результат

— по каким признакам и метрикам пересобирать или останавливать проект

— как превращать ошибки внедрения в основу для более сильного проекта

• ПМПавел МягкихДиректор по ИТ Solfer, эксперт Школы управления СКОЛКОВО

Секция: Оптимизируй свою команду

Переход к кросс-функциональным командам меняет привычные процессы внутри инженерных функций.

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

— Кто отвечает за развитие специалистов?

— Как сохранить единые стандарты качества?

— Что происходит с техническим долгом?

— Как меняется роль лида?

— И почему senior в одной команде может не быть senior в другой?

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

• ДДДаниил ДемитровUzum

Секция: TechLead

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

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

Вместо универсального рецепта я хочу предложить систему координат для к самодиагностики:

— как определить текущий уровень зрелости процессов?

— где искать ориентиры?

— как составить реалистичный план постепенного перехода к aвтономным агентам?

— и как наконец-то построить ту самую темную фабрику?

• СЧСергей ЧистяковРайффайзен Банк

Секция: Оптимизируй свою команду

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

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

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

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

• ДДДанила ДрапезаАкадемия управления WINbd

Секция: Оптимизируй свою команду

Что делать, если требования меняются каждый день, приоритеты пересматриваются, договорённости теряются в чатах, а команда всё чаще спрашивает: «О чём мы вчера договорились? А почему мы именно такое решение выбрали?»

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

• ЮАЮлия АликинаSolopreneur

Секция: База

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

— Как устроена моковая задача: учебный кейс, через который новичок с первого дня знакомится со стеком, библиотеками и git-flow на практике, а не просто читает документацию

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

— Как за две недели на 80% подготовить новичка в бизнес-задачам: что остаётся после онбординга и почему остальное он легко подхватывает уже в команде

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

— Почему можно обойтись без дорогих инструментов: достаточно трекера с задачей, документации и людей

• ЮНЮлия НестероваWildberries & Russ

Секция: Оптимизируй свою команду

Формат: мастер-класс

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

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

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

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

• ВВВероника ВинокуроваШкола выбора профессии "Пункт Б"
• НННата НовоселоваШкола выбора профессии "Пункт Б"

Секция: TechLead

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

• АУАндрей УсенкоРайффайзен Банк
• ВСВладислав СазоновАльфа-Банк
• ГМГлеб МихеевСбер
• ИПИван ПоддубныйCTO, Вебпрактик

Секция: Оптимизируй свою команду

Большие проекты примерно так и устроены: требования появляются позже разработки, скоуп растёт быстрее команды, а вопрос «сколько людей нужно, чтобы сделать завтра?» почему-то звучит совершенно серьёзно.

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

• МНМария НасыроваЯндекс

Секция: База

Руководство массово внедряет AI, требуя от команд стать «AI-Native» и заваливают разработчиков подписками. Однако вместо ускорения тимлиды сталкиваются с деградацией кода, скрытой нагрузкой и новыми рисками для процессов.

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

• МММаргарита МоногароваAltenar

Секция: Митапы и мастер-классы

Формат: мастер-класс

Практический мастер-класс по проведению командных брейнштормов.

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

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

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

• АНАлександра НефедоваНезависимый фасилитатор