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

Вместо высвобождения творческого потенциала разработчиков методология аджайл иногда может подавлять его. В попытке привнести дисциплину и предсказуемость в разработку программного обеспечения первые аджайл-практики обращались к миру материального производства с вопросом: «Как добиться предсказуемости сборочной линии в разработке программного обеспечения?» В результате родился метод организации рабочего процесса канбан, который был буквально заимствован из производственной системы Toyota.

В канбан владелец продукта разбивает недельную работу на небольшие задачи, которые записываются на стикерах и прикрепляются к канбан-доске. Инженеры снимают задания с доски, выполняют работу, перемещают стикеры в колонку «Сделано», и процесс повторяется. Когда неделя заканчивается, они отчитываются о количестве выполненных задач. Разбивка сложных задач на более мелкие необходима, но есть риск, что метод канбан превратит разработчиков в сборщиков на конвейере. Как вы могли понять из прочитанного, я не поклонник такого образа мышления. На сборочной линии автозавода не найти творчества. Автомобили, которые вы производите, не предназначены для решения индивидуальных проблем. Совсем наоборот. Вы хотите, чтобы все автомобили, сходящие со сборочной линии, были одинаковыми. И вам не нужно, чтобы рабочие сборочного конвейера привносили творческие элементы – «Давайте сделаем на этом автомобиле треугольный руль!».

Это подходит для сборки автомобилей, но не для работы творческих людей. Канбан-доски напоминают мне о статье, прочитанной несколько лет назад, – она была интересной, но немного пугающей. В ней рассказывалось о китайской деревне Дафэнь, на которую приходится 60 % мирового производства картин маслом, многие из них – это копии работ великих мастеров. Это фабрика изобразительного искусства со «сборочными линиями», выпускающими выполненные вручную копии картин Винсента Ван Гога, Леонардо да Винчи, Энди Уорхола и многих других. Художники работают в бригадах. Каждый мастер идет по проходу между мольбертами и наносит несколько мазков на каждый холст. Следующий добавляет еще один элемент… В Дафэне работают более 8000 художников, и они выпускают от трех до пяти миллионов картин в год. Превращение Моне в деньги – это довольно хитроумный трюк. Но я был потрясен, когда прочитал о Дафэне: меня оскорбляло то, что компании нанимают творческих людей, а затем полностью изгоняют творчество из их работы.

Тем не менее это именно то, что некоторые компании делают с разработчиками. Они нанимают таланты, а затем засовывают их в офисы открытого типа, где они строчат стереотипные программы, вытаскивая билетики с канбан-доски. Мне часто жалуются, что трудно найти отличных разработчиков, а я в ответ говорю, что это и немудрено, если с ними обращаются как с рабочими сборочного конвейера.

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

Мы, как руководители, привыкли к рабочим дням, заполненным встречами, и часто ожидаем, что у всех в компании одинаковый график. Это то, что Пол Грэм, соучредитель Y Combinator, называет «распорядком менеджера», очень эффективным для сотрудников, чья основная работа – это взаимодействие с другими людьми. Деление дня на одночасовые блоки – это метод, который позволяет координировать работу множества людей. Просто добавьте встречу в мой календарь.

Но сделать что-то с нуля обычно невозможно за один час – это требует сосредоточенности и того, что Грэм называет «распорядком создателя». Возможно, вы слышали о потоке – это состояние, когда человек сосредотачивается на проблеме и решает ее максимально креативно. Авторы, художники, музыканты и даже повара говорят о потоке. Это состояние ума, когда все складывается. А еще поток требует постоянной концентрации. Даже одна встреча может разрушить состояние потока. Грэм говорит: «Каждый тип распорядка прекрасно работает сам по себе. Проблемы возникают, когда они сталкиваются. Поскольку большинство влиятельных людей работают по распорядку менеджера, они в состоянии – если захотят – заставить каждого работать аналогичным образом. Но те из них, кто поумнее, сдерживают себя, если знают, что некоторым подчиненным нужны для работы более длинные интервалы времени».

Поэтому неудивительно, что ежедневные летучки могут нарушать поток. Какое соотношение состояния потока и встреч лучше всего подходит вашей организации? Почему бы вам… не спросить своего разработчика?

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