Про эффективность распределённых команд
Меня очень часто спрашивают, как у меня получается работать в сильно распределённых командах. А когда я рассказываю про ситуации, что я из-за разницы во времени не могу созваниваться со своими сотрудниками по многу дней, то мне говорят, что это не может быть эффективным. В результате меня попросили написать несколько постов на тему распределённых команд.
Ранее я уже писал об этом и я рад продолжить. Я в распределённых командах работал больше, чем в "обычных". И самое важное, что я хочу сказть: В большинстве случаев распределённые команды более эффективны, чем локальные! Это идёт в разрез с общепринятым пониманием, но такова практика. Давайте конкретно рассмотрим, почему так происходит.
- В традиционной локальной команде плюсом считается возможность в любое время подойти к коллеге и очень быстро обсудить любой вопрос. Именно это ускоряет разработку! А как на практике?
А на практике тим лид начинает жаловаться, что ему не дают работать, когда у него хотя бы 5 разработчиков в команде. А при 10 разработчиках лид отстраняется от написания кода гарантированно. Вот именно этот момент, когда в любой момент может прийти человек и выдернуть тебя по какому-то вопросу производительность просто убивает. В результате ключевые сотрудники начинают всё меньше и меньше участвовать непосредственно в написании кода. А ведь это люди, которые могли бы принести больше всего пользы.
Что советуют по этому поводу специалисты по тайм-менеджмент и личной эффективности? Выделять фиксированное время для общения и переносить несрочные вопросы в почту. А это в точности модель, которая используется в распределённых командах. То есть мы в офисе перенимаем "удалёнщеские" метода именно для повышения эффективности. - Ещё забавней ситуация, когда я работаю менеджером. Ну пришёл человек ко мне, и что я могу сделать, если у меня день расписан митингами без перерывов, back to back? Да, я в офисе, но подойти и поболтать в произвольный момент времени со мной нереально. И в результате человек сидит и ждёт. Опять потеря эффективности.
И тут снова мы возвращаемся к приёмам удалённой работы. Лично со мной пересечься трудно, а вот почту я режиме многозадачности читаю. И могу вполне ответить на срочные вопросы. - Удалёнщик вынужденно тщательно планирует свою работу. Каждый день он думает о том, что от кого ему понадобится. Максимальное количество вопросов переводится в почту, что снижает нагрузку на других людей, так как их никто не дёргает в случайные моменты времени.
Если есть важный вопрос, то очевидно, что нужно встретиться. Эта встреча планируется и риск, что она не состоится невысок. Люди учатся пользоваться календарями. Люди учатся пользоваться Джирой. Люди учатся показывать свой экран и это часто оказывается быстрее, чем тащить в офисе лида к своему компьютеру. - Плохие менеджеры отсеиваются. Для меня очень явный тревожный звоночек, когда удалёнщика просят работать по времени основного офиса. Ну это "психотравма юности". Как-то пришлось работать с менеджером, который считал, что проект загибается из-за того, что я работаю не по московскому времени. Когда я с большими проблемами для себя перешёл на его время работы, выяснилось, что говорить нам в общем-то не о чем и ситуация на проекте не улучшилась.
Если менеджер знает, что он делает, то у него не будет больших проблем со внятным формулированием заданий, созданием прозрачных процессов и снижением числа срочных проблем до минимума. - Распределённые команды в среднем состоят из более опытных разработчиков. Кадровый голод мучает все IT компании по планете. Но если ограничиваться только местным рынком работников, то проблемы растут.
Прилетел срочный и очень интересный проект на малоизвестной технологии? В масштабах планеты у вас есть шанс найти архитектора, хороших разработчиков и свободного менеджера, готового к работе. На местном рынке шансов нет. Время набора опытных людей исчисляется месяцами. Вы будете делать проект тем, кто у вас есть.
Если вы в индустрии давно, вы наверняка можете припомнить свой опыт, когда сложный проект делался группой джуниоров и разработчиков, которые были опытны совсем в других технологиях. В результате вся команда получает очень много очень интересного опыта, а лиды с менеджерами дополнително получают порцию седины. - Есть возможность оптимизаций за счёт подбора временных зон. Классика тут -- это когда команда тестирования смещена относительно разработки. Поднимается система Continuous deployment и написанный код оказывается на тестировании немедленно. И когда разработчики приходят на следующий день, то у них уже есть дефекты по тому же функционалу. Им не приходится начинать другую задачу, а потом прыгать к предыдущей.
Аналогично, например, с бизнес-требованиями. Закинули заказчику вопрос -- на следующий день уже есть продуманный ответ. Пауза в работе минимальна. - Многие вопросы теряют эмоциональный накал. Когда кто-то наступил на какую-то проблему, то велик риск, что он взбудораженный прибежит к источнику этих проблем и наговорит грубостей. Если то же самое будет изложено в письме, то тон обсуждения будет гораздо более спокойный. А спокойное обсуждение проблем очень сильно помогает.
В результате распределённые команды получаются состоящими из более опытных специалистов, которые применяют пргрессивные методы управления своим временем в размеренном спокойном, плановом режиме. И это ведёт к повышению эффективности по сравнению с традиционными командами.