- 1. Типы команд
- 2. Зрелость команд и развитие навыков
- 3. Организация кода
- 4. Роли в команде
- 5. Управление проектом
- 6. Оценка продуктивности
https://www.youtube.com/watch?v=jmjzSor1WDU
Как организовать DS в компании, какие варианты построения команд есть, как фокусировать команду на самом важном, проверять гипотезы и как оценивать их эффективность для бизнеса.
https://www.youtube.com/watch?v=qW8JlpNIyDQ
LeanDS — это процессы для исследовательской команды. Мы начали с них и выстроили процесс для большой команды, добывающей себе данные в пилотах, исследующей не только дата-сайнс, но и клиентские кейсы и бизнес-задачи.
https://towardsdatascience.com/data-product-management-ffa582f7e047
The missing link to create value from AI
- Ad-hoc
- Product
- Support
4 уровня зрелости:
- Oblivious
- Emerging
- Managed
- Optimizing
Модель зрелости процессов LeanDS
Уровни зрелости ML-процессов (процессов, связанных с Машинным Обучением)
Это таблица с ролями и навыками, важными для командной цели
Матрица компетенций как инструмент тимлида / Светлана Новикова и Константин Кафтан (Iponweb)
Матрица компетенций: важный инструмент для мотивации команды
Система организации кода и связанной с ним технической части проекта.
todo
Git. Большой практический выпуск
Git и GitHub Курс Для Новичков
Структура репозитория для унификации, прозрачности работы и упрощения переключения между проектами для всех участников команды и сотрудников компании.
- Для каждого изменения в мастер или при проверке очередной гипотезы создается отдельная ветка, в которой эти изменения вносятся и гипотезы проверяются. В случае успеха отправляется pull request для дальнейшего рассмотрения и возможного мерджа с мастером.
- Code review и hypothesis check review проводятся на этапе отправки pull request, и при успешном review ветка мерджится с мастером.
- Каждая ветка предназначена для одной гипотезы, небольших (не более 3х человекодней работы) изменений и соответствует тикету в jira. Поэтому название ветки рекомендуется брать из названия карточки в jira.
- При подготовке pull request НЕОБХОДИМО писать комментарий с кратким описанием изменений, при проверке гипотез можно дополнительно добавлять ридми, где отображать метрики/графики (пример).
https://github.com/dslp/dslp/blob/main/branching/branch-types.md#experiment-branches
Курс MLRepa
Для обеспечения воспроизводимости важно использовать requirements.txt, инициализируя файл в самом начале проекта. Управление зависимостями помогает управлять всеми библиотеками, необходимыми для работы приложения. Можно как использовать виртуальное окружение (приоритетный вариант), так и работать с ноутбуками в контейнере.
Creating Virtual Environments and Managing Packages with pip
Add Virtual Environment to Jupyter Notebook/Juplab
Единый стандарт написания кода для унификации стиля написания кода и упрощения чтения кода.
https://pep8.org
https://gist.github.com/RichardBronosky/454964087739a449da04 - pep8 cheat sheet (short)
Проверка исходного кода на ошибки, проблемы постановки эксперимента.
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
Заполнение документов о результатах проверки гипотез, а также внутренние отчеты (по работе моделей и тд). Процесс должен быть унифицирован и автоматизирован в начале или до начала очередного проекта.
Внешний отчеты для заказчика/клиента/контролирующих органов. Могут составляться по гостам, по форме, согласованной до начала/в процессе проекта, в свободной форме.
Пример отчета
Система организации команды.
Актуально и для единой структурной единицы (лаборатории, отдела), и для проектной команды, работающей над одним бэклогом. У каждой роли свой список обязанностей (должностная инструкция) и свой круг ответственности. Обязанности и ответственность могут меняться в зависимости от проекта и этапа проекта.
- Responsibility assignment matrix:
https://tlroadmap.io/roles/people-manager/team-management/team-design.html
- Мост между бизнесом и DS.
- Понимание возможностей и ограничений DS.
- Полномочия принятия решений.
- Ответственность за результат с точки зрения бизнеса и потребителя.
todo
todo
Team lead - связь между продукт менеджером/продукт овнером и членами DS команды/команды разработки. Может совмещать роли продукт менеджера, проджект менеджера.
Team lead roadmap – это карта навыков и компетенций тимлидов, которую можно адаптировать для любой компании и команды
Конспекты лекций о тимлидстве
Процесс работы DS выглядит следующим образом:
Rules of Machine Learning
Baselines: The First Rule of Machine Learning - Start without Machine Learning
todo
Система организации проектной деятельности.
- 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-моделей от идеи до продакшна
Планируемые встречи (взаимодействие команды):
- Брейнстормы - для наполнения бэклога и определения архитектуры решения (раз в 2 недели)
- Стендапы (Kanban meeting) - для обеспечения прозрачности и выявления рисков/проблем (ежедневно, через день)
- Ретроспективы (ретро) - для настройки процесса и понимания слабых мест (раз в 2 недели)
Для сложных гипотез/проектов "Парный Data Science"
Система (фреймворк), описывающая все процессы взаимодействия с внешними и внутренними лицами и исполнителями и тд.
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
Канбан доска создаётся на основе болей и проблем команды, чтобы она была вспомогательным инструментом в работе и в обеспечении качества проекта.
Оценка личной и командной продуктивности. Процесс может быть выстроен как регулярный анализ и разбор метрик продуктивности (пример команды) или как регулярные performance review (пример члена команды).
Оценка эффективности членов команды чаще всего проходит с помощью регулярных performance review. Performance review - это инструмент измерения эффективности члена команды.
Как часто:
- По времени (раз в квартал)
- По проектам (после каждого крупного проекта)
Дополнительно использовать one-on-one Тим Лида с каждым членом команды, чтобы рассказать результаты ревью, собрать обратную связь, а также обсудить вопросы, которые лучше не выносить на публику.
Оценка эффективности команды/отдельных исполнителей.
- Время проверки гипотез
- Можно через TTM (Time-To-Market) и другие продуктовые метрики
- выполнение плана
https://youtu.be/c0CRiCeJ99s
https://www.datascience-pm.com/9-ways-to-measure-data-science-project-performance/