Нихон (так называют свою страну японцы) до сих пор остается загадочной и необычной в глазах иностранцев. За ее пределами распространено множество национальных стереотипов, среди которых, например, знаменитое японское качество и эффективность труда. А еще нам известно, что японцы очень ответственные и иногда умирают от переработок. На фоне этого (а также бесконечных сравнений «наших с вашими») может создаться впечатление, что Япония – обитель продуктивности и уж кто-то, а эти ребята знают толк в процессах разработки. Так ли это? Разберем на примере нашего проекта, где заказчиком выступала традиционная большая японская компания.

Вступление

Перед нашей командой стояла нелегкая задача адаптировать существующее PoS-решение под японский рынок и сделать его кроссплатформенным, при этом минимизировав отклонения от существующего решения. Можно сказать, что с одной стороны мы получили карт-бланш на изменение продукта, но в то же время были серьезно ограничены существующей кодовой базой. Нам доверили изменение основных (core) функций, и разработка велась по каскадной модели. Работа над проектом заняла 3 года, за которые мы имели дело с гигабайтами строк кода, совершили десятки командировок из Токио в Казань и обратно и успели поработать с тремя сотнями его участников как со стороны заказчика, так и смежных подрядчиков из Японии, России и Филиппин.

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

Работа в Excel

То самое, что вызывало боль. Microsoft Excel в японских компаниях применяется для всего: документации самой разной детализации (даже если там лишь UML диаграммы), сборника скриншотов с багами, и конечно же, бескрайних полей отчетов, из ячеек которых можно было бы складывать мегапиксельные матрицы. У наших менеджеров Excel просто не выдерживал таких страданий и отказывался работать. К слову, иногда подобная одержимость приобретает причудливые формы. Если для отчетов такой формат еще более или менее привычен, то для девелоперской документации — это экзотика, мягко говоря.

Слишком длинные митинги

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



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

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

Языковой барьер

Япония – страна самодостаточная, и уровень эмиграции там сравнительно невысокий. Поэтому тот самый английский язык, на который уповали мы, там не очень популярен: собеседник с уровнем А2 – это максимум, на который мы могли рассчитывать. Помните, если вы начинаете проект с японцами, то без переводчика не обойтись! С самого начала проекта у нас был человек, без которого наше взаимодействие с японцами было бы просто невозможно – разговаривающий на японском языке проектный координатор, на котором лежала ответственность ведения переговоров и ключевых переписок. Кроме него в переводе документации, писем, и тикетов и на переговорах участвовали несколько переводчиков.
Сложности, связанные с языковым барьером, оставались вплоть до конца проекта – но в таких ситуациях помогала большая уверенность и настойчивость с нашей стороны. Мы понимали, что несмотря на разные языки, перед нами стоит единая цель.

Отчеты всегда и везде

Наш проект осуществлялся по каскадной модели разработки, и обилие отчетности и постоянное обновление план-графиков отчасти этим обуславливались. Нельзя сказать, что обилие отчетности — чисто японская особенность. Но если сравнить похожий проект в России и СНГ с Японией, то дальневосточный колорит проявляется во всей красе. Мне как тимлиду пришлось в полной мере столкнуться со всеми видами отчетных документов как в роли читателя, так и автора – за исключением, пожалуй, финансовых: по качеству с разбором причин багов, по прогрессу, внеочередными техническими, и, конечно же, традиционными для waterfall план-графиками. Каждый из этих отчетов представлял из себя увесистый Excel-файл, разлинованный таблицами в лучших традициях сканвордов для дома престарелых.

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


План-график в японском стиле

Тем не менее, у них был и смысл, и даже благая цель: например, отчет по качеству показывает проблемные места, при его составлении можно докопаться до сути проблемы, а отчет по прогрессу помогал трекать объем выполненной на данный момент работы. К слову, второй со временем обрастал все новыми столбцами, и на его заполнение у менеджера могло уходить до трех часов 2 раза в неделю, а иногда и чаще. С план-графиками вышло еще сложнее: изначально я пытался программным путем брать тикеты из таск-трекера вместе с оценками и накладывать на график их в MS Project, но он оказался очень капризным, и план-графики постоянно слетали и менялись. Отчаявшись, я довольно быстро накидал построение план-графиков – в Excel, конечно.

Разница во времени

Мы работаем по московскому времени, и разница с Японией у нас в 6 часов. Когда я был в командировке, такая разница во времени немного угнетала: ты привык, что в течение рабочего дня, кто-нибудь из близких да и напишет тебе в мессенджеры, то, когда я приступал к работе, то в России еще было 3 часа ночи. Но самые большие неудобства такое явление доставляло во время коммуникации с заказчиком.

Работая с западными коллегами, вы, казалось бы, все время играете на опережение: начинаете работать раньше них и можете спокойно настроиться на рабочий лад, разгрести вчерашнюю почту и подготовиться к митингам. Но нет – представьте себя на месте японцев. Вы находите критический баг, который нужно срочно пофиксить, а разработчики еще спят. Пусть даже вы понимаете, что они будут стараться и продолжат фиксить баг и после окончания вашего рабочего дня, но ощущение вечного опоздания будет усиливаться пропорционально срочности бага. Благо наш координатор работает во Владивостоке, что опережает Японию на 1 час. Это очень выручало, поскольку основной удар негодования он героически принимал на себя и немного демпфировал переживания японцев.

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

Фокус на качестве

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

Если многие процессы и избыточные рутины казались нам бессмысленными, то забота о качестве кода и, как следствие, продукта — это то, в чем мы находили общий язык. В разное время весь код прогонялся по двум статическим анализаторам. Заказчик выделял время на фикс обнаруженных проблем, что не такая частая практика в agile/западных проектах. Кроме того, мы покрывали весь новый и измененный код тестами. Получалось не всегда и полностью, поэтому в целях экономии времени и эффективности основной упор в активной фазе багфикса проекта был на интеграционных тестах. Кстати, одним из наших deliverables был отчет по прогону тестов и покрытию кода – такая забота о качестве отзывалась в сердцах, и мы чаще всего мы находили компромиссы именно на этом поприще.

Также в качестве улучшения качества кода мы предложили японцам практику проведения до 4-х ревью от разных людей включая самого тимлида в зависимости от сложности тикета. В результате это подтолкнуло меня на изучение возможностей автоматического пре-ревью кода в GitLab. Применить все это на проекте я не смог, но написал небольшой шаблон для будущих проектов. Кроме усиления ревью мы добились успехов и в части улучшения автоматического тестирования (unit, integration, smoke).

Метрики производительности (KS)

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

Количество строк кода также применялось для расчета производительности программистов.
На ум приходят сразу куча проблем этого метода: код UI гораздо объемнее, но содержит меньше сложности, а иные 10 строк кода могут быть добыты ценой упорной мозговой деятельности на протяжении нескольких дней. Мы пытались начать оценивать работу в количестве use cases, но выделенных аналитиков не было, а компетенций разработчиков не хватало. Ближе к середине проекта предыдущий тимлид предложил использовать количество методов в качестве метрики объема. В результате мы стали посчитывать и KS и количество методов.

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

Эстимейты и дедлайны

В Японии встречается практика продавить разработчика на более низкие эстимейты и, соответственно, дедлайны, а потом давить на чувство вины («ты же сам говорил»), чтобы «виновник» перерабатывал, пытаясь уложиться в сроки. В нашей ситуации это иногда напоминало торг за дедлайны. Мы убеждали, что 2-3 дополнительных разработчика не ускорят работу над задачей – но на другой стороне провода твердо стояли на своем. С переменным успехом мы героически отстаивали сроки, а в преддверие особенно критичных дедлайнов шли на компромисс, который обычно состоял из переработок и реже привлечением дополнительных ресурсов. Впрочем, мы нередко эти дедлайны успешно проваливали.

Со временем было решено автоматизировать и это явление. Я брал за основу тикеты, добавлял необходимые ревью, возможные баги и… Пытался натянуть это в MS Project. К сожалению, из раза в раз он показывал разный порядок задач и неведомым образом выставлял constraint'ы. Времени было немного, поэтому решил по-быстрому сделать построение диаграмм Ганта в Excel – благо он оказался более предсказуемым и послушным. Таким образом, мы могли спокойно менять эстимейты — вместе с ними менялись и даты завершения. Перестраивать план-графики стало гораздо проще, заказчику они понравились. Хоть проблему проваливания дедлайнов это и не решало, но мы могли заранее предупреждать заказчика о сдвиге сроков.

Традиции

Когда я поехал в командировку в Японию в составе из семи человек, нас условили соблюдать традиционный для японских офисов дресс-код: деловой костюм, светлая рубашка и галстук. Конечно, для программистов, привыкших носить худи в повседневной жизни, это был настоящий вызов. Тем не менее время сыграло свою роль, и появилось чувство причастности (можете называть это стадным инстинктом), которое прибавляло энергии и даже делало в каком-то роде «своим». Картина была занимательная: на станции Шинагава в Токио располагается большое количество офисов больших традиционных японских компаний, куда каждое утро тысячи белых воротничков стекались со всей столицы и пригородов. Зрелище фантастическое!


Источник фото

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

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

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

Клиент – бог

Япония отличается особенным отношением к клиенту. И вероятно такого же отношения ждал от нас наш японский заказчик.

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

Заключение

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

Можно ли сказать, что большинство стереотипов о японцах в работе верны? Все не так однозначно.

Субординация между начальством и подчиненными действительно ощущается в Японии сильнее, но в последнее время молодежь все чаще ломает систему. Переработки встречаются часто, но праздников в Японии больше, чем в России. Гиперответственные люди, склонные уложиться в дедлайн во что бы то ни стало, есть всегда и везде – и это вовсе не зависит от страны или менталитета. Чем дольше мы работали с нашими коллегами из Японии, тем меньше были заметны различия и больше находилось сходств. Уникальная история и культура не могут не отразиться на национальном характере и традициях, но все же, общего оказалось гораздо больше. И я благодарен за этот опыт!