Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

Недавно у меня был разговор с руководителем, рассматривавшим проект, для выполнения которого требовалось три года. Это был важный проект, и руководитель очень сожалел, что они не могли «бросить $100 млн на решение проблемы» и справиться с ней за год – лидеры разработчиков заявили, что прямо сейчас они не в состоянии ускорить проект даже с большим бюджетом. Затем руководитель сказал: «Держу пари, если предложить [название крупной консалтинговой фирмы] $100 млн, они сделают это». Я ответил: «Конечно, их торговый представитель скажет, что они сделают это, когда увидит $100 млн, но им тоже не удастся одолеть задачу». Вот почему крупные консалтинговые проекты никогда не укладываются в сроки и бюджет. Примечательно, что руководитель не стал спорить со мной, надо думать потому, что его опыт подтверждал мое мнение. Иногда принятие трудных решений требует времени. Но я все же предложил этому руководителю обсудить с техническими лидерами, что они могут предпринять сегодня и в ближайшие месяцы для увеличения бюджета через полгода и завершения проекта за полтора года вместо трех лет. Это разумный вопрос, и эффективный технический лидер должен знать, как ответить на него.

Даже в нынешней аджайл-среде работа по-прежнему делится между командами. Чтобы ускорить работу, менеджерам нужно либо добавлять персонал в команду (а это ведет к проблемам, описанным Бруксом), либо перераспределять работу так, чтобы команды могли выполнять ее параллельно. В любом случае это влечет за собой огромный перерасход ресурсов сначала на поиск сбалансированного распределения работы, а потом на встраивание ее частей в кодовую базу. Это классическое «замедление ради ускорения». И наконец, нужно укомплектовать команду и добиться продуктивности. Как бы то ни было, лучше всего просто позволить команде продолжить работу в краткосрочной перспективе, а в это время подумать над реорганизацией структуры команд, которая обеспечит ускорение. Существуют естественные точки остановки, где очень удобно провести переоценку и перераспределение задач (я показывал в главе 8, как клеточное деление позволяет с течением времени разделять и выращивать команды), но это надо делать не в разгар работы над проектом, особенно если намечается отставание от графика.

Ловушки методологии аджайл

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

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

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

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

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

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

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

Но сделать что-то с нуля обычно невозможно за один час – это требует сосредоточенности и того, что Грэм называет «распорядком создателя». Возможно,