Танго втроём или Бермудский треугольник: как организовать работу трёх команд в одном проекте

Дени Курумов

Инженер по тестированию

Инженерам по тестированию часто приходится работать над проектами, в которых задействованы несколько команд. Но что делать, если команды находятся в разных странах и часовых поясах? А ещё обладают разным менталитетом, говорят на разных языках и по-разному смотрят на разработку. Расскажем, как мы решаем возникающие на этом пути проблемы в AliExpress Россия.

Сложность №1: время

Две из трёх команд находятся в Москве и Питере. А третья — в Ханчжоу, с разницей во времени +5 часов. Так, в Китае начинали работать слишком рано для нас, мы заканчивали работать слишком поздно для них. И времени для коммуникации друг с другом в итоге оставалось мало.

Решение было простым. Мы сразу определили, что будем ориентироваться на московское время, так как было легче, чтобы одна команда ориентировалась на две другие, нежели наоборот. Китайские коллеги использовали Time Zone Converter, который позволил не пропускать время совместных встреч. Благодаря нему, им не приходилось пересчитывать в уме время. Таким образом, была решена проблема с опозданием или пропуском встреч из-за неправильно пересчитанного времени.

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

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

Отдельная боль работы с азиатскими компаниями — доступы. Китайцы очень трепетно относятся к безопасности, поэтому процесс получения прав и доступов разбивается на несколько этапов и отнимает часы. Мой рекорд — это 6 ступеней апрувов и 2 рабочих дня. И это впечатляющий результат, если сравнивать с первыми попытками получения доступов, на что мог уйти не один день.

Это настолько больная тема, что мы сделали по ней мерч “Hi need access”, который можно увидеть ниже. Кстати, эта толстовка дает +5 к скорости получения доступов.

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

Да, иногда это занимает три дня, зато мы не тратим время, пока проводим тесты.

Сложность №2: язык и культура

Главное в работе с несколькими компаниями одновременно — определиться с терминами и убедиться, что все всегда понимают, о чём именно идёт речь.

Разберу на примере. Два года назад китайские коллеги попросили меня протестировать security code. Я решил, что это какой-то токен или что-то связанное с безопасностью, индивидуально генерирующееся для каждого пользователя.

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

Вторая проблема — имена. Ниже написано, как зовут некоторых моих китайских коллег.

Сложно понять, как правильно обратиться к человеку. В Китае придумали гениальное решение — flower names. В чём их суть?

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

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

И теперь для них я Денг-ми. Это название красного китайского фонарика с загадками. Его можно поймать, отгадать загадку и отпустить дальше. Выглядит они так

Источник: https://jl.huatu.com/2018/0228/1504089.html

Особенно в этом плане повезло носителям имени Дмитрий. Ведь «Дима» переводится с китайского никак иначе, как »«код».

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

Кстати, правило 9-9-6 пошло нам на пользу, потому что китайские коллеги почти всегда на связи.

Сложность №3: структура

Когда вас трое, сложно понять, кто кем управляет, кому писать по разным вопросам и так далее. Это было ожидаемо, поэтому я заранее сделал таблицу, где расписал:

• с кем я работаю;
• какие у коллег роли в проекте;
• к кому и по каким вопросам можно писать.

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

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

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

Кроме того, если разработчик не отвечает на ваши сообщения, в Китае совершенно нормально написать его менеджеру. У нас это скорее воспримут как «предательство» и затаят обиду.

Конфликты

Представьте, у вас есть два куска кода, которые делают одно и то же. Один из них написан лаконично — в несколько строк, — а второй растянут на 60. Какой из них лучше?

Ответ для тестировщика — тот, который работает. Тут дело даже не в том, что лучше, а в подходе, которому следуют западные и азиатские разработчики. В России считают, что «краткость — сестра таланта». В Китае же проект — в том числе код — должен быть большим, как говорится, его должно быть видно издалека, иначе непонятно, чем занимался сотрудник.

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

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

Большую часть других конфликтов нам помогают решать медиаторы — проджект-менеджеры или аналитики. Они собирают претензии разработчиков друг к другу и на их основе предлагают компромиссное решение. Проверено — работает.

И немного итогов

В конце подытожу, как организовать работу трёх команд в одном проекте:

• задавайте вопросы — чем раньше вы начнёте это делать, тем лучше;
• выясните, с кем вы работаете: какая у коллег корпоративная культура, как и когда они привыкли общаться и так далее;
• определитесь с терминами — это поможет избежать недопонимания;
• выясните заранее, что вам понадобится для комфортной и быстрой работы.