Доклады

— Разбор шаблона таблицы

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

Я расскажу:

- про основные причины откладывания задач и ощущения "разряженных батареек"

- как правильно определить свое состояние и отличить лень от усталости, а усталость от выгорания

- и что делать в каждом из этих случаев, чтобы снова вернуть мотивацию и энергию!

А еще поделюсь, по каким признакам вовремя распознать выгорание у команды! (например, по изменению поведения и типичным фразам)

История о том, как однажды захотелось упростить себе жизнь: Успехи и неудачи :)

* Первые шаги и первая эйфория

* Первые (и не последние) встреченные ограничения

* Как отревьюить монолит в 5 миллионов строк.

* Дообучение модели на коде компании. Сколько займет, сколько будет стоить, и нужно ли?

* Компромиссы.

* Рекомендации по сценариям использования.

* Итоги (tldr - скорее таки да, чем нет).

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

Мой опыт в сфере HR составляет более 12 лет, включая пять лет активного самостоятельного найма и 5 лет управленческой деятельности. За это время я накопил значительный объем знаний и практического опыта, который позволяет мне делиться полезными рекомендациями с теми, кто стремится сократить время на поиск и наем подходящих кандидатов.

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

· Поддерживать положительный HR-бренд;

· Быстро выявлять узкие места в процессе найма;

· Решать проблемы, замедляющие процесс найма;

· Найти секреты ингредиенты для ускоренного найма.

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

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

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

Поговорим о чувствах:

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

2. Тревога аддикции: Где та грань, за которой инструмент становится зависимостью? Обсудим, как нейросети взламывают наш мозг, и почему "просто поболтать с AI" вызывает такое же привыкание, как скроллинг ленты.

3. Страх опустошения: Тот самый вопрос про "электроовец". Когда мы делегируем AI мышление и креативность, что остается внутри нас? Поговорим о страхе потерять свои навыки, аутентичность и стать просто оператором машины.

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

- Краткое введение по анализу дампов памяти

- Формат хранения дампов памяти Hprof

- Обход графа объектов памяти

- Реализация индексов для быстрого обхода (на основе работы для JB)

В Python-мире весь код разделен на 2 половины: async и sync. В докладе я расскажу, как с этим можно бороться при помощи шаблонов (нечто похожее на C++). Покажу также свою реализацию тулинга.

Аннотация

Доклад посвящен обзору современных методов Action Recognition с акцентом на задачу Temporal Action Recognition в видео. Я рассмотрю теоретические основы различных подходов, от CNN-based до SSL backbone в купе с ActionFormer. Особое внимание уделено практическому решению конкретного кейса на складе Wildberries. Я покажу преимущества и минусы разных подходов и рекомендации по выбору архитектуры в зависимости от специфики задачи.

Содержание (предварительное)

- Теоретические основы Action Recognition

- Temporal Action Recognition как ключевая задача

- Практический кейс и его решение

- Архитектурные решения и метрики, включая разные эксперименты по VideoMAEv2, ActionFormer, EVR, итд

- Практическая значимость

- Заключение

Краткое описание доклада: Тезисы: Сложности разработки приложений с LLM, хардкодинг и гарантии исполнения пользовательских запросов

1. Почему сложно разрабатывать приложения с LLM?

2. Почему нельзя хардкодить пайплайны для недетерминированных систем?

3. Как гарантировать исполнение желаний пользователя через LLM?

4. Как это все тестировать и проверять что малейшее изменение промпта не поломает отдельные части систем? Сложности промптинга для мульти модальных LLM систем.

5. Что поняли в Apple уже после обещаний внедрить ИИ в 2025 году.

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

— Как развивать с ИИ видение медиа-сплита для брендов

— Особенности применения ИИ планирование таргетов

— Claude vs GPT разбираемся со ключевыми функциями для стратега

Какие боли пытаемся решить:

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

Не укладываемся в оценку задач от слова “совсем”, т.к. не знаем, чего друг от друга ждать

Отсюда завал работой без конца и края

Токсичные высказывания

Не совпадает ожидание с реальностью

Очень хочется сбежать

Теория:

Стадии развития команды по Такману

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

Спойлер: сейчас перешли в стадию норминга, стало морально легче.

Что делать, чтобы не утонуть и не сбежать:

Ретро и ретро-знакомство, small talks, тимбилдинги, оффлайн и онлайн встречи. Цель: дать понять коллегам и понять самой, что работаешь в первую очередь с людьми, а не с чистыми ролями, уйти от восприятия коллег как квадратиков в зуме.

Хвалить коллег, публично и лично, подсвечивать их помощь и сильные стороны. Запрашивать похвалу у руководства (если ее нет или мало). Цель: дать понять, что их усилия видны и ценимы, дать дополнительную точку опоры на работе. Доп плюс: как правило, начинают хвалить в ответ - т.е. твои усилия тоже становятся видимыми и ценимыми.

Спокойно признавать свои ошибки, публично и лично.Благодарить, если вам на них указали (корректно, а не токсично): “Спасибо, что подсветил момент, который я/мы упустила/и”, “Я пропустила, а N нашла, спасибо ей за помощь”. Цель: дать понять, что в команде безопасно совершать ошибки, важно вовремя о них говорить, чтобы успеть их исправить. По ощущениям, это снижает градус конфликтности в команде, перестаем искать виноватого, сосредотачиваемся на исправлении, а не линчевании. Благодарность за указание ошибок здорово ломает мозг, как себе, так и окружающим - но в итоге отмечаю положительный эффект.

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

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

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

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

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

Сверять ожидания, валидировать их о коллег. Ретро, 1-1, личные разговоры. Например, у меня был разговор с одним из разработчиков, который я так и начала: “Провалидируй мои ожидания, я хочу чего-то нереального или все-таки адекватного. Я жду от разработчика, что он может…123” Меня выслушали и мне ответили, что: “Вот это мы можем, умеем и делаем по запросу, вот это мы должны уметь, но пока не умеем, но работаем над этим, вот с этим - это не к нам, это к кому-то еще”. Цель: выровняться с восприятием друг друга.

Что не сработает:

“Тыжспециалист”

Перекладывание ответственности

Ябедничество

Завышенные (относительно стадии развития) ожидания

Выводы:

Шторминг - это естественная стадия развития команды

Это не навсегда

Работайте с ожиданиями

Сохраняйте спокойствие

Зачем это аудитории:

Познакомиться с теорией развития команды

Узнать, что именно нормально на этой стадии развития команды

Понять, что проблема не в вас

Узнать практические приемы выживания, которые можно сразу начать применять

• Нужен ли зумерам HR-портал?

• Каким должен быть функционал, чтобы не получить клеймо "кринж"

• Кейс внедрения HR-портала в Sape. “Галя, у нас отмена?”

• Вовлечь персонал в HR-портал за неделю? Миссия невыполнима

• Влияние HR-портала на удержание персонала? Да/нет/отмена

• HR-портал — вам оно (не)надо?

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

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

Опираясь на многолетний опыт создания и поддержки таких сценариев, мы смогли выделить общие подходы и вынесли все наши наработки в open-source библиотеку Rafinad (https://github.com/hhru/Rafinad), которая существенно упрощает написание и поддержку UI-тестов.

В рамках доклада мы:

- Посмотрим, как обычно пишутся UI-тесты в iOS и разберём пример теста.

- Обсудим, с какими проблемами и неудобствами поддержки тестов можно столкнуться.

- Выделим критерии для поиска решения и оценим существующие библиотеки для написания UI-тестов.

- Познакомимся с библиотекой Rafinad и её основными принципами.

- Перепишем пример теста с использованием Rafinad.

- Создадим более сложные сценарии и посмотрим, как их реализует Rafinad.

- Подведём итог, как Rafinad помогает упростить процесс написания и сопровождения UI-тестов.

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

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

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

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

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

Успешные 1С-проекты — это не только про код, но и про сервис: Проекты, в которых учитывается пользовательский опыт, становятся более востребованными, эффективными и приносят больше пользы бизнесу.

- Машинное обучение в PHP — это реально: опыт внедрения PHP-ML в промышленной разработке.

- Как обучить систему понимать, что "Болт М8" и "У-образный болт М8" — это разные вещи?

- Почему регулярные выражения и ручная классификация не работают на больших объемах?

- Мешок слов и TF-IDF: от простого к более точному подходу в текстовой векторизации.

- PHP как полноценный ML-инструмент: без Python и TensorFlow

Первая часть

Aurora SDK. Что нового для разработчика в 2025 году

1. Обзор возможностей и устройство Аврора SDK

1. Устройство Аврора SDK

2. Поставки Аврора SDK. Для программиста и CI/CD

3. Обзор возможностей Аврора SDK

2. Переход эмулятора ОС Аврора на QEMU и встраиваемый эмулятор

1. Qemu vs Virtualbox для Аврора SDK

2. Новые возможности Qemu эмулятора

3. Встраиваемый эмулятор ОС Аврора

4. Aurora Debug Tool

3. Поддержка Apple M series

1. Аврора SDK на Apple M Series

2. Пара слов о Aurora Build Tools

4. Новый QtCreator

Вторая часть

Kotlin Multiplatform

Как растить людей в реально больших командах (10 команд, 100+ человек)

Как создать систему наставничества, если у вас мало лидеров?

Как создавать условия для инициативности в команде?

Как обучать взрослых коллег и не получить кислотную обратную связь?

В 2025 году многие предприниматели упираются в потолок эффективности Яндекс Директа: аудитория выгорает, ставки растут, а альтернатив, кажется, нет. Это не так! На российском рынке есть недооцененные инструменты, которые работают на разных этапах воронки — и при этом не требуют гигантских вложений.

- Ставки ниже, эффективность на уровне — наш опыт продвижения через Sber Ads.

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

- Programmatic — прозрачный и контролируемый, несмотря на стереотипы. Покажем, как считать каждый рубль.

- Ночь, улица, билборд: DOOH и pDOOH — как запускать умную наружную рекламу с опорой на данные, а не удачу.

Миллионы не нужны — нужны правильные решения.

Помните FuzzBuzzEnterpriseEdition? Повторим?

Возьмём типичный проект и потихоньку, по шагам, перетащим его на DDD с луковой архитектурой и CQRS.

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

Даже тот самый пресловутый бложик...

Недавно мы посчитали, что за 20 лет работы наша команда использовала 9 способов взаимодействия с данными на платформе 1С:Предприятие 8. Среди них были как привычные всем - от толстого клиента 8.0 в 2004 году до веб-клиента 8.5 в 2025, так и экзотические: умный дом и робот с "мозгами" на 1С, веб-клиент собственной разработки. Такое разнообразие говорит о том, что универсального интерфейса для платформы 1С нет, у каждого из способов работы с данными есть свои плюсы и минусы, недостатки и преимущества. В докладе представим сравнительный анализ всех использованных нами интерфейсов для платформы 1С:Предприятие 8, а также поговорим о том, когда технология 1С:Элемент заменит собой (заменит ли?) все остальные интерфейсы.

Приходите, будет интересно!

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

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

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

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

Тестирование в 1С - дискуссионный вопрос. Нужно ли? - однозначно "ДА"! А вот как лаконично и главное в бюджете встроить в проект? Это мы и попробуем разобрать на круглом столе.

В рамках доклада расскажу вводную по большим языковым моделям, параметрам и отличиям существующих моделей, как выбрать модель подходящую под интересующий тип задач, требованя к on primese развертыванию и то, как мы работаем с нашей LLM моделью QWEN 8B в рамках задач автоматизации процессов тестирования.