Кэл Ньюпорт – Новые принципы делового общения (страница 47)

Вудворд начал писать коды и управлять командами разработчиков в Кремниевой долине в середине 1990-х, после того как получил в Стэнфордском университете докторскую степень в области технического проектирования. Свою диссертацию он посвятил эффективному алгоритму, который позволял моделировать физическую среду, аналогичную среде космической челночной программы НАСА. Первое десятилетие работы в отделе программирования, когда сотрудники захлебывались в бесконечных графиках и изучали технические спецификации толщиной с роман, он описывает как «обескураживающее». В 2005 году Грег задумался о том, чтобы сделать работу программиста более эффективной. И получил работу в компании Pivotal Labs. В Кремниевой долине сотрудники этой организации имели репутацию чудаков, которые тем не менее были невероятно эффективными в создании программных кодов. Свои методы они называли «экстремальным программированием» (сокращенно ХР). Как объяснил мне Вудворд, эта технология беспрестанно оптимизируется. «ХР вобрало в себя лучшие практики разработки программного обеспечения, — отмечает он. — Их постоянно оттачивают и отказываются от всего, что не работает». Вудворд стал поклонником этого метода. Проработав на Pivotal семь лет, он применял приемы ХР в каждой компании, где работал после этого.

Вот некоторые (но не все) идеи, которые лежат в основе подхода ХР. Команды, работающие над крупными проектами, обычно делят на группы поменьше, как правило не более десяти человек. В век, когда удаленная работа становится все более популярной, команда разработчиков трудится в едином физическом пространстве. Предпочтение отдается личному общению, а не цифровым средствам связи. «Мы редко проверяем электронную почту в течение дня, — рассказал мне Вудворд, когда мы обсуждали команду, которой он тогда управлял. — Иногда мои сотрудники не заглядывают в свои ящики в течение нескольких дней». Если вам нужно кого-то о чем-то спросить, вы ждете, пока этот человек не сделает паузу в работе, и тогда подходите и спрашиваете. Подобные беседы, как говорит Вудворд, «в сто раз эффективнее электронных писем».

От многих разработчиков программного обеспечения я часто слышал жалобы, что с помощью электронных средств связи их отвлекают сотрудники других отделов — например, маркетологи — или клиенты. В результате регулярные помехи не дают им сосредоточиться на создании прекрасных программных продуктов. Я спросил у Вудворда, как решает эту проблему метод ХР. «Руководитель проекта становится связующим звеном между командой и сотрудниками других отделов или заказчиками, — объяснил тот. — Он обучает [посторонних людей] передавать запросы о новых функциях, отчеты об ошибках и другую информацию через руководителя проекта… Команда разработчиков трудится под его прикрытием». Руководитель проекта по итогам общения с третьими лицами выделяет задачи, которые включает в общую очередь. Члены команды обрабатывают эти задачи по очереди. Когда очередная работа выполнена, они решают, за что взяться дальше.

Один из особо радикальных подходов, которые применяет ХР, — это парное программирование. Разработчики трудятся в группах по двое за одним компьютером. «Непосвященные руководители могут решить, что если два разработчика будут сидеть за одной машиной, то вы получите в итоге только 50% эффективности, — отмечает Вудворд. — А на самом деле эффективность в 3–4 раза больше, чем обычно». Он выяснил, что самый важный этап в программировании — это не механический ввод команд в компьютер, а разработка базового решения, которое затем преобразуется в код. Если вы работаете в паре, то можете обмениваться идеями, находить недостатки и смотреть на задачи под новым углом в поисках более удачного решения.

Чтобы проиллюстрировать эту концепцию, Вудворд рассказал мне одну историю, которая произошла за пару недель до нашего с ним разговора. В тот момент он размышлял о программной функции, которая позволила бы «резко увеличить продуктивность». Он обдумывал эту идею, пока ехал на работу в свой офис в Сан-Франциско. «К тому моменту, когда я добрался, я решил, что стратегия по разработке такой программной функции у меня практически готова». Вудворд сел вместе с партнером, с которым ему предстояло в тот день работать, и начал объяснять ему свою идею. Обсуждение длилось 45 минут. Во время этого разговора партнер Вудворда нашел несколько нестыковок в его стратегии и выявил «пограничные случаи», когда задумки могли не оправдаться в полной мере. Затем партнеру Вудворда пришла в голову блестящая мысль, как можно избавиться от определенного вида ошибок и исключить худшие сценарии. К полудню новая оптимизированная версия системы была готова. Вудворд отметил: «Я уверен, что, если бы я следовал тому плану, который придумал, пока ехал в офис, разработка заняла бы у меня несколько дней. Значит, продуктивность выросла в 3–4 раза». Оценивая, насколько лучше стали трудиться программисты, работая в парах, Вудворд рассыпается в похвалах: «Метод невероятно эффективен».

Еще одна причина продуктивности экстремального программирования — интенсивность работы. Если вы работаете в паре, вы сосредоточены на том, чем заняты. Вы не можете начать проверять почту или бездумно лазить в интернете, поскольку ваш партнер будет сидеть, раздражаться и ждать, когда вы вернетесь к совместной работе[170]. Более того, оказавшись в среде, которая предполагает, что вы посвятите все свое внимание насущной проблеме, в условиях, когда руководитель проекта защищает вас от отвлекающих факторов, вы проводите рабочий день за решением сложных задач. Методы ХР — наиболее близкие к идеалу и успешно применяемые приемы полного погружения в работу.

Еще один основной принцип ХР помимо интенсивной работы — «размеренность». Большинство тех, кто придерживается этого метода, трудятся стандартные 40 часов в неделю (в отличие от принятых в Кремниевой долине норм в 70–80 часов). «Метод ХР предполагает, что сотрудник приходит, усердно работает в течение восьми часов, затем идет домой и думает о других вещах», — объясняет Вудворд. Это не акт щедрости, а признание факта, что человеческий разум имеет свой лимит. «Обычный инженер в компании, которая не использует методы ХР, может заниматься своими прямыми обязанностями всего 2–3 часа в день. Все остальное время он проводит в интернете или проверяет почту». Когда вы действительно работаете — а не посылаете сообщения, касающиеся работы, и не посещаете собрания, где говорят о работе, — восемь часов труда могут стать довольно сложной задачей. Когда в команду, работающую по системе ХР, приходит новый инженер, обычно он чувствует себя истощенным. Постоянная сосредоточенность на работе в течение восьми часов вызывает слишком большое напряжение, и многие новобранцы, придя из офиса домой, отправляются прямиком в постель. Некоторые сотрудники так и не привыкают к сфокусированности на работе — вернее, если сказать точнее, к той огромной ответственности, которая в результате возникает (в офисе, живущем по правилам ХР, не принято отлынивать или скрывать свою недостаточную квалификацию). И вскоре они сбегают в другие компании, занимающиеся разработкой программного обеспечения и работающие в традиционном формате. Там можно прикрыть недостатки в работе громкими словами, переключиться в режим показной занятости. И это альтернатива действительно тяжелому труду, в результате которого с помощью мозгов создается ценный продукт.

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

Подозреваю, что команды, работающие по принципу ХР, могут стать головной болью для более крупных компаний, которые их нанимают. Но разве стоит обращать внимание на эти неудобства, когда вы наблюдаете, с какой впечатляющей скоростью они демонстрируют невероятные результаты. «ХР-команда из 8–10 человек может выполнять такой же объем работы, что и 40–50 сотрудников, не придерживающихся гибких техник управления, — сообщил мне Вудворд. — Я наблюдаю это снова и снова». Неважно, о каком количестве сотрудников идет речь, но при существенной нехватке специализации на кону оказывается продуктивность. Далее в этой главе мы поговорим о стратегиях, которые помогут воспользоваться преимуществами специализации в стиле экстремального программирования.

В заметке 2010 года писательница Энн Ламотт рассказывала об одном совете, который огорчает ее учеников[171]. Она внушает им, что творческий труд может принести хорошие плоды, но затем добавляет ложку дегтя: «Вам придется находить для него время». Энн поясняет, что пытается донести до писателей мысль о том, сколько вреда причиняет «их маниакальное стремление к коммуникации — с помощью мобильного телефона, электронной почты, СМС-сообщений и Twitter». Затем она перечисляет еще несколько на первый взгляд важных видов деятельности, которые ее ученикам, возможно, придется ограничить, если они и в самом деле хотят создать что-то ценное: походы в спортзал, уборку дома, чтение новостей. Вероятно, совет звучит просто, но Энн отмечает, что ее ученикам часто сложно воплотить его на практике. У них насыщенная жизнь, и мысль, что придется от многого отказаться, кажется шагом назад. «Я знаю, как быстро привыкаешь к такому стилю жизни», — пишет Энн. Но подобный «вихрь» несовместим с достижениями, которые вызывают длительное чувство значимости и гордости.