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