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

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

А если собрать команду в одном месте нельзя или это очень дорого? А если речь идёт не о неделе/двух, а о проекте длиной в полгода-год? А если твоя команда мало того, что распределена географически, так ещё и работает в двух таймзонах, а заказчик — в третьей? Сегодняшняя заметка про управление географически-распределённой командой в разных таймзонах.

Итак, с какими сложностями сталкивается и заказчик, и руководитель проекта, и проектная команда во время географически-распределённых проектов в разных таймзонах (далее будем называть это распределенными проектами)?

Вызовы для заказчика и стейкхолдеров

Задержки в коммуникации и принятии решений. Разница в часовых поясах означает, что ответы на вопросы и обратная связь не приходят мгновенно. Простые уточнения могут растягиваться на часы или даже дни, что замедляет прогресс проекта и может приводить к недопониманию.
Сложности с синхронизацией. Найти удобное время для регулярных синхронных встреч (демонстрации продукта, обсуждение требований, совещания по техническим решениям) становится настоящим квестом. Особенно, если в проекте есть Австралия и Европа, где практикуется переход на зимнее/летнее время.
Снижение прозрачности. Заказчику может быть сложнее ощущать «пульс» проекта, если он не видит команду в офисе.
Управление ожиданиями. Необходимо постоянно управлять ожиданиями стейкхолдеров относительно сроков, процессов коммуникации и скорости реакции, учитывая распределенность команды.

Вызовы для проектной команды

Во‑первых, почти все вызовы для заказчика и стейкхолдеров справедливы и для проектной команды:

Задержки в коммуникации и принятии решений. Для проектной команды этот вызов стоит в полный рост — написал бизнес‑аналитик имейл с вопросами к стейкхолдеру, наш архитектор подготовил варианты архитектуры и ждёт обратную связь от архитектора заказчика, наш DevOps подготовил предложение по Blue‑green или Canary развертыванию, и т. п. — все эти обращения могут висеть неделями, если ими не заниматься.
Сложности с синхронизацией. Найти удобное время для встречи с нужным SME и обсудить назревшие вопросы (как вариант — заранее высланные имейлом и уже неотвеченные в течение недели) — если заказчик в Австралии, а ты — в Европе, это не всегда просто.
Снижение прозрачности. Поскольку члены проектной команды не имеют прямого доступа к заказчику, то процессы принятия решений становятся очень похожими на черный ящик.

А, во-вторых, у проектной команды есть ещё целый набор дополнительных вызовов:

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

Нарушение рабочего/личного баланса. Члены команды могут быть вынуждены работать в неудобные часы (очень рано утром или поздно вечером), чтобы участвовать в общих встречах. Это приводит к хроническому недосыпу и выгоранию.
Чувство изоляции и оторванности. Отсутствие неформального общения с коллегами, «коридорных» разговоров и личных встреч может привести к чувству одиночества и снижению причастности к команде.
Сложности с совместной работой. Командные процессы, такие как мозговые штурмы, или оперативное решение внезапно возникших проблем, становятся затруднительными.
Проблемы с доступом к информации. Несмотря на общие хранилища, иногда оперативно получить нужную информацию или помощь от коллеги, находящегося в другой таймзоне, бывает сложно. Особенно остро стоит вопрос с поиском нужного SME на стороне заказчика и получение от него нужной информации.
Культурные различия. Помимо таймзон, распределенные команды часто сталкиваются с культурными различиями, которые могут влиять на стиль общения, принятие решений, отношение к иерархии и даже к критике.

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

Что обычно помогает справляться с этими вызовами

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

Под инструментарием я не имею в виду стандартные Jira/Confluence, аккуратное планирование спринтов, оценку всех задач и их трекинг, создание и поддержание единой базы знаний (Wiki, Confluence, Notion), где хранится вся актуальная информация о проекте - это само собой. А вот что сверх этого?

Проектирование команды

При проектировании сетапа команды важно объективно оценить объём работы, которую нужно делать в офисе у заказчика. Ну или как минимум, в одном с заказчиком часовом поясе. Бывают проекты, где одного онсайт деливери менеджера/пиэма достаточно, а бывают, где на сайте нужен архитектор, пара аналитиков, лид SRE, и прочие члены команды для эффективных синхронных коммуникаций и для «проталкивания» асинхронных коммуникаций оффшор команд.

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

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

Требования к членам команды

Распределенный проект конечно же налагает дополнительные требования к членам распределенной команды:

Все члены команды:
- Ответственность, умение выполнять взятые на себя обязательства
- Самоорганизация. дисциплина
- Способность описывать требования, писать отчёты и готовить другие документы
- Готовность менять рабочий график в зависимости от потребностей проекта (рано вставать / поздно ложиться)
Оффшор лиды и BA:
- Умение обобщать и делать акценты на главном
- Навыки деловой переписки
- Умение вовремя эскалировать вопрос
- Умение вести встречу и готовить протоколы
- Настойчивость при получении нужной информации
- Умение работать в условиях неопределённость
Онсайт команда:
- Высокие коммуникативные навыки, проактивность
- Настойчивость и аккуратность
- Умение вести встречу и готовить протоколы

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

Общий календарь

Уже лет 10 как на всех своих проектах я использую общий календарь (shared calendar). Google Calendar / Microsoft calendar обладают такой функциональностью. Общий календарь — это когда все события и совещания, так или иначе касающиеся моего проекта, планируются в специальном календаре, к которому есть доступ у всей команды и стейкхолдеров. И даже если ты не приглашен на совещание, ты можешь к нему удаленно присоединиться. Зачем это нужно? Затем, что:

Мы получаем единый источник информации обо всех синхронных коммуникациях
Это почти полностью заменяет проектный артефакт «план коммуникаций» и по многим параметром гораздо эффективнее его
Руководство проекта и стейкхолдеры могут просматривать календарь и присоединяться к интересным/важным митингам

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

Запись и протоколирование совещаний

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

Я предпочитаю хранить протоколы либо в Confluence (с использованием соответствующего шаблона от Atlassian), либо в Google Docs. Google Docs хорош тем, что если ваши коммуникации основаны на Google Suite, то вы из коробки получаете возможность протоколирования совещания из Google Meet в Google Docs.

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

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

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

Делаем коммуникации внутри команды более эффективными

Ежедневные синки на уровне лидов

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

Внешние зависимости и проталкивание коммуникаций

Также мы ведём документ по зависимостям, которые у команды есть на заказчика - все эти асинхронные обращения к SME заказчика могут быть очень длительными и неэффективными, если ими не заниматься во время рабочего дня заказчика. Стейкхолдерам нужно аккуратно напоминать о необходимости ответить, дополнительно разъяснить детали, если необходимо, организовать необходимые совещания и привлечь дополнительных SME, и т. п. А кто это будет делать?

Зависит от размера и природы проекта. Но для себя я давно понял, что значимую часть таких асинхронных коммуникаций, если не все (на определённом этапе), должен «проталкивать» руководитель проекта. Во‑первых это позволяет держать руку на пульсе, во‑вторых погрузиться в технические детали проекта, без которых невозможно эффективно работать с заказчиком, в‑третьих это позволяет налаживать и поддерживать контакт с стейкхолдерами, и т. п. Другое дело, что это отнимает очень много времени и тут важно найти правильный баланс. И здорово, если «на сайте» есть ещё кто‑то из проектной команды, кто может часть подобной работы взять на себя.

Overlap window и гибкий рабочий график

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

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

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

Отчёты по прогрессу в конце дня

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

1on1s

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

Делаем коммуникации с заказчиком более эффективными

Еженедельные отчеты и статус-митинги

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

Заранее забронированные таймслоты для встречи с командой

Помимо тематических узко-профильных синков (синки с QA-командой заказчика, синки с SREи т. п., хорошо проявил себя подход когда мы заранее планируем на несколько месяцев вперёд или сразу на весь проект ежедневные синки в заранее определённое время. Например, один — автралийским утром, другой — австралийским вечером. На первый приходит только онсайт команда, на второй — онсайт + лиды оффшор команды.

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

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

Признание и празднование успехов

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

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

Ну и совсем замечательно, если удаётся собрать всю или хотя бы часть команды (например, из Европы) физически в одном месте. Ценность таких мероприятий сложно переоценить.

Подведём итоги

Итак:

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

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

А какие подходы вы применяете при работе с распределёнными проектами?

Предыдущие статьи цикла:

Дневники пиэма. Заметка 03: Таймзоны и эффективность распределенных проектов