Привет, Хабр!
Мы хотим поделиться подходом к формированию успешной продуктовой команды. В построении и развитии продуктовой команды есть свои законы, о которых можно почитать здесь. Но знание теорем бесполезно без навыков их применения в реальном мире. Поэтому сфокусируемся на практических кейсах.
Наш опыт показывает, что равными факторами являются укомплектованность команды как в функциональном плане, так и с точки зрения интеллектуальных и социальных качеств. Статья будет полезна тем, кто занимается построением или оптимизацией работы кросс-функциональных команд.
Разработка IT-решений
В компаниях встречаются два подхода к организации команд разработки: функциональные команды и кросс-функциональные команды.
В первом случае предполагается, что образуются команды с одинаковым набором экспертиз: команда backend-разработчиков, команда frontend-разработчиков, команда data science и т. д. Во втором случае команды формируются из людей с различными компетенциями для достижения некоторой бизнес-цели. Бизнес-целью может являться как создание и развитие продукта, так и выполнение определенного проекта.
Легенды гласят, что кросс-функциональные команды появились в далеких 1950-х годах. Компания Nothwestern Mutual организовала кросс-функциональную команду для исследования перспектив рынка персональных компьютеров.
В обоих подходах есть свои преимущества и недостатки. К преимуществам кросс-функционального подхода относятся:
Тесная связь между функциями
Это одно из главных преимуществ кросс-функциональных команд. Специалисты с разной экспертизой работают вместе для достижения бизнес-целей. Тесное взаимодействие разных функций позволяет эффективно декомпозировать задачи, осуществлять точное планирование работы команды, оперативно выставлять приоритеты и быстро принимать решения.
Взвешенность решений
При принятии решения есть возможность опереться на мнения людей с разной экспертизой, что обеспечивает широту взгляда на проблему.
Отсутствие иерархии
Как правило в кросс-функциональной команде горизонтальная иерархия, то есть нет боссов, а есть процессы и ритуалы, которые позволяют расставлять приоритеты и принимать решения.
К основному недостатку кросс-функционального подхода можно отнести распределённость специалистов одной функции по независимым командам. Это комплексный недостаток, который влечет за собой несколько проблем.
Аккумуляция экспертизы
Распределённость может оказать влияние на накопление экспертизы внутри функции. Это можно наблюдать в независимых кросс-функциональных командах, когда одни и те же задачи решаются по несколько раз несколькими командами. Поэтому межкомандные процессы внутри функций очень важны в случае кросс-функционального подхода.
Взвешенность решений
Вы можете сейчас нас остановить и адресовать на несколько строк выше, где взвешенность решений отмечалось в положительную сторону. Всё так и есть. Но в данном случае может пострадать глубина решений. В кросс-функциональной команде (как правило) несколько человек одной функции. И если возникает узкий вопрос, для решения которого необходимы глубокие знания области, то экспертизы специалистов может просто не хватить. Кроме того, в команде могут быть новички компании, которые могут не владеть устоявшимися практиками и принять ошибочное решение. В обоих случаях крайне важно иметь инструменты по эскалации проблемных вопросов на специалистов своих функций, важно иметь доступ к комьюнити функции, где можно получить ответ на сложные вопросы.
Роли кросс-функциональных команд
Выделяют типы кросс-функциональных команд:
продуктовая команда — занимается развитием и поддержкой определенного продукта;
проектная команда — занимается выполнением определенного проекта.
Наш опыт больше связан с продуктами и кросс-функциональными командами, которые их развивают. Поэтому далее будем повествовать про продуктовые команды. Для проектных команд все выводы верны с точностью до соотнесения соответствующих ролей.
В продуктовых командах выделяют типичные роли, выполняющие определенный набор функций:
владелец продукта — отвечает за продукт, контролирует метрики, приоритизирует задачи, проводит внешние коммуникации;
проджект-менеджер — контролирует работу команды, совместно с экспертами проводит декомпозицию задач и планирование, распределяет нагрузку;
скрам-мастер — отвечает за эффективность команды, за соблюдение регламентов, трекинг выполнения работ над продуктом;
бизнес аналитик — выполняет анализ данных вокруг продукта, генерирует гипотезы, рассчитывает эффект, анализирует документацию;
системный аналитик — отвечает за связь бизнеса и разработки, описывает задачи для разработки, проектирует решения;
технический лидер (архитектор решений) — проектирует архитектуру сервисов и приложений, отвечает за технические решения в команде;
разработчики (dev, ds, de и т.д.) — специализированная разработка согласно экспертизе;
тестировщики — тестирование сервисов, приложений, составных частей продукта.
Возможны также роли: сейл-менеджер, аккаунт-менеджеры, дизайнеры, девопсы и др.
Не существует единого, оптимального состава продуктовой команды. Состав определяется характером продукта, возможностями компании и принятой в компании типичной структуры команды. Мы знаем компании, где есть скрам-мастера и где функции скрам-мастера возложены на проджект-менеджера. Есть примеры, где в командах есть системные аналитики и где соответствующие функции выполняют разработчики.
Случаи из практики
№1
Продуктовая команда ведет разработку нескольких высоконагруженных и архитектурно-сложных IT-решений. В один момент сложилась такая конфигурация, в которой не было человека, который мог бы взять функции технического лидера. Но необходимо было постоянно принимать архитектурные решения и делать прогнозы по срокам разработки. Естественным образом архитектурные функции технического лидера распределились по разработчикам, а функции по срокам взял на себя владелец продукта. Догадливый читатель уже понял, что ничего хорошего не вышло.
Команде не удавалось завершить разработку продуктов. Каждый разработчик в меру своих возможностей реализовывал сервисы на тех инструментах, на которых умел. Команда вместо готовых продуктов получила совокупность слабо поддерживаемых сервисов, написанных с использованием различных технологий. Кроме того, страдали сроки реализации. Владельцу продукта не удавалось давать точные прогнозы в связи с отсутствием поддержки экспертного мнения.
Из мертвой петли команду сумел вывести пришедший технический лидер, который начал качественно выполнять необходимые команде функции.
№2
В продуктовой команде работали несколько разработчиков. Возникла необходимость назначить среди них лида для организации работы, проработки технических решений и планирования. Под эту роль был выбран самый опытный разработчик, который помимо работы над задачами стал выполнять роль лида.
Кто работал в продуктовых командах, знает, насколько важен баланс между менеджерами и инженерами. Бизнес хочет новую функциональность, протестировать новое решение, добавить новых фичей в продукт и так далее. Важная задача инженеров-лидов — приземлять желания бизнеса, трезво оценивать возможности команды и, самое главное, доступно доносить свою точку зрению менеджерам.
Назначенный лид был высоким экспертом своей области, но не в достаточной мере уравновешивал амбиции бизнеса. Это приводило к нескольким неприятным вещам:
постоянная смена приоритетов (у владельца продукта постоянно появлялись новые заказчики и новые идеи, которые лиду не удавалось приземлить);
много работы в стол (многие идеи владельца продукта не фильтровались лидом, а рассматривались как руководство к действию).
Проблемы начали исправляться путем большей синхронизации менеджеров команды и инженеров. Постепенно лид понял, чего же от него хотят, и что быть лидом не так и плохо.
Кстати, тут можно найти кое что полезное о лидах.
№3
Несколько кросс-функциональных команд ведут разработку над IT-платформой. В каждой команде есть владелец продукта, некоторое количество бэкенд- и фронтенд-разработчиков, тестировщики и системный аналитик. Разработка велась по классическому scrum со всеми необходимыми ритуаламии и артефактами. Где же тогда скрам-мастер, можете спросить вы. Или, может быть, проджект-менеджер?
Особенностью данных команд было то, что функции скрам-мастера и проджект-менеджера единолично выполняли владельцы продуктов. При этом не забывая и про свои обязанности. Команды работали как часы. Во многом такое совмещение стало возможным благодаря отлаженным рабочим процессам, хорошей организации от CPO и политики hr по поиску соответствующих специалистов.
Обсуждая состав команды, мы обычно оперируем понятием роль. Но примеры выше говорят о том, что роли в продуктовой команде можно понимать по-разному. А основной фокус уделяется на наличие или отсутствие функции.
Наконец, попробуем разобраться: как все-таки успешно определять состав продуктовой команды?
Определение состава команды
В средневзвешенной продуктовой команде примерно такой ролевой состав:
Мы изобразили условно одного технического лидера, хотя вполне часто в команде могут быть технические лидеры по каждой инженерной функции.
Равновесие между менеджментом команды и инженерами — важный фактор, но не меньший вес имеют связующие звенья в лице проджект-менеджера, скрам-мастера и системного аналитика.
Мы упоминали, что в компаниях часто фиксированная командная структура с определенным набором ролей, которым соответствует определенный набор функций. Сопоставление ролям функций смещается от компании к компании. Функциями оперировать представляется корректнее, так как они являются атомарными единицами.
Функции в продуктовой команде
Выделим некоторые инженерные функции:
коммуникация с менеджерами команды
проектирование архитектуры решений
системный анализ продукта
развитие и поддержка инфраструктуры
поддержание стандартов разработки и качества кода
и другие.
В пример мы привели именно эти функции потому, что их нельзя реализовать через коллективное мнение. Так, например, декомпозицию задачи и оценку сроков ее частей можно эффективно выполнить командой на грумминге. Но проектирование сервисов или коммуникация с менеджерами требует отдельных навыков и «мнение толпы» не может здесь быть равнозначной заменой. Обычно функции коммуникации и проектирования ложатся на технического лидера команды, но иногда и на опытных разработчиков.
Инфраструктурой часто занимаются DevOps специалисты, но бывает, что эта функция принадлежит разработчикам. Системный анализ, на наш взгляд, одна из важнейших составных функций. Она включает анализ задачи на предмет: оценка изменений системы, влияние на подсистемы, изменение модели данных, составление описания для разработчиков и прочее. Часто она отдается на откуп разработчикам, что может сказываться на качестве комплексных задач, которые затрагивают различные подсистемы.
Примеры менеджерских функций:
приоритизация задач
планирование работ
трекинг разработки решений
мониторинг достижения целей командой
коммуникации с клиентами/заказчиками
представление результатов команды
и другие.
Достаточно ли наличие необходимых функций в команде для успеха? Полагаем, что необходимо, но не всегда достаточно. Важно уделить внимание социально-интеллектуальным ролям. Здесь уместно вспомнить о классификации ролей в командах.
Классификация девяти ролей Белбина
Рэймонд Мередит Белбин предложил модель команды. Модель состоит из трёх групп по три роли в каждой.
Интеллектуальные роли
Социальные роли
Роли действия
По мнению Р. Белбина важно, чтобы описанные 9 ролей были покрыты сотрудниками команды. Нет необходимости под каждую роль нанимать сотрудника. Владелец продукта может быть одновременно мотиватором и генератором идей, технический лидер может быть реализатором и душой компании и так далее.
Классификация Р. Белбина предлагает универсальный метод подбора состава команд. Наш опыт говорит о полезности предложенной классификации при формировании команды.
Подход к определению состава команд
Необходимо определить базисный набор инженерных и менеджерских функций продктовой команды (например, из приведенных выше), качественное выполнение которых важно для реализации продукта.
При формировании продуктовой команды необходимо, чтобы сотрудниками перекрывались как роли Р. Белбина, так и базисные инженерные и менеджерские функции:
Другими словами, в таблице выше каждый столбец должен содержать по крайней мере одну галочку.
Также предложенный способ хорошо себя проявляет при определении причины низких показателей команды. Достаточно нарисовать матрицу, слабые места или их сочетания проявятся очевидным образом.
Какой способ организации разработки выбрать?
У многих крупных компаний исторически сложилась функциональная организация разработки IT-решений. Рынок диктует свои условия и вынуждает принимать решение: либо идти по пути оптимизации издержек функционального подхода к разработке, либо идти по пути трансформации. Оптимизация издержек может включать:
создание эффективных инструментов взаимодействия между функциями;
создание инструментов оперативного принятия решений, для которых необходима экспертиза нескольких функций;
синхронизация совместимого стека технологий между функциями.
Как мы видим, все точки оптимизации — это следствие дистанцированности команд друг от друга. В какой-то мере это решаемые вопросы, и функциональный подход может подойти тем компаниям, которые пошли по пути оптимизации и добились нужных показателей по скорости и качеству разработки IT-решений.
Также функциональный подход может быть полезен стартапам на этапе становления и роста, когда штат сотрудников небольшой и издержки на взаимодействия разных функций минимальны.
Наши наблюдения показывают, что все-таки большинство компаний выбирают кросс-функциональный подход. Билайн бизнес сделал свой выбор в сторону кросс-функциональных команд.
Хотим отметить, что решения внутри продуктовых команд одной компании могут пересекаться в определенных модулях, подсистемах и тому подобном. Поэтому важно выстраивать процессы межкомандного взаимодействия. Но это совсем другая история… Мы поделимся таким опытом в одной из следующих статей.
