Создание продуктивных команд

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

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

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

• Четко определенные роли экипажа
• Четко определенный процесс смены экипажа
• Частые корректировки размера экипажа

Группа по доработке функций

Команда функций, или F-команда, фокусируется на будущем. Они работают как эффективная команда с четкой миссией и целью: создавать и выпускать высококачественные функции.

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

Когда член команды F присоединяется к беседе или иногда вовлекается в поток электронной почты, другие члены команды должны упрекать их: "Вы в команде F, что вы делаете?" Если член команды F должен решить критически важный вопрос, им рекомендуется делегировать его команде поддержки клиентов и вернуться к разработке функционала.

F-экипаж работает как сплоченная команда, которая сосредотачивается на небольшом наборе функций. Хороший предел незавершенной работы (WIP) — две функции в разработке для 4-6 человек. Работая вместе, они создают глубокий общий контекст и находят критические ошибки или проблемы разработки, которые пропустят курсорный обзор кода. Выделенная команда обеспечивает более прогнозируемую скорость пропускной способности и время выполнения. Члены команды часто говорят о F-экипаже, как о безмятежном и сосредоточенном. Они находят это умиротворяющим и восстанавливающим, глубоко сосредотачиваясь на функции и уделяя ей все свое внимание. Люди покидают команду Ф, чувствуя себя обновленными и востребованными.

Экипаж клиента

Клиентская команда, или экипаж C, ориентирована на данный момент и обеспечивает первичную поддержку для проблем клиентов и работающего сайта, ошибок, телееметрии и мониторинга. Экипаж C часто собирается вокруг компьютера, отлаживая критическую проблему на активном сайте. Их основным приоритетом является сохранность действующего сайта. Сосредоточившись на этой среде, они развивают экспертные навыки в области отладки и анализа. Экипаж клиента часто называют командой-защитником, потому что он защищает остальную часть команды от отвлекающих факторов. Вместо того чтобы работать над предстоящими функциями, экипаж C является мостом между клиентами и текущим продуктом. Члены экипажа активны в электронной почте, Twitter и других каналах обратной связи. Клиенты хотят знать, что они услышаны, и работа C-экипажа заключается в том, чтобы услышать их. Команда C-экипаж сразу же выдает сообщения о проблемах, сообщаемых клиентом, и быстро участвует и помогает заблокированным клиентам.

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

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

Ротация экипажа

Четко определенный процесс ротации обеспечивает функционирование двухкомандной системы. Вы можете просто поменять местами экипажи («F-crew» становится «C-crew» и наоборот), но это ограничивает возможность обмена знаниями между экипажами и внутри них. Вместо этого выберите еженедельную смену.

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

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

Размер экипажа

Размер экипажа зависит от поддержания работоспособности команды. Если у команды высокий уровень входящих проблем с живыми сайтами или много технического долга, то команда C увеличивается, и наоборот. Изменение размеров еженедельно увеличивает прогнозируемость в результатах и зависимостях команды. Через несколько недель команда может переместить всех в команду C, чтобы учесть отзывы от большого выпуска.

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

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

Дальнейшие шаги

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

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

Корпорация Майкрософт является одной из крупнейших в мире компаний Agile. Узнайте , как корпорация Майкрософт упорядочивает команды в планировании DevOps.