Привет, меня зовут Григорий. Я работаю тимлидом распределённой команды в Positive Technologies. Это мой рассказ, как я стал лидом распределённой команды, с какими проблемами сталкивался, как их решал и какой опыт получил. Мотивами к написанию статьи стали два факта: во-первых, кто-то сейчас может бороться с похожими проблемами, и мой опыт будет полезен, во-вторых, те, кто уже прошёл этот путь дальше меня, могут подсказать, что меня может ждать дальше.

С чего всё началось

У нас было три небольших группы разработки. Каждая жила по своим правилам, у каждой был свой список задач, свои цели и свой лид, одним из которых был я. В какой-то момент все три группы объединили в одну команду, а меня назначили тимлидом этой новой команды. Команда — распределённая, разброс по часовым поясам — от Москвы до Новосибирска, из 11 человек только двое сидели рядом в офисе, 5 человек, включая меня, работали удалённо. В таких условиях была опасность превратиться в группу программистов, каждый из которых получает задачу и выдаёт кусок кода. А мне хотелось построить команду, в которой люди будут участвовать в жизни продукта, который мы делаем.

Проблемы со списками задач

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

Чтобы навести порядок, я начал договариваться с каждым человеком в команде перейти обратно в общий трекер и не забивать на статусы. От себя я пообещал, что за 2-6 недель наведу порядок в трекере. А для того, чтобы история поехала, ввёл несколько правил. Во-первых, разработчик берёт в работу самую первую задачу из списка. Не надо смотреть на приоритеты, на северити, читать комментарии или что-то спрашивать. Если задача вверху, значит её нужно делать. Тем самым мне удалось уменьшить нагрузку на ребят, избавив их от трат времени по выяснению, что нужно делать. Во-вторых, я снял ответственность за то, что была сделана ненужная задача. Т.е. если ненужная задача оказалась вверху списка, то виноват в этом лид, т.е. я. Без каких-либо оговорок.

Само собой система не была (и не должна была быть) статичной. Если кому-то казалось, что стоит поменять порядок задач, или внести новую задачу в список, то это обсуждалось. Если это было обосновано, то список менялся, если у меня были возражения, то я объяснял, почему так. Самым частым случаем была ситуация, когда я вытаскивал наверх несколько якобы неважных задач, потому что они дополняли работы по другим важным задачам.

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

Проблема разных контекстов и способы борьбы с ней

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

Эту проблемы мы решали ежедневными созвонами всей командой на 30 минут. Формально это была ежедневная планёрка, на которой мы обсуждали задачи. Кто что делает, с какими проблемами столкнулся, какая помощь нужна. Я же, введя такие планёрки, решал две своих проблемы: распространение общего контекста о проектах, выстраивание связей между людьми внутри команды, чтобы уменьшить количество ситуаций "с нашей стороны пули вылетели".

Сейчас эти встречи мы больше не проводим, потому что в них отпала необходимость. Но тогда на старте они нам очень помогли.

Чаты как способ выстраивать связи

Команда — это система, частями которой являются живые люди. И как любая другая система, её характеристики меняются от того, какие связи образовались между её элементами.

В удалённой работе нет другого способа формирования нужных связей, кроме как создавать чаты. Нередко можно услышать "у нас слишком много чатов". Порой, это действительно так. Но если каждый новый чат помогает решить проблему, то придётся мириться с их количеством. В целом, можно создать несколько постоянных чатов, а остальные формировать на время решения конкретной задачи. Часто замечал, что для решения какой-то рабочей проблемы достаточно создать чат, позвать в него людей, которые нужны для решения проблемы, описать проблему и подождать. Каждый участник начинает прикладывать усилия для решения проблемы. Т.е. моя задача была в том, чтобы определить необходимый состав группы для решения проблемы и начать формировать связи между людьми. В офисе для этого служат неформальные разговоры на рабочих местах или же официальные совещания, а в удалённой работе связи формируются в чатах.

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

1:1 важнее, чем когда-либо

Встречи один на один стали критически важными. Сам я пришёл к этому не сразу, наверно, спустя почти год.

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

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

Растить замену ещё полезнее

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

На мой взгляд, полезная мысль. Если размеры команды и желания людей позволяют, то лучше растить сразу 2 или 3, тогда лучше начнёшь замечать свои собственные проблемы, на которые раньше не обращал внимания. Для удалённой работы это очень важно, потому что получить фидбек для самого себя намного сложнее, чем при работе всем вместе, ведь мой начальник тоже сидит за 1000км от меня и тоже сталкивается с похожими проблемами, когда хочет поговорить со мной.

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

Итого

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