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

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

Идея о том, что, делая меньше, вы можете получить больше, на первый взгляд может показаться нелогичной, особенно если подумать о конкуренции. Кто-то из сотрудников может решить, что если он откажется от части обязанностей или от выполнения задач, которые не подразумевают использование его профессиональных навыков, то их перестанут считать командными игроками. А возможно, они даже потеряют работу. Но как доказывает Грег Маккеон в своем бестселлере «Эссенциализм. Путь к простоте»[168], опубликованном в 2015 году, вероятнее всего, события будут развиваться совершенно по-другому. Он рассказывает историю одного руководителя по имени Сэм. Сэм работал в одной из компаний Кремниевой долины и, стремясь быть «сознательным гражданином», никому не отказывал. В результате ситуация обернулась тем, что он хронически был завален огромными объемами работы. В итоге компания предложила ему выйти на пенсию раньше. Сэм подумывал согласиться и открыть собственное консалтинговое агентство. Однако по совету наставника решил все-таки остаться в компании, но перестать постоянно со всем соглашаться и выполнять только ту работу, которую считал необходимой. Сэм решил, что терять ему нечего. Если его новая политика рассердит работодателя, у него все еще остается возможность принять предложение о досрочном выходе на пенсию.

Маккеон вспоминает, что Сэм перестал добровольно вызываться, чтобы в последний момент сделать презентацию, и отказался от привычки первым подключаться к электронной переписке. Он больше не участвовал в телефонных конференциях, которые не касались непосредственно его работы, и осознал, что если кто-то отправил ему приглашение поучаствовать во встрече, то совсем не обязательно его принимать. Сэм начал чаще отказывать. Если он считал, что не сможет выполнить задачу достаточно хорошо или она не была для него приоритетной, он открыто заявлял об этом и говорил собеседнику «нет». Сэм считал, что его сочтут несколько «эгоистичным», но его опасения не оправдались. Никто на него не злился. Наоборот, все восхищались его четкой позицией. Продуктивность его работы настолько улучшилась, что руководители наградили его самым большим бонусом за всю его карьеру[169]. История Сэма напоминает нам о прописной истине, о которой мы часто забываем: мало что может быть лучше, чем сотрудник, постоянно создающий ценный продукт, а один из самых оптимальных подходов к работе — позволить сосредоточиться на том, что действительно важно. Приемы, с которыми я вас познакомлю в этой главе, позволят как отдельным сотрудникам, так и организациям достичь той степени специализации, плоды которой вкусил Сэм. Вы начнете трудиться меньше, но будете делать свою работу лучше. И сможете отказаться от гиперактивного коллективного разума, чтобы действовать медленнее и организовывать рабочий процесс более эффективно.

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

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

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

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