Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

Независимо от того, создается ли команда менеджером или путем самоорганизации, необходимо ответить на важный вопрос: «Каким именно образом люди должны быть собраны в команды?» Фактически здесь есть два варианта: объединять людей по функциональному признаку или по бизнесу .

Первый вариант предполагает, что вы собираете разработчиков вместе с разработчиками, тестировщиков вместе с тестировщиками, а проектных менеджеров вместе с другими проектными менеджерами. Такие группы называются функциональными подразделениями, а основная мотивация этого способа организации – эффективность и возможности взаимного обучения в рамках данной функции [Larman, Vodde 2009: 243]. Сотрудникам, ответственным за пользовательские истории, легче всего научиться профессии, когда они входят в состав отдела, который может так и называться: «Отдел пользовательских историй».

При объединение по бизнесу в составе команды оказываются люди, работающие над созданием одной и той же бизнес-ценности, включая создание одной и той же функциональности, одних и тех же продуктов, или работающие на одного и того же клиента. Такие команды иногда называют кросс-функциональными, потому что все сотрудники заняты в одном и том же проекте (или проектах), в результате в составе группы оказываются специалисты в широком диапазоне областей – начиная с пользовательских историй и заканчивая бинарной сборкой.

В главе 12 мы говорили, что организовать в компании хорошую коммуникацию – очень важное и чрезвычайно нелегкое дело. Поэтому данное соображение должно приниматься во внимание при выборе того или иного варианта. Кто из сотрудников наиболее часто нуждается друг в друге? Те, у кого должности называются одинаково? Или те, кто работает над одним и тем же проектом?

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

Люди, работающие над одним и тем же проектом и выполняющие разные функции, испытывают бóльшую потребность в общении друг с другом, чем люди, выполняющие одну и ту же функцию, но работающие над разными проектами (рис. 13.4). Поэтому мы можем сделать вывод, что при реализации проектов кросс-функциональные команды будут наиболее подходящим решением.

Отмечается, что организации, в которых люди организованы по функциональному признаку, страдают от чрезмерной зависимости подразделений друг от друга (иногда такие подразделения называют функциональными колодцами). Создание даже самой незначительной бизнес-ценности (например, одной характеристики продукта) требует коммуникации и координации действий множества команд [Poppendieck 2009: 68]. По этой причине наличие функциональных колодцев оборачивается высокими затратами на осуществление взаимодействий [Augustine 2005: 26].

Когда вы строите команды вокруг функциональных колодцев, а не внутри них, затраты на взаимодействие ниже, но не равны нулю. Дональд Райнертсен перечисляет три недостатка, свойственные кросс-функциональным командам: субоптимизация на уровне проектов, потери в эффективности вследствие недостаточной координации между проектами и ограниченный обмен опытом между специалистами в одной области, работающими в разных проектах [Reinertsen 1997: 104]. Таким образом, представляется, что в случае с кросс-функциональными командами расходуются дополнительные ресурсы в связи с необходимостью синхронизировать стандарты, методы и подходы в рамках одинаковых функций в организации в целом. Например, менеджеру по обеспечению качества может потребоваться больше усилий, чтобы добиться применения лучших практик в тестировании, если тестировщики и другие специалисты, отвечающие за качество, разбросаны по разным командам. Но даже в этом случае цена, которую приходится платить за кросс-функциональность, обычно ниже, чем при функциональных командах.

У кросс-функциональных команд (их также называют проектными, органическими или продуктовыми) есть еще несколько дополнительных преимуществ. Среди них эксперты называют более качественные решения в области дизайна, снижение непродуктивных затрат при передаче частично готового продукта далее по производственной цепочке, более высокую скорость реализации проектов, адаптивность, упрощенное планирование и сфокусированность на результатах [Cohn 2009: 182–188], [Larman 2009: 154].