Дженнифер Грин

почему же многие руководители собирают группы «сильных личностей», вместо того чтобы создавать реальные команды, в которых люди плодотворно сотрудничают?
Попробуйте поставить себя на место такого менеджера. Взгляните на команду как на своего рода «черный ящик», создающий программное обеспечение. Вы говорите программистам, что хотите получить, ждете несколько дней, и программное обеспечение появляется на свет. Если один из разработчиков готов трудиться допоздна и в выходные, то он сразу привлечет к себе ваше внимание своим энтузиазмом. Это подарок для вас как для руководителя: сваливайте всю работу на него, и она будет сделана. Затем воздайте этому человеку должное, и, возможно, другим придется начать работать таким же образом.
Похоже, чем сильнее ваше давление на команду, тем выше отдача от нее. Чем щедрее вы вознаграждаете «полуночников» и тех, кто может быстрее других продраться через хаос, тем больше программ они создают. А как вы оказываете влияние на людей? Вы убеждаетесь: они знают, что им всегда предстоит сделать еще больше работы, а то, что в настоящее время ими дорабатывается, должно быть как можно быстрее «вытолкнуто» к потребителю.
Важно проявлять терпимость к этому руководителю, даже если он создал абсолютно невыносимую атмосферу, где каждый член команды чувствует: некогда думать – надо действовать. Благодаря XP мы имеем возможность увидеть, как это заставляет команду разработчиков создавать плохо спроектированное программное обеспечение, которое трудно изменить. Но руководитель так не считает.
Такой менеджер использует магическое мышление.
Если есть такое мышление, то возможно все. Команда готова взять на себя проект любой величины. О каждом новом проекте говорится, что это «просто маленькая функция» или «ничего страшного, команда справится с этим», потому что группа умных и профессиональных разработчиков может добиться чего угодно. Неважно, сколько работы они выполнили на этой неделе. Наверняка на следующей они способны взвалить на себя еще больше. Менеджер всегда может возложить дополнительную задачу на плечи команды, и она обязательно будет сделана, не повлияв на какие-либо другие работы. Если считается вполне нормальным, когда команде приходится пахать по 20 часов в сутки или несколько разработчиков проводят в офисе выходные, – то они стремятся выполнить свою работу. Действительно, как по волшебству.

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

Теория ограничений утверждает: каждый перегруженный рабочий процесс имеет по крайней мере одно ограничение