Как организовать удаленную работу без
бесконечных видеоконференций

Из-за кризиса в связи с эпидемией COVID-19 многие перестали ездить в офис, и работодатели в целом, пусть иногда и с неохотой, признали, что эффективно работать можно и из дома. Будто из стремления компенсировать дистанцию и поддерживать — виртуально — жизнь офиса в компаниях призывают не отступать от привычного рабочего графика. Идея этого призыва в том, что работа из дома — это отлично и даже очень эффективно, если можно в течение дня в любой момент выйти на связь с помощью видеозвонков.

Но сотрудникам на удаленке часто сложно организовать себе «рабочий день», ведь накладываются еще и семейные дела, особенно когда всем приходится оставаться дома. Эффективно ли на самом деле придерживаться установленных временных интервалов? Или можно не смотреть на часы?

Судя по всему, правильный ответ — можно не смотреть на часы. До пандемии мы изучали практику удаленной работы в технологической компании GitLab и пытались оценить, что может дать компаниям отказ от привязки к определенному временному режиму и физическому офису, и вот что выяснили.

Вызов GitLab

Со времени своего основания в 2014 году GitLab работает с полностью удаленным составом сотрудников, насчитывающим 1300 человек в 65 странах мира. Распределенная git-система организации процесса позволяет членам команды вести проекты из любой точки мира и в любое время. Поскольку рабочий день «с 9 до 17» в разных частях света складывается в постоянно продолжающуюся непрерывную смену, работа не прекращается круглые сутки, и это позволяет добиваться высокой производительности. Звучит отлично, но управление распределенной рабочей силой, рассредоточенной в пространстве и во времени, задает непростую задачу координации с самыми разными последствиями организационного характера.

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

Для такой сложной работы часто лучше подходит совместное присутствие команды и непрерывные коммуникации, имеющие два главных преимущества: синхронность и многообразие способов передачи информации. Временной лаг взаимодействия между двумя или несколькими исполнителями в едином рабочем пространстве почти нулевой. Важно еще учитывать, что даже один и тот же по содержанию разговор в очном и виртуальном формате происходит по-разному: технологии не позволяют в полном объеме передавать неформальные сигналы и фоновую контекстную информацию — легко ли уловить реакции собеседников на конференции в Zoom?

Получается, если пытаться просто воспроизвести в онлайн-режиме (с помощью видео- или голосового чата) то, что раньше делалось в условиях совместного присутствия команды, вряд ли это будет успешная и полноценная стратегия. Тем не менее такой подход с возможностью «видеть друг друга» чаще всего выбирают по умолчанию, когда приходится по необходимости работать удаленно. Об этом свидетельствуют данные нашего исследования о дистанционной работе в начальный период после объявления локдаунов по всему миру.

Непрямая координация

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

Координация в таком случае происходит за счет наблюдения за действиями других сотрудников и возможности прогнозирования их будущих шагов и потребностей на основе общих нормативов. Она может быть синхронной (когда, например, два человека работают в Google doc одновременно) или асинхронной (когда четко обозначается передача управления документом и во время работы одного исполнителя никто другой изменения не вносит).

В организациях, занимающихся разработкой программного обеспечения, часто выбирают этот вариант и используют общие репозитории и инструменты редактирования документов с координацией изменений (например, системы с непрерывной интеграцией и инструментами управления версиями). При этом GitLab — особый случай в коммерческой разработке, поскольку такой третий путь активно применяется не только в программировании, но и в функционировании самой организации. Компания применяет методы асинхронной работы, поскольку команды функционируют в разных часовых поясах. В результате почти никому из сотрудников не приходится целый день проводить на видеоконференциях (хотя они тоже организуются).

Как это работает в GitLab

В основу технической разработки продуктов в GitLab положена модель рабочего процесса Git, придуманная основателем Linux Линусом Торвальдсом. Программист при написании кода использует ветвление (копирование) процесса (форк), не блокируя возможность работы для остальных. После внесения изменений выполняется функция слияния, и вместо исходной версии используется и в дальнейшем редактируется обновленный код.

Такая организация процесса сочетает в себе методы распределенной асинхронной работы и структуру, в которой исключаются потенциальные сбои в координации и четко распределяются права принятия решений. Полностью электронная (допускающая дистанционный формат) и документируемая схема работы составляет важную основу распределенной разработки и в коммерческом контексте, и в контексте программного обеспечения с открытым кодом.

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

Активное использование в GitLab асинхронного режима работы стало возможным благодаря соблюдению на уровне каждой отдельной задачи следующих трех простых правил.

1. Разделите ответственность за выполнение задачи и фиксацию результата

При совместном присутствии команды, когда все сотрудники находятся в одном офисе, простота коммуникации и дополнительные возможности учета контекста общения помогают эффективно разрешать неоднозначные ситуации и управлять конфликтами, связанными с рабочими обязанностями и функциями. В дистанционном режиме с этим бывает сложнее. В GitLab для каждой задачи назначается непосредственно ответственное лицо (DRI, Directly Responsible Individual) с правом свободно определять порядок исполнения.

При этом решение о завершении задачи DRI не выносит. Принимать или отклонять от DRI запросы о слиянии — компетенция ответственного за сопровождение (Maintainer). Ясное распределение ролей по каждой из задач помогает свести к минимуму накладки и задержки и дает возможность многочисленным DRIпараллельно в любом нужном им порядке работать над своими блоками задач за счет создания локальных копий (форков). Функция ответственного за сопровождение — исключать ненужные изменения и следить за согласованностью рабочей версии документа или кода.

Вне контекста программной разработки, например, при составлении внутренних руководств о политике расходов в GitLab, в качестве DRIв каждом отдельном случае может выступать любой сотрудник компании, которому будет поручено сформулировать соответствующие политики; его предложения будет принимать либо отклонять финансовый директор, выступающий в качестве ответственного за сопровождение и уполномоченный давать DRIобратную связь (но не указания). После одобрения скомпонованное руководство выступает единым источником действующих норм политики расходов, до тех пор пока кто-нибудь не внесет новое предложение. И вновь ответственный за сопровождение должен будет его принять, отклонить или дать обратную связь. В подобных контекстах ожидаемо в качестве ответственных за сопровождение выступают менеджеры, занимающие традиционные управленческие посты.

2. Следуйте принципу «минимальных жизнеспособных изменений»

При асинхронной координации есть риск, что накладки могут долго оставаться незамеченными: например, два исполнителя параллельно занимаются одной и той же проблемой, то есть выполняется двойная работа, или кто-то готовит изменения, которые будут несовместимы с разработками другого. Чтобы свести к минимуму такую вероятность, нужно призывать сотрудников предъявлять к сдаче минимальные жизнеспособные изменения — начальный вариант предлагаемых частей кода или документов без окончательной доводки. Так с большей вероятностью остальные смогут отследить совместимость или возможное дублирование разработок между разными участками. Безусловно, политика минимальных жизнеспособных изменений предполагает некритичное отношение к устранимым временным недоработкам. В условиях дистанционного сотрудничества максимально оперативно быть в курсе происходящего на других участках более важно, чем получать идеальный результат.

3. Всегда выбирайте публичные коммуникации

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

Ограничения подхода GitLab

Даже в самом удачном исполнении асинхронная дистанционная работа такого рода мало что дает в части неформального общения между сотрудниками. И это большое упущение, ведь это не просто источник удовольствия и мотивации для многих — это еще и «случайные пересечения», «удачные» открытия из разговоров у кофемашины и на площадке у лифта, это возможности появления новых идей, механизм распространения и перекомбинирования информации.

Чтобы справиться с этим недостатком, в GitLab поддерживают не связанные с профессиональными задачами коммуникации. Каждый день у членов команды есть возможность поучаствовать на свое усмотрение в одной из трех неформальных видеоконференций, поставленных в график с учетом оптимального охвата часовых поясов. Группа из 8—10 человек выходит в видеочат, где можно обсуждать любые темы (чтобы начать разговор, если нужно, GitLab предлагает ежедневные вопросы: «Чем вы занимались в выходные?» или «Где вам больше всего понравилось путешествовать и почему?»)

Помимо этого, в GitLab есть группы для неформального общения в Slack— тематические чаты по интересам (#cat, #dogs, #cooking, #mental_health_aware, #daily_gratitude, #gaming) и канал #donut_be_strangers, в котором можно за чашкой кофе поговорить на общие темы с незнакомыми коллегами.

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

***

Для эффективной работы из дома недостаточно раздать сотрудникам ноутбуки и аккаунты в Zoom. Важно сделать все возможное, чтобы компенсировать или устранить недостатки дистанционного режима, а также максимально использовать предлагаемую им гибкость — возможность выбирать не только место, но и время работы. Мы привели в качестве примера GitLab, потому что компания не только располагает обширным опытом в выстраивании дистанционных взаимодействий, но и использует необычный метод в решении сопряженных с ними сложностей. Некоторые ключевые процессы GitLab (например, продолжительный вводный инструктаж для новых сотрудников на удаленной основе) и преимущества (возможность привлекать кадры из любой точки мира) не могут быть полностью реализованы в краткосрочном периоде компаниями, которые перешли на удаленную работу временно, но кое-что применить будет несложно. 

Об авторах

Марко Минерви (Marco Minervini) — научный сотрудник глобальной бизнес-школы INSEAD, кампусы которой расположены в Абу-Даби, Франции и Сингапуре.

Даррен Мерф (Darren Murph) — руководитель удаленной работы в GitLab, автор книг Gitlab «Remote Playbook» и «Living the Remote Dream».

Фаниш Пуранам (Phanish Puranam)— преподаватель кафедры стратегии и организационного проектирования в INSEAD.