Как организовать работу команды в разных часовых поясах

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

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

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

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

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

С удаленными сотрудниками и командами всё понятно, а что если специалисты находятся в разных часовых поясах? И при этом временная разница не просто +1 или +2 часа от “Московского”, а например +10 часов. Что тогда? На самом деле, даже, если вся команда работает по московскому времени, а один специалист имеет большой временной лаг, то эффективность всей команды будет сильно страдать.

Так как мы работаем с многими российскими корпорациями, где трудятся десятки ИТ-команд, мы видим как всё у них устроено. Если стоит задача собрать распределенную команду, которая не будет привязана к одному часовому поясу, то это целесообразно делать в следующих случаях:

1. Длинные спринты. Когда спринт занимает от 2 недель.

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

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

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

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

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

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

Такой формат позволяет устранить многие минусы:

- Формат позволяет куче людей не подстраиваться под конкретное время

- Написать и прочитать - это очень быстро. Такой формат удобнее, чем тратить 15-30 минут на созвон

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

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

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

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

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

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

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