Локализация (адаптация) продукта для работы в новых регионах

(Из ленты Курсы бизнес анализа, тренинги и обучение бизнес аналитике| ArtofBA)

Если неопытного аналитика попросить оценить, сколько времени у него займет написание требований по локализации продукта для другой страны, в ответ можно услышать что-то вроде:

“нууу… недели должно хватить…”, или, даже: “а при чем тут я? Это работа переводчика!”

Что будет дальше — нетрудно догадаться: заказчик выделяет неделю, наш аналитик начинает и … проигрывает! И неудивительно, ведь одна сторона под локализацией понимает только перевод, в то время как другая ожидает, что продукт будет выглядеть и работать так, как привыкли жители той страны, для которой его готовят!

И эти ожидания совершенно логичны, поскольку, по определению:

Локализация программного продукта — это его адаптация к культуре и законодательству другой страны.

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

Мы — Екатерина Носенко и Олеся Иванова работаем бизнес-аналитиками в компании Astound Commerce. Компания занимается внедрением e-commerce решений для клиентов из разных уголков земного шара. За время нашей работы здесь мы приобрели значительный опыт развертывания продукта на рынки различных стран и хотим поделиться этим опытом с вами.

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

Для наглядности список поделен на три группы:

требования к конфигурации продукта;
требования к внешнему виду продукта;
бизнес-правила и юридические ограничения.

Требования к конфигурации продукта

Товары и цены на них

Важно проверить, может ли пользователь другой страны приобрести те же товары, которые представлены у нас на платформе, или ассортимент должен быть иным?

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

Алкоголь запрещен для продажи во многих арабских странах, поэтому, если в ассортименте есть алкогольные изделия, их необходимо скрыть, если пользователь выбрал такую страну.

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

Методы оплаты

В каждой стране есть свои, привычные для местных жителей, методы оплаты. В Северной Америке традиционно используют банковские карты и PayPal, европейцы любят оплату частями (Klarna) и “Buy Now Pay Later” решения (Afterpay), а в Объединенных Арабских Эмиратах привыкли к Cash on Delivery (оплата курьеру наличными после того, как получатель проверил заказ). В азиатском регионе покупатели предпочитают альтернативные способы оплаты: кроме известных китайских гигантов WeChat и AliPay здесь широко используют локальные мобильные кошельки, функции оплаты через социальные сети и платежные терминалы.

Доставка

Обычно используют три типа доставки продуктов пользователю

Доставка на дом;
Доставка в магазин или пункт выдачи;
Доставка через электронные каналы связи (е-мейл, чат и т.д.).

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

Налоги

Еще одним важным моментом является налогообложение. Даже если вы не разрабатываете систему бухгалтерского учета, эта тема вряд ли обойдет вас стороной.

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

В Соединенных Штатах и некоторых провинциях Канады НДС нет вообще, вместо него удерживается налог на продажу (Sales Tax), при этом система расчета зависит от штата/провинции. Поэтому конечную сумму к оплате можно рассчитать только после того, как потребитель предоставит полный адрес.

Настройки аккаунта

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

Процесс регистрации

Если у вас В2С продукт, то стоит подумать, как пользователи будут в нем регистрироваться.

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

Работая над процессом регистрации не забудьте подумать также над возможностью удалить аккаунт и все данные о нем: во многих странах право пользователя на полное удаление персональных данных закреплено законодательно.

Рис.1. Логин посредством QR кода

Требования к внешнему виду продукта

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

Формат даты, чисел, валюты

Что будет разделителем даты: слэш или точка? Что пишем сначала месяц или день? — такие примеры нам давно известны.

Но есть и более экзотические: например, в Таиланде сейчас не 2021, а 2564 год! И тайцы, действительно, используют свое летоисчисление очень активно, григорианский календарь применяется только для туристов, поэтому, если уж адаптировать продукт под локальный рынок, стоит это учесть.

Относительно денежных сумм, опять-таки, где-то привыкли писать символ валюты, где-то — название, где-то валюту ставят после числа (например, в Украине: 10 грн.), где-то — перед ним ($10), где-то есть пробел между суммой и значком валюты, где-то они пишутся как одно целое.

Конечно, такие особенности не являются критическими для функционирования продукта (и так поймут), но мы же хотим сделать все качественно! Поэтому стоит обращать внимание и на такие «мелочи».

Длина слов и направление печати

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

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

Рис.2. Пример японского интерфейса

Кстати, насчет изменения внешнего вида: а как вам арабский с написанием справа налево? Вот это уж точно джек-пот, — без тщательного анализа интерфейсов здесь не обойтись!

Формат адреса и валидация данных

Если при регистрации или заказе пользователь должен предоставить адрес, то стоит помнить, что его формат также может отличаться. Это касается:

Количества полей. Например, где-то, как в Украине, дом указывается отдельным полем, где-то — как часть строки адреса.
Необходимости полей. Например, штат в США или провинция в Канаде является обязательной частью адреса; область в украинском адресе можно не указывать (хотя люди привыкли это делать, поэтому поле чаще присутствует), а в Германии это поле не используется вообще, потому пользователи будут удивлены, если его не убрать.
Последовательности полей. Например, в Японии адрес пишут «от большего к меньшему», то есть сначала страна, потом префектура, город, район и так далее. Но только если пишут на японском языке! Бывают случаи, когда японский адрес нужно записать не иероглифами, а латиницей — в таком случае порядок меняется на противоположный, уже знакомый нам по адресам США и большинства стран Европы — «от меньшего к большему».
Ну и конечно же, если на форме используется валидация полей, то правила должны учитывать форматы, которые используются в стране. Чаще всего это касается формата телефонных номеров и почтового индекса.

Рис 3. Пример японского адреса, записанного иероглифами и латиницей

Бизнес-правила и юридические ограничения

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

Например, в Соединенных Штатах действует Закон о гражданах с ограниченными возможностями (The Americans with Disabilities Act), который диктует требования к внешнему виду и поведению сайтов, а также и приложений.

Рис 4. Требования ADA в действии

В решениях для европейских заказчиков необходимо соблюдать регламент по защите персональных данных (General Data Protection Regulation). Согласно этому закону, если любые персональные данные (включая куки, GDPR их тоже относит к персональным данным) сохраняются в продукте, мы должны получить явное разрешение на хранение и объяснить, как эти данные могут быть использованы.

А если наш заказчик из Германии, то в дополнение есть еще и BDSG (локальная адаптация GDPR), что добавит головной боли организаторам маркетинговых рассылок.

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

Выводы и рекомендации

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

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

Расписание тренингов от Art of Business Analysis

Новости и статьи по бизнес-анализу — https://t.me/artofba

Источник: Локализация (адаптация) продукта для работы в новых регионах