Agile-менеджмент. Лидерство и управление командами - читать онлайн книгу. Автор: Юрген Аппело cтр.№ 97

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

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

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

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

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

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

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

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

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

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

Психолог Фред Эмери различает два базовых принципа координации деятельности команд. Он называет их первым и вторым принципами организационного дизайна.

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

Второй принцип предполагает урегулирование вопроса о местонахождении холодильника самими командами, то есть команды сами заботятся о согласовании границ. На практике это выглядит как переговоры. Например, команды могут договориться решать этот вопрос путем голосования, введения оплаты за пользование холодильником, ежедневной ротации права доступа к нему или просто подбрасывая монетку. Команды могут даже назначить менеджера холодильника и наделить его полномочиями принимать решения вместо себя. В рамках данного принципа решение в конечном итоге остается за командами (рис. 13.6). (И в таком случае неформальный лидер может оказаться необходим команде для того, чтобы предотвратить бесконечные обсуждения.)

Второй принцип организационного дизайна очень напоминает решение, которое специалист по сложным системам Стюарт Кауфман описывает как «участки»: