Доклады

Опенсорс начинался со светлых идей о сотрудничестве, коллаборации и обмене знаниями. Но что с ними стало сегодня?

Что сейчас можно считать настоящим опенсорсом, а что паразитирует на его идеях?

Экономика современного опенсорса. Жить на пожертвования, строить бизнес модель или договориться с корпорацией?

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

Лицензирование, этические аспекты, конкуренция и другие вызовы.

На примере PostgreSQL, рассмотрим как может функционировать сообщество.

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

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

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

1) Роль трендов прошлого. Заглянем в ретроспективу: Какие механики использовали раньше? Где они дали рост, а где, наоборот, показали излишнюю агрессивность?

2) Персонализация — ключ к повторным покупкам

Почему одним продуктам удается вызвать эффект «своего» у клиента, а другим — нет? Расскажем, как точечная персонализация удерживает внимание, повышает частоту возвратов и дает клиенту чувство, что продукт говорит с ним на одном языке.

3) Как социальное вовлечение формирует лояльность

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

4) Что стоит за понятием «возвращаемость»: метрики и ошибки

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

Что вы получите:

- Понимание современных трендов геймифкации, которые уже дают результаты

- Реальные кейсы и примеры применения персонализации и социального вовлечения

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

Для кого будет полезно: 1) Топ-менеджмент и руководители бизнес-функций 3) CPO/HR/Product-management

Эксперт

Захар Константинов - CEO Utopia, эксперт в геймификации, управлении и развитии продукта. Ex. SberDevices

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

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

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

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

- Тактика миграции: как организовать процесс перехода с нативной разработки (Kotlin/Swift) на React Native с учетом особенностей проекта и уровня подготовки команды.

- Проблемы и их решения: глубокая проработка кейсов с диплинками, пуш-уведомлениями, хардварной кнопкой “назад” и другие технические нюансы.

- Команда и процесс: как работали специалисты с разным уровнем погруженности в натив, избегая выгорания и срыва сроков.

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

- Продажа идеи: как донести до бизнеса преимущества перехода и минимизировать сопротивление.

Что получат слушатели:

- Пошаговый план для реализации миграции с нативной разработки на React Native.

- Реальные примеры и решения проблем, с которыми сталкиваются на практике.

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

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

Почему это важно:

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

ML необходим для масштабирования и развития бизнеса

Существующие инструменты PHP позволяют разрабатывать сложные производительные нейронные сети для решения бизнес-задач

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

Управление ИТ платформой для разработчиков - какие практики и инструменты использовать.

А есть ли раница с управлением другими продуктами?

Описание для программного комитета:

1. Что такое ИТ платформа для разрабочтиков

2. Как найти своего пользователя и помочь ему.

3. А умеют ли разработчики формулировать требования? нет

1. Кто такой играющий тренер. Как сложилось что я им стал

2. Что вообще должен делать такой тимлид и разработчик? Разобрать его обязанности

3. Что не должен делать играющий тимлид?

4. Как правильно распределять время на программиста и тимлида

Для каких команд и компаний это подойдет?

1. Законодательные аспекты увольнения сотрудников.

1.1. Какие варианты расставания с сотрудником и как к ним подготовиться.

1.2. Какой самый безопасный способ расставания с сотрудником для работодателя.

1.3. Интересные кейсы из Российской юридической практики.

2. Эмоциональные аспекты увольнения сотрудников.

2.1. Как понять, что сотрудника пора уволить.

2.2. Как подготовиться к расставанию с сотрудником.

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

2.3. Самое запоминающееся увольнение в моей жизни

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

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

1. Проблема: слабо задокументированные продукты и техписатели «на обочине» бизнеса

Продукт A:

- много документации;

- неструктурированная;

- частично неактуальная.

Продукт B:

- часть документации из продукта А;

- нет пользовательской документации;

- внутренняя документация не структурирована.

Продукт C:

- есть пользовательская документация;

- пробелы во внутренней документации;

- документация плохо структурирована.

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

Задача: включить техписателей в процесс разработки и повысить качество документации.

2. Решение:

2.1. Разработка структуры внутренней и внешней документации (покажу на примере шаблонов);

2.2 Структуризация существующей документации и выявление пробелов;

2.3. Распределение зон ответственности (включение техписателей в проектные команды, развитие техписательских компетенций в условиях специализации);

2.4. Синхронизация документирования с продуктовыми релизами;

2.5. Запуск внутренних техписательских митапов для обмена знаниями.

3. Проблемы и точки роста:

3.1. Отставание документации (отстает на один цикл релиза или пишется в огне);

3.2. Оценка трудозатрат.

В данном докладе планирую хочу внимание на то, как работает kotlin.Sequence под капотом. Не многие задумываются, что эта синхронная структура на самом деле использует suspend-функции для реализации.

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

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

Зачем вообще обычного тестировщику понимать, как работает бизнес и кто у нас клиент.

Разберемся в двух крайностях - "Гендальф", который блокирует каждый релиз или "провайдер информации" который дает выбор бизнесу в принятии решения, катить или нет.

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

Сложность понимания требований и стандартов: Иногда требования и стандарты, предъявляемые к гост документации, могут быть сложными для понимания и интерпретации.

Необходимость знания специфики отрасли: Для написания гост документации требуется глубокое понимание специфики отрасли или области, к которой относится продукт или услуга.

Многочисленные правила и нормы: В гост документации часто приходится учитывать многочисленные правила, нормы и стандарты, что может затруднять процесс написания.

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

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

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

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

1. Бесплатные и очень бюджетные инструменты построения корпоративной культуры

2. 3 элемента корпоративной культуры, которые позволили ДАЛЕЕ попасть в топ-10 работодателей России

3. Как подогревать интерес к корпоративным активностям и не работать в стол?

Планирование ключевых тем и форматов для разных аудиторий.

Выбор площадок и адаптация контента

Упаковка идей в текст, видео, аудио и визуальные форматы с помощью нейросетей

Личный кейс

В 2023 году появился термин “Пробка из джунов”.

И, говорят, сейчас в ИТ нужны только те, кто уже “миддл” или “сеньор”.

Но чтобы стать “миддлом”, нужно какое-то время побыть “джуном”.

А “джуны” “никому не нужны”.

Есть ли выход из этого замкнутого круга?

Есть ли еще открытые двери для входа в IT с “нулевого уровня”?

Основываясь на личном профессиональном опыте и на опыте ИТ компании SimbirSoft, расскажу про то, какие есть варианты входа в ИТ.

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

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

Обсудим варианты обхода “Пробки из джунов”.

Кому доклад будет интересен/полезен:

Всем, кто раздумывает «А не войти ли мне в IT?» - школьникам, студентам СПО и вузов, взрослым людям, кто задумался о смене профессии.

А также их родителям.

А также преподавателям СПО и вузов.

И учителям школ.

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

Возможно, информация будет полезна ИТ студентам всех форм обучения и всех уровней обучения.

Тезисы:

В чем суть локальных LLM, и правда ли, что Open Source >= ChatGPT

Как выбрать модель опенсорса под свои задачи

Промпты для open source LLM = промпты для GPT?

Попробуем использовать опенсорс модели для написания nginx конфига и Docker файлов

Отыщем DDoS атаки в логах с помощью LLM

RAG, Fine-Tuning, QLoRa — вот они слева направо. Как увеличить точность выбранной модели

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

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

Зачем нужна, какая бывает.

Задизайним и шаг за шагом построим реалтайм систему дедубликации данных на сотни RPS, 40+ миллионов событий в сутки. Использовать будем PHP swoole, kafka, redis, scilla.

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

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

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

Но все не так просто.

Например, если сделать универсальный чат, который будет помогать с выбором того, что пользователь бы и так искал руками, сильно конверсию в покупку это не повысит, а GPU время потратит.

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

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

Какое решение?

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

- Умный поиск

- Персонализированные категории каталожного дерева

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

Умный поиск

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

Улучшает обычный поиск, повышает конверсию в покупку

Просто и понятно для пользователя

Мы не можем сгенерировать какой-то бред случайно

Все еще можем быть заддосены + решение, как можно ускорять выдачу результатов

+ разбор, какие части RAG системы можно использовать без огромной LLM для некоторых кейсов по подбору товаров

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

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

и потом масштабировать на количество вариантов

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

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

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

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

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

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