В докладе я обзорно рассказываю об использовании Канбана для DS проектов и продуктов. Мы поговорим о:

• Ролях и ответственности
• Гипотезах и их жизненном цикле
• Канбане как подходе к управлению проектом и продуктом
• Как совместить DS и SWE
• Как запустить канбан в своей команде

Мы обсудим следующие вопросы:

• Должен ли DS уметь все или нужны различные специализации?
• Отдельная DS-команда или нужно совмещать DS и SWE?

Некоторые гипотезы очень долго проверять. Для того, чтобы процесс был прозрачен и понятен всем заинтересованным лицам, нужно уметь разбивать гипотезы на более мелкие. Ориентир — трудозатраты на проверку гипотезы не должны занимать больше 8 человеко-дней.

В докладе мы рассмотрим как в LeanDS продуктовые гипотезы декомпозируются на data- method- гипотезы и пользовательские истории.

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

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

Когда DS-команда выкатила в модель в прод и начала измерять качество её работы возникают проблемы, которые трудно предвидеть на этапе разработки:

1. На новых данных модель показывает заметно худшее качество, чем на валидационной выборке.
2. Модель выдает ошибки на нормальных примерах, которые не встречались в тренировочной выборке.
3. Модель работает неожиданно медленно.

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

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

Experiment review: код ревью или парный дата сайенс?

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

В докладе мы расскажем о наших экспериментах в области повышения качества ревью экспериментов:

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

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

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

Системы с ML — дорогие и хрупкие. То, что ML продолжает приносить пользу, а изменения приводят к улучшениям — само собой не разумеется, нуждается в проверке, тестировании и мониторинге. Я расскажу, как мы, в HH.ru:

• проверяем ML-идеи до того, как начали писать код
• делаем метрики и baseline’ы, чтобы было с чем сравнивать модели ML
• тестируем и мониторим данные для метрик, обучения, расчёта признаков в production
• строим модели на части признаков, проводим time-based кросс-валидацию
• делаем CI/CD для пайплайнов, обучающих модели
• проверяем и мониторим качество, производительность, объём данных для моделей до выката и в prod
• проводим обычные и ухудшающие AB- и TDI-тесты
• мониторим корректность и время расчёта признаков в prod
• валидируем метрики и проверяем их для каждого эксперимента
• встраиваем качество: делаем code review, рефакторинг, применяем framework FeatureGroup, даём разработчикам и DS тестовые стенды, избегаем переключений, многозадачности и перегрузки, снабжаем всё unit- и автотестами, чтобы уменьшить вероятность ошибки человека.

Финтех стартап ANNA делает умного ассистента для индивидуальных предпринимателей и малого бизнеса в UK. Команде DS в ANNA 2 года, за это время ANNA сильно поменялась: число разработчиков выросло от нескольких человек до нескольких десятков; одна доска с общими задачами сменилась работой почти независимых команд. Расскажу, как команда адаптировалась к этим изменениям.

Сессия вопросов и ответом в Адамом Елдаровым

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

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

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

В моём докладе расскажу о том, как методом проб и ошибок мы строили продукт на основе больших данных в Х5

Проблемы совсем не в технической части. Обсудим как правильно построенный процесс DS-проекта может помочь исправить ситуацию.

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

В чём особенности мотивации команды, применения Kanban, продуктовой работы, процесса разработки и CI в проектах, связанных улучшением продуктов с помощью DS и ML. Почему Kanban, а не Scrum, чем полезны элементы методологии ASD, когда делаешь сложный сервис на ML с нуля. Откуда брать гипотезы, как их выбирать, проверять, выкатывать в production, считать и показывать пользу, и особенно – как потом поддерживать и развивать. Чем модели для production, процессы их создания и поддержки отличаются от написания статей или соревнований на Kaggle. Как не просто поверять и мониторить техническое и продуктовое качество сервисов на ML, но и встраивать его в них. Почему нужно быстрее, как искать и расширять узкие места, в т.ч. ускорить A/B-тесты.