Доклады и форматы

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

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

AI резко сократил путь от идеи до работающего прототипа, но ему все еще не получается делегировать задачу выбору одной идеи которую нужно проверять. На кейсах запуска B2B-продуктов и новых направлений в Яндексе покажу подход, при котором команда старается получить доказательства до полноценной разработки. Разберём четыре фильтра: есть ли реальная проблема, а не просто интересная идея;есть ли сильный сигнал со стороны клиента или пользователя;какой самый дешёвый эксперимент способен опровергнуть гипотезу;как заранее определить условия kill / iterate / scale;денежный и рыночные критерии. Покажу, когда вместо MVP нужен разговор с клиентом, когда — ручной процесс, когда — прототип, а когда действительно пора писать production-код. Участники получат одностраничный шаблон проверки гипотезы, который можно использовать со своей командой.

Почти половина разработчиков тратит от 5 до 10 часов в неделю на ревью кода, но так ли эффективно тратится это время? В докладе мы разберём, что не так с типичным процессом создания pull request. Проанализируем ключевые статьи и исследования на эту тему, систематизируем частые проблемы и сопоставим рекомендации с реальным опытом команд Яндекса: что из лучших практик прижилось, что не сработало, и какие конкретные привычки помогли сократить время ревью.

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

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

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

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

Переход к кросс-функциональным командам меняет привычные процессы внутри инженерных функций. Если раньше аналитика работала как сервисная команда, то в матричной организации появляются новые вопросы. Кто отвечает за развитие специалистов?Как сохранить единые стандарты качества?Что происходит с техническим долгом? Как меняется роль лида?И почему senior в одной команде может не быть senior в другой? На примере трансформации data-функции в команде Uzum Fintech разберём, какие изменения действительно приходится пережить при переходе к кросс-функциональной модели, какие проблемы оказываются неизбежными, а какие можно предусмотреть заранее.

Разработчик настаивает на переписывании легаси, показывая страшные графики. Продакт давит дедлайнами, намекая на провал квартала. Архитектор запугивает «отставанием от Netflix». Аналитик подаёт решение как единственно верное, умалчивая о рисках. Знакомо? Это ежедневная реальность IT-команд. Мы называем это «влиянием», «аргументацией», «лидерством». Но часто за этим стоит неосознанная манипуляция, которая разрушает доверие и выгорает команды. Эта мастерская — для всех, кто устал от токсичных игр. Мы соберёмся, чтобы: признать проблему вслух: с помощью интерактивного голосования и живых скетчей мы увидим, как манипуляция выглядит со стороны разработчика, менеджера и аналитика;разобрать наши общие боли: в группах по ролям мы анонимно разберём реальные кейсы участников: когда вами манипулировали и где вы сами перешли грань;создать общий договор: совместно — разработчики, аналитики, менеджеры — сформулируем принципы «Манифеста честной коммуникации в IT». Это будут не абстракции, а конкретные правила: «как говорить о рисках», «как не использовать FOMO», «как давать обратную связь без давления». Итог: Вы уйдёте не только с инсайтами, но с личным обязательством и готовым артефактом для вашей команды — набором правил, которые помогут вам договариваться честно, без скрытых игр.

Переход на позицию руководителя команд такого же или более высокого уровня может представлять собой настоящий challenge даже для опытных руководителей и тимлидов, имеющих солидный профессиональный уровень и значимый послужной список. Конечную проблему можно обозначить так: вы были топ-перформером в прошлой компании, но при переходе в новую команду огромная асимметрия знаний между вами и людьми в новой компании по полгода и более держит вас в середнячках или того хуже - в кандидатах на вылет. Ваша адаптация в новой среде существенно затягивается, и дело здесь может быть не только в уровне новой команды. Часто практика адаптации тимлидов различных уровней не поставлена в компании на системные рельсы, делается от случая к случаю по принципу AS IS (делаем как можем и как умеем) и имеет длинные и непредсказуемые сроки реализации (от месяца до девяти месяцев). Руководители же тимлидов и пиры часто не располагают достаточным бюджетом времени на системную передачу знаний и обучение. Для условно уникальных позиций (например, CTO AI стартапа) говорить о системной практике адаптации и вовсе крайне трудно, поскольку она не носит массового характера и «золотой стандарт» попросту отсутствует. Новая среда может предоставлять весьма ограниченный объем помощи в адаптации в новой команде для ее нового руководителя. Принципы самоадаптации могут позволить не только упростить адаптацию в новой команде и сделать ее более предсказуемой и обозримой по срокам, снизить риски менеджерского фиаско, но и де-факто позволяют в условиях ограниченной внешней помощи во многом взять этот процесс в собственные руки. В докладе на основе многократного личного опыта перехода teamlead=> teamlead, а так же team lead => CTO расскажу, какие практики самоадаптации можно применять, чтобы повысить эффективность адаптации и осуществлять вход в новые команды более просто.

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

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

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

Цивилизованный выход: как расставаться с сотрудниками без конфликтов и репутационных рисков.Дело не в тебе, дело во мне: как подготовиться ко встрече? Собираем себя на сложный разговор.Увольнение сотрудника по инициативе работодателя: можно ли сгладить углы?Давай останемся друзьями. Что такое Alumni Management и зачем поддерживать отношения с бывшими?

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

При автоматизации бизнес-процессов с помощью LLM и мультиагентных систем ошибка модели может быстро превратиться в полноценный инцидент: от утечки персональных данных и обхода внутренних политик до выполнения опасных действий через tools и потери контроля над частью инфраструктуры. В докладе разберем ключевые риски LLM-приложений, почему их нельзя закрыть только промптами или дообучением модели и где проходит граница между безопасностью и полезностью системы. Поговорим о guardrail-подходах на уровне архитектуры: контроле входов и выходов, работе с контекстом, black-box и white-box методах, фильтрах и классификаторах, а также защите агентных сценариев. Отдельно разберем, как валидировать защитные слои: использовать открытые бенчмарки, интерпретировать ASR и FPR и собирать собственный тестовый набор под конкретный домен. В завершение рассмотрим, как собрать базовый guardrail-контур на open-source решениях, оценить его ограничения и понять, насколько такой защите можно доверять в реальном продукте.

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

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

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

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

Кризис смыслов в инженерных командах идёт давно, а с приходом ИИ он ускорился. Название доклада это аллюзия к работе Бердяева 1916 года, где он написал, что человек оправдывается не послушанием закону, а творчеством. Мы будем говорить об инженерах. Сегодня этот вопрос стоит перед каждым, кто управляет инженерами: машина забрала операцию, с которой раньше тебя отождествлял инженер. Чем он теперь оправдан и как им управлять? Многие компании встретили ИИ логикой послушания: больше задач, больше токенов, больше результата. Инженеры закрывают задачи, не понимая, зачем они нужны, а проблемы решают перебором. Так появляется инженерная графомания: команда выглядит занятой и нужной, а копится когнитивный долг. Руководитель видит много сделанного и всё меньше понимает, что из этого действительно работает. В докладе разберём смысл на детали: из чего он состоит, где теряется и как его вернуть в работу команды. Поговорим о том: как отличить уместный перебор от деградации инженерной работы;почему люди держатся за старые роли и чем управлять, пока новые не сложились: позициями, замыслом и местом для мышления, а не должностями и токенами;какими приёмами помочь инженеру подняться к смыслу, найти творческий ход и вернуться с ним в практику;как случается творческое мышление и как создать контекст, чтобы такое мышление случалось чаще.

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

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

Архитектурная ката — это короткое, сфокусированное упражнение, в ходе которого IT-специалисты разных профилей совместно проектируют решение для конкретной технической задачи. В процессе выполнения каты необходимо исследовать различные архитектурные подходы, выявить скрытые риски и найти оптимальное решение. Ключевые принципы: Ограничение по времени: фокусировка на результативности. Конкретная цель: четко сформулированная проблема для решения. Разнообразие мнений: участвуют специалисты разнообразного профиля со своим уникальным опытом. Безопасная среда: голос каждого важен. Командная работа важна. Что это позволит? Сконцентрироваться на high-level design. Отойти от кода и рутины. Научиться мыслить паттернами, искать узкие места до реализации решения. Это позволит в дальнейшей практике разработки сэкономить время и силы на итерации рефакторинга и переработок. Поскольку это командное соревнование, получаем приятный бонус — нетворкинг. Имитация решения архитектурной задачи в ограниченное время с умением слушать друг друга. "В конце победит дружба!" — пресное завершение архитектурной каты. Защита решения будет проходить перед участниками и жюри с итоговой оценкой. Если не страшно — you are welcome! Количество команд и участников ограничено таймингом!

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

Большинство подходов к карьерному планированию предполагают, что человек может ответить на вопрос: «Кем я хочу быть дальше?» Но у многих IT-руководителей проблема сегодня возникает раньше. Они не уверены: нужна ли им вообще следующая управленческая ступень;какая часть их прежней экспертизы будет ценна на фоне AI;остаются ли они руководителями потому, что действительно этого хотят, или потому, что уже слишком много вложили в эту траекторию;чего они хотят больше - влияния, денег, свободы, экспертности, статуса или другой организации жизни;какой из возможных сценариев реален, а какой хорошо выглядит только в голове. В докладе предлагаю пять неудобных вопросов, через которые руководитель может проверить свою нынешнюю стратегию. После каждого вопроса участники получат конкретный принцип и практический карьерный инструмент. Главная идея: тревога требует определённости, а карьерная стратегия требует данных, поэтому задача - научиться создавать несколько возможных ходов и проверять их раньше, чем придётся принимать большое необратимое решение.

Рост внутри компании, новые карьерные предложения и монетизация экспертизы требуют разных действий. На мастер-классе каждый участник сначала определит свою цель, затем разберёт уже имеющиеся инструменты - профессиональный профиль, соцсети, кейсы, публикации и выступления - и выберет те, которые помогут её достичь. Рассмотрим 3 стратегии под задачи: если вам нужен ЛБ потому, что вы хотите дополнительный заработок или выйти из найма;если вы хотите получать больше других в своей компании; если вы хотите перейти в другую компанию. Разберем инструменты ЛБ и как их связать в последовательный личный план на 2027 год. Что получат участники: системное представление об инструментах развития личного бренда и понимание, с чего начать в своей ситуации;сформированную задачу и план действий;разбор существующих профилей и материалов с идеями, что улучшить;проработку личного позиционирования и тренировку публичных выступлений; личный план на 2027 год;в подарок — методичку Светланы Меншиковой «Сам себе пиарщик», к которой можно вернуться при выполнении плана.

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

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

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

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

Формат: интерактивный практикум с AI-тренажёром по сложным разговорам Как сообщить сотруднику о неудовлетворительных результатах? Отказать в повышении? Обсудить конфликт, в котором обе стороны уверены в своей правоте? Сложные разговоры входят в работу тимлида, но готовиться к ним по-прежнему непросто. ИИ может помочь подобрать слова, продумать аргументы и отрепетировать диалог. Но что произойдёт, если собеседник разозлится, начнёт спорить или отреагирует совсем не так, как мы ожидали? На афтепати вместе попробуем разобраться, на что способен AI-тренажёр сложных разговоров и как использовать его в работе руководителя. Что будем делать: пробовать вести сложные разговоры с ИИ на примерах из жизни тимлида;вместе исследовать ответы тренажёра: что помогает, что звучит искусственно, а что хочется попробовать в реальной коммуникации;обсуждать, в каких ситуациях ИИ действительно помогает подготовиться, а где его возможностей недостаточно. Можно будет принести собственный сложный сценарий или включиться в разбор предложенных ситуаций.

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

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

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

Контекстное окно разработчика: хороший тимлид и оркестратор агентов решают одну задачу — короткие проверяемые подзадачи, чекпоинты, контекст держит управляющий.Human-in-the-loop симметричен: вопрос агента к человеку и возврат ответа в живой процесс — та же механика, что эскалация от джуна.Оценка по фактам вместо памяти комиссии: какие сигналы собираем с конвейера задач, что сознательно выкинули.Где агент объективен, а где мы просто спрятали субъективность в промпт — честные границы подхода.Схема выбора режима управления (короткий контекст / автономия / сопровождение) — прежде чем оценивать человека, смотри, в каком режиме им управляли.

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

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

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

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

Обратную связь мы часто откладываем до последнего. Особенно развивающую: страшно, неловко, непонятно, как человек отреагирует и чем вообще закончится разговор. С позитивной тоже не всё просто: вместо полезной обратной связи получается либо дежурное «молодец», либо похвала, из которой непонятно, что именно стоит продолжать делать. BOFF помогает не заучивать готовые формулировки, а держать структуру разговора. Сначала факты: что именно произошло, без оценок и интерпретаций. Затем последствия. Потом собственная реакция и эмоции, без обвинений. И наконец, фокус на будущем: что мы хотим изменить, сохранить или сделать иначе в следующий раз. Главная сила BOFF в том, что одна и та же логика работает в очень разных разговорах: на performance review и после неудачной встречи, с сотрудником, руководителем или коллегой из соседней команды. На воркшопе разберём механику BOFF и посмотрим, где она чаще всего ломается на практике. Большую часть времени будем тренироваться. Каждый попробует себя в трёх ролях: того, кто даёт обратную связь, того, кто её получает, и наблюдателя. После воркшопа участники заберут модель с собой как инструмент, который действительно можно применить в следующем сложном разговоре.

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

Обычно в декабре с дергающимся глазом разрываешься между выполнением квартальных OKR и планированием следующего года, а еще нужно где-то взять силы на подготовку к праздникам… Давайте этот год завершим иначе? На мастер-классе мы разберем "формулу работоспособности" и вместе попробуем конкретные техники, чтобы: вовремя диагностировать утомление и понимать, есть ли когнитивный ресурс еще на одну задачу,управлять своим состоянием, возвращать концентрацию и настраивать мозг на продуктивную работу,снижать стресс и повышать бодрость, даже если есть всего 5 минут между созвонами,знать, когда и какую практику лучше применить, чтобы это действительно работало, а не тратило драгоценное время! Я расскажу, как именно эти упражнения воздействуют на организм и как бесшовно вписать их в свой день. Вы сможете сразу почувствовать эффект и собрать собственный "sos-чемоданчик", чтобы оперативно приводить себя в рабочее состояние. И конечно подзарядитесь энергией, чтобы взять максимум от следующих докладов!

Последние 20 лет я занимаюсь исследованиями в области искусственного интеллекта - как учёный, как руководитель студенческих коллективов, а в последние годы - как руководитель открытого исследовательского проекта и стартапа. И в своей работе я, играя роль тимлида, сталкиваюсь со знакомыми всем вызовами: сжатые сроки, меняющиеся требования, ограниченные ресурсы. Тем не менее, рассказывать я буду не про ИИ в менеджменте, как можно было бы подумать на основе моего опыта, а про вещи куда более фундаментальные, которые не устаревают с выходом новой LLM. Всё это время у меня было ещё одно занятие, на первый взгляд никак не связанное с IT - спортивный туризм. Я хожу в горы с 2009 года, три раза руководил категорийными походами (Крым, Кавказ), и во всех случаях группа возвращалась в полном составе. Чем дольше я совмещаю эти два мира, тем яснее вижу: у руководителя похода и у руководителя IT-команды - на удивление похожие проблемы, и походные практики отлично переносятся в проектную работу. В докладе разберём, что общего между походом и проектом, и как применять этот опыт для: принятия решений в условиях существенной неопределённости;предотвращения выгорания и потери мотивации в команде;эффективного управления рисками, когда цена ошибки высока. Я поделюсь не просто вдохновляющими историями про горы (хотя и это тоже!), а своими рабочими инструментами, проверенными на стыке очень разных сфер - от студенческой лаборатории до горного перевала.

Команда укомплектована. Задачи оценены. Все заняты. Разработка конкретной функции занимает несколько дней - но до ПРОДа она добирается несколько недель. Остальное время работа ждёт: приоритета, доступа, архитектурного выбора, согласования изменения API, подтверждения scope, решения о допустимом риске или ответа человека, который оказался обязательной точкой согласования. У инженерной команды есть два конвейера. Первый - delivery pipeline: разработка, review, тестирование и релиз. Обычно он хорошо виден в таск-трекере и инженерных метриках. Второй - decision pipeline: вопросы, варианты, согласования, эскалации и решения. Он часто существует только в чатах, встречах и голове руководителя. Поэтому команда выглядит медленной, хотя основная часть календарного времени уходит не на выполнение работы, а на ожидание возможности продолжить её. В докладе рассмотрим управленческие решения как отдельный поток с входящей нагрузкой, очередью, состояниями, владельцами, пропускной способностью и SLO. Научимся измерять Decision Lead Time, возраст открытых решений, время фактической блокировки delivery, концентрацию решений на одном человеке и долю вопросов, которые попали на избыточно высокий уровень управления. Это не доклад с выводом «нужно больше делегировать». Для разных классов решений нужны разные действия: убрать лишнее согласование, автоматизировать типовой выбор, превратить повторяющийся вопрос в политику, установить безопасное решение по умолчанию, уменьшить масштаб последствий, изменить маршрут решения или оставить его централизованным, если этого действительно требует риск. Аудитория станет руководителем, к которому одновременно поступят 15 запросов. Сначала попробуем отвечать быстрее. Затем наймём дополнительных разработчиков - и обнаружим, что вместе с производительностью команды вырос входящий поток решений, а очередь стала только длиннее. После этого перепроектируем систему: классифицируем решения по обратимости и blast radius, зададим decision SLO, определим владельцев, правила эскалации, решения по умолчанию и явные границы автономии. Участники получат шаблон карточки решения, карту полномочий, минимальный dashboard руководителя и план внедрения системы за 30 дней. Главная мысль доклада: задача руководителя - не стать самым быстрым человеком в очереди и не передать все решения вниз. Его задача - построить систему, в которой каждое решение принимается на минимально необходимом уровне, с достаточным контекстом, полномочиями и контролируемым риском.

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

ИИ — везде, но между «у нас есть доступ к нейросети» и «ИИ действительно изменил разработку» всё ещё пропасть. Раньше, чтобы обмениваться знаниями, люди объединялись в племена. Позже инженеры собирались в команды, ходили на конференции, читали документацию и искали человека, который помнит, почему сервис работает именно так. Знание всегда было распределено между людьми — его нужно было добывать. Сейчас любой разработчик может запросить контекст в чате, быстрее разобраться в незнакомой части системы, найти нужную экспертизу и перейти от вопроса к действию. И вместе с этим меняется сама роль бэкендера. Всё меньше ценности остаётся в механическом написании кода и всё больше — в умении правильно поставить задачу, спроектировать систему, дать ИИ нужный контекст, проверить решение и взять ответственность за итоговый результат. Инженер постепенно становится не только автором кода, но и архитектором среды, в которой часть работы выполняет ИИ. Мы уже прошли первый этап этого перехода на практике. За считанные недели ИИ из инструмента отдельных хай-перформеров превратился в повседневную практику команд. Это произошло не потому, что разработчикам просто выдали доступ к новым инструментам. Мы запустили «снежный ком»: находили работающие практики, быстро распространяли их через обмен знаниями и AI-амбассадоров, создавали мотивацию пробовать новое и постепенно превращали единичные успешные кейсы в новую норму работы. В докладе я разберу, как мы построили этот процесс и что нужно сделать, чтобы AI-adoption не остался набором разрозненных пилотов: как построить систему AI-adoption и запустить тот самый снежный ком изменений;как находить инженерные практики, в которых ИИ действительно даёт эффект, а не просто выглядит впечатляюще;зачем нужны AI-амбассадоры и как через них масштабировать новые способы работы внутри команд;как мотивировать инженеров менять привычный процесс, а не ждать, что новые инструменты приживутся сами;какие метрики выбирать, чтобы отличать реальный эффект от ощущения, что все просто стали работать быстрее. У нас уже есть результаты, и мы готовы ими делиться.

Руководитель редко приходит к консультанту с запросом «научите мою команду новому». Он приходит с запросом «измените их»: со мной всё в порядке, а люди почему-то не такие. Об этом мне рассказывали консультанты, трекеры и психологи — я провел интервью с двадцатью шестью экспертами о том, зачем к ним приходят. Но заметить, что рынок изменился, а команда всё еще работает по-старому, — только половина дела. Сильная команда сама тянется к новому: ей любопытно, она хочет попробовать первой и всё время ищет способы сделать лучше не в полтора раза, а на порядок. Расскажу, как команда становится такой. Для этого в ней должен работать эволюционный цикл: пробовать новое и закреплять то, что сработало. Без нового команда сначала застывает, а потом отстает от рынка. Без закрепления каждый раз начинает с прежнего уровня. А чтобы цикл не оборвался, нужна устойчивость к встряскам. Это не про железных людей, которым не страшна никакая буря, а про понимание: какие ресурсы нужны команде, от чего их беречь и что подготовить заранее, пока буря не пришла. Без этого команда рассыпается при первом серьезном испытании. Запускать цикл лучше, пока у команды есть силы и она открыта к переменам, — не дожидаясь спокойного времени, которое может и не наступить. Поговорим о том, как команда накапливает и использует опыт и почему на перемены нужен отдельный запас сил. Приведу примеры из работы в Яндексе, где за год пришлось нанять и обучить несколько десятков человек без службы найма и обучения, и из моего курса погружения в новизну, где участник после простого упражнения решил рабочую задачу, над которой двое коллег бились месяц. Объясню, почему так получилось. Прямо в зале сделаем одно упражнение. С собой вы сможете унести вопросы, по которым видно, растет ли команда, и практику, которую можно начать в понедельник.

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

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

Статус не даётся раз и навсегда - его можно менять, как костюм. Главное - это понимать, когда и как это делать. Каждый день мы ходим на встречи, где наше положение в команде или в глазах собеседника меняется: где-то мы лидеры, где-то наблюдатели, где-то просители. Чаще всего мы входим в эти роли неосознанно. А значит, отдаём инициативу другому человеку решать, кто мы в этой ситуации. На воркшопе разберём, как через тело осознанно входить в нужную роль и занимать позицию, которая помогает, а не мешает достигать цели. Покажем, чем "партнёр" и "лидер" отличаются от "жертвы" и "просителя" на уровне позы, взгляда и интонации. Воркшоп проводим совместно с актрисой театра и кино и ведущей корпоративных тренингов Анастасией Фоминой. Цель данного воркшопа: научить участников осознанно управлять своей ролью в коммуникациях. А также показать, как гибкость в позиционировании помогает достигать целей, сохранять партнёрский тон и уверенно вести себя даже в сложных ситуациях. Вы получите: опору на собственное тело в моменты волнения; навык "включать" нужную роль;понимание, как случайно не "провалиться" в роль просителя или наблюдателя;научитесь замечать, в какой роли находится сейчас ваш коллега

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

Рано или поздно любой руководитель сталкивается с потолком – лично или через сильного сотрудника в команде. Человек дошёл до уровня, к которому стремился, а дальше по логике вертикального роста есть только два хода. Подняться ещё на ступеньку-другую и всё равно упереться в кресло директора по разработке: оно одно, и оно занято. Или уйти в другую компанию, где через год всё повторится. Силы, готовность вкладываться и время есть, а понятного «куда» нет. Оба хода, как и совет «найди мотивацию», дают эффект новизны на полгода-год. Экспертный рост – не выход: можно преподавать, выступать, вести проекты на стороне, а на основной работе всё равно некуда деться. Все эти ходы чинят позицию, а «потолок» чаще всего означает не нехватку высоты, а отсутствие вектора – понятного «куда». Разберём: как отличить настоящий карьерный тупик от мнимого: выхода нет нигде – или он есть, но его не нашли, или нашли, но не готовы заплатить его цену (в деньгах, статусе, комфорте);как докопаться до реального запроса под жалобой «всё надоело»;как спроектировать следующий шаг, отталкиваясь от причины, а не от симптома, и учитывая ресурсы, риски, опоры и цену выбора – чтобы не упереться в новый потолок через два года. Подарок от спикера – рабочие инструменты: лестница вопросов, которая вскрывает настоящий запрос;детектор мнимой цели;карта ресурсов и рисков;навигатор «тупик – ход»;структура карьерного разговора с сильным сотрудником, который дошёл до потолка.

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

О чём воркшоп AI быстро пишет код, но проверять и принимать результат всё равно человеку. На воркшопе разберём, как использовать ATDD + AI + двойной цикл TDD, чтобы не получать большой diff «на веру», а вести AI маленькими проверяемыми шагами.Что будем делать На финтех-кейсе применим ATDD с AI: зафиксируем ожидаемое поведение в acceptance-тесте, отревьюим его до реализации, затем реализуем сценарий через короткие TDD-итерации с unit-тестами, AI-реализацией и рефакторингом. Покажем, как настраивать AI через prompt, skills или AGENTS.md.Что заберёте с собойалгоритм работы с AI через ATDD;рабочие промпты;пример настройки AI через skills или AGENTS.md;опыт на учебной задаче;понимание, где подход помогает, а где нужно что-то другое.Кому полезнотимлидам, которые хотят встроить AI в процесс команды;драйверам изменений, которые ищут управляемый способ внедрять AI-разработку;командам, где ошибка в бизнес-логике дорого стоит.Что понадобится Нужны ноутбук, IDE, чистый проект с тестами и доступ к AI-инструменту. Примеры будут на Java/Kotlin, но можно работать на Go, Python, C# или другом языке с тестовым фреймворком. Если будете без ноутбука — можно присоединиться к другим участникам или к модератору.

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

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

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

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

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

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

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

О том, что AI нужно встраивать в процесс, а не раздавать каждому по агенту, сейчас говорят многие. Мы прошли этот путь в разработке целого бизнес-юнита крупного банка и покажем, что получилось в цифрах. С 2025 года AI-агент был у каждого нашего инженера, а время до production вышло на плато: шаги ускорились, но задача по-прежнему шла по цепочке ролей, через передачи и очереди. Перелом дали не модели, а изменение содержания работы и редизайн производственного процесса. Сначала люди. Мы первыми на российском рынке провели полную трансформацию в продакт-инженеров: в нашем бизнес-юните больше нет ролей SA/QA/Ops - продакт инженер владеет изменением целиком. Потом агенты. С лета 2026 года типовой продуктовый код пишет только Atomic, наш автономный harness. Инженер отвечает за постановку, проверку результата и среду, в которой агент достигает успеха. Наш lead time за год сократился в 36 раз по медиане и в 44 раза по 85-му перцентилю. Разберём: почему продакт-инженер оказался условием AI-native трансформации;какие договорённости команды сделали новый способ работы основным, а не пилотом;что, на наш взгляд, будет дальше.

Мы расскажем о своем видении:  Особенности рынка ERP-систем и кастомизированных систем в России: ловушки и ограничения. Проектный треугольник уже давно не треугольник.  Стратегия кадрового суверенитета. Требования к специалистам. Почему нам нужны специалисты нового поколения.  Синергия и экономика win-win-win. Расчет инвестиций компании VS затраты на найм готовых разработчиков и аналитиков. Лояльность и ценности.  Архитектура карьерного трека. Масштабирование подхода по передаче опыта для создания самоподдерживающейся системы подготовки кадров без раздувания штата HR и случайных людей, зашедших не в ту дверь.  Как рассказать будущему специалисту об особенностях работы ИТ-сферы правдиво и с иронией за 15 минут, чтобы он сделал выбор учебной траектории: реальная «ИТ-прожарка» - вернемся в студенчество.

Экспертиза и репутация — не одно и то же. Экспертиза — то, что вы умеете. Репутация — то, что рынок об этом знает и может проверить за 3 минуты до интервью или сделки. Руководитель с сильными навыками, но нулевой видимостью, получает оффер на уровень ниже своих реальных возможностей — рынок оценивает не то, что есть, а то, что видно. На докладе разберём, почему руководители обычно не строят репутацию вовне — и почему обычные причины («нескромно», «некогда», «не знаю с чего начать») не выдерживают проверки практикой. Затем — из чего на самом деле складывается репутационный капитал: экспертная позиция в узкой теме, видимость в момент проверки, регулярность появления, а не разовые вспышки активности. В финале — практический алгоритм из 4 шагов, с которого можно начать на следующей неделе, без бюджета и без привлечения агентства.

Что узнают слушатели • Почему скорость нельзя купить — и что на самом деле покупают те, кто за неё платит. • Почему команда, в которой заняты все, — самая медленная. • Петля давления: почему после каждого «успели» становится только хуже. • Чем технический долг похож на кислородный — и почему банковская метафора [долга] нас обманывает. • К кому и когда на самом деле приходят проблемы «будущих разработчиков». • Почему команды легко режут функционал — и годами терпят то, что замедляет их самих. • Единственная инвестиция в разработке, которая окупается немедленно.

Устали от абстрактных разговоров о "лидерстве" и "коммуникации"? "Битва Лидеров" – это практический инструмент, превращающий 5 ключевых компетенций успешного тимлида (Командную работу, Принятие решений, Лидерство, Коммуникацию и Стратегию) в осязаемую игровую механику. Жетоны компетенций и признания становятся вашими наглядными метриками, позволяющими буквально увидеть сильные стороны и точки роста в ходе динамичного игрового сражения. Попробуйте необычный формат для оценки вашего текущего уровня и прокачки навыков в безопасной среде! Решайте реалистичные управленческие кейсы (Ситуации), оперируйте данными (Статистика) и проходите испытание командным диалогом и аргументацией (Открыт к Диалогу!). Бонус: вы не только продиагностируете свои навыки, но и активно потренируете критику, убеждение, активное слушание и командную синергию – все то, что делает лидера по-настоящему эффективным. Попробуйте управленческие решения в действии – где результат виден сразу!

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

Каждый тимлид сегодня живет в условиях идеального шторма: людей не хватает, бюджеты на материальную мотивацию урезаны, а сроки горят. Ситуация усугубляется, если ваша команда — кросс-функциональная. Как в таких условиях повышать производительность и растить команду, не тратя на это драгоценные часы разработки? Многие считают недирективный подход (командный коучинг) «долгой историей», на которую сейчас просто нет времени. Мы решили проверить это на практике. На докладе Елена Челокиди, пионер командного коучинга в России, впервые представит промежуточные результаты глобального исследования эффективности командного коучинга, проведенного на реальных командах из ТОП-компаний. Вы узнаете: — как измерить неизмеримое: эмпирические доказательства того, что командный коучинг напрямую влияет на производительность — почему недирективный подход парадоксальным образом сокращает временные издержки лидера на развитие персонала — специфика кросс-функциональных команд: какие барьеры съедают ресурсы и как коучинг помогает их обойти — практические нематериальные инструменты, которые тимлид может забрать в работу уже в понедельник, чтобы ускорить команду без дополнительных бюджетов

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

Мы представляем компанию Давай обсудим. Мы – команда психологов и специализируемся на проведении психологических исследований для компаний, консультаций для сотрудников, и обучении навыкам управления коммуникацией и конфликтами, работе в команде. Наш мастер класс будет направлен на тренировку ряда навыков, которые являются крепкой основой для того, чтобы профессиональное выгорание не сразило вас наповал., а именно: 1) Тренировка умения говорить «нет»- техники отказа собеседнику и корректного сопротивления, когда ссориться не нужно, а границы отстоять важно; 2) Тренировка реакции на фрустрацию (неприятное воздействие или событие) – как помогать себе реагировать на ситуации спокойнее и не разгонять внутреннюю тревогу; 3) Тренировка умению работать с эмоциональным напряжением- снижать его интенсивность. Эти параметры выбраны не случайно- мы опираемся на наиболее часто встречающиеся факторы, которые приводят к выгоранию сотрудников по результатам исследований (2023,2024, 2025 гг), которое мы проводили в 5 компаниях, которые работают в гибридном формате (удаленка+офис). Предоставим аналитику по внутренними (личностные качества сотрудников) и внешними(особенности организации процессов) факторами, способствующим выгоранию, приведем примеры решений (краткосрочных и долгосрочных) для снижения риска выгорания. Как раз наиболее частые ВНУТРЕННИЕ факторы мы возьмем за основу- потренируем те навыки, которые помогают справляться именно с этими факторами.

В своё время с собрал на базе Obsidian «операционную систему» собственной жизни — с методологией, отнологией ну и конечно с простенькими AI-свистульками. А потом я попробовал сделать то же, но AI-native — и задумался, а где AI реально усиливает, а где лучше обойтись без него.

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

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

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

• Исчезновение очень узкой экспертизы и 1-ой линии поддержки: почему дешевле обучить одного человека основам 40 систем, чем держать штаты из 40 экспертов первой линии. • Методология трехмесячного-полугодового квантового скачка: пошаговый разбор трансформации аналитиков 1С в универсальных интеграторов через модульное обучение смежным стекам и эмуляция инцидентов . • Единый цифровой паспорт объекта: создание общей базы знаний и визуального графа потоков данных, которые позволили специалистам диагностировать проблемы в незнакомых системах без обращения к разработчикам. • Метрики успеха новой модели: снижение MTTR (Mean Time To Resolution) на стыке систем на 40%, падение количества эскалаций на вторую линию и изменение профиля компетенций при найме. • Цена универсальности: управление рисками потери глубоких технических навыков и способы удержания таких дорогостоящих специалистов через ротацию между проектными задачами.

Почему появление цифрового сотрудника меняет не процессы автоматизации, а саму роль тимлида: руководитель начинает управлять не только людьми, но и системой выполнения работы.Чем цифровой сотрудник отличается от обычного AI-инструмента?Как определить, какие задачи можно отдавать ИИ-аналитику, а какие должны оставаться за человеком?Как перестроить командный процесс: постановка задач, приемка результата, проверка качества, прозрачность использования ИИ и новые рабочие интерфейсы внутри команды.Как оценивать цифрового сотрудника: скорость, стоимость, доля задач без доработки, процент корректных выводов, число эскалаций на человека, стабильность результата на повторяемых кейсах.Почему для ИИ-сотрудника нужны не только KPI, но и “режим развития”: изменение промптов, ограничений, контекста, базы знаний, сценариев проверки и политики применения.Как меняется структура команды аналитики: люди постепенно смещаются из роли исполнителей в роли постановщиков, ревьюеров, архитекторов решений и владельцев качества.Какие риски нельзя игнорировать: ложная уверенность в ответах, ошибки на неочевидных кейсах, bias, непрозрачность источников, утечки данных и подмена управленческого решения автоматическим выводом.Как не вызвать сопротивление у команды: важно объяснить, зачем вводится цифровой сотрудник, где он помогает людям, а где не заменяет человеческое суждение, и какие новые компетенции становятся ценными.Что тимлид должен уметь в новой модели?

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

• Решаемая проблема: Количество обращений в технической поддержке непрерывно растут, возникает острая необходимость пользователей в ответах 24\7, как выстроить процессы в команде технической поддержки, как включить в них ИИ, как провести переподготовку сотрудников для обучения нейросети, нежна ли подготовка пользователей к подобному подходу, на выступлении будет разобран реальный кейс формирования мультикомпетентной команды технической поддержки одним из участников которой стал ИИ. • : новая роль руководителя техподдержки — настройка алгоритмов маршрутизации и промпт-инжиниринг для ИИ вместо контроля дисциплины операторов. • Оптимизация нагрузки размерности L1-L3: внедрение внутренних ИИ-классификаторов, которые автоматически закрывают до 40% типовых запросов, проверяют скриншоты пользователей компьютерным зрением и готовят черновики ответов инженерам. • Человек в контуре принятия решений: выстраивание процесса где нейросеть берет на себя рутину сбора логов и диагностики, а сотрудник решает только нестандартные кейсы, требующие эмпатии, более глубокого анализа или архитектурного мышления. • Контроль качества без контроля прослушивания звонков: использование локальных языковых моделей для анализа диалогов чата и почты в реальном времени, мгновенная обратная связь оператору и выявление пробелов в базе знаний. • Борьба с галлюцинациями ИИ: разработка протоколов верификации ответов нейросети от «-Кто основатель Фирмы 1С? –Борис Николаевич Немцов!» до более сложных и правдивых. сотрудниками второй линии и Методы постоянного дообучения внутреннего ассистента на закрытых корпоративных данных. • На выступлении рассмотрим конкретный кейс команды технической поддержки систему 1С ERP 2.0 Цифровой Росатом, которые ежедневно отвечают на обращения сотрудников более 200 предприятий отрасли, как удалось увеличить количество корректных ответов до 60%, отдать 40% обращений ИИ, увеличить скорость выполнения обращений сотрудниками поддержки на 38%, а количество выполняемых обращений в день на 32%.

• Решаемая проблема: Количество обращений в технической поддержке непрерывно растут, возникает острая необходимость пользователей в ответах 24\7, как выстроить процессы в команде технической поддержки, как включить в них ИИ, как провести переподготовку сотрудников для обучения нейросети, нежна ли подготовка пользователей к подобному подходу, на выступлении будет разобран реальный кейс формирования мультикомпетентной команды технической поддержки одним из участников которой стал ИИ. • : новая роль руководителя техподдержки — настройка алгоритмов маршрутизации и промпт-инжиниринг для ИИ вместо контроля дисциплины операторов. • Оптимизация нагрузки размерности L1-L3: внедрение внутренних ИИ-классификаторов, которые автоматически закрывают до 40% типовых запросов, проверяют скриншоты пользователей компьютерным зрением и готовят черновики ответов инженерам. • Человек в контуре принятия решений: выстраивание процесса где нейросеть берет на себя рутину сбора логов и диагностики, а сотрудник решает только нестандартные кейсы, требующие эмпатии, более глубокого анализа или архитектурного мышления. • Контроль качества без контроля прослушивания звонков: использование локальных языковых моделей для анализа диалогов чата и почты в реальном времени, мгновенная обратная связь оператору и выявление пробелов в базе знаний. • Борьба с галлюцинациями ИИ: разработка протоколов верификации ответов нейросети от «-Кто основатель Фирмы 1С? –Борис Николаевич Немцов!» до более сложных и правдивых. сотрудниками второй линии и Методы постоянного дообучения внутреннего ассистента на закрытых корпоративных данных. • На выступлении рассмотрим конкретный кейс команды технической поддержки систему 1С ERP 2.0 Цифровой Росатом, которые ежедневно отвечают на обращения сотрудников более 200 предприятий отрасли, как удалось увеличить количество корректных ответов до 60%, отдать 40% обращений ИИ, увеличить скорость выполнения обращений сотрудниками поддержки на 38%, а количество выполняемых обращений в день на 32%.

Как не потерять себя в роли руководителя — на примерах из 13 лет управленческой практики в рознице, логистике, HR и IT

Эмпатия как суперсила: Почему отсутствие жестких Agile-сертификатов стало преимуществом, позволив сфокусироваться на людях, а не на слепом следовании догмам фреймворка.Психологическая безопасность как фундамент: Как фраза «какие-то изменения заходят, какие-то нет, и это нормально» снимает страх перед новым и легализует право на ошибку.Соавторство вместо подчинения: Как дать командам право выбора из «меню» опций, чтобы они чувствовали себя создателями процесса, а не его заложниками.Работа с сопротивлением через принятие: История о том, как команда, изначально заявившая «нам ничего не нужно», через два месяца сама пришла за внедрением, потому что ее услышали, а не сломали.Доверие как главная метрика: Почему без выстроенных человеческих отношений ни один, даже самый совершенный инструмент управления (вроде Канбана), не будет работать.

Рынок труда переживает очередной переворот и снова становится рынком работодателя. Несколько лет в Авито я каждую неделю (сейчас реже, вакансий меньше, конкуренция больше) собеседую тимлидов/юнит-лидов на всю компанию. Я подготовил обзор секций собеседования на руководителя, собрав основные типы из разных компаний разных размеров. На чем сфокусироваться для выбора кандидата при оценки менеджерского опыта? Какие есть красные флаги в эпоху AI? А что если ты готовишься к собеседованию на руководителя руководителей? Основная задача доклада: рассказать о разных типах отбора, сделать более прозрачным процесс, дать рекомендации из собственного опыта, подсветить типовые ошибки, попытаться улучшить качество профессии. Что с собой унесет слушатель: 1. Обзор всех секций, в т.ч. инновационных (AI fluency) 2. Соотношение секций и размеров реальных компании, критерии оценок 3. Чек-лист по подготовке к наиболее востребованным (оценка опыта менеджера) для тимлида и тимлида+ 4. Практические примеры с собеседований, corner-кейсы 5. Возможность внедрить в своей компании новые секции для повышения качества найма

«Когда я начинала этот проект, я не знала 70% ответов. 130 витрин, 66 отчётов, никакой документации. Срок — 10 месяцев, хотя бенчмарк — 2–4 года. И это самое честное, что я могу сказать про управление в условиях неопределённости.» За 40 минут я расскажу: Как говорить заказчику «мы подумаем, но ничего не обещаем» — и не потерять его доверие. Три типа людей, которые встречаются в каждом сложном проекте («молчун», «отшельник», «звонкий парень») — и конкретные стратегии для каждого. Почему «начать с лёгкого» — почти всегда ловушка, и как матрица с 7 критериями помогла нам нарезать скоуп без крови. Бонус: сравнение двух моих проектов — с сильной командой профессионалов и с командой из джунов. Когда «идём от сложного» работает, а когда нужны «маленькие победы». PM — он в первую очередь помогатор. И на старте занять эту роль не стыдно. Приходите — покажу, как. Кому точно стоит прийти Вы PM или TPM в DWH/Data-проектах У вас в команде или стейкхолдерах есть люди, с которыми сложно договориться Вы входите в проект, где много неизвестного, а сроки уже горят

КУРС — наш Корпоративный Удаленный Рабочий Стол. Буквально за пару месяцев мы построили инфраструктуру, начали подключать пользователей и очень быстро поняли: их уже более 5 000, и кто-то должен их поддерживать. Техподдержка — это не просто «вторая линия обороны». Это лицо продукта. По действиям этой команды и их отношению к проблемам пользователь формирует свое отношение к системе. Ему не важно, что там под капотом, ему важно, как отрабатывают именно его конкретную проблему. У нас не было ничего: ни людей, ни базы знаний, ни даже понимания, с какой стороны подойти к этой задаче. Мы не знали, сколько нужно специалистов, как их обучать, как измерять качество и вообще — с чего начинать. Но шансов отступить у нас тоже не было. Система уже взлетела, количество пользователей прирастало с каждым днем, а вопросы сыпались со всех сторон. Мы оказались в ситуации, когда назад дороги нет, а вперед — долгий и увлекательный путь создания новой команды. Сегодня это 14 человек, которые поддерживают более 20 000 удаленных пользователей. Четыре направления деятельности, структурированная база знаний, отлаженная система обучения, стажерская программа и полное отсутствие страха перед телефонным звонком. Мы прошли путь от хаоса к системе. И теперь мы не просто отвечаем на вопросы — мы формируем стандарты поддержки в отрасли.

КУРС — наш Корпоративный Удаленный Рабочий Стол. Буквально за пару месяцев мы построили инфраструктуру, начали подключать пользователей и очень быстро поняли: их уже более 5 000, и кто-то должен их поддерживать. Техподдержка — это не просто «вторая линия обороны». Это лицо продукта. По действиям этой команды и их отношению к проблемам пользователь формирует свое отношение к системе. Ему не важно, что там под капотом, ему важно, как отрабатывают именно его конкретную проблему. У нас не было ничего: ни людей, ни базы знаний, ни даже понимания, с какой стороны подойти к этой задаче. Мы не знали, сколько нужно специалистов, как их обучать, как измерять качество и вообще — с чего начинать. Но шансов отступить у нас тоже не было. Система уже взлетела, количество пользователей прирастало с каждым днем, а вопросы сыпались со всех сторон. Мы оказались в ситуации, когда назад дороги нет, а вперед — долгий и увлекательный путь создания новой команды. Сегодня это 14 человек, которые поддерживают более 20 000 удаленных пользователей. Четыре направления деятельности, структурированная база знаний, отлаженная система обучения, стажерская программа и полное отсутствие страха перед телефонным звонком. Мы прошли путь от хаоса к системе. И теперь мы не просто отвечаем на вопросы — мы формируем стандарты поддержки в отрасли.

Чтобы нанять одного senior-разработчика, вы пропускаете через воронку около двухсот человек. Один получает оффер. Остальные 199 уходят с отказом, из которого ничего не поняли. Через год, когда хороших опять будет мало и вы вернётесь к ним, — они к вам не вернутся. Рвётся всё в одном месте. Интервьюер пишет во внутренней системе «не тянет». Рекрутер отдать это кандидату не может и превращает в «решения были неоптимальными, для позиции нужны более узконаправленные навыки». Кандидат не понимает ничего и уходит. Что вы унесёте с доклада: — способ увидеть, где именно рвётся ваша цепочка «интервьюер → рекрутер → кандидат»; — форму фидбека, которую интервьюер заполняет за пять минут, и правило, по которому она собирается из ваших критериев оценки, а не из чужого шаблона; — формулировки отказа, после которых кандидат готов прийти к вам снова. Я провёл больше 250 технических интервью как интервьюер Яндекса и получил 20 отказов как кандидат — внятно объяснили дважды. Один такой отказ разобрал публично: компания прочитала, согласилась и наняла меня переделывать свой процесс обратной связи.

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

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

Мир был неопределенным всегда. Увлеченные научной рациональностью и классическими подходами менеджмента мы совсем забыли об этом. И даже сейчас, когда многие увидели глубину этой неопределенности мы по-прежнему ищем источники и островки стабильности и пытаемся непосредственно и прямо управлять ситуациями. Мы все еще верим в силу планирования и нашей способности предсказывать. Увы, очень часто это плохо заканчивается... Я расскажу о 5 управленческих ситуациях, с которыми часто сталкиваются лидеры и о том, какие ошибки они делают. 1. Ситуации, когда невозможно ясно увидеть и понять систему или ситуацию, и почему наше естественное стремление к ясности мешает, а не помогает. 2. Ситуации, в которых невозможно обоснованного планировать и покажу, почему это не наша ошибка, а свойство природы, с которым глупо бороться. 3. Системы/ситуации, в которых проявляется «эффект бабочки» и почему это ставит крест на линейном мышлении и прогнозировании. 4. Ситуации/системы, которым присущи глубокие, нередуцируемые противоречия, две силы, два антагонистических (враждующих) фактора, которые невозможно помирить. Почему лидер должен уметь удерживать оба противоречия и почему принимать одну из сторон и бороться против другой силы – это значит убить внутренний двигатель развития. 5. Существуют системы/ситуации, в которых возможно согласованное поведение ее элементов без управляющего воздействия – самоорганизация. И как в таком случае нужно управлять? Далее, я приведу пример вариантов управления детским праздником. Расскажу, почему эти управленческие ситуации можно считать сложными и как это меняет управление ими. В конце расскажу о б одном инструменте управления сложными ситуациями - методе Киневин для осмысления управленческих ситуаций и покажу примеры осмысления ситуаций.

Для удовлетворения требований бизнеса на рост и увеличения количества услуг во вторичной недвижимости, требуется изменить тип договора с лицензии на оферту. Поскольку наша команда исторически отвечала за биллинг и часть услуг, то нам поручили произвести переход. — Инициатива с участием ~7 команд и ~50 человек, так или иначе причастных к работе. Узким горлышком стала команда из outstaff без тимлида, аналитика и продакта, которую - ключевой состав рабочей группы. Финальный переход типа договора можно сделать только big-bang и только раз в квартал: все услуги, все пользователи, без отката и без поэтапности. Сегодня все услуги работают на рельсах новой платформы, часть — пока через промежуточную схему. Но финальный целевой переход мы за две недели до даты осознанно сдвинули, когда поняли, что риски не допустимы (суммарный сдвиг от первоначальной даты — уже около полугода). Расскажу, как одна команда координировала семь других, не имея над ними рычагов влияния: какими простыми инструментами мы вернули предсказуемость, как разными подходами пытались расшить блокирующую команду, на каких факапах теряли недели работы и почему сдвинуть «несдвигаемое» бывает зрелее, чем релизить любой ценой. Уйдёте с набором приёмов координации без полномочий, применимых в понедельник.

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

Девять месяцев назад мы взяли OpenSpec и достроили его до процесса разработки. Спека вместо промпта. Итерация вместо чата. Гейты вместо надежды. Документация, которая живёт вместе с кодом. Реальный опыт реальной команды: как мы работаем и что в итоге прижилось. Разберём: какую обвязку мы построили поверх OpenSpec: скилы, агенты, гейты;как у нас документация обновляется сама — и почему агент читает её раньше кода;feedback loop: система учится сама — то, что проработано в итерации, остаётся в проекте и идёт в следующую;как поехала экономика: три сеньора за 1,5 млн стали джуниорами с нейронкой за 850 тыс, доменов вместо одного — несколько.

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

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

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

Опыт работы с узкими специалистами в сфере CRM маркетинга Как вычислить потенциального джуна среди огромной волны желающих Почему ИИ в найме бесят кандидатов

Мы расскажем о том, как в современном мире простую команду HR можно превратить в полноценную Full-cycle команду вайбкодерок, создающую множество корпоративных HR-сервисов за считанные недели.

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

Представьте: к вам приходят со словами «нужно запустить сервис Х». Кстати, нужно вчера. При этом у вас SaaS-экосистема из 13 продуктов, горизонтальные сервисы, легаси и высокие нагрузки. Архитекторы не знают, каким должно быть решение, продукты хотят, чтобы всё работало бесшовно, а команда уже занята другими задачами. Что делать? Только брать и делать. В докладе я пошагово разберу через реальный кейс запуска, а что же нам делать. На каждом этапе кейса остановимся и разберём, какое решение должен принять руководитель: что сначала исследовать самому, когда подключать команду, как декомпозировать неопределённость, о чём договариваться со смежниками и как расширять зону ответственности и не пожечь команду. Отдельно посмотрим, где в этом процессе помогает ИИ: какие части исследования и декомпозиции ему можно передать, как проверять результат и в какой момент его использование начинает создавать больше шума, чем пользы. В итоге получится не идеальная схема из учебника, а жизненный цикл сложной research-heavy задачи — с реальными развилками, ошибками и практическими выводами для тимлида на каждом шаге.

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

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

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

Слышали ли вы когда-нибудь фразу "If I were in your shoes"? У этого британского выражения конечно же есть русский аналог "если бы я был на твоем месте". Как часто мы думаем об этом в моменты взаимодействия с другими командами? "Был бы я продактом, обязательно бы собрал по-другому продуктовый концепт!" или "Был бы я тимлидом бэкэндеров, то совсем иначе выстроил бы работу с теходолгом!". Если узнали себя – приходите на нашу игру. В процессе игры "В твоих ботинках" вы столкнетесь с ситуациями, когда только увидев кейс глазами другого персонажа вы сможете найти лучшее решение. Возможно, вы будете играть самих себя. А, возможно, вам предстоит вжиться в совершенно другую роль. Основная задача здесь – не просто помочь команде решить бизнес-кейс, а воспроизвести реальные конфликты и сложности во взаимодействии, которые возникают в повседневной жизни. Получится ли это у вас? Или все опять разругаются и каждый останется при своем? Игровое поле – отличная возможность не только побывать на месте коллеги, но и протестировать свои способности к кросс-функциональным коммуникациям.

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

Technical debt 2.0: AI помогает закрыть технический долг или создаёт новый тип долга?От technical debt к knowledge debt: какой долг мы создаём, когда AI пишет код за нас?Skill debt: сможет ли джун с AI стать сеньором? И как вообще AI меняет всю систему обучения.Management Debt: что дожен проектировать тимлид в команде из людей и AI-агентов?И что же теперь является объектом управления тимлида?

Я психолог по образованию, руковожу методологической группой в T&D. Никогда не открывала IDE, не проектировала базы данных и не писала код. Но когда команде срочно понадобился тренажер для отработки навыков обратной связи, а очередь на разработку была расписана на месяцы вперед, я решила не ждать — и освоила вайб-кодинг. В докладе честно расскажу свой путь: какие ИИ-инструменты использовала, с какими техническими тупиками столкнулась, как писала промпты для генерации кода и структуры БД. И главное — как отреагировали DevOps и разработчики, когда я принесла им готовое рабочее решение вместо абстрактных требований. Что заберете: Чек-лист первых шагов в вайб-кодинге для нетехнических менеджеров Примеры промптов для генерации кода, структуры БД и технических требований Инсайт: как создание технического артефакта с помощью ИИ повышает эмпатию, авторитет лидера и улучшает коммуникацию с инженерной командой Понимание, когда стоит использовать вайб-кодинг, а когда лучше передать задачу разработчикам

Дать команде AI-агентов недостаточно, чтобы разработчики начали поручать ему полноценные инженерные задачи. В реальных условиях агенту не хватает контекста проекта и внутренних инструментов, а результат приходится долго проверять и докручить. В этот момент звучит то самое: «Я сделаю быстрее сам», — так техническая рутина остаётся в бэклоге. В Яндекс 360 мы попробовали сократить этот разрыв с помощью Вайбатона — однодневного ивента, полностью посвящённого работе с AI. Первый Вайбатон в 2025 году помог участникам освоиться с новым способом разработки, второй в Q1 мы посвятили настройке агентов. В формат входят – минимум три подготовительных вебинара и практический воркшоп, чтобы в день Х более 40 разработчиков за день собрали 27 агентов: для удаления фича-флагов, ревью API, подготовки тест-кейсов, починки нестабильных тестов и разбора алертов. Я расскажу, как выбрать соразмерные формату задачи, как настроить доступы, окружение и контекст, валидировать результаты и передавать удачное решение оунеру задачи после демо. Покажу не только то, что сработало, но и ошибки формата. Спойлер: один Вайбатон сам по себе не дает буст к производительности или сокращение бэклога. Но слушатели получат проверенный нашей собственной практикой алгоритм проведения события и набор метрик, которые стоит заложить заранее.

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

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

Что происходит, когда вы собираете команду из сильных автономных специалистов, но не договариваетесь с ними об общем образе результата? Скорее всего, каждый начнет делать хорошо, но по-своему. А тимлид рано или поздно попытается компенсировать этот разнобой микроменеджментом. Я столкнулся с этим в роли тимлида курса Go в Центральном университете. В моей команде лектор, семинаристы, авторы и ассистенты. Всего 10 человек, имеющих разные задачи. Это сильные специалисты из индустрии, для которых преподавание не является основной работой, а скорее отдушиной. При этом результат нашей совместной работы должен быть единым: программа, материалы, семинары, контрольные, коммуникация и ожидания студентов должны складываться в цельный образовательный продукт. В докладе расскажу, как видение помогает заменить ручное управление системой. На примере перестройки курса Go покажу, как сформулировать образ результата, превратить его в критерии найма и качества, дать экспертам автономию, не потерять общий вектор и построить контур обратной связи. Это история вообще не про образование, а про управленческий вызов: как отвечать за результат команды, которую нельзя эффективно вести через постоянный контроль.

В докладе разберём практический кейс эволюции фронтенд-архитектуры в продукте с 40 регионами и несколькими командами разработки. Изначально у нас был монолит на Next.js, где UI и бизнес-логика (работа с API) были монолитом. Это приводило к замедлению разработки, усложняло эксперименты и увеличивало когнитивную нагрузку на команду. Мы прошли через декомпозицию на региональные приложения и столкнулись с новыми проблемами — дублированием и сложностью поддержки. В итоге пришли к модульной архитектуре с разделением на внутренние пакеты: UI библиотеку и слой бизнес-логики. Расскажу, как это решение повлияло на скорость разработки, как был устроен процесс регистрации с вариативными сценариями, и на какие компромиссы пришлось пойти. Доклад будет полезен тем, кто работает с большими фронтенд-приложениями и ищет способы масштабировать разработку без потери скорости.

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

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

В большинстве компаний хорошие идеи остаются на уровне «было бы круто» и умирают между «всем понравилось» и «кто это будет делать». Мы в сообществе тестировщиков сделали внутренний стартап-хаб — площадку инициатив, где каждый может принести идею (инструмент, фреймворк, стандарт или подход), получить поддержку, собрать MVP и довести пилот до внедрения. В докладе я покажу наш фреймворк развития инициатив (от лендинга и онбординга до регулярных синков), расскажу, как распределили роли и мотивацию, какие инициативы выстрелили (матрица компетенций, MultiTester (генератор тест-кейсов по требованиям)), какие провалились (например, ИИ‑доступность стендов) и почему. Что будет в докладе: Боль и контекст.Несколько сотен продуктовых команд, каждая тащит свои решения для автотестов и качества.Идеи есть у инженеров на местах, но нет ни формальной площадки, ни времени «продавать» их менеджерам.Внутренние митапы и чаты есть, но они не решают проблему «идея - системный результат».Концепция и дизайн площадки инициатив.Почему мы решили делать именно стартап-хаб внутри сообщества, а не рабочую группу или комитет.Какие цели зафиксировали: какие инициативы сюда попадают, что считается успехом, чего мы осознанно не делаем.Ключевой принцип: инициативы должны быть ближе к реальным болям команд, а не к абстрактным потребностям.Фреймворк жизненного цикла инициативы.Путь: идея - обсуждение - формализация - MVP - пилот - обратная связь - доработка - внедрение/архивация.Для каждого этапа: -- какие критерии перехода, -- кто принимает решения, -- какие артефакты должны появиться (шаблон инициативы, краткий pitch, план пилота и т.п.). -- Как мы сделали это «не страшным»: минимум бюрократии, максимум прозрачности.Инфраструктура: лендинг, онбординг, роли, процессы.Лендинг/каталог инициатив: как мы показываем, какие идеи есть, на каком этапе они находятся, кто может присоединиться.Онбординг инициативы: -- как человек с идеей попадает в процесс, -- какие вопросы мы задаём на входе, -- как помогаем сформулировать «что мы хотим изменить» и «как это замерим».Роли: -- лидер инициативы, -- участники, -- эксперты (из других сообществ, архитекторских групп и т.п.), -- роль сообщества и лидера сообщества как “инкубатора”, а не «начальника».Регулярные синки: как мы встроили обсуждение инициатив в жизнь сообщества, чтобы это не было ещё одной лишней встречей по пятницам.Кейсы: что реально взлетело.Матрица компетенций: -- боль: как объективно оценивать рост QA‑специалистов в разных командах, выравнивать ожидания и планировать развитие, когда у команд десятки своих матриц компетенций; -- как инициатива родилась в сообществе и прошла путь до стандарта по компании; -- как мы решали конфликт «матрица как контроль» vs «матрица как инструмент развития».Инструмент MultiTester (генерация тест-кейсов на основе требований): -- стартовая проблема: дублирование инструментов, сложность повторного использования решений между командами; -- как через площадку инициатив инструмент прошёл путь от прототипа до используемого решения; -- что пришлось изменить в архитектуре и ответственности, чтобы инструмент стал “общим, а не ничьим”.Анти‑кейс: ИИ‑доступность стендов и другие провалы.Почему идея казалась перспективной, но не дошла до системного внедрения.Где мы ошиблись: -- в оценке боли, -- в выборе владельца, -- в коммуникации с другими командами, -- в времени и окне возможностей.Какие правила добавили в фреймворк после этого кейса: когда нужно остановить инициативу, как закрывать её так, чтобы не убивать доверие к площадке.Мотивация и устойчивость: как не превратить хаб в кружок энтузиастов.Как мы работали с тем, что у людей это не основная работа: -- какие виды признания, видимости, развития и «карьерных бонусов» мы встроили; -- как подключали тимлидов и менеджеров, чтобы они не воспринимали инициативы как конкурент их планам.Как лидер сообщества балансировал между поддержкой (помогать, снимать блокеры) и фильтрацией (не превращать хаб в склад идей без шансов на реализацию).Как обеспечивали преемственность: что будет с инициативой, если лидер выгорел или ушёл.Измерение эффекта.Какие метрики мы пробовали: количество идей/прототипов/внедрений, снижение дублирования инструментов, вовлечённость в сообщество, скорость онбординга.Какие из них действительно помогают защищать площадку перед руководством, а какие создают только иллюзию активности.Что мы изменили в метриках после первых месяцев работы.

В IT принято смотреть в корень: если падает сервер — мы не перезагружаем его каждый раз, а ищем первопричину. С людьми почему-то работаем иначе. Сотрудник допускает ошибки — мы "даем фидбек". Допускает ошибки снова - даем снова. И так годами. Но если сбой повторяется, дело не в человеке, а в системе. В процессах, которые его к этому подталкивают. Во внешних факторах, которые он не может контролировать. В нехватке знаний, которую мы не закрыли. А стандартные модели фидбека учат только одному — правильно формулировать претензию. Этот мастер-класс — про смену парадигмы. Как перестать быть "судьей" и стать "исследователем". Что будем делать: — Разберем сложные кейсы (можно прийти со своим) — Научимся отличать: перед нами ленивый сотрудник, перегруженный сотрудник или сломанный процесс — Пройдем через все 5 шагов алгоритма - от фактов до решения Результат: — На практике проживете состояние диалога, где нет обвинений, но есть опора — Увидите разницу между "контролирующим" и "вовлекающим" лидером - и сможете выбирать позицию. — Заберете пошаговый алгоритм, который превращает сложный разговор в совместный поиск решения

Когда в компанию приходит запрос “сделайте нам что-нибудь крутое с ИИ”, чаще всего за ним нет ни готового контура безопасности, ни понятного процесса экспериментов, ни договоренности, кто вообще принимает решения. В итоге команды либо тонут в хаотичных пилотах, либо месяцами согласовывают инфраструктуру и так и не доходят до пользы. Мы расскажем, как мы с нуля запускали ИИ-песочницу за три месяца: от постановки задачи до первых сценариев использования, понятных правил работы и контура для безопасных экспериментов. Поговорим и про то, как тимлиду и руководителю собрать процесс, договорить стейкхолдеров и не дать инициативе развалиться на старте. Что будет в выступлении: - Точка старта: откуда взялся запрос на ИИ и почему классический проектный подход здесь не сработал бы. - Команда экспедиции: как определить минимальный состав на старте и какие роли нужны в первые 90 дней (заказчик, техлид, безопасность, инфраструктура, методологи, будущие пользователи; спойлер: ядро 5–7 человек). - Маршрут и правила игры: какие процессы нужно ввести сразу - идей, приоритизация гипотез, правила доступа, критерии успешности пилота, формат демо. - Ямы и обрывы по пути: где обычно всё ломается - завышенные ожидания, отсутствие владельца, конфликт между скоростью и безопасностью, попытка сразу «делать прод». - Результаты: что реально получилось за первые три месяца, какие идеи пришлось отложить или признать неудачными и почему. - Что остаётся после путешествия: как песочница помогает не только тестировать модели, но и готовить команду к AI‑трансформации через понятный и безопасный маршрут изменений.

Когда в компанию приходит запрос “сделайте нам что-нибудь крутое с ИИ”, чаще всего за ним нет ни готового контура безопасности, ни понятного процесса экспериментов, ни договоренности, кто вообще принимает решения. В итоге команды либо тонут в хаотичных пилотах, либо месяцами согласовывают инфраструктуру и так и не доходят до пользы. Мы расскажем, как мы с нуля запускали ИИ-песочницу за три месяца: от постановки задачи до первых сценариев использования, понятных правил работы и контура для безопасных экспериментов. Поговорим и про то, как тимлиду и руководителю собрать процесс, договорить стейкхолдеров и не дать инициативе развалиться на старте. Что будет в выступлении: - Точка старта: откуда взялся запрос на ИИ и почему классический проектный подход здесь не сработал бы. - Команда экспедиции: как определить минимальный состав на старте и какие роли нужны в первые 90 дней (заказчик, техлид, безопасность, инфраструктура, методологи, будущие пользователи; спойлер: ядро 5–7 человек). - Маршрут и правила игры: какие процессы нужно ввести сразу - идей, приоритизация гипотез, правила доступа, критерии успешности пилота, формат демо. - Ямы и обрывы по пути: где обычно всё ломается - завышенные ожидания, отсутствие владельца, конфликт между скоростью и безопасностью, попытка сразу «делать прод». - Результаты: что реально получилось за первые три месяца, какие идеи пришлось отложить или признать неудачными и почему. - Что остаётся после путешествия: как песочница помогает не только тестировать модели, но и готовить команду к AI‑трансформации через понятный и безопасный маршрут изменений.

Менеджерские бои — практика сложных переговоров без скучной теории. Мы даём кейсы, максимально приближенные к реальной жизни, и запускаем живой поединок. Задача — убедить, договориться, сохранить лицо и не провалить проект. Вы сможете прокачать свои переговорные и управленческие скилы, а также получить обратную связь от экспертов-практиков. Версия 3.0 предполагает командные состязания, где нужно решить «критическую» ситуацию на проекте, в котором были внедрены ИИ-решения. Чем больше таких проектов в корпорациях, тем больше вопросов, которые нельзя решить кодом: кто отвечает за данные, почему алгоритм выдал чушь, как объяснить заказчику, что ИИ не магия, и почему доработки — это нормально. Именно здесь на сцену выходит переговорщик. Не тот, кто читает лекции о силе убеждения, а тот, кто способен собрать за столом продактов, разработчиков, заказчиков и юристов и найти решение, которое устроит всех. В мире, где технологии стремительно меняются, навык договариваться становится главным софт-скиллом. Да, будет сложно и весело! И да, ты выйдешь с опытом, который пригодится уже завтра на работе. Участие возможно в двух форматах: активный участник команды или зритель в зале.

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

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

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

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

Как сохранить предсказуемость продуктового планирования, когда поверх квартального roadmap регулярно появляются крупные и срочные стратегические инициативы.Почему постоянное увеличение штата продуктовых команд не решает проблему переменной нагрузки и как разделить постоянную и временную потребность в ресурсах.Как мы создали Portal Integrations — внутренний «аутсорс» из разработчиков и delivery-менеджеров, который подключается к стратегическим инициативам разных продуктовых команд.Как управлять ограниченным ресурсом, когда одновременно несколько инициатив требуют внимания: определять приоритеты, распределять людей и не превращать гибкий контур в бесконтрольный пул разработчиков.Как работа такого контура влияет на продуктовые команды: предсказуемость сроков, выполнение обязательств, количество переключений и нагрузку на людей.Какие выводы и ограничения мы получили за первые семь месяцев работы модели и в каких случаях такой подход имеет смысл применять.

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

«Внедрили AI» — это не результат. Результат — когда типовой документ собирается за 2 часа вместо 2 дней, а сервер под это стоит $250 в месяц. Мы отдали агенту кусок реального производства и год с этим жили. Расскажем, что изменилось: где выросла скорость, где агент уверенно врёт и как мы его проверяем, какие задачи вернулись к людям и как поменялись роли. И отдельно — то, о чём обычно не рассказывают: что сами инженеры в команде думают про агента-коллегу, где было сопротивление и что стало с мотивацией, когда рутина ушла к машине. В докладе — рабочая схема «агент + база знаний + верификатор» и трезвый разбор ROI: за счёт чего сэкономленные часы превращаются в деньги, а не в отчётную галочку.

Июнь 2026, мой отдел. Доля коммитов с участием ИИ у четырнадцати человек, писавших в том месяце код: 100, 100, 100, 93, 91, 89, 88, 84, 80, 57, 17, 2, 0, 0. Оба нуля — не то, что вы подумали: эти двое работают в инструменте, который просто не оставляет следов в коммитах, и разбор их диффов даёт 15% и 12%. Ярлык "не использует ИИ" родился из инструмента, а не из человека и я чуть не выставил по нему грейд людям Это доклад о том, что случилось с перф-ревью, грейдом и обратной связью, когда видимый результат инженера перестал быть признаком его труда. ИИ разорвал связь между усилием и артефактами - две тысячи коммитов за полгода не говорят ни об объёме работы, ни о её сложности. Руководители реагируют двумя способами, и оба проигрышные: перестаём мерить - это возврат к вкусовщине, когда человек не знает, по какой линейке его судят; измеряем внимательнее - надзор и гейминг. Расскажу про третий ход и про то, как дорого он мне обошёлся. Что будет внутри: Как ломается плато ИИ адопшна. Январь–март: 126, 209 и 386 коммитов отдела и ровно ноль ИИ-коммитов при том, что инструменты были у всех. Что не сработало (митапы, обучение, личный пример) и что сработало: не мотивация, а дизайн процесса. Одна конвенция, переехавшая из регламента в конфиг агента, дала рост с 2,7% до 88% за два месяца, чего уговорами было не добитьсяЧетыре канала данных и промахи каждого. Пометки/отслеживание коммитов занижают на 40+ процентных пунктов; замер по основной ветке при НЕ trunk based flow видит 6% работы. У одного человека три замера дают 107, 1568 и 2050 коммитов — разброс в девятнадцать раз; трекер промахнулся для трети отдела. Покажу слайд слепых зон, который печатается до таблицы с цифрами, а не послеШкала уровней и связка с грейдом: что именно шло в грейд (уровень владения инструментом, а не доля ИИ-кода, и почему это принципиально), в каком порядке связку можно включать, чтобы получить адопшн, а не имитацию, и мои ответы на четыре очевидных возражения, включая Гудхарта — он у нас уже случалсяТри места, где я ошибся. Алгоритм соврал про меня самого: 512 моих коммитов, 28 с пометкой ИИ = 5%, а разбор диффов по тем же проектам даёт 82%. Крупнейший вклад в отделе 449 коммитов, 120 активных дней не попал в замер вообще, и клетка уровня у человека так и осталась пустой. И самое крутое: я сделал инструмент, чтобы ко мне перестали приходить с вопросом "что там у тебя в отделе", и с этим же инструментом пришёл к выгорающему тимлиду. Результаты: типовое ускорение х2–4, у лидеров х4–8, у играющего тренера х4; более 1500 сэкономленных человеко-дней за полугодие по 13 верифицированным отчётам, это нижняя граница и не "сэкономленные" ставки, а задачи, до которых раньше не доходили руки. Методику замера и шкалу уровней разработали руководители ИТ, а моя часть - внедрение в своём отделе и защита уровня каждого инженера Унесёте: процедуру выставления уровня на пересечении независимых каналов; готовый список слепых зон, который стоит проверить у себя до ближайшего ревью; порядок, при котором связка ИИ с грейдом даёт адопшн, а не гейминг; и одно правило, которое я вынес - не начинать замер там, где у людей нет сил, а есть выгорание

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

Сделали ассистента — вырастили команду. Но вместе с ростом пришли риски, неоднородность и новые задачи для лидера. Как мы справлялись и что из этого вынесли — в нашем докладе.

Мы привыкли делить компанию на «бизнес», который заказывает, и ИТ, которое реализует. Agile должен был разрушить эту границу, но она выжила: Product Owner часто остаётся переводчиком, backlog — договором поставки, а ИТ — внутренним подрядчиком. С появлением ИИ эта модель становится опаснее: локальные автоматизации дешевеют, а значит, компания может быстрее масштабировать не только улучшения, но и организационный бардак. Разберём, почему деление на бизнес и ИТ разрывает ответственность за результат и как вместо поиска «ответственного со стороны бизнеса» распределять ответственность вокруг конкретных решений.

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

Есть ли жизнь после нагрузочного тестирования? Спойлер: да, и она только начинается. НТшник не исчезает, когда уходит в менеджмент — он просто переносит свое мышление на людей, процессы и продукт. Профилирование команды вместо кода, автоматизация рутины, поиск узкого места в процессах, rate-limit для задач, горизонтальное масштабирование ответственности, мониторинг здоровья команды, правильные метрики и честные отчёты. Бывший разработчик на Си, лидер трёх групп НТ, а теперь продуктовый тимлид — о том, почему НТ это лучший фундамент для управления.

На определенном этапе карьеры я, как техлид, выстроил процессы так, что команда стала полностью автономной, а сервисы — стабильными. Система заработала как часы без моего ежедневного микроменеджмента. И тут я столкнулся с главным вопросом: снова погружаться в операционку и бесконечные созвоны или вернуться к острию технологического прогресса? Я выбрал смену карьерного трека и вернулся в линейную разработку. В этом докладе я честно, на основе собственного опыта, расскажу, почему этот маневр стал для меня не дауншифтингом, а элитным апгрейдом, и как моя «процессная профдеформация» помогает мне работать сейчас. О чем я расскажу в докладе: Как я вернул фокус и перешел на ИИ-разработку: рассказываю, как смена карьерного трека подарила мне 5 часов тишины в день и как системное мышление помогает мне выжимать максимум из Cursor и LLM.Взгляд изнутри на новую культуру код-ревью: почему классическая проверка кода человеком устарела и как я ловил кейсы, когда ИИ за секунды находит 3 критических архитектурных бага в задачах, которые разработчики принесли на ревью в обход нейросетей.Разговор на равных с текущим руководством: как мой прошлый опыт помогает мне быть главной технической опорой для текущего техлида, усиливать процессы команды и при этом не конкурировать за авторитет.Что просит рынок на собеседованиях прямо сейчас: мой личный опыт прохождения интервью и тренд на Hands-on лидеров. Почему бизнесу больше не нужны «митинг-менеджеры», а требуются инженеры с сильными навыками процессов и AI.

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

Во многих компаниях нет никаких четких правил и подходов при принятии сложных архитектурных решений - из-за этого вся информация находится только в головах конкретных людей, которые разрабатывают фичу, а принятые решения часто неоптимальны и субъективны, из-за чего в дальнейшем приходится тратить больше времени на поддержку и на рефакторинг. Как исправить данную ситуацию и улучшить качество разрабатываемого ПО? Один из способов - внедрить ADR! В докладе обсудим следующее: - Что такое ADR/AD/ADL/ASR/AKM и как оно может вам помочь в организации хранения информации об архитектуре в компании. - Как писать и организовывать хранение ADR. Какие практики существуют и как делать это наиболее эффективно. - Когда необходимо писать ADR. - Принципы хорошего ADR и возможные ошибки. - Примеры ADR. - Процесс, структура и жизненный цикл ADR. - Как ADR может помогать при использовании ИИ.

Агенты и LLM везде. У нас много внедрений и видна объективная картина рынка. Практики бывают самые передовые, а бывают отстающие. Но одно понятно точно - AI уже очень глубоко проник в процессы написания кода. Код пишет агент, дебажит агент, коммитит агент и ревьюит агент. А потом он же и деплоит иногда. А IDE все равно нужна и никуда от нее не деться. А почему? Поговорим на докладе.

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

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

Вам знакома ситуация, когда один разработчик держит в заложниках 3 сервиса, команда 8 месяцев пилит рефакторинг, которому не видно конца, а от 5 разных продактов летят инциденты, в которых вы даже не виноваты? Год назад я пришел руководить мобильной командой именно в такой ситуации. За 9 месяцев мы полностью перевернули игру: вышли из затяжного кризиса, решили проблему bus-factor'а, наладили Observability и стали закрывать в 2 раза больше story points. В докладе расскажу: - Как перестать делать рефакторинг ради рефакторинга и научиться «продавать» новую архитектуру (в нашем случае — Video SDK) бизнесу. - Как мы выстроили процесс кросс-приоритезации и снизили количество инцидентов с "1 раз в две недели" до "1 раз в три месяца". - Что делать, если на мобилку повесили бэкенд на Kotlin, и как мы вернули систему авторизации ее законным владельцам. - Практика внедрения Cursor IDE: как мы перешли на агентскую разработку, внедрили AI в код-ревью и безболезненно приучили команду писать тесты и документацию. - Покажу наши главные фейлы (например, как мы потеряли месяц разработки, пытаясь допилить задачу, которая благодаря новой архитектуре уже потеряла смысл).

С 2001 по 2025 гг. наша компания жила как зонтичный бренд: несколько департаментов, отдельная команда на каждый продукт — и дубли функций по всей структуре. За полгода мы собрали её в единую компанию: сокращение штата ≈ 3 раза при том же объёме задач, с лучшими финансовыми результатами и выросшей вовлечённостью. Расскажу, как сокращать через архитектуру функций, а не через проценты: карта функций и дублей, порядок пересборки (что менять первым, чтобы не сломать работающее), работа со страхом команды. И честно — что пошло не так.

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

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

Расскажу: - как встроить LLM-агента в существующую data-инфраструктуру без её замены; - как решить проблему галлюцинаций в аналитическом контексте; - почему MCP лучше прямых API-вызовов; - как считать деньги при продуктивной работе агента.

Большинство историй внедрения ИИ начинаются с выбора модели и заканчиваются красивыми слайдами про рост эффективности… …но у нас все было иначе. Когда мы начали внедрять ИИ, выяснилось, что основная проблема вовсе не в технологиях. Несмотря на доступность различных LLM, RAG и интеграций через MCP большинство сотрудников просто не хотели менять привычный образ работы. На примере полного цикла SDLC будет разобран путь от эпизодического добровольного использования до подхода AI first и дальнейшие движения в сторону AI native. Мы покажим реальную проблематику, с которой столкнулись: инструменты выданы всем, но пользуются ими единицы; ИИ применяется только там, где нет страха ошибки; результат не воспроизводится между сотрудниками; нет явного понимания что компания в итоге получила. Разберем, почему первоначальная стратегия добровольного использования практически проволилась, какие аргументы приводили сотрудники против ИИ, как команда воспринимала риск замещения "Самих себя" и сколько времени было потеряно, прежде чем мы сменили подход. Основной фокус будет на алгоритмах внедрения, которые в итоге сработали. Проблематика, последовательность шагов, критерии перехода между ними, роль обязательных практик и то, что в конечном счете было признано неэффективным. 1. Почему после появления ИИ-инструментов сотрудники не начали пользоваться ими самостоятельно 2. Какие страхи и опасения возникли в команде 3. Какой алгоритм внедрения оказался наиболее эффективным: пошаговый процесс, применимый к любому из этапов SDLC 4. Что мы пробовали до этого и почему это не сработало 5. Какие сценарии и крупные кейсы использования оказались наиболее эффективными 6. Как измерять зрелость использования ИИ в команде 7. Почему мы переходим от AI first к AI native и почему хорошие модели сами по себе не приводят к изменениям в организации

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

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

ИИ — инструмент, а не замена человека Он повышает производительность, но не отвечает за качество продукта.Живой ум — единственный арбитр Ни одно машинное решение не принимается без краш-теста человеческим интеллектом. Валидация — это не этап, а условие допуска.Медленно думаем — быстро делаем Мы педантичны. Скорость включаем только на реализации: всю рутину скармливаем ИИ.

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

IT деградирует. В Windows 95 на кнопку "Пуск" экран появлялся мгновенно. В Windows 10, спустя 20+ лет, он может открываться несколько секунд, потому что локальное действие тащит сетевые запросы, рекомендации и промо. У меня в телефоне вычислительных мощностей больше, чем в компьютерном клубе моего детства. Там было 10 компьютеров, и когда админ создавал пати на сетевую игру, он создавал ее на 11 человек, потому что 11 на клавиатуре набрать быстрее, чем 10, и это имело значение для скорости создания пати. А на современном мощном телефоне почти любое массовое приложение открывается несколько секунд. А теперь у нас добавилась LLM, которая улучшает все хорошее и усугубляет все плохое. В докладе будут размышления о том, почему так происходит, что с этим можно сделать и как должно использоваться LLM чтобы не усугублять деградацию а бороться с ней.

Каждый тимлид знает эту боль: уходит старожил — уходят знания о том, почему сервис написан именно так, почему этот подход запрещён, почему вот этот угловой случай обрабатывается именно здесь. Новый человек (или AI-агент) приходит и делает «технически правильно, но не как у нас». Ты это ловишь в ревью, объясняешь, объясняешь снова следующему новичку. Мы решали ту же проблему — и решили её не через Confluence, а через граф знаний кодовой базы. AI Council строит живой граф: 11 000+ узлов (классы, функции, файлы, зависимости), 16 000 рёбер, плюс машиночитаемые конвенции команды и архитектурные решения. Когда AI-агент начинает задачу, он получает не весь проект целиком, а точечный контекст — именно те части кода и именно те решения команды, которые релевантны его задаче. Это же работает для нового разработчика при онбординге. В докладе — конкретные кейсы из двух внедрений: как сократился цикл «задача → PR» и как mentor-агент автоматически ловит нарушения конвенций до того, как они попадают в ревью тимлида. Поговорим о том, что тимлид реально контролирует в схеме с AI: какие точки approve обязательны (ТЗ, реализация, деплой), как выглядит human-in-the-loop на практике, и почему «AI без надзора» — это найм джуна без испытательного срока. Разберём dual-agent схему: dev-агент (пишет код) + mentor-агент (проверяет конвенции) — прямая аналогия с парой «исполнитель / старший ревьюер», которую тимлид уже знает.

Вы в большинстве своём уже писали ИПР и знаете про GROW и матрицы самооценки — проблема не в незнании инструментов, а в том, что планы разваливаются через 3-4 недели после написания. Цель мастер-класса — не научить писать ИПР "с нуля", а дать механизм, который переживает столкновение с реальной загрузкой, и унести с собой не просто документ, а рабочий ритуал его выполнения.

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

У Руководителя власть становится не правом подписи, а правом вопроса. Вместо жестких регламентов мы внедряем принцип «разрешено все, что явно не запрещено». И в такой структуре мы не распределяем задачи — распределяем ответственность за результат. Главный KPI — как долго команда может работать без Руководителя, не теряя темпа и качества. Если мое отсутствие незаметно — все выстроено правильно. Если без Руководителя коллапс — вы не лидер, вы костыль.

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

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

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

Когда в сложившуюся команду приходит опытный сотрудник, обычного онбординга может оказаться недостаточно. Вместе с профессиональными знаниями человек приносит свои представления о планировании, ответственности и взаимодействии. Если просто научить его существующим правилам, команда рискует потерять полезные идеи: численное большинство быстро превращает «мы так привыкли» в единственно правильный способ работы. Такая ситуация возникает не только после реорганизации, но и при найме, росте команды или изменении её задач. На примере команды Авито я расскажу, как после изменения состава я отказался от модели «новички адаптируются к старым процессам» и пересобрал договорённости всей командой. Покажу, как отделить обязательные требования организации от практик, которые можно менять; понять, какую проблему решает каждый процесс; выбрать, что сохранить, изменить, отменить или проверить экспериментом. Отдельно разберу, как услышать разные позиции, прояснить персональные ожидания и при этом не превратить принятие решений в бесконечный поиск консенсуса. Слушатели смогут определить, когда достаточно обычного онбординга, а когда требуется пересборка командных соглашений. Они получат последовательность действий, которую можно применить при появлении одного нового сотрудника или существенном изменении состава, а также способы оценить результат при разном доступе к метрикам. В нашем случае за квартал команда стабилизировала планирование и ведение инициатив, улучшила результаты health check и вернулась к предсказуемому выполнению планов.

Каждый руководитель сталкивается с одной и той же проблемой: идей больше, чем возможностей команды. Провести внутренний митап или отправить сотрудников на конференцию? Запустить инженерное сообщество или программу развития спикеров? Начать писать технический блог, делать подкаст или инвестировать в Open Source? Каждая инициатива выглядит полезной, но одновременно реализовать всё невозможно. Часто такие решения принимаются интуитивно, на основе чужого опыта или личных предпочтений. Но чем больше компания и количество заинтересованных сторон, тем сложнее объяснить, почему один проект получает ресурсы, а другой — нет. В докладе я расскажу о фреймворке оценки инициатив, который помогает принимать такие решения системно. Мы разберём матрицу оценки, основанную на двух измерениях: потенциальном влиянии на цели компании и стоимости владения инициативой. Покажу, какие критерии лежат в основе оценки, как обсуждать приоритеты со стейкхолдерами и почему иногда лучший результат — отказаться от хорошей идеи.

Я поделюсь идеями, как за относительно короткое интервью составить представление о технических навыках кандидата.

Почему сильный специалист далеко не всегда становится сильным руководителем — и где чаще всего ломается первый управленческий переход.Как использовать Leadership Pipeline, чтобы осознанно выращивать тимлидов, руководителей проектов и продакт-менеджеров, а не просто повышать лучших исполнителей.Как определить, чего именно не хватает будущему руководителю: управленческих навыков, экспертных знаний, зрелости, мотивации или подходящего управленческого профиля.Как применять PAEI Адизеса и спиральную динамику как вспомогательные инструменты диагностики, чтобы выбирать правильный подход к развитию и мотивации руководителя и его команды.Какие практики действительно работают: one-to-one, постепенная передача ответственности, обратная связь, разбор сложных ситуаций и индивидуальные треки развития.Какие ошибки совершают руководители при выращивании своих преемников — и как вовремя понять, что человеку лучше развиваться в экспертном, а не управленческом треке.

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

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

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

На МК мы зададимся и ответим на следующие вопросы: * Как человеку работать совместно с ИИ максимально эффективно? * Какие мыслительные операции можно делегировать ИИ, а какие нет? * Что необходимо делать для того, чтобы ИИ выдавал нужный нам результат быстро, а не через бесконечное количество итераций? Также мы узнаем, что не в каждой ситуации стоит применять ИИ и научимся отличать то, что стоит спрашивать и просить выполнить ChatGPT (клод и пр) от того, что стоит сделать самостоятельно.

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

LLM кратно ускорили разработку — но менеджмент за этой скоростью не поспевает: кода, экспериментов и решений становится больше, на что внимания одного лида уже не хватает. Ускорить управление оказалось сложнее, чем генерацию кода: необходимо отслеживать сотни событий, находящихся в широком и постоянно меняющемся контексте, поэтому чатов с LLM теперь недостаточно — AI-помощников необходимо вшивать прямо в процессы, создавая для них память, инструкции и инструменты. На опыте команды рекомендаций Магнита (всего 8 человек которые создают десятки ML-моделей для нескольких форматов группы) разберём конкретные принципы и механизмы, которые позволят лиду поддерживать и ускорять темп разработки, — и грабли, на которые мы наступили в процессе трансформации системы управления.

Тимлиды часто продают культуру через ценности; инженеры слышат бюрократию. В докладе на кейсе эксплуатации 54 человека – культура как контракт, который защищает инженера. Разберём, почему кодекс и давление не работают, и ответим на 6 возражений не лозунгами, а арифметикой трения. Модель: профилактика vs переспросы ≈ 1 к 7 при явных допущениях. Унесёте карточки ответов, 4 определения, правило отмены регламента без прецедента и план на 14 дней.

История электрификации, компьютеризации и банкоматов показывает: новая технология не повышает производительность сама по себе. Эффект появляется, когда организация меняет процессы, роли и способы контроля. С AI-агентами происходит то же самое: успешная демонстрация ещё не означает успешного внедрения. В докладе я расскажу, как мы одновременно развивали агентскую разработку и агентов для банковских процессов. В портфеле было 37 инициатив, над которыми работали шесть команд: 12 решений дошли до промышленной эксплуатации, ещё 11 — до MVP. Для синхронизации мы проводили Agent Review, стратегические сессии, демо-дни, обучение и развивали сообщество практики. Разберём, почему выдача инструментов и обучение сотрудников не гарантируют принятия, как выбирать сценарии по автономности и риску и почему проверка часто становится новым узким местом. Участники получат практическую модель перехода от пилотов к промышленной работе: воронку принятия, контур ответственности, управленческие ритуалы и систему метрик от использования до бизнес-результата.

Полгода мы были уверены, что делаем всё правильно. С ноября продуктовая команда обсуждала запуск платных тарифов в Яндекс Бизнесе, с февраля разработка двигалась по плану встроить фичу в архитектуру смежного крупного продукта. К маю в коде не было ни строчки и стало ясно, что план, в который мы верили полгода, не взлетит. Расскажу, как мы приняли решение отказаться от него, предложили альтернативную архитектуру через другой смежный сервис и за месяц выкатили полноценный контур оплаты в продакшен. Это не история про везение и не восторженный отчёт про успех, а разбор конкретных инструментов: как ADR фиксирует спорное решение до того, как в него вложат время команды; как разделение discovery и delivery ускоряет работу вместо того, чтобы её тормозить; как декомпозировать и оценивать сроки так, чтобы новый план не повторил судьбу старого. Если вы когда-нибудь понимали, что полгода двигались не туда - этот доклад для вас.

Трение обычно лечат совещаниями, RACI и «давайте договариваться» – через квартал всё возвращается. В докладе – цикл без комитета: опрос → кластеры → P0-артефакты → повторный замер через 3–6 месяцев. Покажу одинаковые вопросы для всех соседей, отбор сигнала от шума и перевод болей в каталог запросов, взаимный DoD, верификацию закрытия, прозрачность статуса – вместо рейтинга команд. Унесёте шаблон 8–12 вопросов, рубрику «сигнал/шум» и чеклист P0 на квартал.

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

Расскажу как мы захотели забрать все рутинные запросы по поддержке внутренних продуктов от разработчиков в IT Support и что из этого вышло.

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

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

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

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

В командах, которые долго развивают сложные продукты, главной проблемой часто становится не написание нового кода, а восстановление контекста: почему было принято архитектурное решение, где находится нужная логика, какие зависимости нельзя сломать, что уже исследовали раньше и почему один из вариантов когда-то отвергли. Пока команда небольшая, это держится на памяти сильных инженеров и тимлидов. Но при росте продукта такая модель перестает масштабироваться: люди тратят время на повторный поиск решений, новые участники дольше входят в контекст, а руководители становятся живой базой знаний. В докладе разберу практический кейс группы Рунити и расскажу, как подходить к снижению когнитивной нагрузки в командах, которые несколько лет работали с крупными проектами, легаси-кодом и постоянным рефакторингом. Покажу, какие знания стоит сохранять в первую очередь, как превратить разрозненные исследования, решения, SQL-запросы, документацию и обсуждения в базу знаний, пригодную для AI-инструментов, и как понять, когда команде достаточно саммаризации, а когда уже нужен RAG и поиск по корпоративному контексту. Отдельно расскажу, как внедрение AI-инструментов может повлиять на работу команды и увеличить долю выполненных задач в квартал на 11% от общего плана, долю задач, завершившихся дефектами, снизить на 13%, а долю закрытых дефектов в квартале повысить на 12%. И как руководителю понять, что команда уперлась в когнитивные ограничения, как выбрать правильный уровень автоматизации и как не построить очередную бесполезную базу знаний, которой никто не пользуется. Тезисы: Как разложить потерю контекста на типовые сценарии: онбординг, рефакторинг, инциденты, аналитика. Какие знания нужно сохранять в первую очередь: решения, связи, исследования, SQL, инструкции. Как определить, какие знания нужно структурировать вручную, а какие можно отдавать AI «как есть». Где проходит граница между саммаризацией, поиском по базе знаний и полноценным RAG. Как встроить AI-инструмент в командный workflow. Как контролировать качество AI-ответов. На какие грабли мы наступили и что делать, чтобы этого избежать. Как оценивать эффект через delivery-метрики, дефекты и скорость восстановления контекста.

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

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

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

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

Вокруг компаний и продуктов всегда было нестабильно. А теперь все трансформируются в микрокоманды, пересматриваются цели, меняются приоритеты у беклогов, и непонятно, куда вообще развиваться. На примере известных инструментов «Тепловая карта» и «Звездная карта» покажу, основные принципы поиска нужной информации, а так же сколько можно вытащить инсайтов про обучение, аномалий по задачам и вариантов перераспределения команд, имея не так уж много информации. И самое главное, сформируем ответ на вопрос: «Что делать-то?»)

Команда, которую ты не понимаешь, сама примет за тебя решения. Часто — не те, что нужны. Доклад - о том, как я научился разбираться в людях, пока руководил командами разработки. Разберем пять типов сотрудников, которых встречал снова и снова: от самых результативных до тех, с которыми возникают сложности. Покажу, как на встречах 1-1 понять, кто перед тобой, чем его мотивировать и почему сильная команда без правильного баланса всё равно может перегореть или развалиться, также ответить на вопрос, кого поддерживать, а с кем расставаться.

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

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

В докладе расскажем про результаты развития практик InnerSource в департаменте ИТ КИБ Сбера. Разберем почему несмотря на достигшие успехи, подход InnerSource не смог принципиально изменить сложившийся Agile подход. Что изменилось с переходом на AI PDLC. Какие механизмы мотивации и кросс-командного взаимодействия приходились в новой эпохе.

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

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

Главная цель любого подразделения — выпускать классные релизы/продукты/услуги и пр. Но по мере роста команды и появления сотен участников эта цель тонет в хаосе. Мы покажем, как выстроили процессы и систему метрик, чтобы вернуть предсказуемость и качество. Вместо скучных фреймворков и дорогих BPMN-инструментов расскажем, как синхронизировать сотни людей с помощью понятных схем и систем контрольных точек. Расскажем эту историю с двух сторон: архитектора процессов и бизнес-заказчика. Вы увидите, как это отразилось на результате: в 1,5 раза больше релизов тем же составом, задержки сокращены до нуля, эскалации снижены в 3 раза. Что зритель унесет с собой: - Алгоритм наведения порядка в процессах, который можно применить в своей команде на следующей неделе. - Понимание, как связать процессы и бизнес-метрики, чтобы доказать: нужна не бюрократия, а предсказуемость результата. - Инсайт о том, как через выстраивание процессов можно «подтянуть» зрелость и культуру команды.

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

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

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

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

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

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

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

Автоматизация часто проваливается не потому, что выбран плохой инструмент. Чаще проблема проще и неприятнее: команда пытается автоматизировать хаос, который никто не посчитал, не описал и не взял на себя. В докладе разберём вредные советы для бизнеса и руководителей команд. Также поговорим о том, как подойти к автоматизации: – как посчитать стоимость ручного процесса; – как найти «дорогой хаос» в команде; – почему одна ошибка иногда дороже десятков часов рутины; – когда автоматизация нужна, а когда преждевременна; – как объяснять автоматизацию через деньги, скорость, риски и контроль, а не через «будет удобнее» Слушатели унесут матрицу выбора процесса для автоматизации и простой чеклист первых шагов

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

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

Я работаю с командами разработки на стыке права и инженерии: регистрация ПО, депонирование кода, оформление процессов. Мой опыт показал, что большинство проблем возникает не из-за ошибок конкретной стороны, а из-за разрыва между юридической и технической частью проекта. Обычно это выглядит так: юристы занимаются договорами и формальными требованиями, разработчики – кодом и архитектурой. Однако реальные риски появляются ровно на пересечении – там, где решения принимаются на уровне библиотек, интеграций, данных и процессов разработки. Я покажу именно те точки, где юридические требования превращаются в конкретные инженерные решения. На докладе рассмотрим реальные кейсы: 1) как одна непроверенная копилефтная лицензия способна перечеркнуть доступ к госзакупкам и реестру Минцифры и почему аудит совместимости нельзя откладывать на потом; 2) как отсутствие простой связки «задача → разработчик → код» оставляет бизнес беззащитным при увольнении сотрудника или аудите инвестора; 3) как использование публичных ИИ-инструментов без корпоративных аккаунтов и DLP приводит к утечкам, которые в финтехе заканчиваются предписаниями ЦБ, а в любом другом бизнесе – потерей ноу-хау. Цель простая: дать вам ориентиры – что стоит держать в голове на уровне тимлида и в каких местах лучше вовремя подключить юриста или безопасника, пока это не стало проблемой.

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

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

Думаем об увольнении уже при наймеУвольнение и bus factorВеские причины для увольнения: когда стоит, а когда всё же нетПольза от увольненияЭкзит-интервью: примеры вопросов

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

Большинство проблем найма начинается не на интервью, а намного раньше - в момент, когда формулируются требования. Требования к кандидату - это не список пожеланий, а попытка перевести бизнес-задачу в понятные и проверяемые характеристики. На практике это часто превращается в набор противоречий: нужен Senior за небольшой бюджет или нужен универсал с глубокой экспертизой, который при этом будет строго следовать процессам. В результате команда сталкивается с ситуацией, когда «никто не подходит», хотя внутри просто не договорились, кого именно ищут и какие компромиссы допустимы. Проблема обычно не в кандидатах и не в интервьюерах, а в отсутствии общего понимания профиля роли до начала поиска. На мастер-классе разберем, как без воды формулировать и приоритизировать требования, как выделять ключевые red flags, которые реально влияют на решение о найме.

Когда я пришёл в команду из 8 человек и 7 микросервисов, всё выглядело как классический ад тимлида: 120 алертов в месяц, минимум один серьёзный инцидент, сроки спускаются сверху «по ощущениям», дежурства не учитываются в планах, люди открыто говорят о выгорании, а стандартные советы «уточняйте требования» и «просите больше времени» не работают. За полтора года я выстроил системный подход: регулярный технический анализ задач, выделение 20% капаситета на поддержку, прозрачный отчёт дежурного и жёсткое планирование на основе регламента. В результате алерты упали со 120 до 50 в месяц, серьёзные инциденты — с одного в месяц до одного в квартал, попадание в сроки выросло с 50% до 80%. Но несмотря на эти цифры, я проиграл битву за культуру: системность назвали бюрократией, и мы с руководством разошлись. На докладе я честно разберу, что сработало, а что нет. Вы унесёте с собой готовые артефакты: шаблон отчёта дежурного, шаблон технического анализа, чек-лист культурной совместимости (как за 1–2 месяца понять, что системные изменения здесь не приживутся) и скрипты переговоров с бизнесом, которые переводят инженерные инициативы на язык денег, рисков и KPI стейкхолдеров. Будет полезно тем, кто устал бороться с хаосом и хочет понять, когда стоит продолжать, а когда — уйти.

В конце 2025 года мы начали внедрение ИИ в разработку с покупки нескольких командных подписок на Claude Code. Для большинства задач ML-команд агенту хватало контекста одного репозитория. Но работа CTO, тимлида, проджекта и дежурного устроена иначе: нужная информация находится в логах, базах данных, корпоративных переписках, документации и результатах предыдущих расследований. Поэтому мы начали превращать Claude Code из инструмента для работы с кодом в полноценного члена команды. Сначала дали ему "руки" - сделали единый виртуальный MCP-сервер, через который агенты с учётом ролей получают доступ к состоянию продукта, инфраструктуре, коду, документации, перепискам и даже анонимизированным медицинским исследованиям. Затем появилась ограниченная память - автоматически пополняемая приватная база знаний руководителей, которую агент использовал в новых сессиях. После этого рабочий день руководителя начал состоять из 5–10 параллельных агентских сессий. Для удобного управления ими мы разработали AI Cockpit - интерфейс для работы с множеством сессий Claude Code и Codex. Наконец, мы добавилии ИИ-агентов в корпоративный мессенджер Mattermost к остальным сотрудникам. ИИ-дежурный стал автоматически начинать расследования инцидентов, а любой сотрудник теперь может обратиться к ИИ-агенту прямо в треде. Открыть корпоративным агентам приватную память руководителей было нельзя, поэтому мы построили отдельную базу знаний через LLM-дистилляцию и санитизацию. В докладе я покажу архитектуру системы и расскажу, как агенты с инструментами и памятью меняют работу тимлида: какие задачи перестают требовать отдельного делегирования, почему растёт число параллельных задач и где проходит граница между самостоятельностью агента и ответственностью человека.

Я ведущий подкаста "В SREду на кухне" (https://vsredu.mave.digital) о стабильности систем и лучших инженерных практиках SRE. Ежедневно я общаюсь с инженерами, техническими менеджерами, различными гостями подкаста. Мы решили провести в Авито исследование, какие soft skills важны в инженерной сфере и в IT в целом. Сравнили с другими исследованиями в индустрии (исследование Андрея Смирнова (Х5), LinkedIn). Заметили расхождения и абсолютно новые тенденции. В частности, как применение AI меняет спрос на soft skills и какие навыки становятся востребованными к 2027 году. Я расскажу какие soft skills выделяют руководители и инженеры в своей практике, дам новые рекомендации для их развития. Покажу какие важны в начале пути, а какие для роста из тимлида.

У команды одновременно есть продуктовые задачи, технический долг, проблемы надёжности и необходимые изменения архитектуры. Всё выглядит важным, backlog растёт, а договориться о том, что действительно нужно делать следующим, становится всё сложнее. Главная мысль доклада: техническая стратегия - не документ о будущем, а система управления техническим развитием. Она связывает текущее состояние продукта и платформы, выбранное направление, измеримые цели, план технических изменений и регулярную проверку результата. Мы разберём, чем такая система отличается от целевой архитектуры, roadmap и обычного списка технических задач. Я покажу полный цикл: как собрать сигналы от продукта, архитектуры, эксплуатации и команд; превратить их в несколько направлений и измеримых результатов; составить программу работ; а затем проверять фактическое движение и пересматривать план, когда меняется контекст. На примерах из управления платформой нескольких команд посмотрим, как стратегия связывает архитектурные решения, надёжность, delivery, технический долг и развитие команд в общий процесс. Разберём, почему план может меняться, не разрушая стратегию, и почему выполнить 70% честного плана иногда полезнее, чем отчитаться о 100%.

Большинство «проблем с людьми» при быстром росте компании — это не проблема людей, а проблема системы управления, оставшейся на предыдущем масштабе: ×10 людей не равно ×10 управления. В IT есть technical debt, в организациях — management debt: пока команда мала, он скрыт, но при росте предъявляется сразу во многих точках — в найме, адаптации, развитии и принятии кадровых решений. В докладе разберу, как проектировать HR-процессы не как набор практик, а как инженерную функцию: вокруг управленческих решений, данных и результата, а не вокруг активности. Отдельно — про роль HR по отношению к руководителю: сильный HR не подменяет лидера, а усиливает его через ясные роли, данные и инструменты. Кейс — три истории из опыта компании МТТЕХ по формату «было → разрыв → решение → стало → доказательство» в найме, адаптации и развитии на основе данных.

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

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

Наверняка вы неоднократно сталкивались с такой ситуацией. Тимлид пишет коллегам или руководителю о риске релиза, статусе проекта, нехватке ресурсов или ещё о чём-то важном. В сообщении есть даты, факты и технические подробности – но после его прочтения у адресата остаются вопросы: что конкретно от меня хотят и почему именно так, а не иначе? Такие сообщения незаметно расходуют когнитивный бюджет команды. Чем больше внимания уходит на расшифровку намерений автора, тем меньше его остаётся на саму задачу. Вместо принятия решения коллеги восстанавливают контекст, уточняют просьбу, спорят о прошлых договорённостях и назначают ещё один созвон. Неясные сообщения замедляют решения и усиливают межкомандное напряжение. Согласно исследованию 2024 года Сколково «Как плохие коммуникации влияют на эффективность бизнеса» ежегодные потери российского бизнеса от некачественных коммуникаций оцениваются в сумму 8,7 триллионов рублей. На практическом мастер-классе участники разберут два письма по узнаваемым IT-кейсам. Сначала они прочувствуют проблему с позиции адресата, затем пошагово перестроят перегруженное письмо, а в финале самостоятельно создадут сообщение из разрозненных рабочих заметок. Для работы участники освоят авторскую модель МАЯК – инструмент, который помогает превратить техническую ситуацию в понятное действие, актуальную картину и подготовленную рекомендацию. Готовые сообщения будут проверены другими участниками: за 15 секунд – на ясность главной мысли, за 30 секунд – на понятность логики решения. На мастер-классе мы не будем говорить о грамотности или деловом этикете. Это будет тренировка управленческой коммуникации тимлида: как влиять на решение адресата, доносить риски без обвинений и не перекладывать на руководителей и коллег работу по выбору решения. Участники уйдут с практическим алгоритмом и инструментами самопроверки, которые можно применить к реальной рабочей ситуации уже на следующий день.

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

Рутинный код дешевеет. Инженер не должен дешеветь вместе с ним. Сначала AI помогает исследовать систему и исправлять отдельные баги. Затем появляется соблазн отдать агенту тикет целиком и получить готовое решение без разработчика. Но без понимания системы, точных требований и встроенной проверки агент производит код, который не работает, стоит дорого в поддержке или не проходит ревью. На реальных победах и неудачах я покажу путь от отдельных экспериментов до разработки нового функционала, переписывания целых компонентов и реализации проектов вокруг AI. Разберём, почему для этого приходится менять процессы всей команды, как защититься от нейрослопа, не утонуть в ревью сгенерированного кода и сохранить человеческий ownership. Мы не будем спорить, изменится ли разработка: она уже изменилась. Поговорим о том, как адаптировать к этому команду, не обесценив инженеров и не сняв с них ответственность.

Расскажу о нашем опыте построения распределённых команд в индийском ИТ-хабе Сбера

AI ускорил код, но сломал привычные признаки роста. Человек закрывает больше задач — и может не стать сильнее в проектировании, диагностике и решениях. Особенно у джунов: модель закрывает пробелы, а тимлид видит готовый PR и думает, что инженер вырос. В докладе — как отличить рост человека от роста инструментов. Почему старые ИПР и матрицы компетенций начинают врать. Как оценивать не только результат, а качество решения: формулировка задачи, ограничения, проверка, альтернативы, защита выбора. Отдельно — система обучения: чему учить вместо «пиши быстрее», какие задачи развивают, а какие маскируют слабость. И зачем для этого общий корпоративный LLM-гейтвей: одинаковые модели, инструменты и правила у всей команды. Без общего слоя тимлид сравнивает не инженеров, а чей сетап удачнее. Сеньорство всё меньше про объём кода и всё больше про ответственность за систему и умение управлять AI. Разберём, как пересобрать one-to-one, ИПР, ревью и критерии повышения.

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

Суть в чём. Весь тайм-менеджмент стоит на скрытом допущении - человек переключается между задачами мгновенно. Это допущение ложно физиологически. Глория Марк (UC Irvine) - на возврат к задаче после прерывания уходит в среднем 23 минуты 15 секунд. Вайнберг - каждый параллельный проект съедает ~20% времени. APA - переключения стоят до 40% продуктивного времени. Календарь говорит "ты всё успел", голова говорит "день в труху". Ирония в том, что для агентов эту проблему уже решили - есть контекст-инженерия с выжимками, компактизацией и изоляцией контекстов. Для железки построили дисциплину, а для собственной головы купили ещё один планировщик.

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

Кросс-командные коммуникации в больших IT-продуктах ломаются не только из-за процессов, но и из-за различий в том, как люди воспринимают информацию, реагируют на изменения и принимают решения. В результате команды теряют время на бесконечные согласования, конфликты и скрытое сопротивление. В работе над внутренней GenAI-платформой банка мы постоянно взаимодействуем с десятками сервисов и команд одновременно. В такой среде аналитику и тимлиду важно понимать не только процессы, но и человеческую архитектуру организации: кто влияет на решения, кто ускоряет изменения, а кто создаёт сопротивление. На мастер-классе мы разберём модель «корпорация как школьный класс». Через знакомые роли — староста, отличник, хулиган, тихоня, бунтарь-умник — участники научатся распознавать коммуникационные роли внутри команд и строить Communication Role Map для реальных рабочих ситуаций.

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

Мы привыкли героизировать «дожимание» проектов любой ценой. Но что делать, когда технический долг, сорванные сроки и выгоревший разработчик превращают работу в токсичный ад? Я честно расскажу, как приняла тяжелое, но единственно верное решение закрыть внутреннюю практическую лабораторию, в которую было вложено много сил. Вы узнаете мой чек-лист «красных флагов», как провести серию сложных 1:1 без демотивации людей, которые верили в проект, и как договориться с CTO о передаче дел, сохранив бизнес-ценность продукта. Что заберете: Чек-лист из 5–7 «красных флагов» умирающего проекта (связка техдолга и человеческого фактора). Скрипт разговора с командой при закрытии проекта и алгоритм передачи дел без токсичности. Шаблон аргументации для переговоров с топ-менеджментом об остановке или передаче проекта. Инсайт: почему остановка проекта — это не поражение, а самый зрелый и эффективный управленческий инструмент.

— Откуда берётся менеджерский «эскалационный лифт», который постепенно становится обязательной частью процесса разработки; — Как мы построили горизонтальное взаимодействие между 6 командами через встречи лидов, межкомандные каналы и распределение зон ответственности; — Где заканчивается автономность команды, когда действительно нужен руководитель и как не превратить горизонтальное взаимодействие в новую бюрократию; — Как пришли к результату, что 85% крупных эпиков не потребовали участия руководителей уровня отдела, а мелкие задачи внутри эпиков решаются командами самостоятельно.

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

Ядро идеи, ключевой месседж, "крючок" для аудитории и ПК. В 1933 году Грайкунас посчитал - 5 подчинённых это ~100 связей, 6 - уже 222. Отсюда правило "5-6 прямых подчинённых", и Gallup в 2026 подтверждает - медиана всё та же. Сто лет прошло, цифра не сдвинулась. Суть в чём. Вся эта математика работает в одной конфигурации - человек контролирует человека. А теперь у руководителя в подчинении команды агентов, которые ещё и перекладывают работу между собой.

Инцидент — лучшая проверка реальной культуры команды: сотрудник сообщает об ошибке или пытается её скрыть. Поиск виноватого создаёт иллюзию контроля, но редко помогает предотвратить повторный сбой. Культура необвинения — это не отсутствие ответственности, а отказ считать наказание главным способом работы с ошибками. Мы встроили культуру необвинения в процесс управления инцидентами через PIR, RCA и CAPA. RCA помогает заменить вопрос «кто ошибся?» на вопрос «почему система позволила этой ошибке привести к инциденту?». Важно различать добросовестную ошибку, рискованное поведение и сознательное нарушение — реакция руководителя на них должна быть разной. За 2025 год этот подход помог установить первопричины в 90% значительных инцидентов, устранить 78% причин и предотвратить 25 повторных сбоев. После доклада слушатели смогут проводить разборы без поиска крайнего и превращать ошибки в конкретные изменения процессов, систем и поведения команды.

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

S7 — не ИТ-гигант, но DS нам нужны. Уже 5+ лет растим HR-бренд через кафедру в МФТИ: full-stack DS, 15+ магистрантов в год. Они хотят полную ставку — и часто приходят с «лапками», даже из сильного техвуза. А лиды брать таких в продукт всё меньше хотят: AI vs нянька: при нормальной постановке задачи промпт пишет код быстрее джуна — и не нужно объяснять по третьему кругу;вырастил → ушёл: через год-два люди утекают в Big Tech, и лиду обидно за вложенные нервы. Если вы не Big Tech, этот разрыв особенно бьёт: вкладываете в выпускников — а команда не получает самостоятельного человека. Разберём, почему классическая модель «кормим с ложечки → через пару лет вырастет» после AI больше не сходится — и что можно сделать до того, как джун «съест» лида, чтобы найм снова имел смысл.

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

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

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

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

Полтора года назад я – оператор event/DJ-бизнеса без строчки кода: вся работа в голове, в заметках и в вечном тушении пожаров. Сегодня три моих направления ведут ИИ-агенты: – операционка – лиды с бирж и площадок, сделки в CRM, сметы и договоры, отчётность ООО в госкабинеты; – музыка – подбор и подготовка DJ-сетов под событие, сведение мультитрека, песни под заказ; – контент – посты, карусели, вертикальные видео и музыка для соцсетей на потоке. Это доклад-путь, а не список фич. Честно: с чего началось, какой сдвиг в голове дался тяжелее всего, как я научился резать любую задачу – хоть счёт, хоть трек, хоть видео – на агентов и делегировать. Где ИИ реально высвободил часы и деньги, а где я месяцами полировал автоматизацию, которая не окупилась. Зал техлидов строит подобное командами. Мой кейс с другой стороны: один не-технический человек прошёл этот путь сам через три очень разных домена – и вывод не «нужен ИИ», а про порог входа и способ мышления. Разберём архитектуру «человек + агенты», гейты на необратимое и экономику на живых примерах и цифрах.

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

Проблема контекста: Почему классический векторный поиск теряет связи и выжигает бюджет, как Граф Знаний сокращает расходы на токены ETL и детерминированная память: Практика сборки «цифрового мозга» Роли в AI-команде: Почему системный аналитик идеально подходит на роль «архитектора поведения» агентов

Я расскажу о том, как внедрять AI в SDLC существующей системы, не ломая процесс и одновременно решая несколько других проблем: боязнь резкого внедрения AI, SDLC governance. Я покажу какой каркас SDLC сохраняется и причём тут server-side harness. Я опишу, как это будет развиваться дальше, закрывая разрыв с тем AI SDLC, про который мы все читаем в новых статьях, и даже как AI поможет этот процесс эволюционировать.

Большинство «провалов оптимизации» — это не плохие фреймворки и не сопротивление команды, а оптимизация того, чего мы по-настоящему не поняли. Доклад о том, как сделать аудит процессов первым и главным шагом: что именно смотреть в команде, как зафиксировать «как есть», где у каждой команды спрятаны реальные процессы (часто — не там, где написано в Confluence), и как из аудита вырастают метрики, стандарты и оптимизации, которые не ломают рабочее.

1 тезис. Теневая сторона лидерства: что вы скрываете и почему это нормально Термин «теневая сторона» часто воспринимается как нечто постыдное. На самом деле это просто те части вашей личности и профессионального опыта, которые вы не готовы предъявлять команде. И это не лицемерие, а функциональная необходимость. Когда вы ведете команду через запутанный проект с дедлайном, который срывается, у вас внутри может быть паника, неуверенность в собственных решениях, желание все бросить. Но ваша задача — не транслировать эту панику. Потому что команда считывает состояние лидера на уровне зеркальных нейронов. Если вы покажете страх, он размножится в геометрической прогрессии. Поэтому вы надеваете маску спокойствия. Это не ложь, это профессиональная гигиена. Однако ключевой навык здесь — не «не показывать», а управлять тем, что вы показываете. Разница тонкая, но критическая. 2 тезис. Эмоциональная устойчивость как техническое умение Эмоциональная устойчивость в высоконагруженной среде — это не врожденная черта характера («такой уж я спокойный»). Это набор инструментов, которые можно натренировать как мышцу. 3 тезис. Интеграция: как тень и устойчивость работают вместе Итак, объединение двух тем — это не просто «маскируйся и терпи». Это создание системы, где ваша уязвимость не выходит наружу несанкционированно, а устойчивость не требует постоянного напряжения. Команде не нужен лидер без страха. Ей нужен лидер, который знает свой страх, но не позволяет ему стать решающим фактором в управлении. Именно эта внутренняя работа — признание ограничений, практика восстановления, дозированная честность — и есть та самая невидимая опора, на которой держится вся конструкция эффективной команды.

Если вы уже внедряете ИИ в команде — знаете, что технология тут самая простая часть. Ломается на людях: сопротивление, страх замены, усталость от «вечных пилотов». Спикер отвечал за эффективность программы внедрения ИИ на 3000+ человек. Мы разберём принципы, которые не зависят от масштаба и работают одинаково на 3000, на 300 и на 30 человек: как вести изменения без потерь, где эффект «затухает» и что именно зависит от лида одной-нескольких команд. В докладе — карта типичных провалов и приёмы работы с сопротивлением, которые вы сможете применить на своей команде.

Что определяет вашу способность зарабатывать больше или меньше? Что влияет на то, как вы распоряжаетесь деньгами, на ваш достаток, отвечает за неразумные траты и за то, что деньги утекают сквозь пальцы? Конечно, ваш мозг! Именно он управляет приоритетами, даёт или не даёт энергию на определённые действия, стимулирует те или другие поступки. И это НЕ про мышление миллионера и нищего! Это про то, как работают элементы мозга в единой системе на уровне нейробиологии. Есть состояние мозга, когда элементы системы работают неэффективно и во вред вам и вашим финансам. И другое состояние мозга, которое позволяет зарабатывать больше. Почти каждый сбой в этой многокомпонентной системе уменьшает заработок человека где-то на 5-10%. В итоге ваш собственный мозг может снижать ваш доход до 26%! Или повышать.

Тимлидов не хватает всем. Все жалуются на рынок — и почти никто не готовит их у себя. Компании говорят, что хотят растить изнутри, а на деле снова открывают вакансию. Это разговор о том, почему так. Устроен он как исповедальный: никаких докладов и правильных ответов. Я начну с трёх своих провалов — как назначил руководителем не того; как сам вышел в роль без подготовки и что из этого получилось; и как целый год собирался заняться своими людьми и не занялся ни разу. Дальше говорит зал. У каждого есть история про то, как из хорошего инженера сделали плохого руководителя, как нового лида бросили и он утонул, как перед отпуском выяснилось, что оставить команду не на кого. Обычно такое не рассказывают: неловко, и кажется, что только у тебя так. Представляться не нужно, называть компанию тоже. Записи не будет — иначе разговор не состоится. Соберем то, что окажется общим у всех. По моему опыту, общего будет неприятно много.

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

Тема: Обман в резюме: как тим-лиду не совершить ошибку при найме сотрудника Тезисы: Виды обмана с кейсами: последствия такого найма Учим тим-лидов распознавать обман и видеть реальный опыт Алгоритмы предотвращения фрод-найма

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

Доклад об опыте организации образовательных курсов в ВУЗах с учетом Приказа Минцифры РФ №270 от 31.03.2026. Рассмотрим как можно использовать опыт экспертов в образовательных проектах. Очень часто это воспринимается потеря ресурсов. Однако в результате мы получаем эффект по смежным направлениям: сотрудник развивается, не выгорает, работает мотивация остаться в контуре компании, устанавливаются межкомандные связи. Кроме того, мы наполняем для HR воронку стажеров. Поделюсь опытом работы над курсом силами одного эксперта и команды под руководством методолога. Вообще нужен ли методолог? Поделюсь обратной связью от студентов наших курсов. В заключении Вы получите план работы над запуском таких проектов.

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

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

Онбординг часто отвечает на вопрос: «Что нужно рассказать новичку?» Попробуем поставить другой: «Что новичок должен впервые сделать сам, чтобы начать работать в нашей системе?» На мастер-классе участники возьмут реальный фрагмент онбординга своей команды и превратят его из передачи информации в сценарий первого рабочего опыта. Будем проектировать не презентации и инструкции, а действия: первую задачу, первый запрос помощи, первую ошибку, первый pull request, первую обратную связь и первое самостоятельное решение. Каждый участник уйдёт с готовым прототипом фрагмента онбординга для своей команды.

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

Наем — это совместная задача тимлида и рекрутера. Почему передача вакансии рекрутерам не гарантирует результат и как вовлеченность руководителя команды влияет на качество поиска. Почему запрос «найдите сильного и адекватного специалиста» не работает и как переводить ожидания команды в конкретные критерии поиска. Разберем зоны ответственности тимлида: формирование профиля кандидата, брифинг, участие в оценке и обратная связь.Разные тимлиды и рекрутеры: как выстроить эффективную коммуникацию. Тимлиды по-разному подходят к поиску: «тимлид-эксперт» фокусируется на технических навыках, «тимлид-практик» — на задачах команды, «тимлид-перфекционист» — на точном соответствии требованиям. Среди рекрутеров также есть разные подходы: «исполнитель», «партнер» и «консультант». Разберем, как учитывать особенности друг друга и выбирать правильный формат взаимодействия. Как правильно поставить задачу на поиск. Почему одного списка технологий недостаточно и как помочь рекрутеру понять, кого именно нужно найти. Обсудим, как выделять ключевые технические и софт-навыки, разделять must-have и nice-to-have и учитывать контекст команды. Разберем, как через правильные вопросы выявить реальную потребность бизнеса и избежать размытого профиля кандидата. Ошибки тимлидов, которые замедляют поиск. Разберем, какие действия руководителей приводят к долгому закрытию вакансий: размытые требования, поиск «идеального кандидата», изменение критериев в процессе, отсутствие своевременной обратной связи, непонятные причины отказов. Поговорим о типичных ловушках: эффекте «кандидат из известной компании = сильный специалист» и ожидании найти недостижимого «единорога». Как превратить наем в управляемый процесс. Покажем, как выстроить работу с рекрутером. Разберем практические инструменты: калибровочные встречи, смарт-процессы, быстрый фидбек после интервью и роль тимлида в продаже вакансии кандидату.

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

Я расскажу про следующее: 1. Как правильно передавать контекст сотруднику, чтобы сформировать у него фундамент для роста в лида. Зачем прокачивать visibility и пиарить будущего лида задолго до официального грейдапа.Как адаптировать новоназначенного тимлида: передача ответственности, работа с микроменеджментом и менторинг. И что делать, если его темперамент и стиль управления сильно отличаются от вашегоИнвестиции в сотрудника vs найм с рынка: как руководителю оценить понять, когда выгоднее вырастить своего человека, а когда привлекать опытного руководителя со стороны.

В онбординге разработчиков легко попасть в один из двух неудачных сценариев: оставить новичка один на один с welcome-документом и десятками ссылок или превратить ментора в круглосуточную поддержку. Особенно остро проблема проявляется на первых практических шагах: собрать бэкенд, пройти CI/CD-флоу и задеплоить сервис, разобраться с незнакомой ошибкой или впервые выйти на дежурство. Инструкция редко покрывает все ошибки, а новичок ещё не умеет отличать рядовой процесс от ситуации, которую надо эскалировать ментору. У нас в команде навигации Яндекс Карт мы используем командный AI-harness помощника, которому доступны документация, база знаний и рабочий контекст команды. Он сопровождает стажёров и мидлов от разминочных задач до выхода на дежурства за продакшен. ИИ формирует персональный маршрут адаптации, помогает въехать и проверяет прогресс по реальным результатам. Его задача не заменить ментора, а дать новичку помощь 24/7 и подключить человека только там, где это действительно нужно. Слушатели получат схему запуска такого онбординга, понятные правила эскалации и набор метрик эффективности процесса.

Кейс TeamStorm о том, как команда перестроила разработку и тестирование после внедрения ИИ: - как команда за три месяца прошла путь от практически полного отсутствия ИИ в рабочих процессах до системного использования ИИ в разработке; - как полностью ручной регресс за два месяца превратился в автоматизированный процесс; - изменение не отдельных задач, а всего процесса разработки — от постановки требований до выпуска фич; - как с помощью ИИ удалось сократить технический долг на 60% за два месяца.

Клиентский сервис часто начинается с простого принципа: есть обращение — нужно его обработать. Но по мере роста продукта этого становится недостаточно. Клиенту важно не только получить ответ на вопрос, но и понимать, что происходит с его задачами, какие результаты он получает и кто отвечает за развитие взаимодействия. В выступлении расскажу, как прошёл путь от реактивной технической поддержки к проактивному Customer Success: • почему поддержки и тикетов оказалось недостаточно и как появилась идея CSM; • как запустил её с нуля — и что помогло; • как разделил зоны ответственности между техподдержкой и CSM; • как преодолевал сопротивление коллег и выстраивал новые процессы взаимодействия с клиентами; • какие ошибки допустил по пути и что сделал бы иначе сейчас. Это не рассказ об «идеальной трансформации по методичке», а честный кейс построения новой функции с нуля — с ограниченными ресурсами, переобучением текущей команды и неизбежными ошибками по дороге.

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

Дизайн часто воспринимают как сферу, где процессы мешают творчеству, а KPI и метрики только усиливают бюрократию. На практике всё наоборот: отсутствие прозрачной системы приводит к постоянным срочным задачам, непредсказуемым срокам, затянутым согласованиям и выгоранию команды. В этом докладе я расскажу, как мы перестроили работу дизайн-команды в быстрорастущем финтех-продукте и превратили её из хаотичной в предсказуемую систему. Разберём, какие процессы работают, какие нет, зачем мы перешли на недельные спринты, почему целевым ориентиром стало выполнение 80% спринта и как сделать метрики инструментом развития. Отдельно поговорим о сопротивлении изменениям, типичных способах манипуляции метриками и о том, как внедрять процессы так, чтобы команда воспринимала их как помощь, а не как ограничение. В результате трансформации нам удалось: - сократить количество срочных задач в неделю с 10 до 2; - уменьшить время работы над крупной фичей с 2,5 месяцев до 1 месяца; - увеличить долю задач без переноса сроков на этапе дизайна с 68% до 93%; - сократить количество итераций дизайн-ревью с 5 до 2; - сократить количество согласований с C-level с 4 до 1; - сократить исправление багов после дизайн-ревью с 5 недель до 2 недель; - сократить время принятия решений по эффективности процессов и развитию дизайнеров с 8–12 недель до 4–6 недель; - повысить оценку приложения с 4,2 до 4,9, при этом приложение стало лидером по скачиваниям среди финтех-приложений.

В докладе расскажем о нашем подходе к метрикам DS и MLOps в промышленной компании, где за пределами узкого круга IT-специалистов классические технические метрики и метрики ML/DS часто непонятны бизнесу. Для нас метрики стали не формальной отчетностью, а инструментом управления: мы исходим из принципа, что управлять можно только тем, что измеряешь. При этом в DS и MLOps возможных метрик слишком много. Поэтому мы опирались на принцип необходимого и достаточного набора метрик, а сбор показателей старались максимально автоматизировать. Одним из результатов стал разработанный dashboard с метриками, где данные автоматически собираются из Jira. Важным фокусом стала не только фиксация технических показателей, но и их перевод на понятный бизнесу язык: через скорость поставки ценности, надежность процессов, прозрачность загрузки и вклад команды в экономические результаты.

Мы много говорим о том, как внедрять изменения в работе. Но чтобы на них появились силы, часто важно начать с изменений в образе жизни! Наверняка вы уже тысячу раз слышали, что для продуктивной работы и хорошего самочувствия важно спать 8 часов, больше двигаться, снимать ежедневный стресс и регулярно ходить в отпуск. Но по факту… игнорируете сигналы усталости, перерабатываете, а вечером отменяете тренировку или встречу с друзьями, но до середины ночи играете или смотрите сериалы, чтобы хоть как-то отвлечься. Узнали себя? 0 % осуждения! В докладе не будет очередных полезных советов о том, как правильно. Наоборот, я разберу, почему вы все это знаете, но не делаете! - узнаете первопричины (часто неочевидные!), которые мешают повысить уровень энергии и регулярно восстанавливаться - получите конкретные рекомендации, что делать с каждой из них - и лайфхаки, чтобы перейти от "знаю, но продолжаю уставать" к "делаю и восстанавливаюсь" и не доводить себя до выгорания

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

Руководитель нескольких команд физически не может читать все MR и тикеты, а доверять ощущениям нельзя. Купить облачную аналитику — данные команды уедут на чужие серверы. Поставить мониторинг — здравствуй, слежка. Я пошёл третьим путём: собрал Hive Keeper — локальный копилот руководителя на Rust. GitLab, YouTrack и стаффинг стекаются в базу на моём ноутбуке, а локальная LLM каждое утро подсказывает, к какой команде сегодня стоит присмотреться. Расскажу, почему такой копилот обязан быть локальным и что влезает в Apple Silicon с 48 ГБ оперативы; как удержать LLM в этических рамках; и что она реально лечит в жизни руководителя — а где пока бесполезна. С демо, боевыми кейсами и честными фейлами.

Расскажу про то, какие есть агенты в Обслуживании, как они устроены, как живут эту жизнь их разработчики и кто их в итоге будет поддерживать?

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

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

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

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

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

Главное знание, которое важно зафиксировать: команды разработки нельзя мерить напрямую деньгами или абстрактной бизнес-метрикой. Они не могут влиять на нее напрямую. North Star Metric — это не просто красивая цифра для отчётности. Это рабочий инструмент, который ежедневно отвечает инженеру и продакту на вопрос, что приоритетнее прямо сейчас. Как работать с фреймворком для выпуска продукта/фичи/глобального обновления? Пройти несколько этапов: Формулируем Единую North Star Metric (NSM)Декомпозиция в Miro(аналоги): Связываем бэклоги Nкоманд с NSMРазметка ответственности командРешение задачи по выпуску фичи/обновления до новой версии без бюрократииCross-Team Working Agreement для релизаМеханизм эскалации «Data-Driven Развилка» в действииРитуал: Квартальный (можно меньше) маркетплейс релизов.

Приходилось ли вам осознанно разрушать хорошую команду, не потому что она не справилась, а потому что ее прежняя задача закончилась? О тимлидстве рассказывают через правильные советы: защищай команду, сохраняй техническую экспертизу, будь вовлеченным. Но в неочевидных управленческих ситуациях правильного решения часто нет, а то, которое выглядит хорошим в моменте, иногда "стреляет" тяжелыми последствиями позже и в неожиданном месте. В докладе я разберу такие истории из своего опыта: я принимал взвешенное решение, а оно приводило к последствиям, которых я не ожидал. Это не уникальные случаи: те же ситуации я регулярно вижу у коллег, это классика для тимлидов. Как заранее увидеть цену выбора, если единого правильного ответа нет? Я покажу, что в таких ситуациях помогают индикаторы. Чтобы их сформулировать, на старте нужно понять, какую проблему я решаю, от какой альтернативы отказываюсь и какой побочный эффект могу получить, а затем решить, как это замерить и как оцифровать риски. Сделать это можно дешево, за полчаса, по джире, календарю и плану работ. Среди разбираемых историй: «Никто не будет тебя учить», «Работать руками нельзя, не работать тоже», «Морфий организации» и «Иногда надо разрушить хорошую команду». У каждой свой индикатор. Например: за что вас хвалят в ревью и нет ли там того, что пора перестать делать; когда вы в последний раз не согласились с технической оценкой команды и оказались правы; знаете ли вы имя человека, который принимает решение, и дату решения, прежде чем сказать команде «скоро». Вы уйдете с набором таких сигналов и примерами порогов для каждого из них.

Почему никто не виноват, а всё работает плохо Бизнес-симуляция о том, как хорошие люди сами создают организационный хаос Вы наверняка видели такие команды. Никто не ленится. Никто не саботирует. Все заняты. Но результата нет. Все умные, все стараются. Почему тогда всё опять идёт не так? На 90 минут мы создадим небольшую организацию. Вы получите роль, часть информации и вполне разумную задачу. Кто-то станет топом, кто-то мидлом, кто-то окажется в команде, кто-то — на стороне клиента. Дальше организация начнёт жить. Несколько игровых дней. Вас будут отвлекать срочные задачи. Не вся информация окажется доступной. Одни решения будут помогать вашей роли и неожиданно мешать организации в целом. Вам придётся принимать решения, договариваться и координироваться с другими уровнями. И довольно быстро станет понятно, сможете ли вы собрать работающую систему — или сами начнёте создавать тот хаос, на который обычно жалуетесь в реальной работе. Самое неприятное: чтобы всё пошло не так, никто не обязан саботировать или специально ошибаться. Каждый может принимать вполне разумные решения со своей стороны — а общий результат всё равно не складывается. После игры мы разберём не «кто виноват», а что произошло с системой: - В какой момент организация перестала понимать сама себя? - Когда локально правильные решения начали вредить общему результату? - Что изменилось после появления общей картины? Затем каждый участник найдёт похожий паттерн в своей реальной работе — в команде, проекте или организации — и попробует определить, что можно изменить не в людях, а в условиях их взаимодействия. Мастер-класс особенно полезен тимлидам и членам кросс-функциональных команд, которым приходится работать между разными уровнями, интересами и приоритетами — особенно во время роста, реорганизации, запуска новых направлений или изменения процессов. Это не лекция и не разбор чужого кейса. Сначала вы сами создадите организацию. Потом посмотрите, что она сделала с вами.

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

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

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

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

Запросов больше, чем людей – обычно отвечают героизмом, и через полгода команда в огне. В докладе – каркас приоритетов для эксплуатации/platform: что резать первым, что защищать в capacity, как говорить «нет» без войны. Разберём, что ломается при x5/x10, чем системный блокер отличается от локального улучшения, и метрики без «единиц учёта»: риск, поток, верификация – не часы как KPI человека. Унесёте каркас совета приоритетов, шаблон «нет» и список анти-паттернов.

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

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

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

Мы делаем системы отказоустойчивыми (автоматическое восстановление, георезерв), но самый важный элемент надежности в ИТ сбое/аварии/инциденте — инженер под стрессом в критической ситуации. Грейд меряет, что инженер знает в покое. Авария позволяет понять, как он думает под огнём. Это разные инженеры, и в кризис мы нередко ставим не на того. Авиация и спасатели научились управлять поведением в кризисе: протоколы, роли назначенные заранее. 20 лет опыта аварии в финтехе и исследование, как соотнести и перенести опыт авиации, спасателей в ИТ production. Покажем поведенческие маркеры сильного инженера в аварии, данные исследования (результаты интервью сотрудников авиации и аварийных служба, опрос ИТ инженеров и лидеров), а в финале представим два готовых инструмента: портрет инженера, который держит удар, и чек-лист первых 5 минут аварии.

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

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

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

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

После объединения зонтичной структуры наши отделы продолжали жить логикой «своих» продуктов: продажи, продукт, маркетинг и логистика делили результат на «наш» и «их», а единственной точкой сшивки был руководитель. Мы убрали «своё/чужое» без новых регламентов: сквозные цели на общий результат, кросс-функциональные связки с обменом экспертизой и правило «все ошибки мои, все достижения — команды» как рабочая механика, а не лозунг. Итог по внутренним замерам: −40% конфликтов и инициативность ×2 — без бюрократической прослойки.

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

Системный аналитик привык делать непонятное понятным: задавать вопросы, прояснять требования, соединять бизнес, продукт и разработку. Но что происходит, когда такой человек становится руководителем? Я расскажу о своём опыте в роли руководителя группы системных аналитиков в Okko. Главный конфликт перехода: раньше мой результат был в требованиях, документации и задачах, которые я делала руками. После перехода в руководство результат стал зависеть от того, насколько понятны приоритеты, ожидания, ответственность и состояние людей в команде. В докладе разберу: - как собрать артефакты управляемости: бэклог, доски, регулярные синки с продуктами и планирование ресурса; - как работать с ситуацией, где одного аналитика тянут несколько продуктовых команд с разными приоритетами; - как руководителю соединять сотрудников и заказчиков так же, как аналитик соединяет бизнес и разработку; - как проводить 1:1 не формально, а как исследование: не принимать “всё хорошо” за достаточный ответ, если факты говорят другое; - как использовать фактуру из 1:1, обратной связи, ИПР и перформанс-ревью для честных управленческих решений. Слушатели унесут практический набор подходов для руководства: как делать работу команды видимой и как переводить экспертный опыт в управляемую систему, как задавать правильные вопросы людям и стейкхолдерам.

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

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

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

Представьте себе команду, которая постоянно загружена на 146%, но всё равно катит фичи месяцами. Эта картина знакома до боли каждому тимлиду. Как в сказке, время таких команд утекает незаметно и порциями. Тимлиды обычно пытаются ускорить написание кода или поднять мотивацию, но главные потери скрыты там, где их меньше всего ищут. На докладе мы снимем хайп с ИИ и разберем, почему точечное ускорение разработки часто не продвигает проект ни на шаг, а лишь перегружает процессы и плодит скрытые баги. Мы деконструируем иллюзию «эффективной работы» и разберем антипаттерны, которые ежедневно воруют часы у ваших инженеров под видом хорошего менеджмента. В результате доклада вы получите готовую рамку для аудита своего процесса поставки. Вы поймёте реальную цену антипаттернов в команде и унесете инструменты для расшития узких мест.

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

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

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

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

Как убрать руководителя и не развалить всё. Расскажу как мы трансформировали R&D в структуру без менеджеров, какие подходи и практики внедрили и причем тут HR

Как договориться, что значит «хорошо», если в команде десять сильных специалистов и каждый работает по-своему? Чем подробнее руководитель описывает «правильный» процесс, тем выше риск получить формальное соблюдение правил вместо хорошего результата. Я покажу другой подход: стандартизировать не способ работы человека, а наблюдаемые признаки качества результата. Разберём, как создавать индикативные карты для командных практик — 1:1, постановки задач, code review, встреч, наставничества — и использовать их для самопроверки, peer review, обратной связи и развития команды.

Мы определим какой ты лид, а также расскажем как может помочь ИИ в твоей работе и стать еще эффективнее

Как увидеть потери которые убивают программные проекты? Как выявление аномалий системы повышает эффективность команды? Последние 5 лет команда обеспечивает выполнение программных проектов без срыва сроков, штрафных санкций и переработок. В 7 раз снижено количество инцидентов. При этом доля ошибок программного обеспечения снижена с 70% до 20%. Скорость решения инцидентов возросла в 5 раз. Рентабельность команды выросла в полтора раза.

ТЕСТ

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

Название явления: в последний год у многих тимлидов, даже без формальной программы трансформации, де-факто появилась четвёртая роль — проводник изменений для команды, поверх кода, продукта и людей. Компания это не всегда называет и не оформляет, но требует. Три конфликта, которые эта роль создаёт для конкретного тимлида: (1) время и фокус — код/продукт vs транслирование изменений команде; (2) доверие — команда устала или сопротивляется, а разъяснять и держать удар должен именно TL лицом к лицу, без права сказать «это не ко мне»; (3) компетенция — от тимлида ждут навыков agile-коуча и HR, которым его никто не учил. Как эти конфликты выглядели на практике в Magnit Tech: конкретные ситуации, включая неудачные — где тимлид перегорел, где команда не поверила, где не хватило языка объяснить «зачем». Что реально помогло именно тимлиду, а не программе в целом: конкретный набор — обучение, AI-агент как второй мозг в рутинных и сложных разговорах, метрика зрелости как способ не спорить с ощущениями, а показывать факт, рабочая группа как место, где TL не один. Показываем, что сработало и что не сработало и почему. Самодиагностика для зала: 4-5 вопросов, по которым тимлид без всякой программы трансформации в своей компании поймёт, что он уже де-факто выполняет эту роль — и что с этим делать до того, как его туда бросят без подготовки. Что участник унесёт с собой Язык для разговора с собственным руководителем: как назвать и обосновать роль проводника трансформации, если в компании её никто официально не выделял, и попросить под неё время или поддержку. Чек-лист самодиагностики: конкретный список вопросов, чтобы понять, где сейчас находится лично он в этой роли, и не считать усталость от неё личной слабостью. Один готовый к копированию артефакт из практики Magnit Tech — сценарий использования AI-агента в сложном разговоре с командой, который можно попробовать в своей команде на следующей неделе без разрешения сверху. Понимание, какие навыки прокачивать первыми, если роль проводника трансформации на тимлида уже легла или скоро ляжет.

Когда-то разработчиков объединяли в функциональные команды: frontend отдельно, backend отдельно, тестирование отдельно. Затем появились кросс-функциональные команды, способные самостоятельно доставлять продуктовый результат. Теперь всем раздали AI-подписки — и организационная модель снова изменилась, хотя на схеме компании этого пока не видно. Один инженер с AI-агентами может анализировать требования, менять frontend и backend, писать тесты, готовить документацию и проверять результат. Разработчик фактически становится лидом виртуальных исполнителей. Но и у тимлида появляются собственные агенты — для работы с контекстом, наблюдения за delivery, поиска архитектурных рисков и моделирования вариантов планирования. На примере full-stack-команды и экспериментов с AI-разработкой в AvitoTech я покажу, как управлять такой двухуровневой системой. Разберём, какими знаниями теперь должен обладать тимлид, как балансировать T-shaped-инженеров и хранителей глубоких компетенций, где проводить границу автономности AI и почему скорость генерации нельзя масштабировать раньше способности команды проверять результат. Слушатели получат модель команды из исполнительного, управляющего и человеческого контуров ответственности, набор командных соглашений, систему quality gates и план перехода от хаотично выданных AI-подписок к управляемому процессу.

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

Опытному лидеру редко говорят простую вещь: опыт не защищает от истощения, он маскирует его. Чем сложнее задача, тем сильнее соблазн «решить всё самому», и через 6-12 месяцев вы оказываетесь единой точкой эскалации в собственной команде — там, где каждое решение проходит через вас, потому что иначе система встанет. Это не про выгорание. Это про то, что у вашей роли нет операционной системы. Есть 30 задач, есть календарь, есть амбиции — а рычага, через который вы принимаете решение «куда потратить следующий ресурс», нет. За 40 минут разберём: Модель 4 ресурсов — время, внимание, здоровье, деньги. Почему именно эти, почему они не переводятся друг в друга, и как понять какой из них у вас проседает первым.Три системных паттерна — «я — единая точка эскалации», «дотерплю до релиза», «регулярный синк по инерции». С голосованием руками — увидите, что вы не один.Фильтр «задача vs изменение системы» — простой тест на 1 вопрос, который отличает силовое решение от структурного.4D-фрейм принятия решения — отменить, делегировать, переспроектировать, защитить. Когда какой ход работает.Формула контракта с собой на 30 дней — глагол + наблюдаемое действие + дата + место. Без «постараюсь».

Сформулируем позже на основе обратной связи от ПК

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

Управленческий мастер-класс по тому как выявить и развивать ключевых сотрудников и что делать с "террористами" и "звездунами"

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

Каждый будний день почти всех из нас (тимлидов/PM/DM/EM/HR/Нead/СТО) на 90% состоит из управления изменениями, но мы не привыкли смотреть на свою работу через эту призму. Зачем слушать: опытным — систематизировать интуитивно обретенные знания, для тех, кто только собирается что-то изменить в своей команде — знать, к чему быть готовым выходя на эту дорогу. По итогу доклада получите: получите блок-схему по управлению изменениями, узнаете о наиболее распространенных ошибках и провальных кейсах поймете, где недоработали вы, а где все было обречено на провал изначально научитесь выявлять бесперспективные изменения на ранней стадии

Классическое планирование по ощущениям («этот разработчик, наверное, справится с этими задачами за квартал, повторить для следующего») почти никогда не работает — команда либо не успевает, либо работает 24/7 в конце отчетного периода. В докладе поделюсь опытом как построить планирование не от балды, а на основе данных: от правила «никакой деятельности без таски» до готовой аналитики по capacity, балансу product/tech debt и загрузке команды в FTE. Разберём не только внедрение самих story points, но и то, как те же данные закрывают управленческие задачи, о которых обычно не говорят вслух. Отдельно — про ограничения story points: где метрика врёт и почему это не серебряная пуля.

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

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

Расскажем о том, как построить автоматизированную управленческую отчётность, которой верят, а затем шагнуть в self-service и AI

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

Расскажу о разнице управления командами в зависимости от её масштаба и задач. О роли тимлида как связующего звена: между бизнесом и командой, между командой и результатом, и зачем он вообще нужен команде. Или не нужен?

Вы закрыли ноутбук, переключились на Telegram, сериал, спорт или прогулку, а сил почему-то не прибавилось. Потому что переключение и восстановление - это разные вещи. Более того, один и тот же способ отдыха сегодня может помочь, а завтра - нет: всё зависит от того, какой восстановительный опыт вам сейчас нужен. На интерактивном мастер-классе разберём шесть механизмов восстановления по модели DRAMMA (отсоединение, релаксацию, автономию, мастерство, смысл и связь) и посмотрим, что об отдыхе, внимании и усталости говорит когнитивная наука. Больше половины времени займёт практика: попробуем несколько способов восстановления прямо в зале - от ритуала закрытия незавершённой задачи и двух минут «ничегонеделания» до микроопыта мастерства и трепета. В финале каждый соберёт своё меню восстановления и выберет один эксперимент, который сразу поставит в календарь.

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

Тезис 1. Фасилитацию считают внешней экспертизой, хотя каждый тимлид использует её ежедневно Фасилитация ассоциируется со стратегическими сессиями и внешними консультантами. Однако большинство тимлидов ежедневно выполняют функции фасилитатора, просто не воспринимают это как отдельную профессиональную компетенцию. Тезис 2. Хорошая коммуникация не возникает сама по себе Даже опытные специалисты не всегда приходят к общему решению. Проблема чаще заключается не в нехватке экспертизы, а в отсутствии человека, который управляет процессом обсуждения и помогает команде договориться. Тезис 3. Фасилитация начинается до встречи Цель фасилитации — не организовать обсуждение, а привести команду к результату. Поэтому её основа — грамотная подготовка: понятная цель встречи, правильный состав участников и общий контекст. Тезис 4. Инструменты фасилитации работают в ежедневной разработке Фасилитация — это дисциплина с понятными методами. Они помогают удерживать фокус обсуждения, вовлекать участников, работать с разногласиями и превращать обсуждения в решения без привлечения внешнего фасилитатора. Тезис 5. Решение существует только тогда, когда оно принято всеми Результат встречи — это не обмен мнениями, а понятное всем решение с зафиксированными договорённостями, ответственными и следующими шагами. Тезис 6. Фасилитация — навык, которому можно научиться Фасилитация — это не врождённый талант, а профессиональная компетенция. В докладе будут показаны практические техники, которые можно использовать уже на следующей рабочей встрече. Тезис 7. Возможно, фасилитация — недостающий элемент современного лидерства Мы много говорим о техническом лидерстве и управлении командами, но редко рассматриваем фасилитацию как базовую компетенцию тимлида. Моя гипотеза заключается в том, что именно этот навык во многом определяет качество коллективных решений и эффективность команды.

Развитие людей в большинстве команд — это либо формальные перф-ревью, либо хаотичные курсы «для галочки». Я предлагаю другой взгляд: развитие своих людей как система из четырёх слоёв — руководитель, сотрудник, команда, бизнес. На воркшопе разберём: — Руководитель: почему начинать надо с себя — оценка других всегда проходит через ваш профиль, а свои сильные стороны определяют, какие гэпы команды вы не видите. Инструменты калибровки себя: Hogan и Gallup CliftonStrengths. — Сотрудник: скоркарта компетенций (шкала «Знаю/Применяю», целевые оценки, вес важности для бизнеса) и путь роста на два квартала — от гэпов к боевым активностям и ежеквартальным синкам. — Команда: конфигурация, где люди дополняют друг друга, — вместо охоты на A-players. Как сделать синергию: каждый знает, в чём силён и где нужна поддержка. — Бизнес: измеримый эффект — качество продуктовых решений, снижение bus-factor, удержание сильных, найм под гэпы конфигурации, прозрачная связь развития людей с P&L. Всё на живых кейсах из моей практики (Билайн, Skyeng, Авито, Garage Eight) — с цифрами изменений ключевых метрик за 6 месяцев, выводами и шишками.

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

В 2025 я зафиксировал свод ограничений современных GPT: зацикливание, галлюцинации, окно контекста, амнезия, деградация на длинной дистанции, jailbreak, неровный интеллект, отсутствие нового смысла. В живом контуре Bitkogan эти же сбои пришли пакетом, потому что в одном цикле работают несколько семейств LLM от разных провайдеров. Что сделано по фактам. Роли зафиксированы: один оркестратор, далее ИИ-1 (например, Claude) дает инструкции и планирует архитектуру, ИИ-2 (Codex) аудирует, ИИ-3 (Grok) реализует код, ИИ-4 (к примеру DeepSeek) рецензирует и принимает качество. Как наблюдаются проблемы: невыполненные поручения, регрессии, потерянные пункты списка. Самодиагностика может врать в 11 из 12 пунктов; а автотесты и гарды могут при этом декларировать что все закрыто 10/10 тестами. Человеческое лицо здесь простое: каждое правило пишется на основе наблюдаемых проблем, доказательство ищется по месту (source, tests, deploy, served, live). Длинный контракт харнеса компилируется в автоцикл с четкими гейтами и проверками. Живые проверки (HIL) которые читает человек, формируются по правилам. Доклад разбирает типовые сбои свода 2025 на этом авто-контуре и те решения, которые уже реализованы через скилы, хуки и приемке на каждом этапе.

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

Вы когда-нибудь принимали проект, который уже «горит», а команда разобщена настолько, что даже не знает имён друг друга? Вы получаете эскалацию от заказчика, предыдущий РП ничего не может внятно объяснить, а тимлид по автоматизации увольняется через день после вашего выхода. Знакомо? На этом выступлении Елена Маламут, руководитель проектов с 10-летним стажем, разберёт реальный кейс приёмки проблемного проекта: команда из 15 человек в 4 часовых поясах, три направления тестирования (ручное, автоматизированное, нагрузка), нулевая коммуникация и негативный отзыв заказчика. Вы узнаете, с чего реально начинать, когда информация по проекту отсутствует, а команда не знакома друг с другом. И главное — как за несколько месяцев превратить молчащий чат в живую команду, получить высшую оценку 360 и благодарность заказчика.

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

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

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

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

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

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

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

Компьютерные стратегии с самого детства давали нам попробовать себя в роли тимлида: Warcraft 3, Heroes of might and magic III и другие. Игровые механики достаточно точно передавали проблемы руководителя: нехватка ресурсов, скорость принятия решения, конкуренты, строительство проектов. Но если так просто играть в игры, то быть тимлидом тоже должно быть просто? В своем докладе я проведу параллель между компьютерной игрой и работой тимлида. Что общего? А какие игровые практики наоборот не стоит переносить в реальный мир. В ходе размышления, мы разберем популярные проблемы начинающих тимлидов и попробуем поменять отношение к этому ремеслу.

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

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

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

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

Переход от роли сильного инженера к руководителю крупного IT-управления — это не просто расширение зоны ответственности, а серия болезненных кризисов идентичности и полная смена управленческого инструментария. То, что делает вас лучшим техническим экспертом или успешным лидом двух команд, гарантированно разрушит стрим из 8 команд или управление на 250 человек, если вовремя не изменить майндсет. В докладе — честный разбор эволюции руководителя на реальном масштабе Enterprise: от дата-инженера и создания критически важной стриминговой платформы с двумя командами до масштабирования ее в стрим (6–10 команд) и последующего перехода к управлению командой из 250 менеджеров и инженеров. О чем поговорим: От инженера к лиду 2 команд: как перестать быть «главным спасателем спринтов», выстроить инженерный конвейер и отпустить написание кода. От 2 команд к стриму (6–10 команд): механика управления через других тимлидов, внедрение Team Topologies, развязка зависимостей и выравнивание стандартов. От стрима к управлению на 250 FTE: разговор с C-Level на языке P&L, оргдизайн под бизнес-стратегию, бюджетирование (CAPEX/OPEX) и защита платформенных инициатив. Грабли каждого уровня: разбор типичных антипаттернов («супер-сеньор у руля стрима», «директор на код-ревью», «платформа в башне из слоновой кости»). Фреймворк самодиагностики: чек-лист для проверки готовности к следующему масштабу управления.

The question everyone asks is whether agents replace engineers. The question a lead actually has to answer is narrower and harder: what can you hand to an agent, what do you have to take back, and what does it do to your people's roles and your costs? We spent a year both building an agent product and running agents inside our own small team. Some things we delegated stuck. Some we delegated and had to pull back, sometimes after they had already caused a mess. The human work didn't disappear; it moved up, toward specification, judgment, and verification, and that shift is a real change in what the job is. This talk is the honest account of what we handed over, the one thing we revoked and why, how roles changed, and where the ROI was real versus where supervision quietly ate the gain. This is not a demo, but rather a year of management decisions.

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

AI меняет разработку — это уже не спорно. Спорно другое: прирост есть, но заметно меньше ожидаемого. Инструменты внедрены, метрики использования растут, а сроки поставки стоят на месте. Похоже на промышленный станок, поставленный в мастерскую, где всё остальное осталось прежним. Станок работает и даже даёт прибавку. А дальше упирается в дверной проём, в то, как подвозят сырьё, и в то, что готовое по-прежнему вывозят на телеге. Подешевело производство ткани, а не производство и доставки готового изделия. Значит, вопрос не в том, какой станок купить, а в том, как устроена мастерская. И тут выясняется неприятное: то, как мы организуем разработку последние двадцать лет, было ответом на условие, которое перестало выполняться. Под прицелом оказывается agile — не целиком, но в очень конкретной своей части. Разберём, что в нём выжило, а что перестало окупаться, и что из этого следует лично для вас: на что смотреть в своей команде, что можно поменять, ни у кого не спрашивая, и где заканчивается ваша зона ответственности.

Внедрение AI ускорило написание кода, но сместило узкие горлышки и когнитивную нагрузку в другие точки. Но пока метрики показывают разные ускорения - у людей незаметно накапливается специфический тип усталости. Его уже называют AI brain fry. На примере моей команды посмотрим, что становится новым узким горлышком и как понять, что ваши сотрудники копят новый тип усталости.

Внедряем многоуровневую верификацию с human-in-the-loop для 100% точности выводов в критических процессах Переходим на федеративное обучение и zero-trust архитектуру, где данные всегда находятся в вашем контуре Строим AI governance с автоматизированными compliance-checks под GDPR, AI Act и российским ФЗ-152

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

Большинство статус-митингов существуют только потому, что данные о разработке размазаны по Jira, GitLab, Confluence и десятку других систем. Люди тратят часы на ручную синхронизацию контекста, хотя вся информация уже есть — просто в нечитаемом виде. В докладе я покажу open-source утилиту, которая собирает поток событий из разных источников, строит связи между задачами, людьми и проектами, а затем с помощью AI превращает это в понятные отчёты и автоматически проводит текстовый “статус-митинг”. Мы разберём, как агрегировать инженерные события до уровня проекта, как LLM может анализировать коммуникацию внутри команды и почему AI способен заменить значительную часть рутинного project management. Без “магии AI” — только архитектура, данные, промпты и реальные ограничения такого подхода.

1) Кто такой AI-лидер? Тот кто умеет пользоваться ChatGPT или это человек, который понимает, где AI реально даёт бизнес‑эффект? Он может найти ответ где AI усложняет систему и увеличивает затраты, и может перевести эту разницу на язык денег и метрик. AI‑лидера нельзя нанимать по универсальному списку навыков: сначала нужно определить, какую бизнес‑задачу он должен решить в первые 3–6 месяцев. Обсудим как сформулировать профиль компетенций? Где искать таких лидеров? Обсудим как по профилю найти компании-доноры, где уже выстроена сильная ML-культура. 2) Как нанимать, когда крутых мало, а крутых AI-лидеров еще меньше? Теоретические вопросы про ML и LLM не показывают, справится ли человек с реальной работой. Лучше работают прикладные кейсы с неполными данными, конфликтующими метриками и меняющимися вводными. Покажу примеры кейсов и критерии правильности их решения. На интервью важно оценивать не «правильность ответа», а способность структурировать неопределённость, связывать метрики модели с вашим продуктом и деньгами, работать с фидбеком и доводить обсуждение до решения. 3) Онбординг в “боевых” условиях Онбординг AI‑лидера должен начинаться с одной приоритетной задачи, карты метрик и ограничений, а не с набора хаотичных AI‑пилотов. В первые 90 дней нужно заранее проектировать: зоны ответственности, стейкхолдеров, ритм синхронизаций, ожидаемые решения и критерии прогресса. Участники получат прозрачный профиль AI-компетенций под задачи бизнеса, структуру боевого интервью и как собрать базу прикладных продуктовых кейсов для проверки мышления и чек‑лист онбординга AI‑лидера.

DORA metrics tell you what happens at and after deployment. They don't tell you where, in the whole path from idea to production, your time is actually going. For most teams the answer is uncomfortable, as you spend far more time waiting than working. We decomposed time-to-market into four parts: Lead Time (idea to first commit), Cycle Time (commit to production), Process Time (actively worked), and Delay Time (waiting in queues). The finding that changed our priorities was that most of our cycle time was Delay Time: code sitting in review queues, changes waiting on a decision, and work blocked on someone's attention. This is not a tooling problem; it is a leadership problem. We had been optimizing CI speed, but the data showed review turnaround mattered several times more. This talk is about how measuring the waiting, which is the part no dashboard showed us, changed what the team worked on, and why the biggest delivery lever for a lead is usually the human queues, not the pipeline.

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

По мере роста мобильного продукта в нем неизбежно появляется множество внутренних инструментов: переключение окружений, feature toggles, изменение URL сервисов, тестовые push-уведомления, подмена даты, debug-настройки и диагностические экраны. Без единого подхода они быстро «рассыпаются» по кодовой базе: открываются через секретные тапы на разных экранах или живут в отдельном кустарном debug-меню. В итоге разработчики каждый раз «изобретают велосипед», QA-инженеры тратят время на поиск нужной настройки, а между проектами внутри компании отсутствует единый стандарт. В докладе разберем опыт создания единого плагинного фреймворка для Dev Mode, который решил эти проблемы: 1) Архитектурный шаблон: Как отделить общую инфраструктуру (UI, навигацию, реестр) от самих отладочных инструментов и бизнес-логики фича-модулей. 2) Стандартизация: Пошаговое подключение новых отладочных экранов через простой контракт без изменения инфраструктуры фреймворка. 3) Синергия ролей: Как превратить Dev Mode в единую рабочую среду не только для разработчиков, но и для QA, аналитиков и службы поддержки (настройка тестовых сценариев без пересборки кода). 4) Безопасность: Подходы к гарантии того, что debug-инструменты не утекут в продакшн-сборки.

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

Внедрение LLM в продакшен сегодня упирается не в генерацию, а в безопасность. Guardrail-модели (фильтры безопасности) банят безобидные вопросы или пропускают явные угрозы, а сравнивать их «на глаз» невозможно: вендоры публикуют только удобные им метрики, а ручной аудит одной модели занимает дни работы ML-инженера. Мы в HiveTrace & AI Security Lab столкнулись с этой проблемой при дообучении собственных guardrail моделей и по этой причине собрали собственную автоматизированную арену для честной оценки guardrails. В докладе мы поделимся результатами аудита топовых open-source моделей и расскажем: • Почему стандартные метрики (Accuracy, F1) врут при оценке безопасности ИИ, и на что смотреть вместо них (FPR/FNR). • Как архитектура и размер модели влияют на скорость (latency) и качество защиты: почему модели на 0.6B иногда обходят гигантов на 15B. • Как мы автоматизировали проверку по 19 бенчмаркам, сократив время аудита с 5 часов до 30 минут, а стоимость цикла — на 90%. • Практический гайд: как выбрать модель под свой бизнес-кейс. Доклад будет полезен всем, кто внедряет LLM, отвечает за AI Safety или хочет понять, как объективно оценивать ML-инструменты без веры маркетинговым обещаниям вендоров.

Этот доклад — для руководителей, которым знакома ситуация: очередное изменение дало локальный эффект, но непонятно, приблизило ли оно команду к нужному результату или лишь перенесло затраты и ограничения в другое место. Inferno Driven Development — аллегория такого движения по кругу: боль → изменение → облегчение → новая боль. На собственном опыте покажу, как разумное решение может появиться раньше, чем сформулирована цель, и почему полезные по отдельности изменения не всегда складываются в значимый результат. Практическая ценность доклада — возможность раньше замечать изменения с неясной целью, сужать или останавливать их до того, как они станут отдельной работой для руководителя и команды.

Инструмент не создаёт процесс. Можно настроить Jira, проводить дейлики и работать спринтами, но по-прежнему не понимать, кто чем занят, сколько работы осталось и почему сдвигаются сроки. Первый шаг к управляемости — сделать работу видимой. Единый backlog, владельцы, статусы, история решений и понятные правила движения задач. Изменение процесса снизу требует поддержки сверху. Инициатива заработала устойчиво только после того, как product- и IT-лиды сделали новые правила нормой для всей команды. Предсказуемость важнее количества закрытых задач. Story points, burndown и история спринтов нужны прежде всего для оценки capacity, перегрузки и реалистичности обязательств. Процесс должен сохранять не только сделанное, но и решения не делать: Won’t Do, Out of Scope, «не ошибка», дубли и причины отказа. Один процесс нельзя механически переносить между командами. То, что работает в разработке, оказалось плохо применимо к непредсказуемому потоку клиентских обращений. Рутину можно постепенно отдавать ИИ, если операция повторяема, а пространство возможных решений достаточно ограничено. Следующий уровень зрелости — управлять не количеством задач, а их ценностью: дерево метрик → влияние на деньги/затраты/риски → RICE/Impact → MoSCoW → проверка эффекта после релиза. Главный вывод: хороший процесс не добавляет бюрократию — он позволяет команде и руководителю понимать что происходит, почему это происходит и чего ожидать дальше.

О чём live coding AI быстро пишет код, но проверять и принимать результат всё равно человеку. На ливкодинге покажу, как использовать ATDD + AI + двойной цикл TDD, чтобы не получать большой diff «на веру», а вести AI маленькими проверяемыми шагами.Что буду показывать На финтех-кейсе применю ATDD с AI: зафиксирую ожидаемое поведение в acceptance-тесте, отревьюю его до реализации, затем реализую сценарий через короткие TDD-итерации с unit-тестами, AI-реализацией и рефакторингом. Покажу, как настраивать AI через prompt, skills или AGENTS.md.Что заберёте с собойалгоритм работы с AI через ATDD;рабочие промпты;пример настройки AI через skills или AGENTS.md;понимание, где подход помогает, а где нужно что-то другое.Кому полезнотимлидам, которые хотят встроить AI в процесс команды;драйверам изменений, которые ищут управляемый способ внедрять AI-разработку;командам, где ошибка в бизнес-логике дорого стоит.

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

Перформанс-ревью часто превращается в театр абсурда. Техлиды жалеют стагнирующих сотрудников, придумывают им "удобные" мелкие задачи и боятся сложных разговоров. Сотрудники выгорают от синдрома самозванца. А ведь у нас есть всё, чтобы разорвать этот порочный круг. У нас есть гигабайты текстовой истории: калибровки за прошлые годы, селф-ревью, статистика git (размер и суть коммитов), логи Jira и активности в мессенджерах. Если перестать демонизировать LLM и включить инженерный подход, AI становится идеальным, беспристрастным помощником руководителя. Модель не умеет "жалеть", она видит паттерны, "жалеет" человек! В докладе я на реальных (анонимизированных) кейсах покажу, как мы скормили LLM данные и научили её подсвечивать слепые зоны менеджмента.

Три года назад на Saint TeamLead Conf я рассказывал, как меня назначили руководителем, я не справился, ушёл с роли - и вернулся в неё. Вот что было дальше. У меня был проект, который умер. Состояние на момент остановки: 88% задач закрыты, 445 тестов в репозитории - и ни одной сборки, которая падала бы от красного. И ни одного демо заказчику, прошедшего в полном объёме. Ни разу Через два месяца заказчик вернулся: доработать пару мелочей под утверждённую спецификацию. Сделал сам за вечер, с агентами. Потом он попросил вещи посерьёзнее и вот она развилка, ради которой этот доклад. Раньше мой ответ был бы: надо собирать команду. Не потому что не умею писать код, а потому что больше трёх-четырёх часов в неделю я этому проекту дать не мог, а три часа в неделю — не разработка, это хобби. Но я впервые пересчитал ту же работу с другими коэффициентами, сделал пару серьёзных фич быстро и показал заказчику. Он предложил возобновить проект: в таком формате это перестало быть затратным. Отсюда главный тезис: проект умер не потому, что был плох, а потому что минимальная команда, способная его двигать, стоила дороже оставшейся в нём ценности. Агенты не ускорили разработку — они опустили порог, ниже которого проект перестаёт быть жизнеспособным. Под этот же порог входа, "провалилась" целая стопка проектов, которые раньше нельзя было делать вообще: не "медленно", а именно нельзя. Сколько ваших проектов заморожено не потому, что не нужны, а потому что "на это нужна команда"? Что ещё будет: Как теперь выглядит "показать". Скринкасты вместо созвона: система сама проходит по сценарию, запись уходит файлом. Демо, которое надо комментировать, это не демо, это защита. И обратная связь "ничего не работает" как входной материал: разложить на проверяемые утверждения - работа руководителя, а не заказчика.Неудобная находка. Агенты делают ровно то, что я прошу. Значит, когда люди делали не то, проблема была не в них. Здесь же сходятся те самые 88% - определения готовности не существовало, оно жило у меня в голове, и каждая из тридцати задач была честно закрыта по своему собственному определению. Правило "до зеленого " оказалось первым письменным определением готовности в истории проекта. Что стало с тестами, когда у них появилась работа: e2e выросли в 9 раз, бэкенд — вдвое. Растёт то, на чём стоит решение.Я не сбежал от менеджмента. ADR до кода, DoD, разделение исполнителя и приёмщика, гейт приёмки. То есть процессной дисциплины стало больше, а не меньше. Кто думает, что агенты отменяют менеджмент, просто ещё не выкатывал ими в прод.Чего агент не делает и где граница применимости - разберемсяс этим и с возражением "сейчас будет вал сгенерированного говнокода". И мой ответ не "зато быстро", а критерий, по которому решается, сколько качества продукт вообще обязан стоить. Что заберете: способ пересчитать замороженные проекты по новым коэффициентам и понять, какие из них живые; почему "команда делает не то" почти всегда диагноз руководителю; что из менеджерской операционки одинаково работает на людях и на агентах, а что было компенсацией её отсутствия; рабочий критерий качества для разработки с агентами

Все говорят про AI-агентов, но единицы довели их до прода. Я расскажу, как мы построили «software factory» — конвейер из 12 специализированных AI-агентов, который ежедневно пишет, ревьюит и поставляет код для AI-native SaaS MShift. Мы решили почеленджить сам подход к SDLC и работе с агентами - получили хорошие цифры как по нашим QPI, так и по бизнес метрикам. Разберём, как устроена оркестрация агентов, кто за что отвечает — от планирования и кодинга до тестов и ревью, где агенты реально ускоряют команду, а где — незаметно её тормозят и плодят технический долг. Покажу метрики, экономику и честные грабли: что пришлось перестроить в архитектуре, процессах и роли инженера, чтобы агентский пайплайн не развалился под нагрузкой реальных задач.

SWOT-анализ регулярно применяется для оценки компаний и продуктов, но почти никогда не применяется к руководителям — хотя даёт то, чего не дают грейдинг, PR/360 и ИПР: честный взгляд на себя со всех четырёх сторон одновременно. В докладе разберём, почему личный SWOT обычно делают неправильно — в одиночку, по памяти, без разделения на внутреннее и внешнее, замалчивая слабости и риски, — и как правильно собрать все четыре квадранта. Отдельно покажу, как через TOWS-матрицу превратить анализ в конкретный ИПР, а не просто красивую табличку, и разберём это на живом кейсе тимлида. Дам рекомендации из своего опыта как встроить личный SWOT в регулярную практику, а не делать его раз в год для галочки.

Каждый техлид и тимлид мечтает о предсказуемом спринте. Но реальность жестока: продакты залетают в личку разработчикам, стейкхолдеры спускают «срочные и важные» задачи напрямую в обход бэклога, а когда на стыках систем что-то ломается — все дружно переводят стрелки друг на друга. При этом попытки попросить ресурсы на рефакторинг разбиваются о глухое «это не приносит денег бизнесу».Как перестать быть «удобным клеем» в компании, очертить суверенитет разработки и заставить бизнес играть по вашим правилам?В этом докладе мы разберем архитектурный подход к процессам управления. Мы рассмотрим команду инженеров как изолированный программный модуль, который должен выставить наружу понятные и жесткие контракты.Вы узнаете, как внедрить 6 практических инструментов, проверенных в VK, Тинькофф, СДЭК и Travelata:Финмодель и PnL: Как оцифровать техдолг в деньгах, чтобы бизнес сам согласовал рефакторинг.Дерево метрик: Как разрезать пересекающиеся KPI и убрать войны за код между соседними командами.Карта стейкхолдеров: Как настроить протокол эскалации политических конфликтов «наверху».Реестры систем и Service Blueprint: Как четко зафиксировать, за какое легаси вы дежурите в субботу, а где «чужой район».Team API и шаблон гипотез: Как легально отсекать 70% мусорных задач от заказчиков еще на входе.DACI-матрицы: Как вылечить команду от коллективной безответственности и оставить ровно одного Апрувера.Никакой абстрактной теории. Только «пацанские правила» взаимодействия с бизнесом, готовые шаблоны в Notion и скриншоты реальных артефактов.

Every team relies on a two-person safety net where the author writes the change and an independent reviewer checks it. But if the author generated it with AI and the reviewer is checking it with AI, the net you're counting on is often one model quietly agreeing with itself. The approval is real, but the independent second judgment behind it has thinned to almost nothing, and nobody decided that on purpose. For a lead, the cost isn't only that defects slip through. It's that review used to be where junior engineers built judgment by reading someone else's code, arguing about it, and learning what good looks like. When both sides automate, that teaching disappears silently, and you don't notice until someone can't reason about a change the AI can't help with. This talk is about what review was actually for, how automation erodes each part, the warning signs, and what a lead does about it.

Представляем ViVA — AI-First DevSecOps Platform, новый подход к управлению IT-инфраструктурой, сервисами и инженерными процессами. Современная инфраструктура объединяет десятки инструментов и технологий: Kubernetes, GitOps, CI/CD, системы мониторинга, управления секретами, базы данных и MLOps-компоненты. ViVA объединяет их в единую платформу, автоматизируя повседневные операции и предоставляя командам централизованный интерфейс управления. Но следующий этап развития инфраструктурных платформ — не просто объединение инструментов, а переход к AI-First подходу. В ViVA мы развиваем концепцию взаимодействия с инфраструктурой через AI-агентов: вместо ручного выполнения множества операций пользователь сможет описать задачу обычным языком, а агент самостоятельно выполнит необходимые действия через API и MCP с учётом прав доступа, политик безопасности и ограничений. На докладе поговорим о том, как меняется подход к управлению инфраструктурой, какую роль в этом играют AI-агенты и почему будущее DevOps — за интеллектуальными платформами, объединяющими автоматизацию, безопасность и управление сервисами.