5 факапов, за которые мы дорого заплатили

5 факапов, за которые мы дорого заплатили

Факап. Неудача. Критическая ситуация. Фиаско. Поражение. Это можно называть как угодно, но суть одна: очень неприятная ситуация, в которой нужно сделать выбор — запаниковать и впасть в депрессию или извлечь урок и предложить план по спасению. Конечно, львиную долю всех человеческих факапов составляют те, что можно условно назвать «новичковыми». Они происходят по недомыслию, неопытности или глупости. Но бывают и те, что случаются с профессионалами. В истории Allcorrect были и те и другие, и что тут скрывать, сейчас мы вспоминаем их с улыбкой 😊 Итак, поехали.

Далекий 2010 год. Факап «новичковый».

Бюро переводов «Окей» занимается всеми видами околопереводческой деятельности, а название Allcorrect еще только зарождается как бренд. За плечами уже есть несколько крупных игровых проектов, а амбиций — несоразмерно больше. Отдела продаж как такового нет, но есть очень успешная продажница, сеть ее друзей и друзей компании. Благодаря одному из таких рефералов к нам приходит заказ от крупнейшего европейского издателя ПО. И это не просто заказ! Это локализация на русский язык того самого профессионального ПО, которое используют ваши друзья-музыканты. Для бюро переводов «Окей» это было просто неописуемо круто.

Однако к заказу прилагалось небольшое техническое требование: работа в SDL Passolo. SDL Passolo — это визуальный инструмент локализации. В нем по ходу перевода видно, как будет выглядеть конечный продукт, и можно менять не только текст, но и, например, размеры плашек. То есть сдать мы должны были законченный локализованный продукт. В Passolo мы, конечно, прежде не работали. Но говорить об этом не стали, решив, что это всего лишь очередной CAT-tool и мы быстро его освоим.

Итак, нам присылают тонну рабочих файлов, дополнительные материалы всякого сорта и маленькую тележку стайлгайдов. Мы начинаем работу. Уже тогда мы кое-что знали о планировании и предпереводческом анализе, поэтому привлекли эксперта в области создания музыки (нам же нужно понимать, что именно означают всякие термины и — самое главное — как работают те или иные функции) и четко распланировали проект. Ах да, эксперт по Passolo тоже имелся! Приключение обещало быть захватывающим, и мы отнеслись к нему со всей ответственностью.

И были довольны тем, что получалось. Мы осваивали Passolo методом тыка: сидели и вручную изменяли размер окошечек, чтобы все выглядело отлично; гнали все мыслимые проверки качества, проводили беседы с экспертами — в общем, развлекались, как могли. В назначенный день мы сдали готовые файлы, замерли и стали ждать обратной связи.

Звонок от клиента.

Практически на следующий день, в четверг, в нашем офисе зазвонил телефон. А у нас никогда не звонил телефон. Это было странно, поэтому трубку взял самый компетентный представитель продакшена.

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

На любые вопросы ответ был «нет», и лишь каким-то чудом удалось выяснить, что за первый час или два проверки было найдено 5000 ошибок.

Три дня огня.

Паника очень быстро превратилась в брейнсторм, и было решено, что это какая-то ошибка: у нас должно было быть нормальное качество, ведь мы так много сделали для этого проекта. И тут до нас доходит, что для часа-двух проверки такое количество ошибок просто невозможно, а значит, это было автоматическое средство проверки. А мы ничего не знаем про автоматические средства проверки в Passolo. Наш эксперт оказался и не экспертом вовсе, а просто мимо проходил. Мы засели за 300-страничный мануал по Passolo, параллельно тыкали кнопки и искали заветную опцию. Когда мы нашли и запустили ту самую проверку, то ужаснулись количеству алертов, которое она на нас вывалила. Большинство из них можно было легко поправить, подвигав размер плашки, где текст на пиксель пересекался с границей. Это не было видно человеческим глазом, но авто-QA не обманешь!

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

Начиная с пятничного утра у нас было три дня на исправление всех ошибок, и первое, что мы сделали, — это классифицировали их. Мы составили большую такую эксельку, где были все типы ошибок и типы проверок соответственно: терминология, горячие клавиши, опечатки и т.д. Команда разбилась на условные бригады, каждая из которых чинила свой раздел. Более того, найти адекватных редакторов-фрилансеров, согласных работать круглые выходные, не удалось, поэтому в состав бригад входила большая часть руководителей компании и несколько штатных редакторов. Все стадии по Кюблер-Росс (ну вы знаете: отрицание, гнев, торговля и так далее), доставка пиццы, ночные совещания — чего только не было! Поздней ночью с воскресенья на понедельник работа была завершена, а файлы — отправлены.

В понедельник утром история повторилась: в офисе раздался звонок. Однако на этот раз тон разговора был иным: мы услышали слова благодарности и согласие работать дальше. Локализация (по результатам автопроверки, конечно) оказалась безупречной.

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

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

2013 год. Факап «новичковый» — 2.

Начинается наше большое и долгое сотрудничество с крупным мобильным издателем. Самые-самые первые задачи были на вычитку английского, который создавался где-то в недрах самого издательства не носителями языка и которому, соответственно, требовался нативный лоск. Мы неплохо справлялись, и настал тот день, когда заказчик предложил нам первый мультиязычный проект. Никогда ранее мы не переводили сразу на много языков, а основной нашей специализацией были корейские и китайские ММО. Проект был довольно крупным — целый тайтл, а перевести нужно было с английского на основные европейские языки и пару азиатских. Что тут говорить, не было предела восторгам в нашем офисе, потому что это был отличный шанс перейти в разряд MLV (Multi-Language Vendor).

Где же собрать команду для такого прекрасного проекта? Своей базы переводчиков у нас, разумеется, не было, и мы пошли на proz.com как на самый большой и популярный ресурс хантинга переводчиков. Набрали там команду по отзывам и рейтингам и какое-то время спокойно работали. Количество проектов росло.

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

Примерно в это же время нам стали поступать первые возвраты от клиента, и они были на французский и немецкий. Грамматические ошибки, фигурировавшие в возвратах, были на уровне пятого класса. Так мы поняли, что очень большой объем наших французских текстов откровенно плох. С немецким ситуация была чуть лучше: там был хотя бы настоящий немец, который, однако, не гнушался нецензурной лексики в своих переводах — а игры, надо отметить, имели рейтинг 3+.

Чтобы исправить ситуацию, нам в срочном порядке пришлось изобретать план реагирования. Весь сомнительный контент пошел под нож: мы создали критерии, как выловить нехорошее, сформировали команды по нейтрализации этого нехорошего и, конечно, запланировали серию отчетных встреч как с клиентом, так и с нашим CEO, чтобы все заинтересованные лица могли следить за ходом починки текстов. Объем текстов, которые нам пришлось редактировать или переводить заново, был настолько велик, что на это ушло около года. И для нас это были большие затраты.

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

2018 год. Факап «профессиональный» — новый уровень.

Первая полноценная локализация игры на арабский. О, сколько статей написано, сколько слез пролито над RTL (right-to-left) языками! Но первый опыт — всегда танцы на чужих граблях, и в этом вся его суть.

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

Итак, какие же были входные данные? Один очень опытный и суперзанятой менеджер проектов, жонглирующий тысячей задач, плюс один (первый в истории Allcorrect) джуниор-менеджер. Один доверенный арабский лингвист, которому мы просто отдали проект под ключ. Отсутствие четкой системы контроля за джуниорами и понятного разделения обязанностей. Отсутствие графика проекта (их тогда не было в принципе). Отсутствие протестированной команды арабских лингвистов — мы еще не изобрели фейк-проекты, через которые прогоняем команды теперь; такие проекты выглядят и оплачиваются нами как настоящие, но их результаты остаются внутри и помогают нам оценить уровень лингвистов перед их отправкой «в поля».

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

Чем это обернулось? Менеджеры не договорились о сферах ответственности, поэтому контроль за ведением глоссария на проекте не попал в поле зрения. Обнаружилось это, конечно, в конце. Как следствие — большие проблемы с единообразием терминов. Срезовые проверки на проекте делали непроверенные лингвисты, поэтому качество текста контролировать не удалось. Отсутствие графика, разумеется, привело к срыву срока. Ну и в целом проект с RTL-текстом — это большая сложность для любого менеджера, не владеющего хотя бы общим пониманием того, как такой текст функционирует: что такое ташкиль, как располагаются теги, какими средствами передается капитализация (да-да, в арабском нет заглавных букв); что такое Modern Standard Arabic и как можно вообще судить о качестве текста на искусственном языке (ведь, по сути, MSA является искусственным литературным языком, призванным избавить арабский от диалектно-региональных различий).

Вдобавок ко всему заказчик просто не смог вставить наш арабский текст в игру.

Далее была вереница мероприятий по выявлению и устранению причин факапа: R&D сессии, внутриигровое тестирование, многочисленные созвоны с заказчиком.

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

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

2018 год. Факап «организационный». Он же «профессиональный», только с другого бока.

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

Проект ввиду его значимости достался старшему менеджеру. А у старшего менеджера, который впоследствии стал руководителем отдела производства (самого большого отдела в Allcorrect, надо отметить), каждый день расписан и забит под завязку: в основном это стратегические и оперативные встречи, которые просто нельзя пропускать. Итог: проекты старшего менеджера ведутся по ночам.

С точки зрения организации производства на тот момент не было системы регулирования менеджерской загрузки.

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

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

Еще один немаловажный момент: мы не знали, как клиент работает с файлами на своей стороне. Работая в memoQ, мы получали Trados-пакеты (Trados — это такая программа памяти переводов) по 428 эксель-файлов на язык. Внутри файлы были отсортированы по персонажам, которые произносят те или иные реплики. То есть логической организации диалогов в файлах не было: сто строк одного персонажа, затем сто строк другого персонажа и так далее. Скриптов к таким сборкам не было, и переводчики не понимали, как эти каталоги реплик должны выстроиться в сюжет.

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

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

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

А еще проект шел летом, в самый разгар отпусков, и сформировать команды было довольно проблематично.

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

Что же было сделано потом? При проведении Кайдзена выяснилось, что мы, LEAN-компания, забыли, как работать с большими проектами, и вели их так же, как мобильные проекты среднего цикла. А это неправильно! Затем было тотальное обучение базовым принципам и рождение «скрижалей» — так мы называем свод непреложных истин бережливого производства, заточенных под нашу специфику. Но это уже совсем другая страница истории Allcorrect 😊

Скрижали действительно висят в нашем офисе. На самом видном месте.

2021 год. Факап «свежий».

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

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

Предпереводческий анализ не выявил особо проблемных областей (тексты были простые, в духе «Мистер Х живет в зеленом доме, а мистер Y — в синем»). На созвон с клиентом вышли слишком рано, не вооружившись сведениями о рисках.

Джуниор-менеджер разделил текст на две части для двоих переводчиков в каждом языке, джуниор-тимлид утвердил график проекта, и началась работа. По техпроцессу разные части от переводчиков предполагалось оценить независимым редактором, а потом свести воедино. Времени на все этапы не было, и мы решили свалить все это на одного человека: один из переводчиков должен был оценить часть своего коллеги, а потом еще и вычитать за ним так, чтобы это все свелось в единую стилистическую картину. Для двух языков это стало решающим фактором: избранные лингвисты оказались по уши в проекте на фоне перегруза по другим активным проектам, и это серьезно отразилось на качестве того, что мы сдали (справедливости ради, другие проекты тоже пострадали по качеству, но там было пространство для маневра).

Фидбек от заказчика не заставил себя ждать: загадки, основанные на игре слов, не работали — перевод просто не отражал эту самую игру слов. В процессе работы у лингвистов не было картинок для каждой загадки, а именно визуальный контекст оказался критически необходимым. Говорящие имена персонажей были местами транслитерированы, из-за чего смысл загадки ускользал от игрока. Так, кличка животного Spot (англ. ‘пятнышко, пятнистый’), была переведена как Спот, поэтому на вопрос о пятнистости игрок просто не мог ответить).

Неразбериха с метрами, милями и размерной сеткой в разных языках локализации: кто-то конвертировал системы мер в свои, привычные, а кто-то оставил как в оригинале. Некоторые ошибки были совершенно немыслимыми: uncommon перевели как если бы это было common (перегруз ответственного лингвиста проявлялся именно в таких нелепых моментах). Причем если читать перевод с листа, то текст выглядел неплохо, и лишь в самой игре было видно, что текст совершенно не лег на механики.

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

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