Привет! Меня зовут Андрей, я продакт-менеджер команды 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: там отображены задачи аналитика, дизайнера и других ребят. 

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

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

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

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

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

Что мы поняли

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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