Всем привет!

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

• «Стоит ли работать удаленно?»
• «Как вы организовали удаленную работу для своей команды?»
• «Нам сложно работать с удаленными разработчиками...»

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

И раз… два… три… Поехали!

Разные структуры удалённых команд

Под удаленными командами понимают разное:

● Команды-спутники
○ Несколько команд сидят в разных офисах.

● Удаленные сотрудники
○ Почти все сидят в офисе, и только пара ребят работает удаленно.

● Полностью распределенные команды
○ Все на удаленке.

● По принципу «remote first»
○ По сути, они полностью распределенные,
○ но кто-то работает в офисе.
○ Стараются общаться так, чтобы удаленные сотрудники были в курсе всего.

Под удаленными командами я подразумеваю полностью распределенные и правильные remote-first-команды. Остальные я считаю гибридами.

Почему так важно видеть разницу?

Просто это совершенно разные типы команд с разными потребностями.

Требования к процессам

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

Например, собрания

— Обожаю собрания.

Да, собрания никто не любит. Но для удаленных команд это особенно дорогое, сложное и утомительное удовольствие.

Как встречается удаленная команда из пяти человек:

• Объявляем о собрании заранее.
• Все записываем, ведь пришли не все.
• Приходим вовремя.
• Пишем повестку.
• Стараемся не затягивать.
• Вдогонку что-то пишем в Slack и т. д.

В офисе в команде из пяти человек просто встаешь и говоришь: «Все сюда, есть разговор». Хотя если в офисе человек 20–25, то повозиться все равно придется. А пока...

— Сказать — легко.

В удаленной команде нельзя просто встать и заговорить со всеми. Ну вот никак. Кто-то офлайн, кто-то спит, кто-то по уши в работе.

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

Нужно систематизировать взаимодействие и ожидания.

Процессами я называю не тяжкий труд с кучей бумаг, где каждое действие нужно подтверждать печатью. Я имею в виду систематизированное взаимодействие и понятные ожидания.

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

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

С гибридами очень сложно

Представьте, что вы один из команды сидите на удаленке. У вас совсем другие требования к процессам. И вы страдаете.

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

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

Сложно создать процессы для требований к связи в таких командах. Это же вообще против человеческой природы. Я пойду на кухню попить водички и поболтаю с кем-нибудь между делом. А в Slack я про это ничего не напишу, потому что… ну, потому что мне в лом! Человек я или где?

— Я не то чтобы ленивый. Мне просто пофиг.

По умолчанию — удалённо или в офисе?

Я опробовал все эти модели. Лично я советую избегать гибридов и стремиться к полностью распределенным командам — или совсем отказаться от удаленки и сидеть в офисе. Оба подхода годятся.

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

В таких ситуациях, если команда по умолчанию работает удаленно, маленький офис сойдет.

Спросите себя:

• Почему вы решили создать удаленную команду?
• Стоят ли преимущества удаленки затраченных усилий?
• Если да, что придется изменить?
• Как часто вы будете встречаться лично?
• Если вам нужен маленький офис, как наладить связь с удаленными сотрудниками?
  ○ Пример. Вас не коробит, если все люди в офисе на конференц-вызовах будут сидеть со своих ноутбуков?

Зачем работать удалённо?

Многие говорят об экономии. Мол, удаленка выходит дешевле. Иногда это и правда так, особенно если вы привыкли к зарплатам в Кремниевой долине. Но иностранцы ожидают зарплату мирового уровня. Вы удивитесь, какие у людей ожидания. Мечтаете о дешевом аутсорсинге? Тогда удаленка не для вас.

— Здрасьте, дайте бутылочку вашего лучшего вина.
— С вас 1600 долларов.
— Отлично, тогда будьте добры, мне самого восьмибаксовейшего.

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

«У нас классный стартап, все к нам хотят!» Кто-то хочет. Кто-то нет. И вот эти последние — это куча людей, которых вы упустите.

С другой стороны, при правильном подходе можно завлечь даже гениев из Кремниевой долины: «Привет, не думал переехать из Сан-Франциско? С Google этот номер не пройдет, а мы другое дело! Будешь работать с ребятами со всего мира над интересным проектом, где захочешь. Ну ^[1] как ^[2], обсудим ^[3]?»

Как по мне, дело не в расходах, классных специалистах и оптимизации качества жизни и своей продуктивности. Главное — удержание кадров. Знаете, как долго работают люди в удаленных командах? Гораздо дольше, чем в офисе.

Итерации vs инновации

Вы быстро поймете, что в Hangout или Slack теряется много человеческих нюансов. Это важные нюансы, особенно если у вас творческий проект.

Допустим, вы меняете направление развития. Вы долго и с энтузиазмом рассказываете, что должна сделать команда, а в ответ: «Извини, у тебя что-то с интернетом. Что ты сейчас сказал?»

Инновации лучше идут при личных встречах, где даже самый тихий и незаметный сотрудник может взять маркер и что-то объяснить.

А когда вы уже до чего-то договорились, все садятся за свои задачи, и это проще делать удаленно.

• Итерации — удаленно
• Инновации — лично

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

Одиночество

Многие жалуются, что на удаленке одиноко. Лично у меня таких проблем нет, но я видел такое у друзей и понимаю, почему люди волнуются.

Руководитель компании должен следить, чтобы все были здоровы и счастливы. Вот что помогло нам:

• Мы работаем не дома, а в офисах с совместной арендой (в коворкинге все время отвлекаешься).
• Мы встречаемся с друзьями не с работы.
• Мы регулярно встречаемся лично.

Оптимизация для итерации — оптимизация для одиночной игры

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

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

Спросите себя:

• Как определить стратегию, чтобы люди ее понимали и сами принимали решения в духе этой стратегии?
• Как определить цели, чтобы люди их понимали и на них ориентировались?
• Как установить иерархию решений, чтобы вы решали только самые-самые важные вопросы?
• Как вселить в людей уверенность? (с ней работается быстрее)
• Когда можно обойтись без вас, а когда вам нужно вмешаться?
• Как сделать так, чтобы вы участвовали только в каждом десятом решении и отменяли только каждое сотое?
• Как организовать среду и процессы, чтобы они работали даже в экстренных случаях?"

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

Задайте эти вопросы не только для всей компании, но и для каждой отдельной вертикали.

Копаем глубже: управление удаленными командами разработчиков

Вот несколько примеров для команд разработчиков (легко провести аналогии и с другими сферами):

Как вы или член команды можете:

• … траблшутить в одиночку посреди ночи?
• … помогать новым разработчикам самостоятельно учиться?
• … делиться советами по написанию кода?
• … не превращать пул-реквесты в затяжной процесс?
• … не встречаться без особой необходимости?
• … позволить разработчикам самим принимать решения о продуктах?
• … избежать наихудших сценариев?
• И снова — как повысить уверенность? (с ней работается быстрее!)

Мы в Product Hunt долго размышляли и вот что надумали:

• Четко обозначьте стратегии и глобальные цели.
• Пусть разработчики несут ответственность за свои команды и проекты.
• Пусть они несут ответственность за свой продукт и цели (стратегия идет сверху вниз, а исполнение — снизу вверх ^[4])
• Четко обозначьте, в каких случаях нужно мнение нескольких человек (например, изменения в стеке, проблемы безопасности и т. д.).
• У вас должна быть продуманная документация для новичков и руководства для сотрудников.
• Пусть новые сотрудники улучшают эту документацию.
• Используйте понятные формулировки.
• Четко обозначайте правила и запреты.
• Не внедряйте решения, пока не возникнут проблемы (особенно для процессов или инфраструктуры).
• По пятницам сотрудники могут делать все, что считают полезным (если проект не горит), — исправлять технические недоработки, улучшать пользовательский интерфейс, пробовать новую библиотеку, перестраивать инфраструктуру…
• Записывайте видео вместо демонстраций вживую (например, для прототипов пользовательского интерфейса).
• Заведите надежный (но не огромный) набор тестов (на интеграцию функций и модульные тесты для рискованных частей).
• Старайтесь использовать стандартные компоненты несколько раз, а не корпеть над каждым пикселем.
• Обязательно используйте линтеры для каждого языка (даже для HTML/CSS).
• Включайте автоформатирование (чтобы не обсуждать стили кода).
• Включайте в линтерах подсчет сложности (️ гениальная идея).
• Не лезьте в консоль продакшена, если это не крайний случай (с логами и алертами).
• Пусть условия продакшена будет легко воссоздать в разработке (без лишних данных).
• Среды разработки должны переустанавливаться одним действием.
• Выберите время для просмотра пул-реквестов (первым делом каждое утро).
• «+1» в пул-реквестах это мило, но не обязательно.
• Если есть риски для безопасности, требуйте «+1» (с помощью danger.js ^[5]).
• В комментах пишите почему, а не что ^[6]
• и т. д. и т. п

Напишите мне ^[7], если нужно, чтобы я расписал все в деталях. А пока подробности можно найти в моей первой презентации о том, как мы работали в Product Hunt: https://www.slideshare.net/andreasklinger/engineering-management-for-early-stage-startups-97402850 ^[4]

Если лень читать много букв: в идеале разработчик должен сам понимать, все ли у него в порядке и когда ему нужны обзорные отзывы от коллег. А детали пусть проверяются автоматически. И главное — относитесь к ним как к взрослым людям.

Это проблемы не только удалённых команд

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

В офисе проблемы с процессами решаются частыми встречами и постоянным вмешательством в работу членов команды.

Удаленные команды требовательнее к процессам, поэтому проблемы с управлением сотрудниками просто возникают раньше и больше бросаются в глаза.

— Правило №1: не трепаться.

Раз встречаться дорого, нужно продумать систематизацию процессов.

Раз нельзя стоять у сотрудников над душой, нужно понимать, в чем им можно полностью довериться.

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

Думаете, вы ещё не на удалёнке?

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

Работаешь на удаленке или нет — уже не вопрос. Вопрос — как много.

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

Конец

Дайте знать, если я не зря старался. А если у вас есть опыт работы с удаленными командами, расскажите ^[7], как можно улучшить статью!

PS. Я много лет ничего не писал в блог… Я здорово нервничал и попросил об отзывах еще в процессе написания. Больше ста человек предложили помощь, я даже не могу упомянуть здесь всех, и я просто в восторге от комментариев. Такая помощь много для меня значит. Всем спасибо.

Если вы хотите помочь мне с черновиками постов, подпишитесь ^[8]. Заранее спасибо.

Автор: nAbdullin

Источник ^[9]