Кросс-функциональные команды и самоорганизация в основе Agile, часть 2

В первой статье из цикла “Кросс-функциональные команды и самоорганизация в основе Agile” мы рассмотрели само понятие и явление Agile культуры, обсудили имеющиеся стереотипы и заблуждения, сформировавшиеся вокруг данного термина, а также рассмотрели принципы, лежащие в основе Agile.

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

Кросс-функциональные команды

Обращаясь к понятию кросс-функциональных команд мы часто сталкиваемся с большим количеством разночтений и отсутствием четкой определенности “кросс-функциональности”.

Термин “кросс-функциональная команда” берет корни из фреймворка Scrum. В то же время, опыт множества проектов показывает, что такой подход к формированию команд является оптимальным как с точки зрения скорости внедрения изменений, так и в плане оптимизации процесса разработки и снижения издержек — ключевых принципов подходов Kanban и Lean. Это позволяет применить данную концепцию и в рамках других Agile фреймворков.

В поисках определения данного термина, логичным будет обратиться к Scrum Guide (здесь и далее приводятся цитаты из официальной русскоязычной версии Scrum Guide):

Scrum‐команды являются самоорганизующимися и кросс-функциональными… Компетенций кросс-функциональной команды достаточно для выполнения полного объема работ. Под последним следует понимать весь комплекс работ в сочетании с оптимальным способом ее исполнения, необходимым для реализации бизнес‐ценности.

Прежде всего стоит обозначить, что сама сущность кросс-функциональной команды подразумевает активное участие в ней не только технических специалистов (Back-end, Front-end разработчиков и QA специалистов). Такая команда может и по возможности должна включать в себя бизнес-аналитиков, маркетологов, UX-дизайнеров и других специалистов, принимающих активное участие в проекте. Все это делается для достижения следующего немаловажного пункта из Scrum Guide:

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

Роли в рамках кросс-функциональной команды

Какие же роли есть в кросс-функциональной команде? Раз уж мы начали рассмотрение данной концепции на примере Scrum, предлагаю продолжить и взять за пример состав стандартной Scrum Команды:

  • Product Owner — отвечает за продукт: формирование требований, работа с roadmap и backlog продукта, планирование релизов, анализ обратной связи, общение со стейкхолдерами;
  • Scrum Master — помогает команде и PO с развитием Agile культуры: следит за следованием Scrum, фасилитирует активности, помогает устранить конфликты и препятствия;
  • Команда Разработки — специалисты в области Back-end, Front-end, Mobile dev, UX/UI, QA, BA и другие.

При этом в рамках Команды Разработки отсутствует формальное деление по “зонам ответственности” и грейдам — все являются равноценными членами команды и несут равную степень ответственности как за успехи, так и за провалы.

В некоторых командах это приводит, например, к отсутствию выделенного QA специалиста, ведь итоговое качество продукта и его соответствие ожиданиям бизнеса является ответственностью и критерием качественной работы всей команды, а не отдельно взятого специалиста. В связи с этим, широкое распространение получили такие технические практики как Test-Driven Development и Pair Programming, являющиеся частью фреймворка Extreme Programming (XP). Возможность применения практик из различных фреймворков, дополняющих базис основного— одно из главных свойств и преимуществ Agile.

Кросс-функциональный подход к формированию команды может применяться и в рамках любого другого фреймворка. Главное ограничение— размер команды. При этом оно не носит формального характера. Вы не обязаны укладываться в рекомендованный Scrum Guide размер “3–9 человек”, но всегда стоит помнить про формулу, предлагаемую нам Project Management Body of Knowledge (PMBOK):

Общее количество каналов коммуникации равно n(n-1)/2, где n — количество участников проекта.

Таким образом, для команды из 10 участников, число потенциальных каналов коммуникации будет равно 45, для 9 человек — 36, и так далее. В справедливости данной формулы не трудно убедиться. Возьмите стандартный набор инструментов коммуникации внутри команды:

  1. Вербальная коммуникация;
  2. E-mail;
  3. Мессенджер (Slack, Telegram, Skype и др.);
  4. Система управления проектом (Jira, Redmine, Asana и др.).

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

На мой взгляд, оптимальный размер команды равен 5+/-2 человека. Стоит учитывать, что в рамках Scrum роли Scrum Master’а и Product Owner’а вынесены за пределы команды разработки и не учитываются при определении размера команды.

Преимущества кросс-функционального подхода

Каковые же преимущества кросс-функциональных команд над классическими?

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

  • Быстрая проверка гипотез — имея в составе команды людей, способных реализовать стадии анализа, дизайна, разработки, тестирования и релиза отдельной фичи или всего инкремента за короткий промежуток времени (например, в течение одного Scrum спринта), мы можем быстро проверить любую гипотезу. Автоматизация стадий тестирования и деплоя (CI/CD), а также сбора ключевых метрик являются существенным подспорьем;
  • Частая поставка продукта —сбалансированный состав команды позволяет нам сделать вышеописанные этапы работы над продуктом прогнозируемыми и оперативными. То же самое относится и к перечисленным выше техническим практикам;
  • Открытость — наличие потребности в регулярном общении внутри команды способствует развитию открытости. Активности в рамках того или иного фреймворка, делающие “сеансы” такого общения обязательными и регулярными существенно ускоряют этот процесс. Главная задача Scrum Master’а или менеджера в данной ситуации — помочь членам команды избавиться от лишней скованности, развивая культуру сотрудничества и полной прозрачности, а также выступая фасилитатором встреч;
  • Равенство участников — регулярно находясь в рамках одной команды, участвуя в командных активностях, особенно таких как ретроспектива или планирование спринта в Scrum, мы развиваем культуру, в которой каждый член команды имеет право голоса, право быть услышанным. Безусловно, при обсуждении вопросов архитектуры мнение Senior разработчика и Junior’а не будут иметь равный вес, но сам факт наличия культуры, при которой Junior имеет возможность высказаться и быть услышанным, очень позитивно сказывается на эффективности команды и командной “химии”.

Собираем кросс-функциональную “команду мечты”

Конечно я не смогу дать Вам универсальный рецепт состава команды на все случаи жизни. Вместо этого я предлагаю кое-что получше — перечень инструментов и факторов, которые стоит подготовить и/или принять во внимание при формировании кросс-функциональной команды для Вашего продукта или проекта.

Следующие факторы должны помочь убедиться что все, кто нужен для работы над проектом, на борту:

  • Roadmap продукта — наличие четких целей и миссии, а также плана развития продукта на несколько месяцев/кварталов вперед является ключевым фактором для сплочения команды вокруг продукта и его Пользователей. Формирование roadmap’а, его донесение до команды, определение целей и ключевых метрик, а также внесение корректив на основе полученных данных является обязанностью Product Owner’а (в Scrum) или любого другого специалиста, занимающегося развитием продукта;
  • Backlog продукта— представляет собой ближайший отрезок roadmap’a, конвертированный в пользовательские истории (user story) или технические задачи. Его приоритизация, оценка, формирование релизов и поддержание бэклога в актуальном виде также является зоной ответственности PO, однако активное участие команды в этой работе крайне приветствуется;
  • Минимум внешних зависимостей достигается за счет кросс-функционального состава команды. Чем меньше зависимостей, блокирующих команду извне, тем меньше будет случаев несвоевременной поставки продукта и проблем с “протуханием” кода или его написанием “в стол”, вызванных, например, нехваткой QA-специалистов, задержкой со стороны дизайнеров или проблемой с процедурой релиза кода в “боевое” окружение;
  • Сбалансированный состав команды соблюдение баланса является вполне логичным требованием. Команде из 3 разработчиков нет необходимости иметь в своем составе 3 аналитиков или 2 тестировщиков. Точно так же не стоит формировать команду исключительно из Junior разработчиков. Даже при достижении полноценной кросс-функциональности, такая команда рано или поздно рискует допустить критическую для продукта ошибку, вызванную неверным выбором технологий или плохой архитектурой;
  • Общий уровень Agile культуры и осведомленности о практиках критичен для успеха команды — даже самая лучшая кросс-функциональная команда не сможет быть эффективной долгое время при постоянное смене приоритетов и скоупа работ менеджментом компании. Точно так же команда не сможет реализоваться полностью, если со стороны менеджмента будет активное препятствование любым экспериментам и ошибкам. Фактор культуры также может играть решающую роль при ротации людей между командами. Подключая в команду какого-либо специалиста, незнакомого с ключевыми практиками и ценностями Agile, мы рискуем потратить большую часть времени на его обучение, что скажется негативно не только на его личной производительности, но и на эффективности всей команды;
  • Здравый смысл — куда же без него. Прежде всего он пригодится нам, чтобы не брать в команду заведомо невостребованных специалистов или не давать полную свободу действий и решений команде, не достигшей достаточного уровня “зрелости”.

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

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

Продолжение следует…

P.S. Видео моего выступления на Krasnodar Dev Day #2, а также выступления других спикеров наконец стали доступны на официальном YouTube канале конференции. Найти его Вы можете по ссылке.

--

--

Org Design consultant, Trainer & LeSS Coach @ Agile Expat | Head of Agile Practices @ PandaDoc | Professional Scrum Master | CMI Team Coach | Kanban Coach

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Agile Expat by Denis Salnikov

Agile Expat by Denis Salnikov

Org Design consultant, Trainer & LeSS Coach @ Agile Expat | Head of Agile Practices @ PandaDoc | Professional Scrum Master | CMI Team Coach | Kanban Coach