Распределенная Команда И Тимлид Удаленно

Здравствуйте, меня зовут Григорий.

Я работаю руководителем распределенной команды в Positive Technologies. Это моя история о том, как я стал руководителем распределенной команды, с какими проблемами столкнулся, как их решил и какой опыт приобрел.

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



Как все началось

У нас было три небольшие команды разработчиков.

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

В какой-то момент все три группы были объединены в одну команду, и меня назначили руководителем этой новой команды.

Команда была распределена, разбросана по часовым поясам — от Москвы до Новосибирска, из 11 человек в офисе рядом сидели только двое, 5 человек, включая меня, работали удаленно.

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

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



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

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

Списки задач были противоречивыми.

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

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

Я от себя пообещал, что через 2-6 недель наведу порядок в трекере.

И чтобы история развивалась дальше, он ввел несколько правил.

Сначала разработчик берет на себя самую первую задачу из списка.

Не надо смотреть на приоритеты, северность, читать комментарии или что-то спрашивать.

Если задача находится наверху, то ее нужно выполнить.

Таким образом, мне удалось снизить нагрузку на ребят, избавив их от траты времени на выяснение того, что делать.

Во-вторых, я снял с себя ответственность за выполнение ненужной задачи.

Те.

Если ненужная задача находится вверху списка, то виноват лид, т. е.

я.

Без всяких оговорок.

Конечно, система не была (и не должна была быть) статичной.

Если кто-то считал, что стоит изменить порядок задач, или добавить в список новую задачу, то это обсуждалось.

Если это было обоснованно, то список менялся, если у меня были возражения, то я объяснял, почему так.

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

Важная заметка.

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

Поэтому самое главное — убедить людей поддержать вас, а затем сделать то, что обещали.

Никакие правила не могут с этим справиться.



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

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

Мы решили эту проблему, созванивая всю команду ежедневно на 30 минут. Формально это была ежедневная встреча, на которой мы обсуждали задачи.

Кто чем занимается, с какими проблемами столкнулся, какая помощь нужна.

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

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

Но на старте они нам очень помогли.



Чаты как способ налаживания связей

Команда – это система, частями которой являются живые люди.

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

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

Нередко можно услышать «у нас слишком много чатов».

Иногда это правда.

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

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

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

Каждый участник начинает прилагать усилия для решения задачи.

Те.

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

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

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



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

Встречи один на один стали критически важными.

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

Поэтому тому, чтобы получать и давать обратную связь, нужно уделять время и силы.

Когда мы впервые начали звонить тет-а-тет, разговоры занимали весь отведенный час, а под конец все равно оставалось желание поговорить.

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

Я отменяю такие встречи, только если нахожусь в командировке.



Выращивание замены еще полезнее

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

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

На мой взгляд, полезная идея.

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

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

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



Общий

За время работы удаленным руководителем я приобрел собственный набор навыков, которые позволили мне решить некоторые наши проблемы.

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

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

Теги: #Карьера в IT-индустрии #Удаленная работа #Управление персоналом #удаленное управление

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.