[Перевод] Краткий курс по управлению удаленными командами
Всем привет!
Я уже давненько не писал и подзабыл, как это делается, но хочу поделиться информацией, которая многим может пригодиться. Ведь ко мне постоянно пристают с вопросами, вроде:
● «Стоит ли работать удаленно?»
● «Как вы организовали удаленную работу для своей команды?»
● «Нам сложно работать с удаленными разработчиками…»
Пост вышел длиннее, чем планировалось, — я попытался описать все моменты, которые вам нужно учесть. В этой статье я покажу разные структуры удаленных команд, как и почему удаленные команды работают иначе, когда стоит, а когда не стоит работать удаленно, и, наконец, приведу реальные примеры. Спасибо за чтение.
И раз… два… три… Поехали!
РАЗНЫЕ СТРУКТУРЫ УДАЛЕННЫХ КОМАНД
Под удаленными командами понимают разное:
● Команды-спутники
○ Несколько команд сидят в разных офисах.
● Удаленные сотрудники
○ Почти все сидят в офисе, и только пара ребят работает удаленно.
● Полностью распределенные команды
○ Все на удаленке.
● По принципу «remote first»
○ По сути, они полностью распределенные,
○, но кто-то работает в офисе.
○ Стараются общаться так, чтобы удаленные сотрудники были в курсе всего.
Под удаленными командами я подразумеваю полностью распределенные и правильные remote-first-команды. Остальные я считаю гибридами.
Почему так важно видеть разницу?
Просто это совершенно разные типы команд с разными потребностями.
ТРЕБОВАНИЯ К ПРОЦЕССАМ
У удаленных команд требований к процессам где-то в пять раз больше, чем у офисных.
Например, собрания
— Обожаю собрания.
Да, собрания никто не любит. Но для удаленных команд это особенно дорогое, сложное и утомительное удовольствие.
Как встречается удаленная команда из пяти человек:
● Объявляем о собрании заранее.
● Все записываем, ведь пришли не все.
● Приходим вовремя.
● Пишем повестку.
● Стараемся не затягивать.
● Вдогонку что-то пишем в Slack
● и т. д.
В офисе в команде из пяти человек просто встаешь и говоришь: «Все сюда, есть разговор». Хотя если в офисе человек 20–25, то повозиться все равно придется. А пока…
— Сказать — легко.
В удаленной команде нельзя просто встать и заговорить со всеми. Ну вот никак. Кто-то офлайн, кто-то спит, кто-то по уши в работе.
Собрания — это просто хороший пример, но речь идет о любом общении или командной работе. В удаленных командах процессы в пять раз сложнее.
Нужно систематизировать взаимодействие и ожидания.
Процессами я называю не тяжкий труд с кучей бумаг, где каждое действие нужно подтверждать печатью. Я имею в виду систематизированное взаимодействие и понятные ожидания.
Например, каждое утро мы отмечаемся или всегда делаем одну задачу, прежде чем сделать другую. С такими понятными правилами люди знают, чего ждать, и избегают лишнего общения.
Не хочу вас разочаровывать, но… все-таки это работа, и вам нужно вести себя так, будто компания у вас больше, чем на самом деле. Вам нужны строгие правила. Проблемы с общением будут возникать постоянно — и в больших количествах.
Люди часто жалуются на эти проблемы общения, когда думают, не перевести ли команды на удаленку и не нанять ли удаленных разработчиков. И они решаются на гибриды…
С ГИБРИДАМИ ОЧЕНЬ СЛОЖНО
Представьте, что вы один из команды сидите на удаленке. У вас совсем другие требования к процессам. И вы страдаете.
Сложно быть отщепенцем в офисной команде — у вас в пять раз больше требований, и вас забывают позвать на обсуждения, все решается без вас, вы один понятия не имеете, что да почему. В общем, жизнь — боль.
У офисов-спутников тоже есть проблемы. Между офисами требований к связи в пять раз больше, а в самих офисах люди работают, как обычно. Если только офисы не работают почти независимо друг от друга, связь между ними пострадает.
Сложно создать процессы для требований к связи в таких командах. Это же вообще против человеческой природы. Я пойду на кухню попить водички и поболтаю с кем-нибудь между делом. А в Slack я про это ничего не напишу, потому что… ну, потому что мне в лом! Человек я или где?
— Я не то чтобы ленивый. Мне просто пофиг.
ПО УМОЛЧАНИЮ — УДАЛЕННО ИЛИ В ОФИСЕ?
Я опробовал все эти модели. Лично я советую избегать гибридов и стремиться к полностью распределенным командам — или совсем отказаться от удаленки и сидеть в офисе. Оба подхода годятся.
Если вам нужен небольшой офис, пусть в нем не сидит основная масса команды и пусть удаленных сотрудников не исключают из обсуждений.
В таких ситуациях, если команда по умолчанию работает удаленно, маленький офис сойдет.
Спросите себя:
● Почему вы решили создать удаленную команду?
● Стоят ли преимущества удаленки затраченных усилий?
● Если да, что придется изменить?
● Как часто вы будете встречаться лично?
● Если вам нужен маленький офис, как наладить связь с удаленными сотрудниками?
○ Пример. Вас не коробит, если все люди в офисе на конференц-вызовах будут сидеть со своих ноутбуков?
ЗАЧЕМ РАБОТАТЬ УДАЛЕННО?
Многие говорят об экономии. Мол, удаленка выходит дешевле. Иногда это и правда так, особенно если вы привыкли к зарплатам в Кремниевой долине. Но иностранцы ожидают зарплату мирового уровня. Вы удивитесь, какие у людей ожидания. Мечтаете о дешевом аутсорсинге? Тогда удаленка не для вас.
— Здрасьте, дайте бутылочку вашего лучшего вина.
— С вас 1600 долларов.
— Отлично, тогда будьте добры, мне самого восьмибаксовейшего.
Наем удаленных сотрудников дает четыре преимущества: вы нанимаете лучших людей, где бы они (или вы) ни были; повышаете качество жизни; управляете своей продуктивностью; у вас низкая текучка кадров.
«У нас классный стартап, все к нам хотят!» Кто-то хочет. Кто-то нет. И вот эти последние — это куча людей, которых вы упустите.
С другой стороны, при правильном подходе можно завлечь даже гениев из Кремниевой долины: «Привет, не думал переехать из Сан-Франциско? С Google этот номер не пройдет, а мы другое дело! Будешь работать с ребятами со всего мира над интересным проектом, где захочешь. Ну как, обсудим?»
Как по мне, дело не в расходах, классных специалистах и оптимизации качества жизни и своей продуктивности. Главное — удержание кадров. Знаете, как долго работают люди в удаленных командах? Гораздо дольше, чем в офисе.
ИТЕРАЦИИ vs ИННОВАЦИИ
Вы быстро поймете, что в Hangout или Slack теряется много человеческих нюансов. Это важные нюансы, особенно если у вас творческий проект.
Допустим, вы меняете направление развития. Вы долго и с энтузиазмом рассказываете, что должна сделать команда, а в ответ: «Извини, у тебя что-то с интернетом. Что ты сейчас сказал?»
Инновации лучше идут при личных встречах, где даже самый тихий и незаметный сотрудник может взять маркер и что-то объяснить.
А когда вы уже до чего-то договорились, все садятся за свои задачи, и это проще делать удаленно.
● Итерации — удаленно
● Инновации — лично
Даже если вы работаете удаленно, договоритесь, как часто нужно встречаться. Я советую встречаться раз в квартал или дважды в год всей командой. А команды для отдельных проектов пусть встречаются по необходимости.
ОДИНОЧЕСТВО
Многие жалуются, что на удаленке одиноко. Лично у меня таких проблем нет, но я видел такое у друзей и понимаю, почему люди волнуются.
Руководитель компании должен следить, чтобы все были здоровы и счастливы. Вот что помогло нам:
● Мы работаем не дома, а в офисах с совместной арендой (в коворкинге все время отвлекаешься).
● Мы встречаемся с друзьями не с работы.
● Мы регулярно встречаемся лично.
ОПТИМИЗАЦИЯ ДЛЯ ИТЕРАЦИИ — ОПТИМИЗАЦИЯ ДЛЯ ОДИНОЧНОЙ ИГРЫ
В удаленных командах все должно быть устроено так, чтобы люди могли работать максимально автономно. Это не значит, что нужно оставить сотрудников в покое. Просто дайте им возможность работать в одиночку, если это надо.
Поодиночке люди принимают решения быстро, а команда часто тормозит. Чтобы достичь результата, нужно работать и так, и так, но старайтесь избегать командной волокиты, если в ней нет крайней необходимости.
Спросите себя:
● Как определить стратегию, чтобы люди ее понимали и сами принимали решения в духе этой стратегии?
● Как определить цели, чтобы люди их понимали и на них ориентировались?
● Как установить иерархию решений, чтобы вы решали только самые-самые важные вопросы?
● Как вселить в людей уверенность? (с ней работается быстрее)
● Когда можно обойтись без вас, а когда вам нужно вмешаться?
● Как сделать так, чтобы вы участвовали только в каждом десятом решении и отменяли только каждое сотое?
● Как организовать среду и процессы, чтобы они работали даже в экстренных случаях?»
Если вы наняли умных и талантливых ребят, то почему бы просто не дать им свободу действий? Чего не хватает? Вы наняли не тех? Вы не смогли четко обозначить цели? Вы лично не уверены в стратегических элементах? Лучше решить эти проблемы раз и навсегда, чем каждый раз разбираться с последствиями.
Задайте эти вопросы не только для всей компании, но и для каждой отдельной вертикали.
Копаем глубже: управление удаленными командами разработчиков
Вот несколько примеров для команд разработчиков (легко провести аналогии и с другими сферами):
Как вы или член команды можете:
● … траблшутить в одиночку посреди ночи?
● … помогать новым разработчикам самостоятельно учиться?
● … делиться советами по написанию кода?
● … не превращать пул-реквесты в затяжной процесс?
● … не встречаться без особой необходимости?
● … позволить разработчикам самим принимать решения о продуктах?
● … избежать наихудших сценариев?
● И снова — как повысить уверенность? (с ней работается быстрее!)
Мы в Product Hunt долго размышляли и вот что надумали:
● Четко обозначьте стратегии и глобальные цели.
● Пусть разработчики несут ответственность за свои команды и проекты.
● Пусть они несут ответственность за свой продукт и цели (стратегия идет сверху вниз, а исполнение — снизу вверх)
● Четко обозначьте, в каких случаях нужно мнение нескольких человек (например, изменения в стеке, проблемы безопасности и т. д.).
● У вас должна быть продуманная документация для новичков и руководства для сотрудников.
● Пусть новые сотрудники улучшают эту документацию.
● Используйте понятные формулировки.
● Четко обозначайте правила и запреты.
● Не внедряйте решения, пока не возникнут проблемы (особенно для процессов или инфраструктуры).
● По пятницам сотрудники могут делать все, что считают полезным (если проект не горит), — исправлять технические недоработки, улучшать пользовательский интерфейс, пробовать новую библиотеку, перестраивать инфраструктуру…
● Записывайте видео вместо демонстраций вживую (например, для прототипов пользовательского интерфейса).
● Заведите надежный (но не огромный) набор тестов (на интеграцию функций и модульные тесты для рискованных частей).
● Старайтесь использовать стандартные компоненты несколько раз, а не корпеть над каждым пикселем.
● Обязательно используйте линтеры для каждого языка (даже для HTML/CSS).
● Включайте автоформатирование (чтобы не обсуждать стили кода).
● Включайте в линтерах подсчет сложности (️ гениальная идея).
● Не лезьте в консоль продакшена, если это не крайний случай (с логами и алертами).
● Пусть условия продакшена будет легко воссоздать в разработке (без лишних данных).
● Среды разработки должны переустанавливаться одним действием.
● Выберите время для просмотра пул-реквестов (первым делом каждое утро).
● »+1» в пул-реквестах это мило, но не обязательно.
● Если есть риски для безопасности, требуйте »+1» (с помощью danger.js).
● В комментах пишите почему, а не что
● и т. д. и т. п
Напишите мне, если нужно, чтобы я расписал все в деталях. А пока подробности можно найти в моей первой презентации о том, как мы работали в Product Hunt: https://www.slideshare.net/andreasklinger/engineering-management-for-early-stage-startups-97402850
Если лень читать много букв: в идеале разработчик должен сам понимать, все ли у него в порядке и когда ему нужны обзорные отзывы от коллег. А детали пусть проверяются автоматически. И главное — относитесь к ним как к взрослым людям.
ЭТО ПРОБЛЕМЫ НЕ ТОЛЬКО УДАЛЕННЫХ КОМАНД
Все эти проблемы касаются не только удаленных команд, и решения можно использовать те же, что в офисе. Просто офисным командам не нужны такие строгие правила — они всегда могут что-то поправить по ходу дела. Может, разработчики и не в восторге от собраний и болтовни, но это работает и все это делают.
В офисе проблемы с процессами решаются частыми встречами и постоянным вмешательством в работу членов команды.
Удаленные команды требовательнее к процессам, поэтому проблемы с управлением сотрудниками просто возникают раньше и больше бросаются в глаза.
— Правило №1: не трепаться.
Раз встречаться дорого, нужно продумать систематизацию процессов.
Раз нельзя стоять у сотрудников над душой, нужно понимать, в чем им можно полностью довериться.
Раз нельзя следить за каждым шагом, нужно определить стратегию и цели и относиться к разработчикам как к взрослым людям, способным принимать решения.
ДУМАЕТЕ, ВЫ ЕЩЕ НЕ НА УДАЛЕНКЕ?
Можно, конечно, обсуждать все плюсы и минусы удаленной работы, но давайте говорить честно.
Мы уже так работаем. Проверяем почту по выходным, читаем бумаги по дороге на работу и доделываем проекты дома по вечерам. Вы уже работаете удаленно, вопрос только — как часто и сколько у вас нужных инструментов.
Работаешь на удаленке или нет — уже не вопрос. Вопрос — как много.
Удаленная работа — это логическое развитие работы с цифровыми технологиями. И методы работы удаленных команд можно применять ко всем, кто работает в цифровом пространстве.
КОНЕЦ
Дайте знать, если я не зря старался. А если у вас есть опыт работы с удаленными командами, расскажите, как можно улучшить статью!
PS. Я много лет ничего не писал в блог… Я здорово нервничал и попросил об отзывах еще в процессе написания. Больше ста человек предложили помощь, я даже не могу упомянуть здесь всех, и я просто в восторге от комментариев. Такая помощь много для меня значит. Всем спасибо.
Если вы хотите помочь мне с черновиками постов, подпишитесь. Заранее спасибо.
