Новые принципы делового общения

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

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

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

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