Mechanisms for Effective Technical Teams
Юджин Янь описывает четыре механизма, повышающие продуктивность технических команд и команд команд. End of Week Debrief — неформальные часовые встречи без подготовки, где участники делятся прогрессом, получают обратную связь и быстрее вводят новичков в курс дела. Monthly Learning Sessions — часовые сессии (30-45 минут доклад плюс Q&A) для масштабирования экспертизы с записью для тех, кто пропустил. Quarterly Review для команд команд позволяет отрефлексировать прошлый квартал и согласовать приоритеты в духе нетфликсовского принципа «highly aligned, loosely coupled». Weekly Business Review фокусируется на input- и output-метриках по подходу из книги «Working Backwards» — управляемые входные показатели приводят к желаемым выходным. Автор подчёркивает, что у механизмов есть стоимость и их ROI зависит от стадии команды, поэтому выбирать их нужно осознанно.
Механизмы для эффективных технических команд
Ранее мы обсуждали механизмы для проектов машинного обучения. Здесь мы поговорим о механизмах для технических команд и команд команд. Цель — повысить продуктивность и эффективность команды. Команда — это группа людей, организованная вокруг общей функции, например инжиниринга, бизнес-аналитики или машинного обучения. Другое определение — «2-пицца-команды» Amazon, которые организованы вокруг продукта или сервиса.
Разбор в конце недели (команда)
Разбор в конце недели (end of week debrief, EOWD) — это возможность для команды собраться вместе и поделиться прогрессом за неделю. Такие встречи обычно неформальны и длятся час. Единственное требование — не тратить время на подготовку заранее. Это лёгкий механизм для команды, чтобы делиться информацией, собирать обратную связь и просить помощи.
На EOWD члены команды могут представлять свою работу через jupyter-ноутбуки, pull request'ы или наброски документов. Делится ли кто-то новым датасетом, который нашёл или построил, оптимизацией пайплайна данных или новой техникой машинного обучения — это шанс для всех чему-то научиться. Также это форум для запроса обратной связи: есть ли слепые зоны или недостатки дизайна? Какие-то предложения по улучшению?
Чтобы извлечь максимум, я обычно трачу несколько минут перед EOWD на размышления о том, какой вход я хочу получить от команды. При команде из 4-6 человек у каждого есть только 10 минут, чтобы поделиться. Поэтому важно быть лаконичным. Обратите внимание, что EOWD не предназначены для замены методологических ревью. Тем не менее, они хорошо работают как мини-ревью, позволяющие итеративно получать обратную связь и корректировать курс до полного методологического ревью.
Одно из преимуществ EOWD в том, что они дают каждому больше контекста о том, над чем работают остальные. Это особенно полезно для новых членов команды, чтобы быстро войти в курс дела. Кроме того, частый обмен способствует передаче знаний и более крепкому сотрудничеству внутри команды.
Ежемесячные обучающие сессии (команда)
Это для обмена знаниями, выходящего за рамки ~10 минут на EOWD. Цель — масштабировать экспертизу отдельного человека на команду или с команды на более широкую организацию. В зависимости от темы аудитория может расширяться от команды до других команд в организации.
Сессии обычно длятся час. Спикер делится знаниями 30-45 минут, а оставшееся время отводится на Q&A. Мы обычно записываем такие сессии, чтобы те, кто пропустил, могли посмотреть запись. Это также позволяет людям пересмотреть детали сессии.
Жёсткого формата у этого механизма нет. Если тема — техники машинного обучения или методология оценки, может быть полезно иметь слайды и визуалы. С другой стороны, если мы учим пользоваться инструментами вроде SageMaker или Airflow, может быть эффективнее провести практические демо, посмотреть код и повзаимодействовать с UI.
Обучающие сессии могут охватывать широкий спектр тем. Вот некоторые из тех, на которых я был:
Машинное обучение: если мы рассказываем про bandits, можно обсудить такие концепции, как вознаграждение, контекст, обратная связь, explore-exploit и примеры из индустрии. Инструменты: если мы учим Airflow, можно начать с просмотра продакшн-DAG через UI, а затем пройтись по его коду. Затем мы расскажем, как наша команда настроила алармы и тикетинг для падений или задержек задач. Навыки: если мы делимся, как ориентироваться в CloudWatch, можно сначала показать, как строить графики метрик и запускать запросы, а затем разобрать кейс, как мы использовали CloudWatch для триажа корневой причины сбоя.
Квартальный обзор (команда команд)
Техническим командам легко погрузиться в повседневные детали исполнения и потерять из виду более широкие бизнес- и продуктовые приоритеты. Здесь и пригодится квартальный обзор. Это возможность сделать шаг назад, отрефлексировать и согласовать средне- и долгосрочные цели. Цель — дать более широкой команде правильный контекст, чтобы она могла принимать хорошие решения в своей работе.
В Netflix эту концепцию воплощают в культуре «highly aligned, loosely coupled» (сильно выровненные, слабо связанные). Их собственными словами: «Мы тратим много времени на обсуждение и фиксацию стратегии и контекста, а затем доверяем друг другу выполнять тактику без предварительного одобрения». Квартальные обзоры помогают командам жить по этому принципу.
Обычно мы начинаем обзор с рефлексии о прошлом квартале. Чего мы достигли? Это можно измерить выпущенными фичами, операционными улучшениями или проведёнными экспериментами. Кроме того — чему мы научились? Что прошло хорошо, а что не очень? Это шанс отпраздновать победы и извлечённые уроки.
Затем мы фокусируемся на приоритетах следующего квартала. Какие приоритеты продолжаются и переходят в этот квартал? Какие новые приоритеты появились — запланированные ранее или совершенно новые инициативы? Если это новая инициатива, почему она важна? Наконец, что мы перестанем делать и почему? Это может быть связано с негативными результатами, плохой реакцией клиентов или временной депрриоритезацией.
Во время обзора важно делиться «Почему» за каждым приоритетом, чтобы команда понимала контекст. Это даёт команде возможность принимать информированные решения о том, «Что» делать или не делать, позволяя действовать эффективнее и быстрее.
Квартальный обзор — также отличное время для укрепления командного духа. Будь то очно или виртуально, мы можем отвести время для игр и совместной трапезы. Среди отличных онлайн-игр, которые я пробовал, — Fibbage: Enough About You, Drawasaurus и Codewords. Цель — повеселиться, сблизиться и уйти с общим пониманием приоритетов следующего квартала.
Еженедельный бизнес-обзор (команда команд)
Цель еженедельного бизнес-обзора (weekly business review, WBR) — дать всеобъемлющий обзор бизнеса или команды. В его основе лежат метрики: входные и выходные.
Важно понимать, как входы (они же опережающие индикаторы) влияют на выходы (запаздывающие индикаторы) наших систем. С этим знанием мы можем корректировать управляемые входы, чтобы достичь желаемых выходов. Хотя выходные метрики критически важны, ими нельзя напрямую манипулировать в долгосрочной перспективе. С другой стороны, входные метрики измеряют то, что — если делать правильно — приводит к желаемым выходам.
В книге Working Backwards мы узнаём, что Amazon использует такие входные метрики, как добавление товаров в каталог, снижение себестоимости для снижения цен и размещение запасов для ускорения доставки клиентам. Выходные метрики включают заказы, выручку и прибыль. Чтобы узнать больше о WBR, рекомендую обзор Commoncog про управляемые входные метрики. Также в книге «Working Backwards», написанной двумя давними инсайдерами Amazon, есть целая глава, посвящённая метрикам.
Давайте посмотрим на некоторые входные и выходные метрики гипотетической команды машинного обучения в e-commerce-стартапе. Для продаж выходные метрики включают конверсию, выручку, размер корзины и воронку продаж (например, клики, добавление в корзину, в избранное). Входные метрики включают количество экспериментов, проведённых на поиске и рекомендациях, покрытие виджетов рекомендаций по главной странице, странице товара, странице оформления заказа и т.д., а также задержку между поведением клиента и обновлёнными рекомендациями.
Другой пример — прогнозы доставки. Выходной метрикой может быть доля доставок, приходящих до, в день или после прогнозируемой даты доставки. Входные метрики могут включать интеграцию данных со сторонними логистическими провайдерами, своевременность, гранулярность и качество логистических данных, а также усилия по улучшению точности прогнозирования.
• • •
Хотя эти механизмы повышают продуктивность команды, у них есть цена. Некоторые, как EOWD, требующий лишь часа в неделю, — это небольшая инвестиция. Другие, как WBR, требуют больше времени и сил. ROI от этих механизмов будет варьироваться в зависимости от стадии команды. Поэтому будьте осознанны при выборе механизмов для внедрения.
Пробовали ли вы похожие механизмы и как они сработали? Какие ещё механизмы есть у вашей команды? Поделитесь!
Спасибо Yang Xinyi за прочтение черновиков.
Если эта статья оказалась полезной, пожалуйста, цитируйте её так:
Yan, Ziyou. (Feb 2023). Mechanisms for Effective Technical Teams. eugeneyan.com. https://eugeneyan.com/writing/mechanisms-for-teams/.
или
@article{yan2023teams, title = {Mechanisms for Effective Technical Teams}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2023}, month = {Feb}, url = {https://eugeneyan.com/writing/mechanisms-for-teams/} }
К 11 800+ читателям присоединяйтесь, чтобы получать обновления о машинном обучении, RecSys, LLM и инжиниринге.