довольно интересный пример более вдумчивой альтернативы гиперактивному коллективному разуму. Через несколько месяцев после выхода интервью я получил письмо, по старинке отпечатанное на бумаге. Его доставили в мой кабинет в Джорджтаунском университете. Автором письма оказался Грег Вудворд, программист и руководитель, много лет проработавший в Кремниевой долине. Он писал, что только что прослушал мое интервью и особый интерес у него вызвало наше обсуждение гибких техник управления. Грег утверждал, что если я хочу в полной мере осознать, каким потенциалом обладают оптимизированные рабочие процессы, то мне необходимо узнать о проекте по внедрению программного обеспечения, которым Грег в тот момент руководил. Они внедряли методологию, «которая позволяла свести все техники гибкого управления воедино и выжать из них максимум». Этот процесс был очень метко окрещен «экстремальным программированием», и он просто потряс мое воображение.
Вудворд начал писать коды и управлять командами разработчиков в Кремниевой долине в середине 1990-х, после того как получил в Стэнфордском университете докторскую степень в области технического проектирования. Свою диссертацию он посвятил эффективному алгоритму, который позволял моделировать физическую среду, аналогичную среде космической челночной программы НАСА. Первое десятилетие работы в отделе программирования, когда сотрудники захлебывались в бесконечных графиках и изучали технические спецификации толщиной с роман, он описывает как «обескураживающее». В 2005 году Грег задумался о том, чтобы сделать работу программиста более эффективной. И получил работу в компании Pivotal Labs. В Кремниевой долине сотрудники этой организации имели репутацию чудаков, которые тем не менее были невероятно эффективными в создании программных кодов. Свои методы они называли «экстремальным программированием» (сокращенно ХР). Как объяснил мне Вудворд, эта технология беспрестанно оптимизируется. «ХР вобрало в себя лучшие практики разработки программного обеспечения, — отмечает он. — Их постоянно оттачивают и отказываются от всего, что не работает». Вудворд стал поклонником этого метода. Проработав на Pivotal семь лет, он применял приемы ХР в каждой компании, где работал после этого.
Вот некоторые (но не все) идеи, которые лежат в основе подхода ХР. Команды, работающие над крупными проектами, обычно делят на группы поменьше, как правило не более десяти человек. В век, когда удаленная работа становится все более популярной, команда разработчиков трудится в едином физическом пространстве. Предпочтение отдается личному общению, а не цифровым средствам связи. «Мы редко проверяем электронную почту в течение дня, — рассказал мне Вудворд, когда мы обсуждали команду, которой он тогда управлял. — Иногда мои сотрудники не заглядывают в свои ящики в течение нескольких дней». Если вам нужно кого-то о чем-то спросить, вы ждете, пока этот человек не сделает паузу в работе, и тогда подходите и спрашиваете. Подобные беседы, как говорит Вудворд, «в сто раз эффективнее электронных писем».
От многих разработчиков программного обеспечения я часто слышал жалобы, что с помощью электронных средств связи их отвлекают сотрудники других отделов — например, маркетологи — или клиенты. В результате регулярные помехи не дают им сосредоточиться на создании прекрасных программных продуктов. Я спросил у Вудворда, как решает эту проблему метод ХР. «Руководитель проекта становится связующим звеном между командой и сотрудниками других отделов или заказчиками, — объяснил тот. — Он обучает [посторонних людей] передавать запросы о новых функциях, отчеты об ошибках и другую информацию через руководителя проекта… Команда разработчиков трудится под его прикрытием». Руководитель проекта по итогам общения с третьими лицами выделяет задачи, которые включает в общую очередь. Члены команды обрабатывают эти задачи по очереди. Когда очередная работа выполнена, они решают, за что взяться дальше.
Один из особо радикальных подходов, которые применяет ХР, — это парное программирование. Разработчики трудятся в группах по двое за одним компьютером. «Непосвященные руководители могут решить, что если два разработчика будут сидеть за одной машиной, то вы получите в итоге только 50% эффективности, — отмечает Вудворд. — А на самом деле эффективность в 3–4 раза больше, чем обычно». Он выяснил, что самый важный этап в программировании — это не механический ввод команд в компьютер, а разработка базового решения, которое затем преобразуется в код. Если вы работаете в паре, то можете обмениваться идеями, находить недостатки и смотреть на задачи под новым углом в поисках более удачного решения.
Чтобы проиллюстрировать эту концепцию, Вудворд рассказал мне одну историю, которая произошла за пару недель до нашего с ним разговора. В тот момент он размышлял о программной функции, которая позволила бы «резко увеличить продуктивность». Он обдумывал эту идею, пока ехал на работу в свой офис в Сан-Франциско. «К тому моменту, когда я добрался, я решил, что стратегия по разработке такой программной функции у меня практически готова». Вудворд сел вместе с партнером, с которым ему предстояло в тот день работать, и начал объяснять ему свою идею. Обсуждение длилось 45 минут. Во время этого разговора партнер Вудворда нашел несколько нестыковок в его стратегии и выявил «пограничные случаи», когда задумки могли не оправдаться в полной мере. Затем партнеру Вудворда пришла в голову блестящая мысль, как можно избавиться от определенного вида ошибок и исключить худшие сценарии. К полудню новая оптимизированная версия системы была готова. Вудворд отметил: «Я уверен, что, если бы я следовал тому плану, который придумал, пока ехал в офис, разработка заняла бы у меня несколько дней. Значит, продуктивность выросла в 3–4 раза». Оценивая, насколько лучше стали трудиться программисты, работая в парах, Вудворд рассыпается в похвалах: «Метод невероятно эффективен».
Еще одна причина продуктивности экстремального программирования — интенсивность работы. Если вы работаете в паре, вы сосредоточены на том, чем заняты. Вы не можете начать проверять почту или бездумно лазить в интернете, поскольку ваш партнер будет сидеть, раздражаться и ждать, когда вы вернетесь к совместной работе [170]. Более того, оказавшись в среде, которая предполагает, что вы посвятите все свое внимание насущной проблеме, в условиях, когда руководитель проекта защищает вас от отвлекающих факторов, вы проводите рабочий день за решением сложных задач. Методы ХР — наиболее близкие к идеалу и успешно применяемые приемы полного погружения в работу.
Еще один основной принцип ХР помимо интенсивной работы — «размеренность». Большинство тех, кто придерживается этого метода, трудятся стандартные 40 часов в неделю (в отличие от принятых в Кремниевой долине норм в 70–80 часов). «Метод ХР предполагает, что сотрудник приходит, усердно работает в течение восьми часов, затем идет домой и думает о других вещах», — объясняет Вудворд. Это не акт щедрости, а признание факта, что человеческий разум имеет свой лимит. «Обычный инженер в компании, которая не использует методы ХР, может заниматься своими прямыми обязанностями всего 2–3 часа в день. Все остальное время он проводит в интернете или проверяет почту». Когда
