Мы продолжаем получать от потенциальных клиентов ответы в духе, что «мы разочаровались в тестовых, потому что реальной квалификации подрядчика они не показывают». Действительно, не всем клиентам нужно тестовое задание, ведь они просто не все знают, что с ним делать. Тут мы возвращаемся к теме, когда клиент хочет локализовать игру на язык, которого не знает.  

 

Клиенты выбирают подрядчика как? Устраивают конкурс. И в результате появляются несколько вариантов тестовых на руках, однако они сами в том же португальском бразильском ни в зуб ногой. Как понять, кто как сделал и кому платить? Это проблема, ведь тогда клиенту надо обращаться еще и к стороннему агентству за экспертным мнением. И там определенная степень доверия должна быть. В итоге клиент тратит время, бюджет и получает какой-то результат. Такова причина номер 1, почему не все любят делать тестовые задания.

 

Причина номер 2: тестовые задания — это разовая вещь. То есть тестовое задание не всегда отражает реальные возможности команды. Я всегда провожу тут параллель с тем, как мы подбираем фрилансеров, потому что клиенты точно так же выбирают и оценивают подрядчиков и исполнителей. Как мы смотрим на ТЗ фрилансера? Например, если ТЗ выполнено на русском, мы можем оценить квалификацию исполнителя сами. У нас есть для этого хорошие тестовые задания и штатные редакторы. Но у нас в принципе нет гарантии, что это ТЗ человек выполнил самостоятельно. Сделали это его друзья, знакомые или просто он это купил — таким, правда, обычно студенты балуются, чтобы практику пройти. Тем не менее, в моей переводческой практике встречались и такие ребята, которые выдавали чужие работы за свои. Понятно, что на проекте все это всплывет, ведь 500 слов теста и 20 000 на проекте — это небо и земля. Однако ты потратил время, понадеялся, для себя закрыл этот вопрос, а тут такое разочарование.

 

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

 

Обычно объем ТЗ — не больше 1500 слов. Плюс это менее жесткие временные рамки, чем на реальном проекте. В индустрии бытует такое негласное правило трёх дней. Сделал за три дня — молодец. Только вот за три дня можно эти 1500 слов вылизать до идеального состояния. Привлечь редакторов, созвать консилиум и разобрать каждую точку с запятой, а каждое слово проверить по десяти словарям. И это будет идеальный текст. Но на реальном проекте такого не будет. Там не будет двух редакторов, консилиума на каждое слово и прочих маленьких фантазий. Или все же будет? Все зависит лишь от честности бюро, которое выполняет тест.

 

Это те самые моменты, из-за которых у клиентов-таки возникает сомнение в том, покажет ли тестирование реальное положение дел или нет.

 

Теперь поговорим о том, почему несмотря на все это тестирование нужно.

 

Даже в условиях, в которых у тебя, казалось бы, есть все возможности сдать идеальное качество, не все тестовые хороши. Сравнивая с тестированием фрилансеров, я со своим многолетним опытом работы и проверки переводчиков могу сказать, что при проверке исполнителей ты никогда не увидишь 50% хороших тестовых, да даже 20% не увидишь среди всех. При этом люди явно старались и должны были показать свой максимум по идее. По большому счету ТЗ — это критерий максимального качества, которое может выдать исполнитель или команда. Всегда виден порог высшего, что может сделать человек.

 

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

 

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

 

Как составить хорошее тестовое задание для своего проекта?

 

Следует включить особые и локальные вещи, которыми будет отличаться ваш проект. Иными словами предупредите исполнителя о возможных трудностях, если в вашем проекте есть какая-то специфика.

 

Не вставляйте тексты, сильно зависящие от контекста в вашей игре. Почти гарантированно вне контекста текст будет переведен не так, как вам надо. Либо будьте готовы ответить на уточняющие вопросы исполнителя. Буквально вчера пришло тестовое от китайцев, живой пример. Там есть фраза: Вероятность выпадения отдельных карт повышается. При 10 гарантия 100%. При 10 чего? 100% чего? Конечно, мы можем оставить максимально обтекаемую конструкцию, но игроки нам за это спасибо не скажут. И никакого контекста, чтобы мы могли догадаться, о чем речь.

 

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

 

Так все-таки, нужно ли давать подрядчикам тестовые задания?

 

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

 

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