Доклады конференции Saint TeamLead Conf 2026

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

Фреймворков для анализа продуктивности разработки много (DORA, SPACE, Kanban-метрики, ...). Но для конкретной ситуации они могут быть слишком универсальны, сложны во внедрении или не соответствовать текущим потребностям.

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

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

Поговорим про управление людьми, ИИ-агентами, командами людей и роями ИИ-агентов. Разберемся, какие управленческие навыки теряют актуальность, какие, наоборот, становятся сверхвостребованными и кого все-таки не заменят роботы (по крайней мере до следующей TeamLead Conf).

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

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

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

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

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

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

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

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

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

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

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

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

Команда соглашается, но не делает. Ответственность размывается.

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

Что заберете: - диагностику: где сейчас находится ваша команда - понимание системного сопротивления и его проявлений - конкретные приёмы работы с командой и стыками без давления - чек-лист работы с сопротивлением

Доклад о том, как с помощью LLM можно вывести подход Architecture as Code на новый уровень. На реальном кейсе покажу, как связка Structurizr DSL + Claude Code помогает быстрее готовить архитектурные решения, генерировать диаграммы, проводить предварительное ревью и убирать рутину из архитектурной работы.

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

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

И это всё неправда.

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

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

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

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

В докладе разберу практическое внедрение AI-инструментов в полный цикл большого проекта: от системного анализа и требований до разработки, тестов, PR/review и релиза. Покажу, почему часто внедрение AI не дает ожидаемого эффекта, и как мы запускали пилот и встраивали AI в SDLC так, чтобы он снимал бойлерплейт, а не занимался бесконечными генерациями. Отдельно разберем, как считать эффект и не выдать желаемое за действительное: baseline, ключевые метрики и сравнение с аналогичными проектами без использования AI.

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

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

Ключевые принципы:

• Ограничение по времени: Фокусировка на результативности.

• Конкретная цель: Четко сформулированная проблема для решения.

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

• Безопасная среда: Голос каждого важен. Командная работа важна.

Что позволит?

1) Сконцентрироваться на high-level design. Отойти от кода и рутины. Научиться мыслить паттернами, искать узкие места до реализации решения. Это позволит в дальнейшей практике разработки сэкономить время и силы на итерации рефакторинга и переработок.

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

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

Если не страшно — you are welcome! Количество команд и участников ограничено таймингом!

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

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

В интенсивной групповой работе мы:

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

Где этот навык может пригодиться?

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

Расскажу про инструмент для улучшения коммуникации из арсенала переговорщиков.

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

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

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

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