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

Немного обо мне: 12 лет профессиональной разработки, из которых больше половины я работал вне офиса. Работал в компании LinguaLeo, участвовал в ряде стартапов, о которых уже никто не услышит, в том числе своем. Последние почти 2 года (на текущий момент) я руковожу разработкой компонентов SaaS-платформ.

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

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

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

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

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

= Среда
Каждый разработчик должен обеспечить себе рабочую среду, соответствующую оговоренным заранее требованиям.
Эффект домино: когда никого нет в онлайне, и самому не хочется работать. Когда вся онлайн-работа закипает сама собой. Поэтому очень важно иметь фиксированное время общего аптайма команды.

= Управление
Управлять людьми крайне неэффективно. Гораздо проще управлять потоками информации. Это не делается по щелчку пальцами, и глупо пытаться объявить на общем звонке, что "со следующего понедельника мы делаем все по-новому". Это непростой процесс, но это ключ к масштабируемости.
Каждый разработчик должен обладать достаточными знаниями о проекте, чтобы принимать решения ежедневно с минимальным количеством коммуникаций. Продукт, как правило, имеет достаточно стабильный план развития, который нельзя менять каждый день.
Мотивировать людей слишком дорого, достаточно устранять факторы, снижающие мотивацию. Пример с машиной: сделать имеющуюся машину мощнее/быстрее очень затратно, а с помощью своевременного ТО можно сохранить параметры, близкие к начальным.
Нужно быть толерантным к ошибкам, но не толерантным к вредительству.

= Scrum или не Scrum?
Scrum - это хороший фреймворк для построения очень и очень эффективного процесса разработки. Так же, как автомобиль - более эффективное средство передвижения на средние и дальние дистанции, чем ходьба. Но для вождения нужны навыки, сноровка и внимательность. Попытка пользоваться прогрессом без должных навыков чревата печальными последствиями.
К сожалению, в головах сейчас преимущественно каша из новомодных слов, которая, будучи помноженной на невысокий уровень критического мышления, приводит к очень плачевным результатам.
Как бы то ни было, Agile и Scrum - далеко не единственные техники повышения эффективности работы.
Ответ прост: нужно использовать здравый смысл. В конце концов, эффективная разработка была возможна задолго по появления самих терминов.
В любом случае вы должны помнить, что продукт, разрабатываемый без методологии, может быть успешнее чем с Scrum/Agile/name it на первом месте.

= Эффективность удаленной работы
Еще долго ни один онлайн-инструмент не заменит маркерной доски. Пожалуй, колокейшн смогут заменить только нейроинтерфейсы вроде слияния из “Тихоокеанского рубежа”. Я сомневаюсь, что удаленная работа может сравниться по эффективности с хорошо организованной офисной работой. Но по совокупности многих факторов удаленный формат работы может быть выгоднее офисного.