О конференции

В 2026 году конференция состоится в пятый раз и станет площадкой демонстрации прикладных компетенций ИТ-специалистов. Приоритетом будут реальные навыки, а не сухие знания. Вас ждёт обновлённый и практикоориентированный формат.
Приглашаем тебя не только выступить с докладами, но и провести мастер-классы, создать эксперименты в лабораториях, вместе с аудиторией найти новые решения, которые сразу можно применить в работе, и многое другое — приноси всё, что позволит прокачать реальные навыки ИТ-специалистов и инженеров, а также создать на конференции пространство для свободного обмена знаниями и идеями.
Конференция проводится с 2022 года и уже стала точкой притяжения для профессионалов ИТ и инженерной отрасли. Ежегодно в Москве мы объединяем более 2 000 участников и 130+ спикеров — признанных экспертов, руководителей компаний и ведущих специалистов.

Форматы и активности

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

Направления деловой программы

Трек 1: архитектура и проектирование

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

Трек 2: продуктовое видение и доменная разработка

О чём трек?
Продуктовое видение — это не должность и не отдельная роль, а образ мышления, который позволяет понимать, что и зачем мы строим, а не только как. В этом треке мы говорим не про абстрактную теорию продакт-менеджмента, а про прикладной образ мышления и инструменты, которые помогают инженеру принимать продуктовые решения: куда идти из множества развилок, как понять, что выбранный путь вообще имеет смысл.
Часто бывает так, что разработчик научился классно делать, но не знает, что делать — особенно в эпоху ИИ, когда порог входа в создание собственного продукта резко упал. Трек про то, как из «умею делать» перейти к «понимаю, что и зачем делать».
Для кого?
Для тех, кто:
  • создаёт свой продукт или пет-проект и хочет усилить его с точки зрения продукта, а не просто «запилить крутую штуку, которую никто не просил»
  • из разработки начал двигаться в сторону создания продуктов и стартапов
  • хочет найти продуктовые фишки и применять их в ежедневной работе, чтобы лучше помогать своей команде
  • сталкивается с вопросами развития: на чём основывать продуктовое решение, как его принимать, как проверить идею
  • хочет понять, как его инженерное видение влияет на продукт, и что он недооценивает
Какие темы мы ждём?
ИИ и продукт
  • Синдром упущенной выгоды в эпоху ИИ: все бегут делать свой стартап на ИИ — а нужно ли? Доклад про образ мышления, что меняется в голове.
  • Быстрое прототипирование с ИИ: как на коленке собрать кликабельный MVP, который уже можно показать и презентовать.
  • Заменить продакта на ИИ — где ИИ реально вывозит, а где нужен человек.
Продуктовый образ мышления для инженера
  • Базовые продуктовые инструменты и зачем они нужны: custdev (развитие клиентов), проверка гипотез, A/B-тесты, опросы.
  • Карта пути клиента и путь пользователя для исполнителей: почему рядовому разработчику важно понимать, что его задача — часть большого процесса, а не просто запрос из списка.
  • Чек-лист «здорового продукта»: признаки, по которым можно оценить адекватность своего продукта.
Продуктовые и инженерные метрики
  • Параллельность продуктовых и ИТ-метрик: как соотнести наблюдаемость с условным LTV.
  • Юнит-экономика на простом уровне: покрываются ли затраты, сколько стоит привлечение пользователя.
  • Метрика эффективности в заказной и продуктовой разработке.
Кейсы и личные истории
  • Реальные истории личностей, путь «из разработчика в продукт/основателя».
  • Истории выживших и истории провалов: «у меня получилось» против «а у меня не получилось» и разбор опыта.
На стыке с другими треками
  • Влияние инженерного видения на продукт: где техническая история сильно влияет, а продакт-менеджер это недооценивает.
  • Построение команд под продукт (закон Конвея и обратный манёвр) с акцентом на то, зачем резать команды, а не как.

Трек 3: DevOps как процесс и SDLC

О чём трек?
DevOps — это не должность и не отдельная роль, это процесс и культура, которые позволяют быстрее и надёжнее доставлять ценность до пользователя. В этом треке мы говорим не про абстрактные «процессы ради процессов», а про технические практики, инструменты и подходы, которые реально ускоряют поставку, повышают качество и делают жизнь команды легче.
Меньше теории и больше реальных примеров: что сработало, что нет, как измерять результат и жить в постоянных изменениях. Про применение инструментов для повышения качества и скорости разработки, безопасности и отказоустойчивости систем, автоматизаций и конфигурации окружения.
Для кого?
Разработчик, SRE, администратор и просто «человек в роли devops-инженера». Для тех, кто ежедневно сталкивается с тем, как:
  • построить CI/CD так, чтобы он не разваливался
  • автоматизировать развёртывание и тестирование
  • наладить мониторинг и процесс устранения инцидентов
  • внедрять новое без потери надёжности
А также думает, не как тушить пожары, а как решить проблемы, ускорить разработку и технические процессы, как сделать выкатки быстрее, а проверки — качественнее.
Какие темы мы ждём?
ИИ в инфраструктуре
  • Как жить с AI в продакшене: инфраструктура, надёжность, измерение эффективности.
  • Как поддерживать систему, где AI генерирует код, ревьюит, помогает в CI/CD.
  • Ограничения безопасности: как не дать агенту доступ к секретам и продовым данным. Incident resolving process и мониторинг
  • Мониторинг и алертинг.
  • Как выстроить процесс разбора инцидентов: от дампа профилировщика до blue‑green деплоя.
  • Метрики «нормальности» системы, самовосстановление, post‑mortem без буллинга.
Этапы развития автоматизаций
  • От загрузки по ftp до оркестрации.
  • Переходные этапы, уместность и стратегии.
Реальные пайплайны автоматизаций: успехи и провалы
  • Истории из жизни: от баш-скриптов до полноценного процесса.
  • Гибридные подходы: где автоматизация выигрывает, а где приходится оставлять ручные шаги.
  • Как ускорить билд с 15 минут до 6 и измерить экономический эффект.
Импортозамещение и миграции
  • Переезд с зарубежных решений (Openshift, VMware) на российские (Astra, Deckhouse, «Штурвал»).
  • Практические примеры: что сломалось, как починили, стоило ли оно того.
Инфраструктура как код и управление конфигурациями
  • Не просто «терраформ есть», а как жить с IaC в большой команде.
  • Когда GitOps работает, а когда превращается в бюрократию.
Метрики работы DevOps и ускорение поставки
  • DORA-метрики, закон Гудхарда.
  • Как объяснить бизнесу, почему надо вкладываться в автоматизацию и не быть «надоедливым админом».
Безопасность в процессе поставки
  • Разграничение доступа к кластеру, секреты, политики.
  • Безопасность в работа с агентами: промт-инъекции, песочницы и контейнеры.
Культура и опыт команд в решении задач
  • Как жить, когда нет отдельного devops-инженера?
Эксперименты и смелые решения
  • Отказ от код-ревью в пользу AI — как это было, что вышло.
  • Внедрение Docker в компании, где «все пишут локально».
  • Провалы, от которых мы стали сильнее.
Неожиданные применения инструментов
  • Не как задумано, а как работает на самом деле и что можно с помощью этого сделать.

Трек 4: дизайн и пользовательский опыт

О чём трек?
Дизайн — это не должность и не профессия для рисования картинок. Это процесс, который пронизывает весь путь продукта: от бизнес-идеи до впечатлений, эмоций и ощущений, которые остаются у человека после взаимодействия с компанией. В этом треке мы говорим не про инструменты ради инструментов и не про «почему Figma лучше Pixso». Мы говорим про то, как проектировать опыт, который работает на людей.
Меньше абстракций — больше кейсов: где дизайн выстрелил, где провалился, как измерить его ценность и как договориться с теми, кто не понимает, зачем это вообще нужно. Трек про применение дизайн-мышления для улучшения пользовательского опыта, про доступность продуктов для всех категорий пользователей, про роль дизайна в команде и про то, как перевести бизнес-требования в решения, которыми люди захотят пользоваться. Как делать продукты, которыми приятно и удобно пользоваться всем: и маме с ребёнком на руках, и человеку без мышки, и новому клиенту банка.
Для кого?
Дизайнеры — те, кто хочет выйти за рамки «нарисовать макет» и влиять на продукт от постановки задачи до релиза.
Разработчики frontend и интерфейсов — те, кто воплощает дизайн в жизнь и хочет понимать, зачем то или иное решение принято, чтобы не кипеть над макетом.
Продакт-менеджеры — те, кто ставит задачи дизайнерам и хочет научиться делать это так, чтобы в ответ получать решение, а не чек-бокс.
Все, кто взаимодействует с продуктом — тестировщики, аналитики, разработчики любого профиля — те, кому не всё равно, каким получается продукт на выходе.
Не важно, на какой должности ты работаешь. Важно, что тебе небезразлично, каким получается пользовательский и клиентский опыт. Если ты хочешь или можешь влиять на то, насколько продукт доступен, удобен и ценен для пользователей — этот трек для тебя.
Какие темы мы ждём?
Доступность
  • Как сделать продукт удобным для всех: людей без мыши, слабовидящих, работающих одной рукой, с инвалидностью и не только. Ситуативные и постоянные ограниченные возможности.
  • Постановление Правительства №102: что изменилось для бизнеса, и как это влияет на разработку.
  • Вёрстка как инструмент дешёвого внедрения доступности в проект.
  • Доступность начинается с продуктовой разработки, как заложить a11y, чтобы её не было мучительно больно внедрять.
  • «Примерь чужую шкуру»: как работает продукт, если отнять мышку или выключить монитор.
Ценность дизайна и цена от дизайна: как говорить с бизнесом на его языке
  • Как объяснить, почему дизайн — это инвестиция, а не статья расходов.
  • Метрики дизайна: LTV, удержание пользователей, конверсия — что и как влияет.
  • Как защищать решение так, чтобы тебя услышали, а не просто кивнули.
Взаимодействие дизайна и разработки
  • Как правильно передавать дизайн в разработку.
  • Общий язык: как команда начинает говорить одинаково об одних и тех же вещах.
Перевод бизнес-требований в дизайн-решения
  • Как за задачей «нарисуй маркированный список» увидеть настоящую потребность.
  • Цель задачи — как она влияет на пользовательский опыт: не для бизнеса ради бизнеса, не дизайн ради дизайна.
  • Как собрать и применить пользовательскую обратную связь — пользователи иногда хотят странного.
  • Почему дизайнера нужно подключать к задаче раньше, а не в финале.
Карта пути клиента и точки боли
  • Как находить узкие места там, где все привыкли и перестали замечать.
  • Примеры того, как переизобрести привычный сценарий и изменить индустрию.
Насмотренность и дизайн-культура
  • Как развивать насмотренность, если работаешь один или в небольшой команде.
  • Зрелость дизайна в компании: от «нарисуй кнопку» до влияния на продуктовую стратегию.
Эксперименты и смелые решения
  • Истории, где неожиданный подход к пользовательскому опыту изменил продукт.
  • Провалы, от которых стало лучше: честный разбор решений, которые казались хорошими.

Трек 5: участие в командах и процессах

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

Твоё участие – это возможность!

  • Показать экспертизу на деле, а не на словах

  • Стать голосом ИТ-сообщества, чтобы тебя действительно слышали
  • Найти прикладные решения для ежедневных ИТ-вопросов

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

Как это было в 2025

Здесь ты можешь посмотреть, как проходил ИМПУЛЬС Т1 в 2025 году
Сайт Импульса
impulse_form_feedback-70impulse_form_feedback-70impulse_form_feedback-70impulse_form_feedback-70
Стать спикером
Прием заявок завершается 15 августа
Хочешь прикоснуться к вселенной ИМПУЛЬСА Т1 и стать спикером конференции? Заполняй анкету, и мы рассмотрим твою заявку в течение десяти рабочих дней.
Стать спикером
Прием заявок завершается 15 августа
Хочешь прикоснуться к вселенной ИМПУЛЬСА Т1 и стать спикером конференции? Заполняй анкету, и мы рассмотрим твою заявку в течение десяти рабочих дней.

Остались вопросы?

Напиши нам: impulse@t1.ru