Удаленная команда: проблемы в управлении, о которых никто не говорит

Приветствуем вас в блоге томского IT-сообщества! Здесь мы пишем об интересных кейсах и опыте томских IT-компаний по разработке и продвижению своих продуктов. А еще мы проводим медиаконференцию «Город IT 2020: продуктовый сезон», где будем обсуждать темы, которые будут затрагиваться в этом блоге. Больше информации о Городе IT 2020 можно найти тут.

Эта статья расскажет про компанию Standuply и их опыт по организации работы распределенных команд. Передаём им слово.

Привет! Меня зовут Артем Бородин. Работаю в качестве менеджера проектов и продуктов уже более 10 лет. Последние 4 года тружусь над Standuply, платформой для управления процессами в удаленных командах. Там я сооснователь и директор по продукту. Все эти годы я наблюдал реалии, связанные с управлением распределенными командами, и очень много над этим думал. Своими размышлениями я решил поделиться с вами.

Звучит знакомо?

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

Но вам также должны быть знакомы следующие фразы:

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

Куда свернула мотивация удаленного труда?

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

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

В свое время в Кремниевой долине такие гиганты, как Google, Microsoft, Intel и т.д., в буквальном смысле жадно «пылесосили» и вбирали в себя всех лучших талантов поблизости. Поэтому, когда стало возможным организовывать удаленную занятость, новые стартапы стали смотреть за пределы штата и страны.

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

Эта парадигма в дальнейшем станет главенствующей в решении поиска удаленных сотрудников.

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

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

К сожалению, эта парадигма позже вытеснила все остальные, преобразовавшись в своеобразную Химеру.

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

Индустрия IT-разработки кардинально изменилась за последние 20 лет. Это особенно заметно по изменениям в различных методологиях, сильно эволюционировавших к текущему моменту.

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

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

Изначальный порядок и вес ценностей организации удаленных команд всегда предназначался только для определенных групп людей, которым он подходил. Но современный рынок сказал: «Мы любую команду можем сделать удаленной, потому что это выгодно/за это надо меньше платить». На первый план вышла экономия затрат. Если можно за эти же или меньшие деньги нанять разработчика из другого города/страны, зачем переплачивать?

Однако на деле не любая команда к этому готова, несмотря на возросшую самоорганизованность людей.

Есть много компаний, которые:

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

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

Когда я работал в одной крупной российской компании, у нас была команда в офисе. Практически во всех крупных компаниях проджект-менеджеры тоже планируют определенное количество времени на сотрудника. Мы, например, планировали по 32-34 часа в неделю на разработчика.

Получается, что в среднем разработчик в офисе эффективнее более чем на 50% в сравнении с удаленной командой из примера? Потому что на него там планируется задач на 20 часов, а 20 часов остается на «бюрократию» плохо идущих процессов?

Конечно, нет!

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

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

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

Standuply — это мощный, но простой инструмент, автоматизирующий множество Agile-процессов и помогающий командам экономить свое время. С помощью Standuply можно автоматизировать такие процессы, как стендапы, ретроспективы, груминг бэклога, покер планирования, опросы 360 и т.д.

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

Из общения с клиентами Standuply мы понимаем, как ведут себя наиболее успешные распределенные команды:

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

Например, если бы вы были командой из одного офиса и планировали задачи на 40 часов, то на удаленной работе вам пришлось бы стремиться планировать как минимум столько же. А в перспективе делать больше, чем когда вы были co-located.

Только неуспешная удаленная команда воспринимает проблемы в коммуникации как норму, тратя на нее гораздо больше времени

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

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

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

Другой пример, стендапы: мы находимся рядом и нам нужно собраться. Мы заходим в одну комнату, тратим 15-20 минут и возвращаемся на место. Проводить стендапы в распределенной команде сложнее: всех надо оповестить, не у всех работает гарнитура, могут быть проблемы со связью.

Соответственно, будь мы в одном офисе, процесс не занимал бы столько времени.

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

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

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

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

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

Я наблюдал их довольно часто, чтобы определить повторяющиеся паттерны. Более того, думаю, что у меня есть несколько советов о том, как преодолеть эти проблемы.

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

Для этого вам необходимо:

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

Но иногда, я думаю, это может навредить больше, чем помочь. И вот почему.

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

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

Асинхронный стендап — это самая первая и основная фича, с которой начинался Standuply четыре года назад. Сегодня можно отвечать на стендапы с помощью текста, голоса или видео и перевести в асинхронный режим большинство Agile-процессов.

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

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

Вам поможет:

Желательно, чтобы было много небольших дробных коммуникаций.

Когда co-located Scrum команда проводит планирование итераций, все берут на себя задачи и работают как бы над единым инкрементом.

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

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

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

Здесь есть два основных момента:

Отдельно про законы и правила мы поговорим позже.

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

Если про стандартный митинг мы говорим: «По итогу мы должны к чему-то прийти/уложиться в определенное короткое время», то про эти встречи: «Это нужно, чтобы просто пообщаться».

Это называется пространством для управляемого хаоса.

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

Когда люди переходят на асинхронные процессы, это не значит, что они все свои стендапы заменяют текстом и больше не общаются голосом. Большинство из них проводят стендапы три-четыре дня в неделю, с понедельника по четверг, отвечая текстом, используя Standuply.

А в пятницу они проводят запланированную сессию на час-два, чтобы вживую созвониться и, как может показаться, неэффективно пообщаться: обсудить, что было сделано за вчера, за неделю, иметь возможность пофлудить и поперебивать.

Но разница заключается в том, насколько постоянно это происходит.

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

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

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

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

Если вы и этого не делаете, то непонятно, какой смысл говорить о какой-то эффективности в принципе.

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

Желательно, чтобы такого не было.

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

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

Должны быть изначально заложенные затраты на хорошую инфраструктуру — камеры, гарнитуры, софт и прочее. Причем выделенные как сотрудникам/командам, которые работают из офиса, так и тем, кто коммуницирует с ними удаленно.

Для этого нужно:

Должно быть простое правило насчет опозданий: начинать нужно тем составом, который есть. Если вы договорились, что у вас созвон/стендап в 12:00, а пришло 80% сотрудников, вы не ждете оставшиеся 20%.

Должна вестись запись митинга, чтобы те, кто подошел позднее, могли быстро вникнуть в процесс. Если что-то непонятно, участники не переспрашивают, а ждут follow-up, который вы отправите после митинга.

Ключ к успеху распределенных команд кроется в одном факторе — люди.

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

80% успеха — это правильно подобранные люди в команду. Процесс найма в распределенную команду должен быть отстроен еще лучше и детальнее, чем в офлайн-команду.

Что значит неподготовленные люди? Это люди без должного опыта, без понимания ценностей и методологий удаленной работы в целом и с низким уровнем самоорганизации.

Очень важно иметь свои правила и законы, которые должно быть частью культуры компании. Это базовые и понятные вещи, которые не просто четко сформулированы, а донесены на интуитивном уровне. Это должно быть у всех на подкорке.

Чем правило отличается от закона?

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

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

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

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

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

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

Этот закон дает возможность слушать и слышать позицию другого по проблематикам в команде.

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

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

Дальше подключается правило «Критикуешь — предлагай». Так и происходит процесс улучшения работы.

Например, у нас одно из правил — стараться писать развернутые ответы на асинхронные процессы, не отделываться короткими сообщениями.

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

Мы не очень любим рассуждения на уровне: «Было бы здорово сделать вот так, тогда все будет классно работать».

Нам больше нравится такая парадигма: «Смотрите, тут было не очень, я сделал по-другому. Это первая версия, она очень примитивная, но она уже что-то решает и имеет эффект. Давайте обсудим?».

Чувствуете разницу?

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

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

Если ты что-то берешь в работу, желательно, чтобы это было на перспективу постоянных улучшений.

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

Эмпатия — очень важный фактор для построения успешной распределенной команды.

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

Есть несколько способов для развития эмпатии.

Пример: наша команда поддержки работает удаленно. У нас есть специальный канал в Slack, в который интегрировано общение команды поддержки из Intercom.

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

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

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

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

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

А когда ты работаешь удаленно, тебе нужно более эффективно решать какие-то вопросы. И наличие на другой стороне «своего» человека, к которому проще обратиться, чем к остальным, помогает ускорить процесс и работать эффективнее.

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

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

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

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

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

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

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

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

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

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

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

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

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

Сейчас многие компаний используют Standuply, в том числе для решения этой проблематики, тем самым организуя у себя свой внутренний Q&A. В ней аккумулируются знания и ответы по самым разным вопросам, которые поднимались внутри команды и на которые отвечали или сами сотрудники, или внешние эксперты.

Обеспечьте постоянство процессов в вашей команде

Эффективность команды во многом зависит от последовательности и постоянства процессов в ней. И поддерживать это в распределенных командах очень трудно.

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

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

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

По принципу Паретто в любом процессе есть то, что дает тебе 80% успеха. В распределенных командах это — люди.

В работе с ожиданиями сотрудников 80% успеха тебе дает правильно выстроенные 1-on-1’ы, которые должны проводиться регулярно. Главный секрет и инсайт 1-on-1 встреч — это обеспечение их постоянства.

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

Например, на 1-on-1 у вас происходит такой диалог:

Затем вы собираетесь через три месяца, и ты спрашиваешь:

Для вас это не должно быть сигналом как-то наказать сотрудника!

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

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

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

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

Синхронизируйте время и цели со всеми, кто работает удаленно

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

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

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

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

Про цели часто забывают даже в рамках scrum разработки, где они «как бы» обязательны.

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

Поэтому эффективно делать запись такого анонса, отправить в чат, закрепить ее, чтобы было постоянно на виду, и периодически на это ссылаться. Можно также запустить опрос, например: «А познакомились ли вы с целью, которую мы выбрали на эту итерацию?»

Мы создали целый шаблон Team Goals в Standuply для удобной и эффективной синхронизации целей.

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

Желательно, чтобы цель упоминалась на каждом собрании, фокусируя команду на ее достижение.

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

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

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

Не стоит пренебрегать таким инструментом, как обычный здравый смысл. Спросите себя: а вы сами работали бы эффективно по такому расписанию?

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

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

Это та же философия, о которой мы говорили ранее: успешная распределенная команда не считает нормальным тратить 50% времени на сломанные коммуникации и планировать из-за этого задачи на 20 часов.

Успешная распределенная команда будет планировать на те же 40 часов и решать вопрос с налаживанием коммуникаций.

То есть нужно искать ответ в плоскости «Как с отсутствием общего окна времени мы могли бы работать так же эффективно, как с его наличием?»

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

Избегайте излишнего контроля

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

Чаще это приводит лишь к тому, что больше времени тратится на решение вопросов коммуникации или мотиваций команды.

Успех состоит в том, чтобы давать как можно больше свободы своей команде.

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

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

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

Могу с уверенностью сказать, что так поступают только неэффективные команды.

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

Они ему может быть даже и не понадобятся, но на уровне безусловных инстинктов человек начинает думать: «Если вдруг что-то случится, какие есть обходные способы себя подстраховать?»

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

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

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

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

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

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

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

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

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

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

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

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

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

Откровенно говоря, наши аутсорсеры изначально были сильно удивлены такому формату работу. Но в итоге мы часто видим следующую картину.

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

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

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

Вот и все, друзья!

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