Привет, Хабр! Это Иван Чаплыгин, руководитель отдела переводов компании КРОК. Сегодня речь пойдет про Agile. Вы, конечно, все на нем собаку съели, а может, и не одну. И сколько agile-коучей обитает на Хабре, одному богу известно. Но в области ИТ-переводов, вечно находящейся на стыке технических и гуманитарных знаний, гибкость оказалась тоже очень кстати. К Agile мы пришли не в результате цифровой трансформации, коучинговых сессий или серии онлайн-тренингов. Все гораздо банальнее. Методом проб и ошибок мы изобрели свой переводческий «agile-велосипед», чтобы ехать с ветерком. Подробности о том, как мы дошли до жизни такой - под катом.
Человеческий мозг не любит тратить энергию, поэтому, решая ту или иную задачу, homo sapiens идет или даже ползет по пути наименьшего сопротивления. Например, у нас это работает так: нам обычно присылают текст, мы делаем перевод и отдаем заказчику. Можем пару-тройку вопросов задать, если в оригинале что-то не вполне ясно, и все. Это классический waterfall — каскадный подход. Если требования автора и контекст уже известны, глоссарий давно утвержден и много раз мы переводили подобные тексты, то лучшего сценария работы придумать невозможно.
Ах, вот ты какой, северный олень…
В какой-то момент стали появляться «черные лебеди» или, с учетом нашего климата, скорее, «северные олени», т. е. большие проекты, где использование waterfall-подхода было сопряжено с немалыми рисками. Например, надо было перевести руководства пользователя и администратора на несколько сотен страниц или документацию и интерфейс географически распределенной системы с большим количеством ну очень заинтересованных ЛПР, и стало просто боязно. Однажды я проснулся и чётко представил себе эту картинку, как мы через пять месяцев отдаём перевод и вдруг выясняется, что все приведенные в документации команды из интерфейса или названия кнопок (которые мы, к слову, перевели на русский) заказчик хотел бы оставить на английском, или хотел бы, чтобы всё было переведено в императиве, а не безличными предложениями и от третьего лица. Представил себе кислые мины коллег-переводчиков, вихрь демотивации и трехэтажные маты как в курилке у заказчика, так и в нашей условно-фигуральной курилке. Представил, как менеджер рвёт на себе волосы и не знает, как запихнуть в и так распухший бюджет проекта еще часов двести трудозатрат на переделки переводчиков. Представил живо, во всех подробностях, и мне не понравилось. Не люблю переделывать от слова совсем. Вот я и стал думать, как бы нивелировать риск из серии «это фиаско, братан». Ответ лежал на поверхности — сделать страниц пять мануала и показать заказчику, мол, как тебе, милый друг, нравится или не очень. А если не очень, то что именно тебе не любо.
Сказано — сделано. Так уже в самом начале проекта появился на коленке сделанный, но утвержденный всеми ЛПРами стайл-гайд, где чётко прописано, как обращаемся с названиями кнопок, вкладок, как называем акторов, как называем те или иные системы, и даже как строим некоторые типичные фразы и предложения. Сложно даже представить, сколько проблем по ходу проекта удалось избежать благодаря такому подходу, который на самом деле на всю голову agile. Вроде бы всё. Риск закрыт, и можно на этом успокоиться и переводить весь проект дальше до самого конца. Но нет. Червячок сомнения все равно остается. А правильно ли мы поняли заказчика? А точно ли это он имел в виду? А не передумал ли наш заказчик и не поменял ли в одночасье названия в интерфейсе? Дабы не гадать на кофейной гуще, отправляем заказчику следующий кусок, уже страниц на двадцать-тридцать, и трясем с него обратную связь. Но и к обратной связи относимся критически, прогоняем между Сциллой и Харибдой логики и здравого смысла, гуглим в конце концов, как тот или иной термин употребляется у соответствующих вендоров и в отраслевой литературе, ведь если заказчик не ровен час ошибся, расхлебывать и переделывать все равно нам.
Пока заказчик собирается с мыслями, мы не ждем у моря погоды, а спокойно переводим дальше, потому что поправить постфактум несколько терминов, пусть и на десяти страницах, много времени точно не займёт. Кроме того, текст бьется на несколько частей. Если в проекте перевода книги задействовано, скажем, пять переводчиков, они параллельно переводят пять глав, каждый свою, сверяясь с постоянно меняющимся глоссарием и делая поправки на другие вводные от заказчика, если таковые имеются. А потом, продолжая гнуть agile-линию, один переводчик заканчивает свою главу #3, берёт в работу главу #6, а пока он переводит шестую, редактор уже начинает вычитывать третью.
Девять беременных за месяц не родят, а вот с переводом такое бывает
Agile-подход классно работает на срочных задачах. Например, присылают на перевод презентацию на 2000 слов с жестким дедлайном — отдать надо всё целиком через четыре часа. Обычно на перевод 2000 слов, да ещё и презентации, нужен как минимум один рабочий день (если это не rocket science, конечно), а потом еще полдня на вычитку. Но это в нормальных условиях, а как быть здесь? Можно предложить машинный перевод, но для презентаций «машинку» можно использовать лишь как подстрочник, да и то далеко не всегда, т. к. текст в презентации разбит на отдельные блоки, в которых машине бывает непросто ориентироваться. Кроме того, текст должен быть красивым, «продающим» или, как минимум, лаконичным и не царапающим глаз. Поэтому делаем следующее. Если у нас есть три переводчика и один редактор, то мы на пару часов забываем о том, что у семи нянек дитя без глазу, и разбиваем текст на шесть частей. Скажем, 300 слов + 200 + 300 и еще 400 + 400 + 400. Три переводчика берут каждый по одной из первых трёх частей. Причем тот, кто объективно переводит быстрее остальных, берёт первую часть. Через час, а то и раньше, он заканчивает первую часть и берёт в работу четвёртую. Редактор начинает вычитывать первую и параллельно пишет в чат, какие термины и какие часто встречающиеся обороты он правит и почему. Если серьезных возражений у переводчиков нет, они берут варианты редактора и продолжают переводить дальше. Пока редактор дочитывает первую часть, два других переводчика успевают закончить вторую и третью и отдают их редактору, а сами берут в работу пятую и шестую. Когда редактор доделывает первые три части, уже готова четвертая, и первый переводчик может помочь оставшимся двум. В зависимости от степени жёсткости и неадекватности дедлайна первые три части могут быть еще меньше, даже по 100-150 слов каждая, лишь бы редактор включился в работу как можно раньше. Много раз именно так мы и закрывали задачи из серии «прошу-понять-простить». И что это, если не agile?
Я памятник воздвиг нерукотворный… глоссарием назвал
И, конечно, нужно сказать про термины. Устаканить терминологию, то есть утвердить ее у заказчика и по возможности отлить в граните — крайне важно, и чем раньше переводчики начнут заниматься этим богоугодным делом, тем лучше для всех участников проекта. Поэтому после перевода первых пяти-десяти страниц составляется глоссарий. Как только в тексте попадается нетривиальное слово или термин, явно допускающий как минимум два варианта перевода (даже простейшие слова, например, customer можно перевести и как заказчик, и как клиент), переводчик сбрасывает находку в переводческий чат и сразу предлагает свой вариант перевода. Коллеги либо принимают предложенный термин, либо штормят дальше, пока не найдут слово или фразу, которая всех устраивает и, по крайней мере с лингвистической точки зрения, вопросов не вызывает. Слово с переводом уже как термин добавляется в общий глоссарий, которым пользуются все переводчики, и когда набирается с десяток или два терминов, глоссарий отправляется заказчику. И чем непонятнее проект/тема/отрасль/решение, тем больше надо общаться с заказчиком и тем чаще надо показывать ему варианты терминов и уже переведенный материал.
На одном проекте тема была совсем для нас новая, с терминологией всё было сложно, и первые два-три месяца она постоянно менялась. Просто у нас было своё представление о прекрасном, у заказчика — другое, основанное на работе с SAP. А у вендора 1С была своя терминология и даже свой частичный перевод интерфейса, и нам надо было привести всё к единому знаменателю. Например, в модуле по техническому обслуживанию был очень частотный термин «объект ремонта». Изначально были варианты supported item, maintained object, maintenance object, machine и т. д. В итоге пришли к тому, что «объект ремонта» — это asset, и все, т. к. с учетом контекста понятно, о чем речь. А когда объект ремонта принимается к учету в бухгалтерии, то asset становится еще и основным средством, т. е. fixed asset. В том же проекте фигурировал и «типовой объект ремонта». Логично было бы предположить, что это typical asset или common asset, general asset и т.д. Но оказалось, что это сущность более высокого уровня в функциональной иерархии, куда де факто входят отдельные объекты ремонта. Так и назвали по-английски «типовой объект ремонта» как «asset group». Примеров подобного неожиданного перевода терминов там был воз и маленькая тележка. Зато после трёх месяцев постоянных изменений мы через три-четыре итерации смогли зафиксировать основные термины и даже для заказчика стали центром экспертизы по этому вопросу.
В общем всё вышло по фэншую, в смысле по agile, просто тогда мы не думали, что в приличном обществе сие именно так называется. С другой стороны, а как ещё решать подобные переводческие и не только переводческие задачи, когда у тебя куча неизвестных, мол, пойди туда, не зная куда, и переведи то, не зная что. Имхо, никак. Одним словом, жизнь заставит, и не так раскорячишься.
Ещё, правда, пока не про agile, а про ИT-переводы и жизнь вокруг и около них я пишу в телеграм-канале "X-ren переведешь". А как вы используете agile-подход в повседневной жизни? Если у вас в арсенале есть интересные приемы, которые стоит взять на вооружение, делитесь в комментариях.
