Постигая Agile

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

– Почему все так плохо закончилось, Тимати? – спросила Кэтрин, выходя из кабинета руководителя. – Ведь было так здорово. Что случилось?

Тимати был программистом и работал в команде почти столько же времени, сколько и Кэтрин.

– Я не знаю, – сказал он. – Похоже, все тянется вдвое дольше, чем следует.

– Я не против работать больше, – вздохнула Кэтрин. – Но возникает ощущение, что, сколько бы мы ни напрягались, мы все равно опаздываем.

– Да, – согласился Тимати. – И нам никогда не выбраться из этого замкнутого круга.

– Кэти, Тим! У вас есть минутка?

Кэтрин и Тимати переглянулись.

– Это звучит не слишком обнадеживающе, – сказала она. Дэн, руководитель, снова позвал их в свой кабинет.

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

Тимати сказал:

– Хорошо. Мы на середине спринта. Что нужно удалить?

Кэтрин бросила на него быстрый взгляд. Она знала, что добром это не кончится.

Во время разговора Дэн смотрел в свой экран. Он медленно поднял глаза на Тимати.

– Вы думаете, у вас недостаточно ресурсов, чтобы сделать работу в этом цикле?

– Ну, э-э, у нас есть четыре другие функции, и одна из них уже закончена… – забормотал Тимати.

Дэн оборвал его:

– Это отговорки. Все эти дни я не видел никого, кто бы задерживался допоздна или слишком перенапрягался. Я пришел в шесть утра – офис был пуст. Ты говоришь, что мы не можем уделить этому чуть больше времени? Это не слишком большая работа. Я мог бы и сам потихоньку писать код.

Кэтрин поняла, к чему он клонит. Она уже слышала нечто подобное, и в прошлый раз все закончилось не слишком хорошо. Буквально только что она превратила в программное обеспечение точно такие же «хорошие новости» в виде запроса от Дэна, пропуская модульные тесты и накапливая технический долг. И пользователи это заметили – если прежде их отзывы были четырех– и пятизвездочными, то теперь они упали до двух-трех звезд.

– Попросите всех сконцентрироваться и выполнить задание. Это не займет много времени, зато мы заслужим признательность всей компании.

Создание героев и магическое мышление

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

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

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

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

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