Привет! Меня зовут Андрей, я продакт-менеджер команды Passenger в inDriver. В этой статье расскажу, как из маленькой якутской команды мы превратились в большой департамент, который работает из разных точек мира. И не просто превратились, а еще и научились эффективно работать и взаимодействовать друг с другом (по крайней мере, нам так кажется). Погнали!

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

2 часовых пояса

Команда Passenger образовалась в феврале 2021 года. Как понятно из названия, мы занимаемся развитием пассажирского модуля в приложении inDriver. Изначально команда состояла из нескольких человек, базировавшихся в нашем основном офисе в Якутске (GMT+9). Затем мы начали разработку нового масштабного проекта и стали активно расширяться.  

На тот момент у нас был один человек, который работал не в Якутске — тестировщица Катя из Сочи (GMT+3). Вообще, она тоже из Якутска, но не очень любит холода, поэтому перебралась поближе к теплу. 

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

Когда появилась Катя, мы начали изменения в процессах по совместной работе. У нас SCRUM и SCRUM-события, которые важно делать совместно со всеми: дейлики, планирования, ретро, PBR'ы (Product Backlog Refinement). Все это необходимо было планировать в таком часовом поясе, чтобы было удобно и для Якутска, и для Сочи.

Изначально Кате было не очень удобно, потому что многие синки начинались, когда в Сочи было 9 утра (а в Якутске уже 15 часов). Долго договаривались, переходили на текстовые стендапы одно время, но в итоге оставили это время для коротких созвонов.

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

4 часовых пояса

Летом 2021 года мы поняли, что рынок Якутска исчерпан в плане подходящих нам людей. Тогда мы посовещались и решили, что готовы искать коллег из других городов России. Так у нас появились бэкенд-разработчик Никита из Новосибирска (GMT+7), Android-разработчик Антон из Хабаровска (GMT+10), а также продуктовый дизайнер Коля из Москвы (GMT+3)

Исходя из этих изменений, выработали 4 правила, которых придерживаемся до сих пор:

  1. Флоу работы учитывать согласно часовым поясам. Разные часовые пояса — это не минус, если правильно распределять время работы ребят.

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

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

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

Что касается конкретных процессов, все стендапы мы оставили в 9 утра по Москве. Классическая ситуация: разница большая — 6 часов с Якутском, 7 — с Хабаровском. Получается, если я работаю в Якутске, у меня есть 3 часа с 15 до 18 часов на то, чтобы команда могла общаться друг с другом. После стендапа те или иные вопросы разбираются непосредственно с конкретными участниками команды. 

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

5 часовых поясов

В начале 2022 года к нам присоединился iOS-разработчик Нурбек из города Нур-Султан (GMT+6) в Казахстане. В этот момент наш Agile Coach Тима придумал хорошую штуку — дашборд, в котором мы смотрим, какие задачи делают все участники нашей команды. Мы решили не ограничиваться тикетами разработчиков в Jira: там отображены задачи аналитика, дизайнера и других ребят. 

Скрин типов задач в Jira
Скрин типов задач в Jira

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

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

Пример SCRUM-дашборда в Jira
Пример SCRUM-дашборда в Jira

Например, разработчик понимает, что предполагается какая-то задача. И он говорит: «О, в Discovery попала задача, расскажите подробнее, какие там требования». И уже на этапе Discovery ребята начинают задавать вопросы и уточнения, что сокращает нам флоу, и задача сразу готовится в Delivery. Процесс не самый идеальный, но задачи поступают декомпозированными и с более точными сроками. 

Плюс мы отошли от ватерфола, начали обсуждать сторипойнты, и у наших разработчиков поменялось мышление. Раньше было: «Я считаю столько-то». А сейчас: «Я считаю столько-то, но давайте еще послушаем QA-инженеров». Ребята поняли, что их работа зависит от других. 

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

Чаще всего в Telegram мы делимся мемами (но не только)
Чаще всего в Telegram мы делимся мемами (но не только)

Что мы поняли

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

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

Мы можем улучшаться и в тайм-менеджменте. Такие простые вещи, как встречи с 15 до 18 часов по Якутску проходят не так органично, как хотелось бы. Ребята могут готовить пул вопросов заранее, более организованно относиться к этому времени. Понимать, что есть время для обсуждений, а есть для разработки.

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

Типичный пост в Slack
Типичный пост в Slack

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

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

Еще в Google Calendar есть классная штука для часовых поясов. Ставишь свое рабочее время, обеденное, какие-то другие дела. Мы стараемся не нарушать work-life balance и, например, москвичам не ставить встречи слишком рано. 

Я работаю из офиса в Якутске, поэтому все встречи у меня проходят во второй половине дня
Я работаю из офиса в Якутске, поэтому все встречи у меня проходят во второй половине дня

Советы и лайфхаки

Правила созвонов нашей распределенной команды:

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

  • Микрофон включаем только тогда, когда говорим.

  • Не отвлекаемся на соцсети.

  • Создаем вокруг атмосферу, чтобы никто не отвлекал вас во время звонков.

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

  • Голосом передаем слово. Как правило, это делает фасилитатор.

  • Объясняем, какие инструменты будем использовать.

Соблюдение правила «»

Ответьте на следующие вопросы:

  • Поставленная цель. Зачем проводим встречу?

  • Продукт. Что нужно получить в итоге? Какой результат встречи ожидаем?

  • Приглашенные участники. Кто должен быть?

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

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

Нюансы работы фасилитатора в распределенной команде:

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

  • Всегда резюмируем по итогам каждого этапа.

  • Даем четкие инструкции, как действовать участникам (Action points).

  • Визуализируем информацию (обычно используем для этого Miro).

  • Даем слово каждому, чтобы никто не присутствовал на встрече молча.

На этом все. Хочу поблагодарить нашего Agile Coach Тиму за помощь в создании материала. Если у вас есть вопросы по работе нашей команды — пишите, на все постараюсь ответить :) 

Комментарии (2)


  1. saipr
    03.06.2022 11:51
    +5

    как наша команда научилась эффективно работать в 5 часовых поясах

    А я расскажу как мы работали в разных часовых поясах в 1997-2000 г. в ЗАО "Микротест". Тогда ЗАО Микротест стало одним их главных подрядчиков по строительству СПД МПС (Сеть Передачи Данных Министерства Путей Сообщения) России — оптоволоконной сети всероссийского масштаба. Руководством компании принято было решение иметь три офиса: Екатеринбург, откуда родом Микротест, Тюмень и, конечно, столица — город-герой Москва. Задумка была вести круглосуточное проектирование (а проектные работы на начальном этапе съедали чуть ли не 90% времени) и разработки. Что не успели сделать в Москве передавалось в Екатеринбург, затем Тюмень и по кругу. И процесс был налажен и и функционировал. Удаленка, с точки зрения, работы на дому, тоже присутствовала.


  1. rotorobotor
    04.06.2022 19:31
    -2

    А что вы вообще делаете-то?