Ural Digital Weekend 2025

Просишь человека обновить статусы в таск-трекере, а в ответ получаешь: «Знаешь, мне удобнее вести свои задачи в бумажном блокноте, неудобно дублировать оттуда информацию куда-то ещё».

Садишься оценивать бэклог в рамках планирования, слышишь на это «Зачем все эти страдания? Какая такая прогнозируемость? Я если сказал, что к 15-му числу будет готово, отвечаю, так и будет».

Это не сцена из фильма ужасов про ИТ; не воспоминания ИТ-старожила в духе «А помните, когда-то много лет назад как всё было?»; не анекдот с Пикабу — но реальность, которую мне регулярно доводится встречать в командах неинженеров в ИТ (деврелов, эйчаров, внутрикома и других).

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

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

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

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

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

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

В рамках доклада рассмотрим один из вариантов ответа на этот вопрос в теории и на практике одного банка.

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

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

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

1. Текущая ситуация и тенденции на рынке AI: почему ChatGPT — больше не «золотой стандарт» языковых моделей?
2. Чем отличаются разные языковые модели, и на какие параметры обращать внимание при выборе LLM для интеграции в продукт? Расскажем про ключевые критерии: размер контекстного окна, скорость обработки данных, поддержка языков, мультимодальность, адаптация под решение задач определенного типа, дополнительные функции «из коробки». Дадим советы, как ориентировать эти возможности моделей на задачи продукта.
3. Maas vs Хостинг (самостоятельное развертывание): поговорим про преимущества и недостатки моделей по типу доступа. Поднимем вопрос стоимости и работы с лицензиями, юридические ограничения и правовые моменты, а также дообучение LLM на своих данных (файн-тюнинг).
4. Какие тренды будут менять рынок нейросетей в ближайшие годы, и почему важно учитывать это при выборе языковой модели для продукта. Расскажем о том, действительно ли hosted-модели приближаются по возможностям к моделям вендоров, про новых крупных игроков и изменения в тарифах
5. Заключение: перечень вопросов, на которые необходимо ответить, чтобы выбрать подходящую языковую модель

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

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

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

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

Разбор кейсов в процессах изменений команды:
4.1 Я тимлид, как мне понять, что команде нужны изменения?
4.2 Как вовлечь команду в процесс изменений? Как преодолеть сопротивление?
4.3. Как убедить вышестоящее руководство в необходимости изменений?
4.4. Моя команда в процессе глобальных изменений: как пройти, избежав крупных потерь?
4.5. Как внедрить изменения не только в моей команде, но и для соседей?

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

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

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

Пример картирования потока, основанного на IT-артефактах (ADR, CR, макеты, техническое решение, код, тест-кейсы, автотесты, сборка), а также его дальнейшую привязку к Jira, релизному циклу.

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

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

Мы разберём:

Почему «чистота» в цифровом пространстве снижает стресс так же, как уборка дома.

Как настроить безопасность, чтобы конфиденциальные данные не утекали, а сотрудники не путались в доступе.

Какой лежащий на поверхности инструмент заменит десятки чатов и писем.

Это не теория — а опыт команды Cloud.ru, которая сократила время поиска информации по проектам и сделала адаптацию новичков в разы проще.

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

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

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

Обычно менеджер отвечает или за регулярные процессы или за большие разовые проекты или участвует в решении кризисной ситуации (аварии, «„выстрелившие риски“» и тд).

Но учения по отключению дата-центра — это все везде и сразу. Каждый квартал. В одну ночь. И на 700 с лишним человек.

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

1. В какой момент нужно писать свой Elastic?
2. Особенности поисковой базы данных.
3. Типовая архитектура поиска.
4. Statefull, stateless. Разделение частей системы и зон ответственности сервисов.
5. Внедрение ML в поисковую систему

1. Автоматизация аудита и ее значимость:
2. Создание стандартного процесса аудита, который позволит распределить задачи между специалистами различных уровней, включая начинающих.
3. Повышение эффективности и точности аудита с помощью автоматизированных инструментов.
4. Выбор сервисов и ИИ для аудита:
5. Обзор популярных инструментов и платформ, обеспечивающих автоматическое тестирование производительности и безопасности.
6. Использование И И для обнаружения уязвимостей, анализа пользовательского опыта и оптимизации кода.
7. Ключевые аспекты процесса аудита:
8. Фокус на технические требования и UX, включая производительность, безопасность и соответствие стандартам.
9. Разработка системы отчетности, которая облегчит анализ результатов и принятие решений на основе данных

1. Решаем проблему. Когда мы недоступны — недоступны многие ключевые сценарии.
2. Почему простое кеширование не решает проблему целиком?
3. Как выстроить механизм синхронизации данных?
4. Оптимизация использования сети.
5. Ошибки и фейлы

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

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

Современные языковые модели впечатляют своими возможностями, но их знания ограничены моментом завершения обучения, а события после этой даты остаются для них «белым пятном». Кроме того, LLM склонны к галлюцинациям — генерации правдоподобных, но вымышленных фактов. А еще им недоступны закрытые данные — внутренние документы, актуальные регламенты и инструкции к устройствам. Как минимизировать эти проблемы и обойти ограничения? Один из эффективных подходов — RAG (Retrieval-Augmented Generation), позволяющий дополнять модель актуальными данными из внешних источников.

Что будет в докладе?

1. Архитектура RAG — от индексирования данных и векторного поиска до генерации ответов.
2. Баланс между простыми запросами и сложными решениями: когда достаточно промпта, а где необходимы RAG или тонкая настройка модели.
3. Практическое применение на реальном опыте — использование RAG в службах поддержки, работе с внутренней документацией и чувствительными данными.
4. Методы улучшения поиска: оптимальная разбивка документов, реранкинг, графовые техники и другие подходы.
5. Демонстрация сборки простой RAG-системы в Jupyter Notebook.
6. Интерактив: модель отвечает на вопросы аудитории на основе загруженных материалов

Анализ и работа с игровым пространством.
Моделирование игрового мира с точки зрения игровой физики.
Как ИИ и геймплей взаимодействует с игровым миром.

Про навмеши, оптимизацию физики, анимацию и игровой интеллект.

1. Эволюция подхода к сборке и развертыванию web-приложений от ручной установки с использованием Jenkins на виртуальные машины до полноценного CI/CD в Kubernetes.
2. Как ускорился процесс выпуска хотфиксов для продукта.
3. Дробление изначального монолита (с использованием монорепозитория) привело к уменьшению количества ошибок, увеличив качество продукта.
4.Переход с GitFlow на TBD (тема для холивара о подходах к ветвлению кода, плюсах и минусах каждого подхода), а также работа с feature-флагами и эволюция автотестов, когда при каждом MR проходит полный цикл тестирования.
5. Использование blue-green deployment для обкатки нового функционала на реальных пользователях

1. Что такое Outbox, какую проблему он решает?
2. Как закрыть потребности всех сервисов одним решением?
3. Sidecar: плюсы и минусы таких решений
4. Какие опасности вас ждут на пути. Где можно потерять данные?
5. Чего нет в паттерне, но очень нужно в бизнесе

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

Мы внедрили в нашем департаменте практику создания Observability Passport для каждого проекта. Это документ, который объединяет все ключевые ссылки на инструменты мониторинга и анализа: Sentry, логи, телеметрию, системы отслеживания уязвимостей и другие важные ресурсы. Observability Passport позволяет быстро получить доступ к нужной информации, упрощает диагностику и делает процессы наблюдаемости более прозрачными для всей команды.

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

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

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

1. Виды тестов и зачем они нужны.
2. Почему продукт без надлежащего тестирования обречен быть переписанным с нуля.
3. Какие существуют фреймворки для тестирования, и как выбрать подходящий под конкретную задачу.
4. Как используются разные фреймворки, в чем их преимущества и недостатки;
5. Как внедрять фреймворки для тестирования и работать с ними в Битриксе