«Наш продукт популярен на внутреннем рынке, поэтому теперь мы думаем выходить на международный. С чего мне начать как менеджеру по продукту?»
«Поначалу выход на новый рынок не казался чем-то сверхсложным, но вопросов появляется всё больше и больше… а сроки поджимают».
Примерно такое я регулярно слышу от людей, которые начинают выводить свой продукт на международный рынок. Сложность выхода на глобальный уровень обычно недооценивают, и это приводит к задержкам, дополнительным расходам и сокрушительным провалам.
В этой статье мне хотелось бы пройтись по моему контрольному списку вопросов, составленному на основе общепринятых рекомендаций по локализации и моего 10-летнего опыта международного масштабирования программных продуктов (это и мобильные игры, и B2C-приложения для массового рынка, и SaaS-продукты B2B).
Примечание. Этот список ни в коем случае не исчерпывающий. В нем рассмотрено в основном то, что поможет менеджеру по продукту обеспечить беспроблемный выход ПО на новом рынке (поэтому здесь я не углубляюсь в продажи, маркетинг и юридические аспекты).
Для начала — основные понятия:
- Глобализация — подготовка продукта к работе на разных рынках. Сюда относится различные аспекты маркетинга, дизайна и технологической реализации.
- Интернационализация (сокращенно — i18n) — обеспечение максимальной универсальности продукта, создание прочного фундамента для локализации и перевода.
- Локализация (сокращенно — l10n) — адаптация продукта к определенным региону, культуре и языку.
- Перевод (сокращенно — t9n) — собственно перевод продукта на новый язык.
Недооценка объема работы по интернационализации и локализации часто связана с тем, что эти процессы воспринимаются лишь как перевод пользовательского интерфейса и документации, тогда как на самом деле это куда более сложные задачи.
Взаимоотношение различных процессов в рамках продукта. Источник: блог Adobe.
Переведено в Alconost
А теперь — обещанный список вопросов!
Я разобью его на три категории: бизнес и маркетинг, дизайн и разработка, работа с клиентами и поддержка.
Бизнес и маркетинг
Какую будем использовать международную стратегию?
В зависимости от продукта и аудитории можно рассматривать глобальную, транснациональную или комплексную международную стратегию. Несколько примеров:
- Глобальная. Microsoft обеспечивает единообразную работу с продуктом по всему миру, но адаптирует приложения в соответствии с местными языками. Таким образом компания жертвует скоростью адаптации к местным требованиям в пользу эффективности.
- Транснациональная. McDonald’s пытается найти равновесие между стремлением к эффективности и необходимостью приспосабливаться к требованиям конкретных стран. В меню всегда есть как «культовые», так и местные блюда: «Биг Мак» будет везде, в Макао — морепродукты, в Киеве — традиционный украинский картофель. Когда мы с командой работали на их цифровой платформе, мы могли использовать глобальные инструменты (веб-шаблоны, мобильное приложение), но у нас была и возможность подстраиваться под местную аудиторию — например, добавлять специальные промо-страницы.
- Комплексная. Возможности, который предлагает Uber, существенно зависят от региона: можно использовать и завязанные на местной культуре варианты, такие как мотоциклы — в оживленных индийских городах или лодки — на побережьях Хорватии. Еще один пример — Pokémon Go: игра вышла в более чем 35 странах и была серьезно адаптирована для каждого региона. Некоторые покемоны живут только на определенных континентах, и все они переименованы в соответствии с особенностями каждого языка.
Разнообразие имен покемонов. Источник: Applanga.
Опытный специалист по продуктам постарается определиться с международной стратегией как можно раньше и поставит в известность владельцев и команду, поскольку это может повлиять на основные архитектурные и бизнес-решения, которые будет довольно сложно и дорого изменять на более поздних этапах развития продукта.
Какие у нас приоритеты в расширении на международный рынок?
Крайне важно выбирать регионы для международного расширения в определенном порядке — а не полагаться на интуицию. Для этой цели особенно полезны будут такие модели приоритезации, как ICE (вот пример того, как ее применял Dropbox).
Не пытайтесь назначать строгие сроки или планировать запуск в нескольких странах одновременно, особенно если вы впервые выходите на другие рынки. Лучше всего сгруппировать регионы по уровням — например, вот так: 1) наивысший приоритет, запуск в одной-двух странах, срок — как можно скорее; 2) высокий приоритет, запуск в течение следующих двух-трех кварталов; 3) все остальные, — и действовать в порядке приоритета. На эту тему есть отличная публикация от Мины Радхакришнан — первого директора Uber по продукту.
Какие мы определим показатели успеха?
Зачем мы выходим на новые рынки? По сути, это позволяет использовать эффект множителя — увеличение охвата, числа покупок, вовлеченности и монетизации за счет выхода на каждый новый рынок.
Простейшая формула окупаемости вложений (ROI) для локализации будет выглядеть следующим образом:
ROI = (совокупная выгода от локализации − стоимость локализации) / стоимость локализации
Следующий вопрос: «Как рассчитать совокупную выгоду»? Подумайте, какие дополнительные доходы компания может получить, выпустив локализованный программный продукт. В идеале этот прогноз составляется специалистами по продукту совместно с отделами продаж и маркетинга с учетом показателей спроса на целевых рынках. Однако на практике нужные данные доступны не всегда — поэтому измерять совокупную выгоду локализации придется через косвенные показатели:
- Потенциальное увеличение рыночной доли в результате проведенной локализации.
- Повышение числа просмотров страниц и загрузок приложения.
- Коэффициенты конверсии до локализации и после.
- Присутствие в социальных сетях и упоминание в СМИ целевого региона.
- Рейтинг по ключевым словам в SEO.
- Снижение заявок в службу поддержки клиентов на новом рынке.
Что касается временно́го горизонта, я рекомендую рассчитывать стоимость и затраты на ежегодной или хотя бы полугодовой основе — так вы сможете учесть долгосрочные эффекты локализации, а также бюджет интернационализации, которая обычно охватывает все регионы.
Насколько мы будем конкурентоспособны на новом рынке?
Наличие этого пункта вполне предсказуемо :) Хороший менеджер по продуктам готовится заранее и изучает конкурентов, а затем определяет, нужно ли улучшать функциональность, пересматривать оформление и цены на продукт и так далее.
Фото — Kyle Glenn, площадка Unsplash
Чем отличаются потребности, контекст и привычки целевой аудитории на новом рынке по сравнению с текущей базой пользователей (клиентов)?
Этот пункт уже посложнее. Если потребности и привычки пользователей в данном регионе существенно отличаются от внутреннего рынка, то локализация может потребовать полного переосмысления бизнес-логики, дизайна интерфейса и подхода к потребительскому комфорту, а также цен и оформления.
Мне пришлось столкнуться с этой задачей, когда мы масштабировали Netpulse (платформа повышения активности клиентов для фитнес-клубов) на рынок ЕС. Система отлично работала на исходном рынке — в США, где большинство спортивных залов — недорогие, а личная тренировка считается платной услугой. В европейских странах, например, в Германии, положение обстояло несколько иначе: ежемесячный абонемент был дороже и включал в себя помощь личных тренеров в зале. Чтобы соответствовать этому региону, мы адаптировали продукт: добавили непосредственное взаимодействие между клиентами и тренерами.
В рамках стратегии локализации следует проанализировать ожидания от продукта в новом регионе и найти несколько потенциальных пользователей (клиентов) с этого рынка, которых можно опросить — и проверить таким образом свои предположения. Набрать респондентов для исследования из нужного региона и конкретной социальной группы можно на сайте Respondent.
Нужно ли изменять контент в App Store и ASO?
Речь идет о снимках экрана, видео и описаниях приложения, которые могут и должны быть локализованы при добавлении нового языкового стандарта. Также полезно обновить ключевые слова, поскольку они повышают рейтинг в поисковой выдаче магазина.
Что еще можно сделать, чтобы улучшить показатели SEO?
Отправляясь в отпуск, англичане будут гуглить holidays, американцы — vacations, а итальянцы — vacanze. Найдите правильные ключевые слова, которые используют для поиска вашего продукта в Интернете, и используйте их в текстах и метаданных (заголовок, описание и ключевые слова метатегов). Подробнее смотрите в руководстве от Google.
Да, и когда мы говорим «гуглить» — это не обязательно будет поиск через Google: в некоторых странах может понадобиться оптимизировать продукт для работы с популярными местными поисковиками — например, Baidu в Китае или Яндексом в России.
Какие правила защиты данных действуют на целевых рынках?
Вот здесь-то и начинается настоящее веселье. Если ваш продукт — из ЕС, вы (надеюсь) уже обеспечили соответствие требованиям GDPR; если из солнечной Калифорнии — вы наверняка знаете о CCPA. Но что насчет Китая? Австралии? Японии? Прежде чем определяться, на какие рынки выходить в первую очередь, поговорите с юридическим отделом: местные требования к защите данных могут существенно повлиять на расчет окупаемости вложений и, следовательно, на план развития продукта. Хороший пример — требование к расположению данных в Китае: с 2017 года оператор инфраструктуры с критически важной информацией должен хранить «персональную информацию» и «важные данные» в Китае. Исключение — если бизнес прошел государственную оценку безопасности. То есть, чтобы избежать нарушения требований к размещению данных, некоторым компаниям придется организовать передачу данных за границу, а значит — изменить структуру соответствующих механизмов.
Когда мне нужно быстро сравнить правила защиты данных в различных странах и сформулировать конкретные вопросы для юристов, я иду на сайт DLA Piper.
Какие ограничения по контенту есть в новом регионе?
Когда я занималась мобильными играми, нам приходилось вносить многочисленные правки в материалы для китайского рынка. Во-первых, оказалось, что местная цензура запрещает показывать скелетов, поэтому их пришлось убрать. Потом они забраковали все игры, упоминавшие «восстание». Наконец, нам пришлось убрать лужи крови.
Одна из наших любимых игр — «Котокалипсис» (вероятность выхода в Китае — 0%…)
Дизайн и разработка
Какие мы будем применять принципы и процессы в политике интернационализации и локализации?
Менеджерам по продукту нужно обсудить весь процесс с командой и задокументировать его, чтобы у всех была нужная информация. Учесть нужно следующее:
- Изменения в общей библиотеке требований к продукту и системе разработки.
- Система управления переводами (TMS), которую вы будете использовать.
- Кто будет делать перевод: штатные специалисты, фрилансеры или агентства.
- Руководства для переводчиков по терминологии, стилю и т. д.
- Рабочий процесс локализации: например, импорт исходных XLIFF-файлов в TMS, перевод, проверка, доставка конечным пользователям.
- Создание и поддержка общего хранилища текстовых строк.
- Уровень автоматизации (допустимо ли обновлять тексты с небольшой задержкой или нужно делать это на лету — в последнем случае придется интегрировать специализированные SDK).
- Бюджет первоначальной локализации и последующих обновления и поддержки.
Если отложить обсуждение этих вопросов, это выльется в затраты времени и денег — что и случилось со мной, когда ко мне попало уже два года как вышедшее мобильное приложение с примерно 10 тысячами жестко закодированных строк текста. Нам пришлось заплатить за перевод одного и того же текста дважды (для iOS и Android), а затем потратить время разработчиков на добавление переведенных строк в код. Мне понадобилось около 4-5 месяцев, чтобы разгрести всё это и перевести приложение на единое хранилище текстов для iOS и Android, подключенное к платформе переводов.
Затраты на решение проблем интернационализации после выхода продукта могут быть астрономическими. Источник: блог Adobe.
Страна, регион, язык… языковой стандарт?
Допустим, вы уже нацелились на определенную страну — следующим шагом будет поиск распространяющихся на нее языковых стандартов («языковой стандарт» — это языковые и культурные ожидания для региона).
Возьмем, к примеру, США. Может показаться, что при выходе на этот рынок достаточно, чтобы продукт «говорил по-английски», но миллионы людей в США дома говорят на других языках. Поэтому в продукте для массового рынка может понадобиться поддержка испанского и китайского языков.
Источник: Statista, США; Бюро переписи США; 2018; от 5 лет
Кроме того, в зависимости от региона, могут потребоваться несколько языковых стандартов для одного языка, например — для испанского в США: es_mx (испанский — Мексика), es_us (испанский — США) и кое-какие еще. Наконец, чтобы охватить Испанию, может быть недостаточно локализации es_es (испанский — Испания); для одного из массовых продуктов, который мы запускали в этом регионе, оказалось чрезвычайно важным поддерживать языковой стандарт ca_es (каталонский — Испания).
Как наш интерфейс выглядит с текстами на разных языках?
Главное правило — такое: «Чем более гибкий дизайн интерфейса, тем лучше». Я рекомендую дизайнерам учитывать средние показатели удлинения текстов, переведенных с английского на другие языки — эти данные можно взять, например, из рекомендаций IBM по глобализации:
Источник: IBM Globalization
Общие правила для интернационализации и локализации должны быть частью системы проектирования продукта, чтобы команда могла последовательно применять их ко всем функциям. Сюда будут входить правила по запасу на удлинение текста, переносу или усечению длинного текста, требования к изображениям и значкам и т. д. (Хороший пример — система Meetup.)
Как будет применяться языковой стандарт? Будет ли у пользователей возможность менять язык?
В мобильных приложениях обычно языковой стандарт применяется согласно языку устройства: пользователь из США, который задал на телефоне испанский (США), будет видеть приложение в языковом стандарте es_us.
Для Интернета всё немного сложнее: можно положиться на языковые настройки браузера — но у многих пользователей они будут неправильные. Представьте себе американца, работающего в Германии на корпоративном ноутбуке: ему нужен языковой стандарт «en-us» (английский — США), но в браузере установлен de-de (немецкий — Германия), и менять эту настройку может только администратор компании. Незадача…
Чтобы избежать путаницы, дайте конечным пользователям возможность изменять предпочитаемый язык, причем так, чтобы это можно было делать в процессе работы приложения.
Это относится и к другим элементам интернационализации — например, к переходу с британской системы единиц измерения на метрическую, а также к выбору валюты, в которой отображаются цены.
Переключатель валют на сайте Booking.com
Какой языковой стандарт будет базовым (по умолчанию)?
Как правило, базовым будет английский язык — однако нужно выбрать языковой стандарт: например, UK или US (Великобритания или США). Все переводы будут делаться по текстам этого языкового стандарта — он же будет использоваться по умолчанию, если продукт не поддерживает язык пользовательского устройства.
Нужно ли поддерживать различные направления письма?
В некоторых языках — например, в арабском и иврите, — текст записывается справа налево (RTL); в традиционном китайском допускается писать как слева направо (LTR), так и сверху вниз (TTB). В зависимости от типа продукта и профиля целевой аудитории может потребоваться слегка обновить интерфейс или даже полностью его перестроить.
Источник: блог Airbnb Design.
Обратите внимание: на снимке экрана ниже порядок пунктов в меню Airbnb на иврите изменен, так как носители языка не только пишут, но и читают справа налево.
Мобильное приложение Airbnb на иврите и на английском.
Есть ли в продукте заполняемые формы, которые нужно локализовать?
Если ответ «да», то вам предстоит здорово повеселиться!
Возьмем, например, имена. Мы обычно даже не догадываемся, насколько может отличаться структура человеческих имен в других странах. Мне пришлось узнать это на собственном горьком опыте: мы запустили в Индонезии приложение, для регистрации в котором нужно было вводить имя и фамилию, и на следующий после запуска день мы получили кучу жалоб… от мононимов — людей, у которых нет «фамилии», из-за чего они не смогли пройти регистрацию. Не очень приятная неожиданность.
Другие связанные с именами изменения в формах: смена местами имени и фамилии (Корея, Венгрия), проверка введенных данных должна принимать специальные символы, пробелы и символы вне диапазона ASCII — например, ë в имени Zoë (другие примеры смотрите на сайте W3.org).
Еще одна сложность — адреса и телефоны.
Порядок элементов в адресе от региона к региону сильно меняется. Подводные камни здесь обычно такие: ненужные обязательные поля (штат), фиксированный формат почтового индекса (только для США), непонятные подписи и тексты подсказок.
Что касается телефонных номеров: нужно будет решить, местный или международный формат использовать, разбивать номер на группы цифр или нет.
Источник: блог Flexport
В зависимости от особенностей продукта можно выбрать один из трех распространенных подходов к интернационализации форм: конкретное, изменчивое или стандартное форматирование — подробнее об этом в отличной статье Люка Вроблевски.
Я советую найти баланс между необходимостью получения точных данных из форм и удобством их использования. По возможности заполняйте некоторые поля формы автоматически, используя контекст, например, географическое положение, данные SIM-карты или почтовый индекс — это упростит задачу пользователям.
Нужно ли локализовать цены и валюты?
Если в вашем приложении отображаются цены, то нужно сделать так, чтобы пользователи видели правильные цены — в знакомом виде и в местной валюте.
Клиенты, посещающие сайт из Германии, ожидают увидеть цены в евро, а покупатели из США — в долларах. Канадцы также будут ожидать увидеть доллары, но им нужно будет знать, это доллары США (USD) или канадские доллары (CAD)… (подробнее о форматировании валюты см. в отличной статье от Etsy).
Источник: блог Etsy.
Цену можно представить себе как структуру, состоящую из целого числа, валюты, десятичных знаков и разделителей. В зависимости от варианта использования ее можно разбить на основную цену и налоги — например, НДС.
Обсудите планы на поддержку нескольких валют с коллегами в отделах разработки и дизайна заранее — это помогает учесть необходимый уровень гибкости и избежать серьезного рефакторинга в будущем.
Что насчет различных систем единиц?
В компании Netpulse мы разрабатывали продукт для завсегдатаев спортивных залов и любителей фитнеса, поэтому нужно было учитывать, что в разных странах предпочитают использовать различные системы измерения. Для пользователей в США рост, вес и расстояния по умолчанию были в британской системе единиц (футы и дюймы, фунты, мили), для европейцев — в метрической (метры и сантиметры, кг, км). И, конечно же, систему единиц можно было переключать в настройках.
Источник: Statista.
Отображает ли наш продукт дату и время?
Разнообразие форматов дат очень «порадует» вашу команду… Давайте я просто приведу слова одного разработчика:
«Хотелось бы, чтобы каждого, кто придумывает новый формат даты, били по лицу раскаленной сковородой до тех пор, пока он не откажется от программирования в пользу выращивания кактусов». — DevRant.com
Источник: DevRant.com
Когда выбор правильной даты имеет решающее значение для пользователя (например, при покупке билета на самолет), нужно показать календарь и указать месяц словами.
Источник: Google Авиабилеты.
А что с часовыми поясами? И с переходом на летнее время?
Работать с часовыми поясами сложно, потому что придется учитывать огромное количество пограничных случаев, и каждый из них обязательно вам попадется, как только вы решите схалявить:
- Переход на летнее время: один день в году будет длиться 23 часа, а другой — 25 часов (однако в некоторых регионах часы не переводят).
- В разных странах стрелки переводят в разное время.
- Часовых поясов не 24, а 38 (источник: Сколько всего часовых поясов?), и смещение — не всегда на один час, например, в Индии — UTC+5:30.
- Часовые пояса не совпадают с географическими границами.
Главный вывод: не опирайтесь на предположения «по умолчанию». Если часовой пояс не очевиден, уточните его в пользовательском интерфейсе, учитывайте пограничные случаи и выделите достаточно времени для контроля качества.
Какой смысл будут иметь наши значки и символы на новом рынке?
Со значками, символами и пиктограммами в интерфейсе нужно быть внимательными: в регионе, куда вы собираетесь выходить, их могут понимать иначе.
Например, неожиданное значение могут приобретать изображения животных: в США совы символизируют мудрость, а в некоторых азиатских регионах — наоборот: глупость. Поэтому если вдруг на веб-сайте интернет-курсов значок совы используется как индикатор того, что пользователь или учащийся получает хорошие баллы, то для посетителей из Азии такое изображение может быть оскорбительным.
Есть ли у нас изображения людей или аватары?
Посмотрите на них свежим взглядом: представляют ли они местное население, сохраняется ли гендерный, расовый и возрастной баланс?
Я руководила разработкой одного из приложений, и нашей команде перед выходом на международный рынок пришлось убрать все аватары и заменить их на загружаемые пользователями картинки, а в качестве изображения по умолчанию использовать первые буквы имени и фамилии. Так пришлось сделать для того, чтобы пользователи были представлены в приложении надлежащим образом, и чтобы никого не обидело отсутствие подходящего аватара (подробнее об аватарах можно почитать в статье UXCollective).
Как новая аудитория воспринимает цвета?
Цвета должны быть тщательно подобраны в зависимости от целевого рынка так, чтобы они отражали местные культурные особенности (для справки можно использовать эту таблицу символики).
Какие шрифты мы используем и будут ли они хорошо выглядеть для письма на других языках?
Если вы планируете выходить в регионах, где используется нелатинский алфавит, нужно проверить шрифты и убедиться, что они поддерживают специальные знаки и символы — чтобы избежать появления кракозябр. На странице Google Fonts есть удобный фильтр по поддержке языков.
Источник: Phase.com
Подходит ли наше решение для входа в учетную запись и управления идентификацией для нового рынка?
Допустим, ваш продукт дает возможность входить через Facebook или с помощью электронной почты, и вы планируете запустить его в Южной Корее. В этой стране 83% аудитории используют KakaoTalk, поэтому они могут ожидать, что можно будет входить через социальную сеть Kakao.
Приложения, используемые для общения в социальных сетях, могут и совпадать, и не совпадать с используемыми для входа в учетные записи. Если ваш продукт опирается на социальные сети и (или) рефералы, было бы разумно познакомиться с популярными на новом рынке мессенджерами и социальными сетями (например, WhatsApp в Южной Америке, WeChat в Китае).
Можем ли мы принимать платежи так, чтобы это было удобно и нам, и нашей аудитории?
Международные платежи — это большая и сложная задача: здесь пойти не так может буквально всё, начиная со скрытых комиссий и заканчивая проблемами в системе безопасности и экзотическими требованиями законодательства. На что следует обратить внимание:
- Распространенность предпочитаемого вами способа оплаты на целевом рынке.
- Нормативные требования к интернет-платежам, например, необходимость иметь местный торговый счет или запрашивать код безопасности для каждой транзакции.
- Можно ли использовать такие известные системы, как PayPal и Stripe, для запуска бета-версии, а другие (с более низкими комиссиями) добавить позже.
Может ли API возвращать данные в местных форматах и на различных языковых стандартах?
Если у вас есть открытые API, необходимо разрешить включать определенные или несколько языковых стандартов в запросы API и возвращать соответствующим образом оформленные данные в ответах.
Поддержка и работа с клиентами
Есть ли у нашего отдела по работе с клиентами данные и информация о продукте, связанные с новым рынком?
Важная обязанность менеджера по продукту — ввести в курс дела новых коллег в отделах по продажам и поддержке клиентов, чтобы они знали, как представлять продукт в новом регионе. «Локализуйте» используемые для обучения новичков материалы: добавляйте статистику и аналитику для каждого нового рынка (вы же, в конце концов, менеджер продукта, и данные — ваш главный инструмент ).
Какую выбрать стратегию продаж на новом рынке?
На одних рынках вы организуете продажи напрямую, на других — через местных партнеров. Во втором случае партнеры могут начать забрасывать вас вопросами, замечаниями и просьбами о новых функциях… так что лучше заранее разобраться с тем, что и зачем им может понадобиться.
Есть ли у нас местные клиенты (B2B) или конечные пользователи (B2C) для запуска бета-версии?
Начните с малого, отполируйте продукт и только затем развертывайте его полностью. Как бы вы ни старались и как бы хорошо всё ни спланировали, неожиданности будут — и лучше разобраться с ними, пока вы работаете на малом масштабе.
Есть ли разница в соглашениях на обслуживание и других документах?
Юридические вопросы — скука смертная, но без них никуда. Соберитесь вместе с юристами и отделом по работе с клиентами и пересмотрите договора и шаблоны соглашений на обслуживание, которые будут использоваться в новом регионе — если это сделать заранее, вы сэкономите много времени и нервов.
Есть ли у нас локализованные материалы для тех. поддержки?
Как и внутренние материалы для новичков, ресурсы для тех. поддержки пользователей нужно будет дополнить: руководства, ответы на частые вопросы, страницы справки — всё должно отображаться в правильной (местной) версии, на правильном языке и регулярно обновляться. В противном случае готовьтесь к лавине запросов в службу поддержки от пользователей с нового рынка.
Будем ли мы нанимать местных представителей поддержки для нового рынка?
Кстати, кому-то нужно будет оперативно разбираться с этими заявками и отвечать на них. А это значит, что нужно будет организовать глобальные или местные линии поддержки, перевести страницы статуса, нанять говорящих на местных языках представителей службы поддержки и изменить соответствующий график работы, чтобы охватить новые часовые пояса.
Будут ли изменения в структуре недельной или суточной нагрузки, которые нужно учесть?
Когда продукт запускается в новом регионе, он может стать популярным (вы же на это и рассчитываете, верно?), и шаблоны нагрузки изменятся. Возможно, понадобится изменить график обслуживания и выпуска продукта — чтобы не попасть на часы пиковой нагрузки. Кроме того, можно попросить отдел разработки и эксплуатации организовать «развертывание без простоев».
Удачи, и пусть ваши продукты живут долго и процветают во всех уголках мира!
О переводчике
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
→ Подробнее
