Привет! Меня зовут Андрей, я продакт-менеджер команды 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 правила, которых придерживаемся до сих пор:
Флоу работы учитывать согласно часовым поясам. Разные часовые пояса — это не минус, если правильно распределять время работы ребят.
Заранее смотреть календари на планируемый квартал в зависимости от городов, чтобы не было сюрпризов во время планирования спринтов и не происходило резкого снижения velocity.
Собирать команду офлайн хотя бы раз в год, чтобы ребята познакомились лично.
На звонках по возможности сидеть с включенными камерами, чтобы повышать открытость к диалогу.
Что касается конкретных процессов, все стендапы мы оставили в 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 Тиму за помощь в создании материала. Если у вас есть вопросы по работе нашей команды — пишите, на все постараюсь ответить :)