Локализация (адаптация) продукта для работы в новых регионах
Если неопытного аналитика попросить оценить, сколько времени у него займет написание требований по локализации продукта для другой страны, в ответ можно услышать что-то вроде:
“нууу... недели должно хватить...”, или, даже: “а при чем тут я? Это работа переводчика!”
Что будет дальше — нетрудно догадаться: заказчик выделяет неделю, наш аналитик начинает и ... проигрывает! И неудивительно, ведь одна сторона под локализацией понимает только перевод, в то время как другая ожидает, что продукт будет выглядеть и работать так, как привыкли жители той страны, для которой его готовят!
И эти ожидания совершенно логичны, поскольку, по определению:
Локализация программного продукта — это его адаптация к культуре и законодательству другой страны.
И перевод — это лишь часть большой работы. В требованиях к локализации часто скрывается много так называемых "обязательных функций" из модели Кано: функций, о которых заказчик вряд ли даже вспомнит на интервью, но будет очень зол, если не найдет их в готовом решении.
Мы — Екатерина Носенко и Олеся Иванова работаем бизнес-аналитиками в компании 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