Привет, Хабр! Меня зовут Даниель, я занимаюсь машинным обучением в Garage Eight.
Как рождается ML в компании с точки зрения бизнеса, рассказал Родион. Я же хочу обсудить особенности жизни ML команды.
Вводные: Будем говорить про команду с горизонтальной структурой. В такой команде нет лида, а голоса всех разработчиков имеют одинаковый вес при принятии решений.
Кто здесь?
Важный момент, на который стоит обратить внимание — ответственность. На любом проекте будут возникать вопросы «кто принимает решение о направлении работы команды?», «как команде принять решение голосованием?» и другие.
Например, кто‑то хочет хранить модели локально, а кому‑то ближе MLflow. Конечно, бывают ситуации, когда решение принимается голосованием на основании рациональных критериев, но в ситуации, когда голоса распределены равномерно, требуется более качественная проработка вопроса. Тогда стоит обсуждать вопрос в несколько подходов, а иногда лучше пересмотреть задачу.
Еще один момент про ответственность — определение метрик и сроков проекта. У нас в компании есть люди, которые определяют текущий проект команды, а вот метрики и сроки определяются как средневзвешенное между желанием бизнеса и возможностями команды. В команде с горизонтальной структурой может не быть человека, который смог бы донести бизнесу ожидания от проекта и при этом был бы ответственным за результат работы команды. Это может приводить к тому, что запрашиваемые командой сроки на проект сокращаются, методики расчета метрик не всегда фиксируются.
Для решения этого вопроса мы внедрили дизайн ML проектов на разных этапах согласования.Такой подход позволил синхронизировать у заказчика его понимание, желание и уверенность в проекте, а также определить четкие критерии работы со стороны команды, при этом оставаясь в горизонтальной структуре.
Как всё успеть?
Когда направление новое и интересное, резкий рост числа проектов практически неизбежен. В определенный момент, а конкретно после первого успешного проекта, ажиотаж вокруг деятельности команды может быть сравним с открытием первого Макдоналдс в Москве.
Отсутствие устоявшихся практик разработки и готовой инфраструктуры может привести к ситуации, когда на поддержку существующих проектов будет уходить больше времени, чем на разработку новых. Упреждающими и очень важными решениями со стороны нашей команды были:
разворот MLOps платформы, которая позволила сократить время на поддержание текущих проектов и вывод в продакшн новых;
разработка общих правил создания кодовой базы.
Кто-то может справедливо заметить, что было бы хорошо иметь еще и некую воронку отсечения проектов из разряда «хотелок» и приоритизацию действительно профитных проектов для компании. Мы обсуждаем такие вопросы с бизнесом, приходим к решению как делать проект и стоит ли его делать вообще с точки зрения профита. Сплоченность команды вокруг общего решения и убежденность в позиции относительно проекта позволяют команде отстаивать свои идеи и доносить ценности для бизнеса.
Разбираем задачи
Когда проект все‑таки утвержден — команда приступает к его реализации. Задачи создаются и распределяются командой, исходя из целей и сроков проекта. Тут может возникнуть вопрос «Как распределять задачи, когда вес голоса у всех одинаковый, а голоса распределены равномерно?». Сейчас выясним.
Поскольку лида в команде нет, задачи распределяются по следующей схеме:
Каждый выбирает интересные ему задачи в разрезе ценности для бизнеса и вектора собственного развития.
После предыдущего этапа может оставаться часть задач, которые по мнению команды несут невысокую бизнес ценность, поэтому они говорят «I»ll be back» и отправляются в бэклог, чтобы вернуться после декомпозиции.
Для ускорения процесса стоит выделить области компетенций разработчиков и договориться внутри команды о зонах ответственности. Такой подход позволит улучшить процесс распределения задач и сбалансировать атмосферу в команде.
Человек
После того, как все задачи распределены по схеме выше, в процесс написания кода вмешиваются важные качества личности разработчика — возможность самомотивироваться, умение организовать собственную работу и приоритизировать задачи.
Своевременная мотивация со стороны команды + некоторая помощь в решении задач сильно ускоряют перемещение задачи в целевую колонку «DONE». В поддержании мотивации и организации процесса планирования помогают SCRUM‑мастера, которые в нашей компании работают с несколькими командами.
TL;DR
Особенности горизонтальной структуры команды:
Ответственность за сроки и метрики проекта ложится на всю команду, а не на отдельного человека, как и выполнение приоритизации проектов, когда их становится +100 500, а также отслеживание прогресса по задачам.
Распределение задач происходит с учетом ценности для бизнеса и вектора развития разработчика.
Для формирования позиции команды по проекту проводится глубокая проработка вопроса с учетом мнения каждого разработчика.
Горизонтальная структура позволяет разработчикам развивать навыки самомотивации, самоорганизации и приоритизации задач.
Есть возможность экспериментировать с технологиями и инструментами, позволяющими создавать ценности для бизнеса.
Возможен быстрый рост компетенций за счет эффективного обмена опытом и знаниями.
Команда сплачивается вокруг совместных решений.
P.S.
Пройдя через эти ситуации, мы успешно трансформировали горизонтальную структуру команды и адаптировали её под существующий формат работы компании. Это позволило создать эффективные бизнес‑процессы, которые дают разработчикам возможность экспериментировать, ускоряют поставку решений, создают комфортную атмосферу в команде и помогают двигаться вперед.
P.P.S.
Пишу о жизни ML команды, развитии и новостях из мира DS у себя на канале.
А как вы относитесь к горизонтальной структуре, какой опыт у вас?
