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

Идея укрупнения: группа объектов воспринимается как единый блок. Граница этого блока немного похожа на клеточную мембрану или границу государства. Она определяет идентичность блока, состоящего из группы объектов. В зависимости от контекста мы можем игнорировать внутреннюю структуру блока либо учитывать ее [79].

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

При управлении границами команд надо обращать внимание на три аспекта: как именно структурированы команды, как соотносятся отдельные сотрудники и команды и как команды меняются со временем. В организациях, сотрудники которых находятся на высоком уровне в плане зрелости и наделены широкими полномочиями, возможен самоотбор людей в команды (см. главу 7). В такой компании вы создаете пул кандидатов на вхождение в команду, а затем предоставляете людям самим сформировать ее. Есть проекты, участвовать в которых хотят все, а есть и такие, для которых трудно найти желающих. Очень интересно со стороны наблюдать за горячими спорами, в ходе которых группа сотрудников пытается выработать правила формирования команд. Но в реальных условиях увидеть процесс самоотбора в действии удается лишь изредка. Об этой практике стоит подумать, но вы должны быть уверены, что люди действительно понимают, как правильно формировать команды. Получить на выходе команду из тридцати разработчиков и еще одну, в составе которой двадцать тестировщиков, – не самый лучший вариант. Возьмите, к примеру, какой-нибудь бойз-бенд: в теории в ее состав, конечно, может входить тридцать человек, но тогда это будет скорее хор мальчиков, и с такой численностью вряд ли они будут обладать достаточной гибкостью, чтобы оставаться в тренде индустрии развлечений, как это удается небольшим музыкальным группам. Чтобы повысить шансы команды добиться успеха, вам понадобится вначале наложить определенные ограничения на ее численный состав, необходимость включения разных специалистов и некоторые другие.

Еще одна связка, которую нужно брать в расчет, – то, как отдельные люди соотносятся с командами. Может ли один и тот же сотрудник входить более чем в одну команду? Когда людей просят уделять силы нескольким командам, это, как правило, отрицательно сказывается на продуктивности. Мик Джаггер не пытался в дополнение к The Rolling Stones подрабатывать в группе Jackson Five, и на это есть веские причины. Такие ситуации приводят к тому, что люди разрываются между разными задачами, возникает конфликт интересов, размываются обязательства и пропадает мотивация. Сделайте все возможное, чтобы конкретный сотрудник был членом только одной команды. Люди не будут эффективно действовать как часть команды, если не знают, кто в нее входит. Они могут время от времени помогать сотрудникам из других команд с их проектами или время от времени исполнить дуэт, но у каждого сотрудника должна быть только одна своя команда, в которую он возвращается с подобных заданий.

И наконец, важной темой будет жизненный цикл команд. Исследования показывают, что команды более эффективны, когда они достаточно долговечны. И не только при разработке ПО [Larman, Vodde 2009: 149/153], но и в других видах бизнеса, например в авиакомпаниях [Hackman 2002]. Так что лучше, чтобы команда существовала настолько долго, насколько это возможно, потому что для возникновения устойчивых правил и каналов связи требуется время. Оно также необходимо, чтобы люди как команда научились отличать, какая информация для них важна, а какая – нет. И еще подумайте вот о чем: какая поп-группа была самой знаменитой за всю историю? И как долго они были вместе? Больше, чем несколько лет? Я так и думал. Если ваши проекты по своей природе краткосрочны, постарайтесь сделать так, чтобы жизненные циклы команд были длиннее, чем жизненные циклы проектов. Так вы дадите одной и той же команде возможность выполнять несколько проектов один за другим.