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

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

Это непродуктивный, хотя довольно традиционный подход. Но группы по-прежнему приходят к выводу, что такое «индивидуалистское» мышление способствует созданию плохого ПО. Почему?

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

Так почему же многие руководители собирают группы «сильных личностей», вместо того чтобы создавать реальные команды, в которых люди плодотворно сотрудничают?

Попробуйте поставить себя на место такого менеджера. Взгляните на команду как на своего рода «черный ящик», создающий программное обеспечение. Вы говорите программистам, что хотите получить, ждете несколько дней, и программное обеспечение появляется на свет. Если один из разработчиков готов трудиться допоздна и в выходные, то он сразу привлечет к себе ваше внимание своим энтузиазмом. Это подарок для вас как для руководителя: сваливайте всю работу на него, и она будет сделана. Затем воздайте этому человеку должное, и, возможно, другим придется начать работать таким же образом.

Похоже, чем сильнее ваше давление на команду, тем выше отдача от нее. Чем щедрее вы вознаграждаете «полуночников» и тех, кто может быстрее других продраться через хаос, тем больше программ они создают. А как вы оказываете влияние на людей? Вы убеждаетесь: они знают, что им всегда предстоит сделать еще больше работы, а то, что в настоящее время ими дорабатывается, должно быть как можно быстрее «вытолкнуто» к потребителю.

Важно проявлять терпимость к этому руководителю, даже если он создал абсолютно невыносимую атмосферу, где каждый член команды чувствует: некогда думать – надо действовать. Благодаря XP мы имеем возможность увидеть, как это заставляет команду разработчиков создавать плохо спроектированное программное обеспечение, которое трудно изменить. Но руководитель так не считает.

Такой менеджер использует магическое мышление.

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

Но дело тут не только в менеджерах с магическим мышлением. Здесь имеет место симбиоз с героем – герой готов работать сверхурочно, творить «чудеса» ради признания, лидерства и, возможно, более высокой зарплаты. Он становится эталоном, с которым сравнивают всех других членов команды. Руководитель не хочет разбираться в том, как фактически спроектировано и написано программное обеспечение или сколько плохо проработанных временных заплаток превратились в долгосрочные решения. Таким образом, главным мерилом того, кто является наиболее ценным членом команды, становится количество отработанных часов в неделю.

Магическое мышление воспринимается хорошо. Неважно, кто вы: менеджер, «мотивировавший» команду, или «герой», который очень много работал, чтобы получить готовое программное обеспечение, – вам кажется, что вы решили серьезную проблему. Но программа, разработанная под воздействием магического мышления, вызывает больше вопросов, чем решает их: технический долг накапливается, ПО никогда не достигает состояния «полностью завершено», а качество и тестирование не всегда являются «желательными». Слишком часто появляются ошибки, которые, как правило, обнаруживают пользователи уже после выпуска продукта. В итоге команда серьезно замедляется, потому что тратит основное время на исправление этих ошибок, поддержание плохого кода, а не на создание новых объектов.

Описывая Scrum и XP, мы уже говорили о том, насколько быстро может производиться лучшее программное обеспечение теми командами, которые уделяют достаточно времени выполнению работы (через ограниченные временные итерации), проявляют способность сосредоточиться на одной задаче и создают атмосферу, в которой члены команды помогают друг другу преодолевать препятствия. Разумеется, Agile не уживается с магическим мышлением или героями-разработчиками.

Так как же избежать магического мышления?

Это одна из главных целей Lean. Вместо того чтобы рассматривать коллектив как «черный ящик», бережливое мышление поможет точно понимать, чем именно занимается команда день за днем, чтобы создать программное обеспечение. Lean-мышление заставляет вас смотреть на команду, ясно видя, что происходит, в том числе прежде, чем команда начнет работать, и после поставки готового ПО – потому что магическое мышление происходит и там тоже. Бережливое мышление помогает отринуть ту «маленькую» неправду, которую руководство сообщает команде, менеджеры – друг другу, а остальные участники – сами себе. Ведь именно эта ложь не дает создать лучшее программное обеспечение, на которое вы способны, и сделать это максимально быстро. Lean пытается избавить вас от этих фальшивок и помогает командам работать вместе, думая о том, как обеспечить реальную ценность, а не просто затратить усилия.