Как стать автором
Обновить
70.12
Слёрм
Учебный центр для тех, кто работает в IT

Краткий курс по управлению удаленными командами

Время на прочтение 8 мин
Количество просмотров 13K
Автор оригинала: Andreas Klinger

Всем привет!


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


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

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


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



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


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


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


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


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


По принципу «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. Я много лет ничего не писал в блог… Я здорово нервничал и попросил об отзывах еще в процессе написания. Больше ста человек предложили помощь, я даже не могу упомянуть здесь всех, и я просто в восторге от комментариев. Такая помощь много для меня значит. Всем спасибо.


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

Теги:
Хабы:
+31
Комментарии 7
Комментарии Комментарии 7

Публикации

Информация

Сайт
slurm.io
Дата регистрации
Дата основания
Численность
51–100 человек
Местоположение
Россия
Представитель
Антон Скобин