Привет, Хабр! Меня зовут Даниель, я занимаюсь машинным обучением в Garage Eight.

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

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

Кто здесь?

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

Например, кто‑то хочет хранить модели локально, а кому‑то ближе MLflow. Конечно, бывают ситуации, когда решение принимается голосованием на основании рациональных критериев, но в ситуации, когда голоса распределены равномерно, требуется более качественная проработка вопроса. Тогда стоит обсуждать вопрос в несколько подходов, а иногда лучше пересмотреть задачу.

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

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

Как всё успеть?

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

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

• разворот MLOps платформы, которая позволила сократить время на поддержание текущих проектов и вывод в продакшн новых;

• разработка общих правил создания кодовой базы.

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

Разбираем задачи

Когда проект все‑таки утвержден — команда приступает к его реализации. Задачи создаются и распределяются командой, исходя из целей и сроков проекта. Тут может возникнуть вопрос «Как распределять задачи, когда вес голоса у всех одинаковый, а голоса распределены равномерно?». Сейчас выясним.

Поскольку лида в команде нет, задачи распределяются по следующей схеме:

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

2. После предыдущего этапа может оставаться часть задач, которые по мнению команды несут невысокую бизнес ценность, поэтому они говорят «I»ll be back» и отправляются в бэклог, чтобы вернуться после декомпозиции.

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

Человек

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

Своевременная мотивация со стороны команды + некоторая помощь в решении задач сильно ускоряют перемещение задачи в целевую колонку «DONE». В поддержании мотивации и организации процесса планирования помогают SCRUM‑мастера, которые в нашей компании работают с несколькими командами.

TL;DR

Особенности горизонтальной структуры команды:

1. Ответственность за сроки и метрики проекта ложится на всю команду, а не на отдельного человека, как и выполнение приоритизации проектов, когда их становится +100 500, а также отслеживание прогресса по задачам.

2. Распределение задач происходит с учетом ценности для бизнеса и вектора развития разработчика.

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

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

5. Есть возможность экспериментировать с технологиями и инструментами, позволяющими создавать ценности для бизнеса.

6. Возможен быстрый рост компетенций за счет эффективного обмена опытом и знаниями.

7. Команда сплачивается вокруг совместных решений.

P.S.

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

P.P.S.

Пишу о жизни ML команды, развитии и новостях из мира DS у себя на канале.

А как вы относитесь к горизонтальной структуре, какой опыт у вас?