Страница 52 из 66
Никиас не единственный, кто экспериментировал и отправлял короткие письма. В 2007 году веб-дизайнер по имени Майк Дэвидсон опубликовал в своем личном блоге очерк под названием «Простые решения для того, чтобы не утонуть в электронных письмах»[162]. В этой статье Майк рассказывает о том, какую досаду у него вызывает ассиметричная природа электронной коммуникации. «Часто отправитель задает два-три коротких вопроса, допускающих разные трактовки, а получатель вынужден писать длинный текст из множества абзацев, — отмечает он. — Таким образом, отправитель тратит на сообщение всего минуту, а получатель, как предполагается, должен потратить примерно час». В результате Майк пришел к такому же решению, что и Х. Л. Макс Никиас: все отправляемые им письма — короткие. При определении размера писем Майк тоже ориентировался на 160 символов, которые отведены для СМС. Но, понимая, что для подсчета понадобится некое дополнительное программное обеспечение, он нашел способ проще: все его письма состоят из пяти и менее предложений.
Чтобы «вежливо» объяснить свои новые правила в отношении переписки респондентам, Дэвидсон запустил простенький сайт http://five.sentenc.es, где на оформленной в минималистичном стиле целевой странице вкратце рассказывается о его новой политике. Затем Майк добавил вот такую приписку, которая появляется во всех его письмах:
Вопрос: почему в этом письме всего пять (или меньше) предложений?
Ответ: зайдите на сайт http://five.sentenc.es.
Во вводном абзаце Дэвидсон отмечает: «Гарантировав, что я трачу на все отправляемые сообщения одинаковое количество времени (а именно — не так уж много), я создаю справедливые условия игры и в конечном счете обрабатываю большее количество сообщений».
Идея строго ограничить длину сообщений — более чем хитрый ход. Это шаг, на который совсем немногие отваживаются в наш цифровой век. Он точно ограничивает, для чего можно и для чего нельзя использовать электронную почту. Гиперактивный коллективный разум хочет, чтобы она была нейтральным передатчиком, который поддерживает гибкую неструктурированную и постоянную коммуникацию по всем вопросам. Течение, выступающее за краткость сообщений, бросает вызов такой установке. Его приверженцы считают, что электронная почта подходит для коротких вопросов и ответов и передачи краткой актуальной информации. А любые более сложные вопросы должны решаться с помощью других, более подходящих средств коммуникации. Сейчас это может казаться сложным, но если следовать идеям Клода Шеннона, то в долгосрочной перспективе такая стратегия окупится более низкими средними затратами.
В своей статье для The Wall Street Journal Никиас приводил такой пример. Когда он руководил самым масштабным расширением территории кампуса в истории университета, то часто получал сообщения от руководителей строительных работ. Ему присылали информацию об изменениях в документации или запрашивали одобрение относительно незначительных изменений («речь могла идти о чем угодно: от видов кирпича до использования витражей»). В таких вопросах электронная почта — прекрасный инструмент: если бы по каждому из этих вопросов руководители строительных работ звонили Никиасу или назначали встречи, пострадал бы его рабочий график. Однако, как отмечает Никиас, если касающийся строительства вопрос требовал предметного обсуждения, беседа продолжалась не посредством переписки, а по телефону.
При правильном использовании политика кратких сообщений может стать эффективным протоколом, который использует главные преимущества электронной почты (быстрота и асинхронность). Если же коммуникация выходит за определенные рамки, собеседники вынуждены прибегать к более подходящим инструментам. Писать краткие сообщения — простое правило, но оно может дать хорошие результаты. Как только вы перестанете считать электронную почту универсальным инструментом, подходящим для обсуждения любых вопросов в любое время, ее притязания на ваше внимание уменьшатся.
В 2002 году Майкл Хикс и Джеффри Фостер присоединились к факультету информатики Мэрилендского университета в качестве новоиспеченных доцентов. Они начали работать вместе, чтобы создать исследовательскую группу. Чтобы заниматься наставнической работой с выбранными студентами, Хикс и Фостер применили стратегию, которую профессора в области информатики используют почти повсеместно. Они устраивали еженедельные встречи со студентами, чтобы проверять, как продвигается работа, и решать вопросы, связанные с исследованиями.
Какое-то время эта стратегия работала хорошо. Как и у многих молодых научных работников, у Хикса и Фостера было всего по 2–3 студента, чью работу они курировали, и относительно небольшой объем других задач помимо преподавательской работы и исследований. Однако, как они отметили в техническом отчете об эффективности научного труда, опубликованном в 2010 году, по мере их карьерного роста стандартная стратегия наставничества «исчерпала свои возможности»[163]. Вместо 2–3 студентов теперь у каждого из них было по 6–7. Росла их нагрузка в качестве наставников, а также количество прочих обязанностей: рецензировать работы, заполнять заявления на гранты. В результате у ученых оставалось все меньше свободного времени. Ежедневные встречи с каждым из студентов стали «крайне неэффективными». Они всегда планировались с учетом того, что встреча займет определенное количество времени, от получаса до часа. Но почти никогда ожидания не оправдывались. Иногда встреча занимала всего десять минут, если требовалось лишь ввести собеседника в курс дела. А порой приходилось тратить пару часов, чтобы решить особенно сложную проблему.
У Хикса и Фостера появлялось все больше дел, и им было сложно найти время, чтобы добавить встречу с очередным студентом в свое расписание, поскольку в нем было уже запланировано немало встреч с другими студентами. В результате их подопечные оставались без внимания. Если кто-то сталкивался с проблемой, иногда приходилось целую неделю ждать возможности обсудить потенциальные ее решения. Кроме того, Хикс и Фостер заметили, что индивидуальные встречи не позволяли их исследовательской группе ощутить себя единым целым. «У нас не команда, в которой все сотрудничают и занимаются исследованиями, а группа отдельно взятых студентов», — писали ученые. Изучив все аспекты проблемы, Хикс и Фостер пришли к выводу: «Очевидно, что нужно что-то менять».
К переменам их побудила встреча исследователей, которую посетил Хикс в 2006 году. Он пообщался со знакомым, с которым вместе учился в школе. Тот стал разработчиком программного обеспечения. Знакомый рассказал Хиксу, как ему нравится метод Scrum, входящий в число гибких техник управления. Его работодатель использовал этот метод, чтобы организовать работу своего IT-отдела. Описание подхода запало в душу Хикса. Когда он вернулся в Мэриленд, то заявил Фостеру, что, возможно, эти экзотичные приемы организации работы, пришедшие из мира разработки программного обеспечения, — как раз то, что нужно, чтобы наладить эффективную работу их исследовательской группы.
О гибких техниках управления в общем и методе Scrum в частности я рассказывал в главе 5, когда мы говорили о досках задач. Этот метод предусматривает разные приемы. То, что понравилось Хиксу и Фостеру больше всего, — практика ежедневных встреч. Как вы помните, согласно методу Scrum, работа команды по разработке программного обеспечения делится на спринты — отрезки длительностью от двух до четырех недель, посвященные разработке конкретного набора функций. Во время спринта команда ежедневно собирается на утреннее совещание (scrum), которое длится не более 15 минут. Во время таких встреч каждый член команды отвечает на три вопроса: 1) что он сделал с момента последней встречи, 2) есть ли какие-то проблемы, 3) что он планирует сделать до следующей встречи. Далее в течение рабочего дня каждый сотрудник выполняет свои задачи. В сфере разработки программного обеспечения такой метод оказался более эффективным, чем целый день обмениваться письмами или сообщениями в мессенджерах. Чтобы собрание не длилось больше 15 минут и не превратилось в бесполезную трату времени, во время утренней встречи принято стоять.
162
Mike Davidson, “A Low-Fi Solution to E-Mail Overload: Sentenc.es,” MikeIndustries.com, July 17, 2007, https://mikeindustries.com/blog/archive/2007/07/fight-mail-overload-with-sentences.
163
Michael Hicks and Jeffrey S. Foster, “Adapting Scrum to Managing a Research Group” (Department of Computer Science Technical Report #CS-TR-4966, University of Maryland, College Park, September 18, 2010), https://drum.lib.umd.edu/handle/1903/10743.