Новые принципы делового общения. Как сфокусироваться на главном в эпоху коммуникативной перегрузки

Весной 2019 года я записывал интервью для подкаста The Rich Roll Podcast. В ходе него мы обсуждали идеи, которые я изложил в этой книге. Я отметил, что техники гибкого управления, популярные у разработчиков программного обеспечения, — довольно интересный пример более вдумчивой альтернативы гиперактивному коллективному разуму. Через несколько месяцев после выхода интервью я получил письмо, по старинке отпечатанное на бумаге. Его доставили в мой кабинет в Джорджтаунском университете. Автором письма оказался Грег Вудворд, программист и руководитель, много лет проработавший в Кремниевой долине. Он писал, что только что прослушал мое интервью и особый интерес у него вызвало наше обсуждение гибких техник управления. Грег утверждал, что если я хочу в полной мере осознать, каким потенциалом обладают оптимизированные рабочие процессы, то мне необходимо узнать о проекте по внедрению программного обеспечения, которым Грег в тот момент руководил. Они внедряли методологию, «которая позволяла свести все техники гибкого управления воедино и выжать из них максимум». Этот процесс был очень метко окрещен «экстремальным программированием», и он просто потряс мое воображение.

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

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

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

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