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

Возможной или даже предпочтительной будет ситуация, когда функциональная команда возникает в результате самоорганизации. Команды-специалисты могут формироваться органически с целью решить общую для нескольких команд проблему. Например, возможно объединение в одну команду специалистов по непрерывной интеграции, чтобы на более высоком профессиональном уровне оказывать соответствующие услуги другим командам. Члены проектных команд могут входить в функциональную команду на условиях полной или частичной занятости, также возможна их ротация [Highsmith 2009: 272/280]. Могут создаваться команды, отвечающие за отдельные компоненты, – например, команда будет специализироваться на разработке архитектуры ПО и передавать готовую архитектуру проектным командам. В этом случае проектные команды выступают по отношению к ней в роли заказчиков [Cohn 2009: 185]. Главная причина формирования команд специалистов – повышение эффективности (в результате разделения труда).

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

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

Это противоречит изложенной здесь философии. Проектный офис не может иметь в качестве клиентов одновременно команды и топ-менеджмент. Это приводит к конфликту интересов, в результате чего обычно страдают проектные команды.

Я убежден, что за результаты проекта ответственность должны нести команды , а не менеджеры . Это означает, что топ-менеджмент должен работать с командами непосредственно или через линейных менеджеров, минуя проектный офис. Подобно системным администраторам и отделу кадров проектный офис существует для того, чтобы помогать и координировать, а не контролировать.

Организационные иерархии – необходимое зло. Они нужны, поскольку должны существовать четкие линии подчиненности между сотрудниками и владельцами компании. Иерархии – это плохо, потому что ими очень легко злоупотреблять, а это имеет ужасные последствия для потока информации. Такие выводы вытекают (теоретически) из первого принципа организационного дизайна Эмери и подтверждаются (практически) эмпирически. Пример можно найти в книге Малкольма Гладуэлла «Гении и аутсайдеры» [81], в которой он пишет о наличии сильной корреляции между авиакатастрофами и иерархическими культурами (из-за плохой коммуникации в кабине пилота) [Gladwell 2008]. Но это не значит, что иерархий быть не должно . Если бы иерархии были злом по определению, мы не наблюдали бы их повсюду в природе ( принцип иерархии):

Сложные природные явления организованы иерархически, и каждый уровень состоит из нескольких интегрированных систем [82].

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

Цель создания организации – снизить необходимое количество коммуникации и координации; поэтому организация сама по себе представляет собой радикальный способ решить проблему коммуникации…Организации с древовидной структурой возникают как реакция на потребность структурировать полномочия и ответственность. Поскольку невозможно одновременно служить двум хозяевам, организации и приобретают древовидную структуру. Но каналы, по которым осуществляется коммуникация, не до конца подчиняются налагаемым этой структурой ограничениям, поэтому организационное древо лишь весьма приблизительно отражает реальные процессы коммуникации, которая по своей природе будет сетевой [83].

Нам необходимо оптимальное переплетение формальной иерархической и неформальной сетевой структур [Augustine 2005: 48]. Менеджеры должны понимать, что информация движется в первую очередь по сетевой структуре, а не по иерархическим линиям. Но не нужно пытаться заблокировать или контролировать неформальные потоки информации. Наоборот, им следует всячески способствовать. Иерархия определяет распределение полномочий; роль сетевой структуры – гарантировать эффективную коммуникацию (рис. 13.9).

Организационный психолог Эллиот Жак, автор концепции реквизитной организации, в своих работах указывает, что у иерархий есть полезные функции, хотя их структура обычно оставляет желать лучшего [Jaques 1998]. Важное требование для каждого уровня иерархии – он должен привносить в организационную структуру дополнительную ценность. Подобно тому, как каждый более высокий уровень в иерархических структурах, существующих в природе, ведет к появлению новых эмерджентных свойств, которых не было у более низких уровней, так и каждый новый уровень в организационной структуре должен выполнять функцию, которая не выполняется на более низких уровнях.

В качестве примера Жак приводит разные горизонты планирования для разных уровней организации [Jaques 1999]. Проблемы, решение которых занимает от одного дня до трех месяцев, находятся в ведении самого нижнего уровня; второй уровень занимается вопросами с горизонтом планирования от трех до двенадцати месяцев; на третьем уровне решаются вопросы с горизонтом планирования от одного года до трех лет и так далее. У проектных команд (обычно) нет времени раздумывать о том, что необходимо для того, чтобы компания и через пять лет оставалась успешной. Есть и другие примеры: наем сотрудников, создание стратегических альянсов, сведение бюджетов – все это задачи, которыми проектные команды, как правило, сами не занимаются. Правда, стоит отметить, что не все эксперты в области менеджмента согласны с таким подходом. Некоторые из них пишут о том, что даже президенты компаний иногда вынуждены заниматься повседневными проблемами [Mintzberg 2005: 110].