Локализация (адаптация) продукта для работы в новых регионах
Если неопытного аналитика попросить оценить, сколько времени у него займет написание требований по локализации продукта для другой страны, в ответ можно услышать что-то вроде:
“нууу... недели должно хватить...”, или, даже: “а при чем тут я? Это работа переводчика!”
Что будет дальше — нетрудно догадаться: заказчик выделяет неделю, наш аналитик начинает и ... проигрывает! И неудивительно, ведь одна сторона под локализацией понимает только перевод, в то время как другая ожидает, что продукт будет выглядеть и работать так, как привыкли жители той страны, для которой его готовят!
И эти ожидания совершенно логичны, поскольку, по определению:
Локализация программного продукта — это его адаптация к культуре и законодательству другой страны.
И перевод — это лишь часть большой работы. В требованиях к локализации часто скрывается много так называемых "обязательных функций" из модели Кано: функций, о которых заказчик вряд ли даже вспомнит на интервью, но будет очень зол, если не найдет их в готовом решении.
Мы — Екатерина Носенко и Олеся Иванова работаем бизнес-аналитиками в компании Astound Commerce. Компания занимается внедрением e-commerce решений для клиентов из разных уголков земного шара. За время нашей работы здесь мы приобрели значительный опыт развертывания продукта на рынки различных стран и хотим поделиться этим опытом с вами.
В статье мы рассмотрим список компонентов системы, которые с большой вероятностью должны быть адаптированы к правилам другой страны. Такой чек-лист поможет вам избежать многочисленных подводных камней процесса локализации и отделить функциональность, которая будет использоваться глобально (платформу), от специфичной для конкретного региона.
Для наглядности список поделен на три группы:
требования к конфигурации продукта;
требования к внешнему виду продукта;
бизнес-правила и юридические ограничения.