Как софтверные компании могут совместить локализацию и Agile – история Infobip

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

По этой причине мы недавно решили приступить к очередному раунду исследований и экспериментов, которые привели к интересным и даже неожиданным результатам.

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

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

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

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

Рассмотрим в качестве примера наш собственный случай. Наши продукты (пользовательский интерфейс) содержат около 95 000 слов. Нам может потребоваться перевести всего 120 слов на 11 языков в течение 48 часов.

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

• уточнить требования и принять проект

• связаться с 11 поставщиками

• подтвердить их доступность и найти замену тем, кто не был доступен или не отвечал в столь короткие сроки

• контролировать ход проекта

• отвечать на вопросы и решать проблемы

• проверять завершение и доставлять переводы

• выставлять счета клиенту и оплачивать поставщиков

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

Непрерывная локализация всегда была нашей целью в Infobip, но из-за всех вышеперечисленных ограничений она была в лучшем случае «полунепрерывной». Поэтому недавно мы начали эксперимент с низким риском и высокой прибылью, чтобы проверить, сможем ли мы сделать наш процесс локализации действительно непрерывным. Другими словами, мы хотели посмотреть, сможем ли мы без проблем встроить наш процесс локализации в нашу гибкую структуру.

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

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

^{Гибкий подход VS каскадный подход}

Итак, внеся всего несколько изменений в исходное Манифесто, мы сформулировали несколько принципов, которые позволяют сделать локализацию более гибкой.

Вот наши 12 рекомендаций для непрерывной локализации:

1. Публикуйте переводы на ранней стадии и улучшайте их позже — не ждите идеально отрецензированныхd переводов.

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

3. Наладьте сотрудничество во всей компании — не изолируйте команду локализаторов.

4. Полагайтесь на людей, доверие и командную работу — не применяйте стиль командования и контроля в вашем отделе или программе локализации.

5. Отдавайте приоритет прямым методам коммуникации с переводчиками и другими заинтересованными сторонами — не полагайтесь на косвенную коммуникацию через LSP.

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

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

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

9. Позвольте команде локализаторов выбирать, как им работать — не настаивайте на строго определенных процедурах.

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

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

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

Как только мы нашли подходящего поставщика языковых услуг (Beluga Linguistics), мы выбрали шведский язык в качестве тестового и создали наш переосмысленный треугольник: клиент, поставщик языковых услуг и два внештатных переводчика. Мы постарались отказаться от любых водопадных практик, используя технологии и общаясь друг с другом в рамках треугольного контура.

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

Мы обнаружили, что эта новая треугольная конфигурация наконец-то позволила обеспечить реальную непрерывную локализацию и принесла пользу всем участникам процесса.

Преимущества для компаний-разработчиков программного обеспечения:

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

• Любые языковые проблемы можно было исправить мгновенно — будь то исходный язык или перевод.

Преимущества для переводчиков:

• Они получали оплату своевременно, быстро и в полном объеме – без вычетов со стороны банков или каких-либо сопутствующих комиссий.

• Прямая коммуникация с клиентом — не нужно ждать ответов или разъяснений через LSP.

Преимущества для поставщиков языковых услуг и переводческих компаний:

• Нет необходимости беспокоиться о сроках и административной работе.

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

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

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

^{Треугольник локализации решен}

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

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

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

• Заранее определите ожидания и доверьтесь людям, чтобы они продемонстрировали свой профессионализм.

• Предоставьте переводчикам возможность и финансовые стимулы для изучения вашего бизнеса.

• Часто проводите небольшие проверки и эксперименты, чтобы все могли совершенствоваться.

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