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

Но, как часто бывает с интуитивным знанием, это предположение неверно. Программное обеспечение с открытым кодом — от операционной системы Linux до системы управления базами данных MySQL, языка программирования PHP и фреймворка Rubi on Rails — обставило продукты таких коммерческих монстров, как Microsoft, Oracle и так далее.

По сравнению с разработкой обычного приложения для корпоративного или личного использования, написание ПО с открытым кодом — задача бесконечно более трудная и требует участия гораздо большего количества людей. И если кто-то умудряется на базе удаленной работы создавать операционные системы, СУБД, языки программирования, веб-фреймворки мирового класса, наверное, и вам стоит внимательно изучить, как это делается.

Мы развиваем фреймворк Ruby on Rails уже больше десяти лет, добавляя все новые функции и улучшая качество кода. За эти годы свой вклад в проект внесли почти 3000 человек из десятков стран и сотен городов. Подавляющее большинство из них никогда не встречались друг с другом в реальной жизни! Все шло как всегда при создании софта: старый код + куча новых функций + куча разных программистов = большой слипшийся ком спагетти!

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

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

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

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

Поэтому, если вас одолевают сомнения по поводу возможных проблем, связанных с удаленной работой, подумайте: по крайней мере я не пытаюсь собрать в кучу 3000 человек со всего мира и координировать их совместную работу над одним проектом. Вам мгновенно станет легче, ведь масштаб вашей задачи сравнительно невелик.

Если относиться к удаленным сотрудникам как к гражданам второго сорта, неприятностей не миновать. Чем ниже их рейтинг по сравнению с рейтингом офисных коллег, тем выше вероятность проблем. Это обычная ситуация, и сама собой она не разрешится.

Чувствовать себя человеком второго сорта — то еще удовольствие. Представьте: полная комната людей, система конференц-связи работает плохо, удаленный сотрудник с трудом слышит тех, кто находится в офисе, об участии в разговоре и говорить не приходится. Представьте также, как раздражает, если любая дискуссия заканчивается фразой: «Мы тут с Джоном вчера все обсудили в офисе и решили, что твоя идея не сработает». Да пошли вы…

Если вы владелец или руководитель компании, ваш долг — создать и поддерживать как минимум равные условия и для тех, кто в офисе, и для тех, кто вне его. Конечно, это легче сказать, чем сделать. Повысить шансы на успех может переход на удаленную работу кого-то из высшего руководства. Люди, у которых есть полномочия изменить ситуацию, должны испытать те же сложности, что и их подчиненные, вынужденные лишь мириться с ними.

Когда в 1990-х годах в нью-йоркской подземке участились случаи преступлений и вандализма, комиссар полиции Нью-Йорка Уильям Брэттон приказал офицерам ездить на метро. Они своими глазами увидели масштабы бедствия, и все изменилось очень быстро.

Мы не призываем руководителей вашей компании переехать в другой город, чтобы почувствовать все неудобства, связанные с удаленной работой. Пусть просто поработают дома несколько дней в неделю. Так они получат хоть какое-то представление о том, каково это — быть в шкуре удаленного сотрудника. А еще лучше, если они станут работать удаленно всегда, а не время от времени. Бетти Хэйс, главный дизайнер расположенной в Мичигане компании Herman Miller, крупного производителя мебели и оборудования для дома и офиса, работает в Чикаго, ее босс — в Нью-Йорке, а команда из десяти человек разбросана по всей стране.

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

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

Такое общение мы называем «один на один», а в других компаниях говорят «регулярный созвон» или просто «чекин». Главное, чтобы оно было а) неформальным и б) диалогом. Это скорее звонок типа «что нового, как жизнь вообще?», чем конкретная критика конкретного проекта или реакция на выполненную работу. Разговор обычно длится двадцать-тридцать минут, но лучше иметь в запасе час — на всякий случай. Если беседа задалась, вы сами не захотите ее прерывать.