DS-team-roadmap

Table of Contents

• 1. Типы команд
• 2. Зрелость команд и развитие навыков
  • 2.1 Зрелость команд
  • 2.2 Матрица компетенций
• 3. Организация кода
  • 3.1 git
  • 3.2 Типовая структура git репозитория
  • 3.3 Git Workflow
  • 3.4 Environment Managing
  • 3.5 Pep8
  • 3.6 Code review
  • 3.7 Internal reporting (automized in Python)
  • 3.8 External reporting (semi-automized)
• 4. Роли в команде
  • 4.1 Дизайн команды
  • 4.2 AI Product owner
  • 4.3 Project manager
  • 4.4 Team lead
  • 4.5 Data scientist
  • 4.6 Developer
• 5. Управление проектом
  • 5.1 Проработка проекта в начале
  • 5.2 Взаимодействие членов команды
  • 5.3 Организация проекта
  • 5.4 Организация канбан доски
• 6. Оценка продуктивности
  • 6.1 Individual
  • 6.2 Team

Как мы проверяем и оцениваем гипотезы в YouDo, Адам Елдаров, Head of Product and Data Science

https://www.youtube.com/watch?v=jmjzSor1WDU

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

Процессы для самоорганизующейся DS команды: встречи, доски и best practices

https://www.youtube.com/watch?v=qW8JlpNIyDQ

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

Data Product Management

https://towardsdatascience.com/data-product-management-ffa582f7e047

The missing link to create value from AI

1. Типы команд

• Ad-hoc
• Product
• Support

2. Зрелость команд и развитие навыков

2.1 Зрелость команд

4 уровня зрелости:

• Oblivious
• Emerging
• Managed
• Optimizing

Ссылки

Модель зрелости процессов LeanDS
Уровни зрелости ML-процессов (процессов, связанных с Машинным Обучением)

2.2 Матрица компетенций

Это таблица с ролями и навыками, важными для командной цели

Ссылки

Матрица компетенций как инструмент тимлида / Светлана Новикова и Константин Кафтан (Iponweb)
Матрица компетенций: важный инструмент для мотивации команды

3. Организация кода

Система организации кода и связанной с ним технической части проекта.

3.1 git

Описание

todo

Ссылки

Git. Большой практический выпуск
Git и GitHub Курс Для Новичков

3.2 Типовая структура git репозитория

Описание

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

Ссылки

https://github.com/YKatser/ml-project-template

3.3 Git Workflow

Описание

1. Для каждого изменения в мастер или при проверке очередной гипотезы создается отдельная ветка, в которой эти изменения вносятся и гипотезы проверяются. В случае успеха отправляется pull request для дальнейшего рассмотрения и возможного мерджа с мастером.
2. Code review и hypothesis check review проводятся на этапе отправки pull request, и при успешном review ветка мерджится с мастером.
3. Каждая ветка предназначена для одной гипотезы, небольших (не более 3х человекодней работы) изменений и соответствует тикету в jira. Поэтому название ветки рекомендуется брать из названия карточки в jira.
4. При подготовке pull request НЕОБХОДИМО писать комментарий с кратким описанием изменений, при проверке гипотез можно дополнительно добавлять ридми, где отображать метрики/графики (пример).

Ссылки

https://github.com/dslp/dslp/blob/main/branching/branch-types.md#experiment-branches
Курс MLRepa

3.4 Environment Managing

Описание

Для обеспечения воспроизводимости важно использовать requirements.txt, инициализируя файл в самом начале проекта. Управление зависимостями помогает управлять всеми библиотеками, необходимыми для работы приложения. Можно как использовать виртуальное окружение (приоритетный вариант), так и работать с ноутбуками в контейнере.

Ссылки

Creating Virtual Environments and Managing Packages with pip
Add Virtual Environment to Jupyter Notebook/Juplab

3.5 Pep8

Описание

Единый стандарт написания кода для унификации стиля написания кода и упрощения чтения кода.

Ссылки

https://pep8.org
https://gist.github.com/RichardBronosky/454964087739a449da04 - pep8 cheat sheet (short)

3.6 Code review

Описание

Проверка исходного кода на ошибки, проблемы постановки эксперимента.

Ссылки

https://tlroadmap.io/roles/technical-lead/product-quality/code-review.html
https://mtlynch.io/human-code-reviews-1/
https://mtlynch.io/human-code-reviews-2/
https://youtu.be/2F6J82-Ch88

3.7 Internal reporting (automized in Python)

Описание

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

Ссылки

Пример отчета

3.8 External reporting (semi-automized)

Описание

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

Ссылки

Пример отчета

4. Роли в команде

Система организации команды.

4.1 Дизайн команды

Описание

Актуально и для единой структурной единицы (лаборатории, отдела), и для проектной команды, работающей над одним бэклогом. У каждой роли свой список обязанностей (должностная инструкция) и свой круг ответственности. Обязанности и ответственность могут меняться в зависимости от проекта и этапа проекта.

• Responsibility assignment matrix:

Ссылки

https://tlroadmap.io/roles/people-manager/team-management/team-design.html

4.2 AI Product owner

Описание

• Мост между бизнесом и DS.
• Понимание возможностей и ограничений DS.
• Полномочия принятия решений.
• Ответственность за результат с точки зрения бизнеса и потребителя.

Ссылки

todo

4.3 Project manager

todo

4.4 Team lead

Описание

Team lead - связь между продукт менеджером/продукт овнером и членами DS команды/команды разработки. Может совмещать роли продукт менеджера, проджект менеджера.

Ссылки

Team lead roadmap – это карта навыков и компетенций тимлидов, которую можно адаптировать для любой компании и команды
Конспекты лекций о тимлидстве

4.5 Data scientist

Описание

Процесс работы DS выглядит следующим образом:

Ссылки

Rules of Machine Learning
Baselines: The First Rule of Machine Learning - Start without Machine Learning

4.6 Developer

todo

5. Управление проектом

Система организации проектной деятельности.

5.1 Проработка проекта в начале

• AI canvas

Как мы используем AI Канвас в БигДате МТС, Мария Ракитина, менеджер продуктов МТС
The Ultimate AI Canvas
MISSION Canvas by DataMonsters

• Check list

• User story map

Story mapping. Как спроектировать продукт с AI-состовляющей
User Story Mapping – инструкция по применению by scrumtrek

• Dataset Card (Паспорт датасета, карточка с различной информацией о датасете)
  • Объем данных, баланс классов, Примеры данных, источник данных и лицензия, тип разметки, иные особенности
  • Помогает не сойти с ума при работе с данными, онбордить новичков, оперативно снабжать другие отделы информацией, принимать решения по данным
  • Формат - Google Doc, Markdown, интерактивная витрина (Streamlit-приложение)

Источник - MLOps: жизненный цикл ML-моделей от идеи до продакшна

5.2 Взаимодействие членов команды

Описание

Планируемые встречи (взаимодействие команды): 

• Брейнстормы - для наполнения бэклога и определения архитектуры решения (раз в 2 недели)
• Стендапы (Kanban meeting) - для обеспечения прозрачности и выявления рисков/проблем (ежедневно, через день)
• Ретроспективы (ретро) - для настройки процесса и понимания слабых мест (раз в 2 недели)

Для сложных гипотез/проектов "Парный Data Science"

Ссылки

Парный Data Science

5.3 Организация проекта

Описание

Система (фреймворк), описывающая все процессы взаимодействия с внешними и внутренними лицами и исполнителями и тд.

Ссылки

Team Data Science Process (TDSP)
CRISP-DM
Lean Data Science 1.0 (SOTA) | LeanDS book | Mini-course
The Data Science Lifecycle by Dominodatalab
QUEST framework

5.4 Организация канбан доски

Описание

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

Ссылки

https://www.youtube.com/watch?v=QYkuv2zuCFk

6. Оценка продуктивности

Оценка личной и командной продуктивности. Процесс может быть выстроен как регулярный анализ и разбор метрик продуктивности (пример команды) или как регулярные performance review (пример члена команды).

6.1 Individual

Описание

Оценка эффективности членов команды чаще всего проходит с помощью регулярных performance review.  Performance review - это инструмент измерения эффективности члена команды.

Как часто:

• По времени (раз в квартал)
• По проектам (после каждого крупного проекта)

Дополнительно использовать one-on-one Тим Лида с каждым членом команды, чтобы рассказать результаты ревью, собрать обратную связь, а также обсудить вопросы, которые лучше не выносить на публику.

Ссылки

Performance review
One-on-One 1
One-on-One 2

6.2 Team

Описание

Оценка эффективности команды/отдельных исполнителей.

• Время проверки гипотез
• Можно через TTM (Time-To-Market) и другие продуктовые метрики
• выполнение плана

Ссылки

https://youtu.be/c0CRiCeJ99s
https://www.datascience-pm.com/9-ways-to-measure-data-science-project-performance/