Время чтения: 13 мин

20 сентября 2022 г.

Нажмите Enter или кликните, чтобы открыть изображение в полном размере

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

Нажмите Enter или кликните, чтобы открыть изображение в полном размере

Признаки хорошей команды разработки ПО

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

• Четко определенные роли — Каждый член команды приносит пользу и опыт для поддержки проектов и целей рабочих направлений (streamwork). Понятно, почему конкретный человек был выбран в команду и какова его роль.
• Сбалансированный уровень квалификации (seniority) — Работы должно хватать для разных типов специалистов. То, что опытные разработчики (seniors) считают скучным и демотивирующим, для начинающих (juniors), скорее всего, станет сложным и увлекательным вызовом. Несбалансированные команды приводят к плохим результатам и отсутствию осмысленной работы, особенно когда все в команде — senior-специалисты.
• Ответственность и чувство собственности (ownership) — Каждый человек отвечает за свою работу, и здесь нет возможности оставаться «в тени». Хорошие команды поддерживают ответственность как на личном, так и на групповом уровнях.
• Разумный размер — Большая команда = сложное общение. Чем больше людей нужно держать в курсе дела, тем меньше работы будет сделано и тем больше возникнет путаницы. Идеальная agile-команда состоит примерно из 4–5 инженеров + продакт-менеджер и/или дизайнер для поддержания простоты и плавности процессов.

Нажмите Enter или кликните, чтобы открыть изображение в полном размере

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

• Доверие — Люди должны знать друг друга ближе, чем просто по планированиям, стендапам и спорам в PR (pull requests). Хорошая команда — это группа людей, которые доверяют друг другу и могут вести честные и конструктивные дискуссии, даже если они не согласны друг с другом. Это ультраважно в мире, где преобладает удаленная работа (remote-first).
• Прозрачность — Четко понятно, над чем работает команда. Обычно это означает наличие обновляемой доски задач и связь тасок с высокоуровневыми целями компании и направлениями работы (roadmap). Хорошая команда проактивно делится тем, что делает, без необходимости вытягивать из нее обновления.
• Сильное лидерство — Лидеры — это единственный и самый важный фактор успеха команды. Гораздо сложнее понять их влияние, если некоторые из упомянутых мною ранее моментов отсутствуют (например, нет прозрачности, четко определенных ролей или вовлечено слишком много менеджегов).

В конечном счете, хорошая команда разработки — это та, которая эффективно работает, но вы удивитесь, как часто все складывается иначе. Техническое руководство и разработчики редко ставят под сомнение статус-кво в отношении организационной структуры, полагая, что знакомое зло лучше незнакомого. Именно поэтому так много организаций топчутся на месте, работая неэффективно. Миру приходится придумывать дурацкие фразы вроде «Великое увольнение» (Great Resignation) или вошедшее в моду «Тихое увольнение» (Quiet Quitting), чтобы привлечь внимание к плохому руководству, которое, скорее всего, так ничего и не изменит.

Нажмите Enter или кликните, чтобы открыть изображение в полном размере

Глубокий разбор наиболее распространенных структур команд

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

Однодисциплинарные команды с техническими менеджерами (Single-discipline teams)

Нажмите Enter или кликните, чтобы открыть изображение в полном размере

Такую структуру часто можно встретить в типичных waterfall-моделях (каскадная методология). Однако совсем недавно я натолкнулся на компанию с именно такой структурой инженерной команды, которая при этом пыталась работать по Agile. Моей первой целью было уйти от этого, так как подобный подход порождал колоссальную неэффективность в продукте, а инженеры были перегружены работой, но доставляли меньше ценности, чем могли бы.

Плюсы

• Позволяет объединить каждую технологическую команду и выстроить образцовую коммуникацию между ее членами.
• Dev-менеджеры (руководители разработки), скорее всего, являются техническими экспертами в своей дисциплине.
• Просто настроить; структура кажется интуитивно понятной, когда команды совсем крошечные (по 2–3 человека). Часто этот вариант предпочитают люди, которые вообще не имеют представления о том, как должны строиться инженерные команды.
• Обычно предполагает довольно четкое распределение обязанностей в команде.
• Легко масштабировать на новые технологические направления.
• Проще проводить собеседования с новыми сотрудниками, так как они общаются с тем же менеджером, с которым будут работать, что помогает формировать лучшую культуру в командах.

Минусы

• С высокой вероятностью порождает местничество (трайбализм) в технической организации, поскольку каждый член команды идентифицирует себя только с одной узкой группой. Это ведет к менталитету «МЫ против НИХ».
• Иногда этот подход применяется без инженерного менеджера (Engineering Manager), и командой управляет продакт-менеджер или деливери-менеджер, что означает нулевой карьерный рост для разработчиков и слабый фокус на технологиях. Команды начинают работать только на фичи (feature-driven), а инженеры превращаются в бездумных кодеров (code monkeys).
• Создает изолированные колодцы (silos) внутри организации и бесконечные зависимости, поскольку продукты часто требуют реализации на нескольких платформах. Командам приходится полагаться друг на друга и ждать друг друга, имея при этом разные приоритеты.
• Слишком много направлений и проектов внутри одной команды, так как каждый член команды, скорее всего, работает над чем-то своим.
• Иногда члены команды понятия не имеют, над чем работают их коллеги, несмотря на ежедневные апдейты на стендапах. Им просто все равно.
• Сложнее координировать кроссплатформенные релизы.
• Продакт-менеджеры, деливери-менеджеры и скрам-мастера становятся «бутылочным горлышком», так как им приходится жонглировать множеством заказчиков и пытаться координировать кучу проектов силами нескольких инженеров одновременно.
• Отсутствие понимания того, что и как делают другие команды, с минимальными шансами получить помощь извне.
• Людям сложнее вовлекаться в любые другие сферы бизнеса, кроме той, которой занимается их команда. Инженерам практически невозможно изучать новые технологии и области, в которых они еще не являются экспертами.
• Меньше возможностей для обмена знаниями и освоения нового, например, попробовать себя в роли лидера команды, поучаствовать в других проектах или примерить новые роли.
• Сложнее проявить инициативу, особенно когда в команде доминируют авторитетные или эгоистичные senior-разработчики.
• Ограниченная масштабируемость при необходимости расширения штата. Ситуация, когда у одного менеджера более 7 подчиненных, становится проблематичной. Это парализует команду, а если создать еще одну (например, две веб-команды), вы получите двух веб-менеджеров, действия которых, скорее всего, не будут согласованы.

Кросс-функциональные команды с техническими менеджерами (Cross-functional teams)

Нажмите Enter или кликните, чтобы открыть изображение в полном размере

Такая схема очень распространена в «agile-среде», но она несет в себе множество вызовов и проблем. Я бы поспорил с тем, что, несмотря на свой современный вид, она является шагом назад по сравнению с однодисциплинарными командами с техническими менеджерами, о которых я говорил ранее. Она собрала в себе худшее из всех миров, но при этом заставляет высшее руководство чувствовать себя хорошо — вероятно, поэтому она так популярна. Слишком популярна.

Плюсы

• Легко настроить.
• Очень легко масштабировать по горизонтали, просто добавляя новые команды.
• Легко находить менеджеров, так как им не нужно быть техническими экспертами. Они сфокусированы только на людях, а не на технологиях.
• Легко привлекать подрядчиков (контракторов) и распределять их в конкретную группу.
• Создает четкие зоны ответственности и фокуса, понятные для людей извне инженерной команды.

Минусы

• Часто слишком много разных менеджеров, вовлеченных в agile-команду, создают путаницу в отношении зон ответственности и лидерства. Особенно когда возникают технические споры и кому-то нужно принять непопулярное решение.
• Менеджеры часто превращаются просто в «people-менеджеров» (кадровиков), а их технический опыт становится невостребованным и забывается. Большинство инженерных менеджеров когда-то сами писали код, поэтому для них это может быть особенно болезненно.
• Переход инженера из одной команды в другую похож на устройство на новую работу: новый менеджер, новые процессы, а иногда и новые приложения. Среда может сильно отличаться, и это часто дается тяжело как инженерам, так и компании.
• Набор навыков команды становится жестким и предопределенным.
• Иногда этот подход существует без инженерного менеджера, когда командой управляет продакт или деливери-специалист, что означает отсутствие карьерного роста и слабый фокус на технологиях.
• Практически нет стимулов для согласования инженерных практик между командами, особенно если каждая работает над своим приложением. Это может привести к разным стандартам, лишним накладным расходам и различиям в методах работы.
• Формируется групповой менталитет, когда любой человек вне команды воспринимается как чужак, а инженеры часто оказываются оторваны от своих коллег, работающих над той же кодовой базой и технологиями в других группах.
• Меньше возможностей общаться с другими инженерами и оспаривать решения, которые могут навредить компании в долгосрочной перспективе.
• Менеджеры — это бывшие разработчики, у которых, скорее всего, одна специализация, а их команды при этом кросс-функциональны. Это ограничивает их технический вклад и может приводить к предвзятости.
• Разработчики часто понятия не имеют, над чем работают другие команды, как и их коллеги по той же специализации. Это можно решить, но обычно данный вопрос пускают на самотек.
• Такая структура очень часто приводит к идее нанимать исключительно full-stack инженеров, чтобы решить часть проблем (но это порождает новые).
• Процесс найма выглядит странно, так как кандидата могут собеседовать люди, с которыми он никогда не будет тесно работать. Это очень плохо.

Это упрощенная версия модели Spotify, которую вам, вероятно, не стоит рассматривать, если только вы не огромная корпорация, которая может себе это позволить. В Spotify признали, что у них эта модель тоже не работает, так что это должно быть хорошим сигналом, если вы раздумываете над ее внедрением. Кроме того, их терминология (squads, alliances, tribes, chapters — отряды, альянсы, племена, гильдии) звучит для меня довольно странно.

То, что действительно работает — Самоуправляемые кросс-функциональные команды (Self-managed cross-functional teams)

Нажмите Enter или кликните, чтобы открыть изображение в полном размере

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

«Каждый менеджер должен быть в состоянии накормить своих непосредственных подчиненных двумя большими пиццами» — следуйте этому правилу, и команда будет расти естественно и предсказуемо.

Эта структура была протестирована командой из более чем 70 инженеров на 15 рабочих направлениях (с небольшими доработками). Она также тестировалась на небольших группах (например, 6 инженеров и 2 направления) и в любых промежуточных вариантах. Конечно, все усложнится, если применить ее к технологической организации численностью более 100 сотрудников. Тем не менее, масштабировать ее не составит труда, если разделить структуру на более мелкие подразделения на основе продуктов или приложений, но все зависит от конкретных обстоятельств.

Примечания к диаграмме для прояснения нескольких моментов:

• Темно-желтые блоки в каждом направлении (stream) = тимлид (team lead).
• Инженерная группа, группы продукта и дизайна подчиняются одному и тому же менеджеру для создания прочной синергии между различными дисциплинами, но во многих случаях на практике это неосуществимо.
• На диаграмме нет QA (тестировщиков), поэтому имеет смысл добавлять их в каждое рабочее направление наравне с остальными участниками. Я бы также добавил QA-менеджера для руководства ими.

Плюсы

• Инженерные менеджеры видят картину по нескольким рабочим направлениям в целом, могут выявлять проблемы и помогать в различных проектах.
• Проще перемещать людей между командами туда, где они действительно нужны (будь то временно или на постоянной основе). При этом вообще не требуется менять линейного менеджера.
• Навыки или стремления людей можно лучше сопоставить с проектами (направлениями) из дорожной карты.
• Менеджеры, скорее всего, будут экспертами в той технологии, для руководства которой их наняли. Это делает их не просто people-менеджерами, но и позволяет помогать в технических вопросах и направлять ключевые решения.
• Каждый инженер чувствует себя частью как своей agile-команды, так и технологической группы. Это предотвращает изоляцию задач и местничество.
• Проще проводить собеседования с новыми сотрудниками, так как они общаются с тем же нанимающим менеджером, что помогает формировать лучшую культуру в инженерных командах.
• Легко сегментировать дисциплины на более мелкие команды. Например, дизайн может разделиться на UI-команду и команду исследований (Research), каждая со своим менеджером, подчиняющимся Head of UI/UX.
• Менеджеры видят общую картину происходящего во всей инженерной группе, а не фокусируются только на одной маленькой части или одном проекте.
• Проще привлекать подрядчиков, так как они привязаны к технологии и станут частью той же платформенной группы. Их также легче перемещать между agile-командами.
• Менеджеры могут учитывать не только технологии, но и человеческий фактор в своей команде. Это позволяет создать надежный путь карьерного роста и больше возможностей для развития.
• Большинство менеджеров по-прежнему остаются увлеченными разработчиками и хотят делиться своими знаниями, помогать с PR и время от времени писать код.
• Проще заменить людей или подменить их в случае изменений.
• Стимулирует обмен знаниями, обсуждение решений и взаимопомощь на всех уровнях технологического стека. PR — отличный пример того, как разработчики могут заглянуть в работу других команд.
• Плюсы значительно перевешивают минусы при создании независимых и счастливых agile-команд, способных быстро реагировать на изменения.

Минусы

• Может возникнуть путаница, так как менеджеры могут вовлекаться в несколько проектов, если у инженеров недостаточно развиты навыки самостоятельного ведения задач (ownership).
• PR из другой agile-команды могут доставлять головную боль, если они не управляются должным образом или не учитываются в планах.
• Требуется проактивность, самостоятельность и ответственность от каждого члена команды, поскольку они выступают представителями своих технологий в своих agile-командах.
• Может быть трудно получить одобрение от высшего руководства, так как им придется поступиться контролем, а этот подход требует доверия к тому, что люди являются способными инженерами, а не просто исполнителями.
• Требуется дополнительное планирование по структурированию команд время от времени (вероятно, дважды в год).
• Такая схема иногда приводит к избыточному числу инженеров в каждой agile-команде. За этим нужно следить.
• Некоторые люди будут переходить из одной agile-команды в другую чаще остальных.
• Сложнее внедрить жесткий agile-процесс «сверху вниз», если руководство, например, хочет, чтобы все работали строго по учебнику Scrum.

Нажмите Enter или кликните, чтобы открыть изображение в полном размере

Другие контрпродуктивные вещи, которые делают компании, и которые не исправит никакая красивая структура команд

• Выделенные и изолированные команды для работы с такими вещами, как дизайн-системы или Core-платформы, часто полезны, но если у вас не работает более 200 разработчиков, они вредят целям компании и хорошим инженерным практикам.
• Ставка исключительно на универсалов (full-stack разработчиков), которые умеют делать всё понемногу, при полном отсутствии фокуса на найме талантливых инженеров с глубокими знаниями в конкретных областях для развития технологий, архитектуры и эволюции цифрового продукта.
• Навязывание конкретной методологии Agile и попытка втиснуть все команды в один и тот же подход. Например, строго 2-недельный Scrum по учебнику. У разных групп разные потребности, и если руководство ожидает, что все будут работать абсолютно одинаково, все команды будут слабыми ровно настолько, насколько слабо самое неэффективное звено в цепи.
• Инженерная команда во главе с не-инженерами (например, продактами или дизайнерами) — это верный признак того, что дела пойдут плохо. Люди, которые не понимают жизнь инженера, редко могут сбалансировать разработку и приоритеты так, чтобы приносить компании реальную ценность. В большинстве случаев это приводит к одержимости фичами, когда важно только выкатить очередную задачу и просто поставить галочку.
• Компании, одержимые продуктом (product-obsessed), порождают огромное количество мусора под названием «инженерный бэклог», делая жизнь каждого невыносимой и никогда не признавая проблему, пока не станет слишком поздно.
• Компании, которые слишком сильно полагаются на дорогих подрядчиков, потенциально делая их большинством в штате инженеров, часто страдают от близорукости. Всё работает здесь и сейчас, но в будущем это дорого обойдется компании. Это признак слабого руководства, часто встречающийся в корпорациях, где деньги — единственное, что имеет значение.
• Слишком много поваров на одной кухне! Как часто вы видели команду, в которой есть деливери-, продакт- и инженерный менеджеры? А вдобавок к этому, возможно, еще дизайн-менеджер и проектные менеджеры? В крупном корпоративном мире такие команды — не редкость. Это приводит к избытку пустой болтовни при полном отсутствии результатов. Скрам-мастера и деливери-менеджеры в каждой команде не приносят никакой пользы и часто создают «бутылочное горлышко» и проблемы в общении между инженерами и продуктовой командой.

И последнее слово…

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

Получайте публикации Эндрю Винницки на почту

Присоединяйтесь к Medium бесплатно, чтобы получать обновления от автора.

Запомнить меня для быстрого входа

Пробуйте, дерзайте и не бойтесь экспериментировать. Хотя это будет непросто.

Еще несколько статей о командах и методах работы, которые могут показаться вам интересными…