Руслан — старший менеджер по развитию цифровых продуктов. Он работает с приложением Мой Beeline и расскажет про свой опыт создания продукта.

• Команда и её вовлеченность.
• Воруйте стикеры с доски.
• Как практически сдохнуть от сбоев, но не сдаться.
• Слезы Руса.

160 роботов в год.
Что? Да! Расскажем не только о том, как мы их создавали, но и как роботы помогают нам в работе.

• Что такое технология RPA?
• Как показали роботы себя роботы в Beeline?
• С каких процессов лучше начинать роботизацию, а какие лучше избегать.
• Пишем руками или используем визуальное программирование.
• Взвешиваем все «за» и «против».

Постоянная обратная связь от пользователей — важный фактор для развития продукта.
Мы организовали такой процесс в нескольких продуктах обслуживания Интернет дома и ТВ. Какими инструментами и практиками при этом стоит воспользоваться.

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

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

Как построить QA с нуля в крупной компании. Опыт Beeline Казахстан

• Трудности, с которыми мы столкнулись при построении QA.
• Работающие процессы в Beeline Казахстан и планы в направлении обеспечения качества.
• Распределенная команда: как выстраивать процессы с командой, работающей в разных городах и странах.

Поговорим про то, как устроен Devops в Beeline Казахстан.

• Единый стандарт.
• Инфраструктура как код в GitLab.
• Непрерывная поставка кода.

Разрабатывать, планировать и мониторить сложные процессы в одном инструменте реально? Как будто да.

• Расскажем про наш опыт внедрения Apache Airflow.
• Как развивали инструмент.
• Пробы и ошибки, и выводы.

Прикладной доклад на примере одного из проектов Beeline Казахстан.

Оптимизация производительности, сокращение потребления памяти в Apache Spark. Бережливый расход ресурсов при написании кода в Apache Spark.

Поговорим о том, как применять AI в промышленности.

• Промышленная безопасность: нейросети vs. бизнес-задача.
• Компьютерное зрение на горнодобывающей технике: трудности и эффекты.
• Актуальные направления развития технологии.

Доклад будет полезен и новичкам в построении воронок, и тем, кто уже работает с инструментом.

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

Путь от Telecom к Digital-компании. И роль архитекторов на этом пути.

• Как изменилась архитектура.
• Как повлияла архитектору на развитие цифрового бизнеса в TelCo.
• К чему пришли сейчас и к чему стремимся.

Обсудим актуальность задачи и рассмотрим общий pipeline работ по распознаванию текста на картинках на примере одного из кейсов.

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

В финале обсудим ошибки при построении pipeline.

Прикладной доклад на примере одного из проектов Beeline Казахстан. Как работают бустинги, сравнение с остальными алгоритмами ML.

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

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

• Постановка задачи, основные трудности.
• Технологии: архитектуры, метрики, оценка эффективности.
• Рабочий пайплайн.
• Сбор данных, тренировка, тестирование.
• Рабочий процесс и экспертиза для построения прототипа.
• Анализ результатов: улучшение системы, что работало, что не работало.

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

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

• Что такое продажа и какие есть сложности.
• Как понять, что все идет хорошо.
• Что такое AI в понимании бизнеса. С чего начать, чтобы продавать AI.
• Как мы делаем это в Verigram.

Ведущий — Бинали Рустамов, руководитель отдела разработки в Beeline Казахстан

Участники дискуссии:

Мадияр Ногаев, тимлид Core-команды Beeline Казахстан
Артём Шалхаков, старший .NET-разработчик в Global Talent
Николай Киндяков, руководитель backend-разработки в Kolesa Group

Обсудим что входит в понятие «Культура разработки», нужны ли стандарты разработки, как ставить задачи и оценивать их. А так же обсудим QA и DevOps. Возможно похоливарим.

Ждем всех: от новичков до профи в разработке. Будет интересно инженерам, которые страдают. Тем, кто не страдает тоже будет интересно и полезно.

Ведущий — Александр Пузеев, техлид, Beeline Казахстан

Участники дискуссии:
Елизавета Швец — Chief Operating Officer, лидер DevRel в ДоДо
Дмитрий Ботанов — Chief Operating Officer в Kolesa Group
Алексей Шаравар — Директор по изменениям и IT в Beeline Казахстан

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

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

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

Ведущий — Андрей Остафичук, Chief Data Officer в Beeline Казахстан

Участники дискуссии:

Уахат Бастимиев, COO, co-founder, Verigram

Иван Ямщиков, доцент ВШЭ в Петербурге, руководитель лаборатории естественного языка ЛЕЯ Яндекса и ВШЭ, автор и ведущий подкаста «Проветримся!» t.me/progulka

Александр Пак, IICT Head of Laboratory Intellectual Analysis of BigData 2018-Currently
FIT KBTU Assoc. Prof 2018-Currently


Поговорим о трендах NLP в 2021 в Казахстане и в мире; о том, стоит ли инвестировать силы и время в голосовых помощников на казахском языке и кому они нужнее – бизнесу или пользователям.

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

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

У меня есть фобия: я до ужаса боюсь багов на продакшене. Даже если это не моя явная вина, даже если в других командах – когда я их вижу, испытываю страх. Не самое комфортное для тестировщика чувство, скажу вам.

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

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

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

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

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

Что такое раннее тестирование. Преимущества и советы по внедрению.

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

«Вот бы всё это было на другом стеке». За мою карьеру IT-инженера такая мысль приходила в голову точно больше одного раза.
Где-то упираешься в ограничения тулинга, где-то слишком много легаси-кода и зависимостей. Иногда хочется в новый стек, чтобы стало проще с людьми – находить, нанимать, онбордить. Но одно дело — мечтать, а другое —пойти и действительно сделать.

В конце 2019 года мы в Самокате решили сменить стек: перейти с Python на Kotlin. На тот момент мы были в продакшене: реальные пользователи, курьеры, дарксторы, логистика, инфраструктура, партнёры.

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

Тизер: мы успели к дедлайну и теперь пользуемся инсайтами из опыта смены стека в «мирное время».

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

В Самокате мы строим собственную платформу данных.

Наш бизнес – это создание нового слоя городской инфраструктуры для доставки товаров. Работаем в городах-миллионниках, даём пользователям возможность получить заказ в течение 15 минут – чтобы не нужно было строить отдельных планов на приём заказа, не дожидаться звонка от курьера "за час". Заказал, получил, that's it.

Всё это стало возможно только благодаря технологиям – автоматизации; быстрым решениям, в которых не участвует человек. И данным.

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

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

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

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

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