Люди постоянно меняют команды. Есть много причин, включая смену работы, внутреннюю миграцию, личное свободное время и т. Д. Прошли те времена, когда люди оставались в компании надолго, не говоря уже о работе в одной команде. Принятие этого факта и подготовка делает команду устойчивой к изменениям. Большая часть подготовки включает в себя твердый план адаптации. Команды машинного обучения (ML) отличаются друг от друга, поскольку они включают в себя множество различных методов и навыков по сравнению с типичными программными продуктами. Таким образом, вступление в такие команды сопряжено с некоторыми уникальными проблемами. В этой статье мы покажем процесс адаптации как часть обработки изменений в команде в области продуктов машинного обучения. Мы поделимся своим взглядом на процесс вывода из системы в отдельной статье.

Задний план

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

  • бизнес-процесс, управляемый данными
  • (гибкие) способы работы, открытые для исследования
  • данные и платформы данных
  • публичное / частное облако
  • Методы машинного обучения
  • бэкэнд / фронтенд программные системы

Для поддержки этих параметров требуется ряд квалифицированных специалистов, таких как product owner, бизнес-аналитик, аналитик данных, data science , инженер машинного обучения, инженер данных, инженер-программист, инженер DevOps и т. д. Продуктовые группы выбирают смену ролей / команд быстрее, чем другие роли в другом типе команды разработчиков программного обеспечения, из-за сильного дефицита на рынке, быстро меняющегося технического ландшафта, возможностей совмещения нескольких ролей в одной и т. д. наблюдения, мы видели, что это происходит не реже одного раза в три-шесть месяцев. Ожидая аналогичного показателя, мы увидели, что лучшая стратегия - сосредоточиться на совместных знаниях и владении в сочетании с надежным процессом адаптации / увольнения. Здесь мы сосредоточимся на процессе адаптации в такой обстановке.

Процесс адаптации

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

Мы рассматриваем адаптацию как четырехэтапный процесс (см. Рисунок 2). Этапы следующие:

  1. Набор. Начинается, когда принято решение, что кто-то начнет работу в команде в определенный день. На этом этапе составляется план по привлечению нового сотрудника.
  2. Ориентация: начинается, когда кто-то присоединяется к команде. Обычно это длится несколько недель, в течение которых этот человек получает всевозможную информацию высокого уровня и обучается, чтобы понять, как внести свой вклад в продукт.
  3. Сотрудничество: начинается в течение пары недель. Обычно это длится пару месяцев, в течение которых новый сотрудник сталкивается с различными проблемами, связанными с применением информации об ориентации для внесения вклада в различных измерениях. Эти задачи должны быть решены в сотрудничестве с другими членами команды.
  4. Вклад: Начнется через пару месяцев с момента нового найма. На этом этапе ожидается, что человек знает, как внести свой вклад в продукт независимо, и может время от времени сотрудничать с другими.

Для адаптации мы рекомендуем следующие методы.

Этап набора

  • Определите область участия. Владелец продукта (ЗП) должен инициировать процесс адаптации, проинформировав команду о новом сотруднике. Команда должна оценить профиль нового сотрудника и выделить от трех до пяти основных областей вклада, имеющих отношение к продукту. В случае специалиста по данным, это может быть обучение модели, анализ данных, анализ прогона модели, поддержка операций и документация.
  • Выявление / выбор проблем: команда должна найти набор соответствующих проблем разного уровня сложности, которые можно поручить новому сотруднику во время адаптации. Проблемы могут быть столь же простыми, как написание модульного теста для функции обработки данных, перемещение жестко запрограммированного параметра в переменную и т. Д. Это может быть более сложным и может потребоваться несколько дней для решения, например, изучение влияния уменьшения размера выборки обучающие функции, реализация нового графика, который помогает исследовать предвзятость и т. д. Это может быть намного сложнее и потребует нескольких спринтов, таких как внедрение нового метода выбора функций, автоматизация выбора модели, оптимизация обработки данных и т. д.
  • Назначьте приятеля по адаптации. Команда должна выбрать друга по адаптации, который будет составлять список, планировать и проводить ознакомительные занятия для нового сотрудника. От партнера не ожидается, что он будет делать все, но он должен знать большую часть деталей адаптации и может поддержать нового сотрудника, выполнив большую часть настройки среды (разработки). Обычно отбор следует проводить в соответствии со справедливой политикой, если только особые обстоятельства не требуют конкретного человека. Например, если новый нанимаемый инженер - DevOps-инженер, полезно выбрать какого-нибудь инженера, даже если это было время для человека с другой ролью.

Ориентационный этап

  • Обеспечьте регистрацию при адаптации: владелец продукта должен запланировать и проводить регулярные проверки вместе с новым сотрудником, чтобы быть в курсе того, что происходит. Первая проверка должна быть посвящена пониманию ожиданий как нового сотрудника, так и команды относительно друг друга. Последующие должны быть посвящены оценке исполнения ожиданий.
  • Настройка рабочей среды: новый сотрудник должен настроить среду для работы с продуктом, используя самостоятельный процесс. Это может включать доступ к системам контроля версий кода, данных и моделей, установку лицензий для различных систем, доступ к локальным и удаленным рабочим средам, платформам данных и т. Д. В случае возникновения проблем человек должен обратиться к партнеру. Весь процесс не должен занять больше пары дней.
  • Примите участие в ознакомительных занятиях: новый сотрудник должен участвовать в ознакомительных занятиях, которые могут длиться несколько дней в течение нескольких недель, чтобы у человека было достаточно времени, чтобы понять детали. . Ориентационные занятия должны быть на высоком уровне. В это время приятель становится тем, кто уточняет вопросы и проблемы. Если возникнет необходимость, приятель может перейти к обсуждению с кем-нибудь еще.
  • Участвуйте в обучении: новый сотрудник должен начать читать документацию по дизайну, способам работы, техническому дизайну и т. д. продукта. Этот человек также должен начать (самостоятельное) обучение техническим компонентам продукта.
  • Практические методы работы: Новый сотрудник должен участвовать во всех запланированных встречах, в которых участвует команда. Этот человек также должен быть приглашен на специальные обсуждения. На всех этих встречах и обсуждениях человека приветствуют, но не ждут, что он внесет свой вклад. Кроме того, человек должен получить набор очень простых задач, которые можно использовать, чтобы попрактиковаться в работе над продуктом. Написание модульного теста, работа с жестко запрограммированным параметром, улучшение документации и т. Д. - хорошие примеры таких проблем. Последнее собеседование должно быть посвящено сбору отзывов для улучшения процесса адаптации.

Этап сотрудничества

  • Выполнить первый тикет: новый сотрудник назначается тикету, который, как ожидается, завершится в течение спринта. Кандидат должен получить в заявке соразработчика, который разделяет ответственность за закрытие заявки. Двое должны регулярно заниматься парным программированием. Со-разработчик должен играть более активную роль во время сессий. Эта практика задает тон способам работы в команде - совместной работе. Кроме того, желательно, чтобы время доставки билета было немного сокращено.
  • Продолжить обучение. Первые несколько спринтов нового сотрудника не должны быть слишком занятыми. У человека должно быть достаточно времени для продолжения обучения, изучения документации и обсуждения с командой.
  • Выполнение более сложных заявок: после закрытия первой заявки новый сотрудник должен получить набор заявок, которые в совокупности немного сложнее и потребуют большую часть спринта. Хорошими примерами таких билетов являются исследование влияния размеров выборки на обучение модели, внедрение новых простых способов квалификации модели и т. Д. Человек должен получить одного соразработчика на каждый билет. Однако в этом случае человек несет основную ответственность за закрытие билетов и, как ожидается, возьмет на себя ведущую роль во время сеансов парного программирования. Однако желательно, чтобы время доставки билетов было немного снижено, чтобы облегчить обучение при участии.
  • Спланируйте эпопею. Команда должна спланировать эпопею, над которой новый сотрудник будет работать на последнем этапе адаптации. Хотя первоначальное планирование может быть выполнено без привлечения нового сотрудника, но уточнение работы должно выполняться вместе с новым сотрудником. Работа должна быть намного сложнее по сравнению с предыдущими задачами. Эпопея может быть посвящена реализации нового метода выбора функций, автоматизации процесса выбора модели, оптимизации обработки данных и т. Д.

Стадия вклада

  • Проведите первую крупную эпопею: Нового найма следует назначить на эпопею, состоящую из двух-трех спринтов. Человек должен спланировать и оформить отдельные билеты в рамках эпоса. Человек должен активно сочетать программу с другими разработчиками, чтобы обеспечить согласованность мышления. Однако желательно, чтобы время доставки эпопеи было немного сокращено.
  • Внесите свой вклад в отставание продукта: во время работы над эпиком новый сотрудник должен начать вносить свой вклад в отставание продукта, добавляя и уточняя несколько заявок.
  • Сбор отзывов об улучшении процесса адаптации. В качестве последней части процесса адаптации новый сотрудник должен пройти собеседование с владельцем продукта об общем опыте адаптации, что станет основой для улучшения процесса для следующего. человек.

Лучшие практики, влияющие на адаптацию

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

  • Команда определяет основные аспекты вклада в продукт. Измерения должны касаться не только технических аспектов, например, обработки данных, управления моделями, проверки гипотез и т. Д., Но и способов работы, например, scrum / kanban-активности, документации и т. Д.
  • Некоторые заявки в бэклоге должны быть помечены для обучения. Идея состоит в том, что эти билеты можно использовать в процессе адаптации. Их также можно использовать для повышения квалификации члена команды. Билеты также должны быть помечены размерами взноса. Билеты обычно должны иметь низкий или средний уровень сложности и умеренные сроки.
  • Следует разработать шаблоны для стандартизации рутинной работы, например, план адаптации, синхронизацию во время адаптации, обратную связь по адаптации и т. Д.
  • Команда должна принять прочную стратегию в отношении документации и архивирования. Необязательно все подробно записывать. Хорошая документация должна легко обновляться, как часть большинства заявок, собранных во время спринтов. Он может включать в себя несколько диаграмм бизнес-процессов, дизайна инфраструктуры, дизайна кода, происхождения данных и т. Д., Документацию по API, инструкции, документацию по коду, сводки исследований и т. Д. Хорошая документация обеспечивает более быстрое подключение без излишних усилий со стороны команды.
  • В специальный раздел документации следует включить руководство по настройке среды разработки и эксплуатации. Некоторые технологии могут быть новыми для кандидата. Следовательно, для всех технических компонентов, например Python, Docker, sklearn и т. Д., Должны быть включены (публично) доступные учебные пособия. Хорошая документация по настройке и учебные пособия обеспечивают более быстрое и легкое подключение.
  • Презентационные материалы для ознакомительной сессии должны быть подготовлены таким образом, чтобы их можно было рассматривать как учебные пособия. Например, введение данных может быть выполнено в виде самостоятельной записной книжки с примерами и упражнениями, введение в управление моделями может быть разработано как задача программирования и т. Д. Сеансы следует записывать и повторно использовать, если материалы презентации остаются в основном неизменными. В случае записанных сеансов следует организовать короткий сеанс вопросов и ответов для получения дополнительных разъяснений после каждого сеанса. Ознакомительный материал в стиле учебного пособия обеспечивает увлекательный опыт. Сеансы записи и архивирования позволяют ускорить процесс адаптации, поскольку устраняют конфликты планирования.
  • Процесс адаптации должен принадлежать всей команде, а не нескольким избранным. Общий процесс должен быть стандартизирован и понятен всем. Ориентационные занятия следует распределять между разными членами команды, но большинство из них должны уметь обсуждать общие общие вопросы. Обучение по процессу адаптации должно быть организовано для новых членов команды, чтобы они могли владеть процессом в будущем. Разделение ответственности при адаптации делает команду устойчивой к изменениям в команде.
  • Команде следует придерживаться стиля совместной работы, в котором широко используются парное программирование, мозговой штурм, активные дискуссии и т. Д. Высокая степень сотрудничества делает процесс адаптации более персонализированным и эффективным.
  • Команде следует стремиться к высокому уровню автоматизации рутинной работы, при которой на каждой итерации происходит очень мало изменений. Высокая степень автоматизации сокращает объем знаний, которые необходимо объяснить члену команды.
  • Команда должна руководствоваться гипотезами во всех идеях. В работе с машинным обучением довольно часто случаются сюрпризы. Хороший способ справиться с неожиданностями - рассматривать каждый неизвестный шаг как исследование, проверяющее идею. Результаты исследования указывают на то, что они должны вдохновить на дальнейшую реализацию или исследование. Это значительно упрощает постановку задач перед новым сотрудником за счет уменьшения неопределенностей.
  • Команде следует стремиться к процессу, в котором доля активного обучения по сравнению с внесением изменений меняется прагматично. Рисунок 4 иллюстрирует такое изменение. Обычно активное обучение, которое включает чтение документации по продукту, прохождение технического обучения и т. Д., Должно быть очень высоким в первые несколько недель. Он никогда не должен быть очень низким, даже когда процесс адаптации завершен, чтобы быть в курсе последних достижений. С другой стороны, участие, которое включает техническую работу, документацию, планирование, обсуждение и т. Д., Должно начинаться с самого начала. Вначале следует начинать с низкой доли. Однако он должен достичь высокого процента в последней части процесса адаптации и оставаться на этом уровне после. Конечно, могут быть исключения, например. g., необходимо изучить новые технологии для поддержки исследовательской, инновационной работы.

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

Замечания

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

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