Письма: переводчики и ИТ

Вопрос:  «IT-перевод - это актуально и стоит ли с этим связываться переводчику»?

Зависит от того, что вкладывается в понятие «связываться»: глобальное посвящение себя делу ИТ-переводов или точечное, то есть участие в неком проекте. Если имеется в виду первое, то тогда сразу встает другой вопрос: а кто будет являться потребителем результатов этой деятельности? Если на него есть ответ, то все хорошо, а вот если нет…

Как мне кажется, можно выделить три основных направления деятельности в области ИТ-переводов, и каждое связано с определенной целевой аудиторией:

1. предоставление иностранным компаниям и их сотрудникам документации, переведенной с русского, если наши ИТ-шники сами ее составить не могут (речь идет о проектной документации и подобном);
2. перевод английских материалов технического характера (ТЗ и прочее) для наших ИТ-шников;
3. перевод, книжек по ИТ с английского языка на русский для широкого круга (или не очень широкого - все зависит от содержания книги; случаев перевода отечественных книг по современным ИТ на английский мною не наблюдалось).

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

То же касается и второго направления: в английской документации наши вполне способны сами разобраться. К тому же в России давние традиции пиратства, программные продукты в части интерфейса (меню и т. д.) часто переводились, как бог на душу положит, и ничего – никто не умер, и все как-то пользовались (да и сегодня перевод часто так же осуществляется – уже легально, но с тем же качеством, и никого это не только не напрягает, но особо и не волнует). Читать же справочную информацию наши способны «на раз» без всякого перевода, поскольку профессиональный язык весь заимствован «оттуда». Программист, возможно, не сможет объяснить иностранцу, как проехать до ст. метро Тверская, но с аргументами функций разбирается легко.

Третье направление связано с книгами по ИТ (учебные, фундаментальные и т. д.) на английском языке, которые в большом количестве переводят на русский различные издательства. Иногда результат можно назвать удачным, иногда – нельзя. Тут уже другой момент: из-за все того же сленга и специфической тематики, переводчик в идеале сам должен быть ИТ-шником, иначе понимание им самим переводимого не гарантируется, контекст пропадает, и мне доводилось видеть в исполнении весьма известных и крупных издательств многие «творения», содержание которых противоречило не то, что истине, а даже здравому смыслу в самом примитивном его понимании, и это было видно с первого взгляда.

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

Поэтому:

• Чтобы заниматься ИТ-переводом, необходимо разбираться в предмете, то есть знать ИТ изнутри, иметь в этой области образование как минимум на уровне среднего специального.
• Перед тем как посвятить свою жизнь делу ИТ-переводов, нужно ответить на вопрос, кто будет потребителем ваших услуг и ориентироваться соответственно.

Талантливые люди талантливы во всем (в остальном талантливы их родственники)

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

Я часто говорю о том, что в последние годы типичный программист изменился, как и мнение о нем (в минусе клетчатые рубашки, пиво, кофе и круглосуточное затворничество у компьютера; в плюсе - активный образ жизни с кучей увлечений). Что же касается склонностей или близости к литературному творчеству, то они у деятелей вычислительной техники прослеживаются на всем ее историческом пути - либо сами деятели "баловались", либо состояли в близком родстве с маститыми писателями. Такой вот феномен.

Поскольку на днях я "добил"-таки первый том книги Ю.Л. Полунова по истории вычислительной техники (Полунов Ю.Л. От абака до компьютера: судьбы людей и машин. Том 1. - М.: Русская редакция, 2004), я позволю себе привести несколько примеров:

• Клод Перро (-1688) был академиком, врачом, архитектором (среди прочего он был автором восточного фасада Лувра), физиком, натуралистом, переводчиком, конструктором, механиком, а при случае и рифмоплетом. Помимо всего прочего он был братом небезызвестного нам Шарля. Вообще, из пяти братьев Перро только один - Жан - был более менее постоянен в роде деятельности, а остальные были "многостаночниками" и, надо сказать, везде добивались успеха. Что же до Клода Перро, то он изобрел первую суммирующую машину, где вместо зубчатых колес применялись зубчатые рейки (кремальеры) и назвал ее "Рабдологическим абаком".
• На леди Августе Аде Лавлейс (1815-1852) останавливаться подробно не буду - всем известно, что она была дочерью Джорджа Гордона Байрона. Кстати матерью ее была Анна Изабелла Милбэнк - человек весьма одаренный, "принцесса параллелограммов", "незаурядная женщина, поэтесса, математик, философ", как писал Байрон.
• Много позже в годы Великой Отечественной Войны будущий "отец" легендарного Джеймса Бонда Ян (или Иан) Флеминг (1908-1964) плодотворно работал в качестве профессионального криптолога в "Правительственной школе кодов и шифров" в Блетчли - это был проект Департамента связи Министерства иностранных дел Великобритании. Кстати, там же и в то же время трудился и Алан Тьюринг.
• Нельзя не отметить, наверное, самого выдающегося советского программиста - Андрея Петровича Ершова (1931-1986). Ученик А.А. Ляпунова (одного из основоположников кибернетики, члена-корреспондента Академии наук СССР) после аспирантуры возглавлял отдел автоматизации программирования Вычислительного центра Академии наук СССР, издал первую в мире монографию ("Программирующая программа для быстродействующей счетной машины"), посвященную созданию трансляторов, из которой друг и соратник Ершова Дональд Кнут почерпнул по его собственному признанию "интересные алгоритмы оптимизации компилятора". Ершов был убежден, что "программирование - вторая грамотность" и ратовал за включение "Основ информатики и ВТ" в школьный курс (он же написал первый учебник по дисциплине). Помимо прочего Андрей Петрович увлекался поэзией, блестяще зная английский язык, переводил Киплинга, любил играть на гитаре и петь.

Так что, подводя итог, литературность и высокие материи нам не чужды. Я себя, конечно, к классу вышеперечисленных деятелей не отношу, но тоже иногда возникает желание побаловаться сочинительством. Да и на гитаре приспичило научиться играть в 30 лет. А уж если вспомнить, сколько хохм (правда, с трудом относимых к качественной литературе) было придумано моими друзьями и мной за прошедшие годы... Взять хотя бы небольшой набор рассказов про Красную Шапочку. Вряд ли они когда-нибудь увидят свет, но кто знает... кто знает...

Еще раз о поиске работы в секторе ИТ

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

Цель статьи - систематизированно изложить взгляд конкретного работодателя в сфере ИТ на содержание и структуру качественного резюме соискателя, а также перечислить и обосновать наиболее часто встречающиеся в подобных документах недостатки. Работа адресована тем, кто претендует на вакансии в сфере ИТ (в частности, разработчикам ПО) и при этом испытывает сложности с составлением резюме.

Наброски ландшафта

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

Техника отбора резюме

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

Во-вторых, в силу бюрократии найм нового разработчика зачастую происходит отнюдь не тогда, когда он нужен, а в нарушение Закона Брукса («Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше») с приличным опозданием и после долгих переговоров с разными начальниками, смысл которых вкратце сводится к следующему: «Работу некому делать, проект уже на две недели отстает от графика, дайте же наконец человека!». После этого сотрудники департамента HR все-таки получают указание от руководства и вываливают соответствующему техническому специалисту – менеджеру проекта, тимлиду, - пачку из пяти-восьми, а то и десяти резюме. У него, специалиста, от которого зависит решение «принять/не принять», реально нет столько времени разбираться с каждым кандидатом! У него и своей работы выше крыши, и сроки уже подпирают! Поэтому, как только будет найден человек соответствующей квалификации и «вписывающийся» в проект, все остальные резюме отправятся прямиком в корзину. Может быть, в конце пачки были кандидаты и лучше, но у специалиста нет времени на них, а «достаточно хороший» человек уже найден. Все.

Выбираем резюме

С точки зрения работодателя резюме должно быть:

• «Вменяемым», то есть понятным.
• Структурированным.

Что касается понятности, то все довольно очевидно: резюме, как визитная карточка, а встречают «по одежке». В резюме не должно быть грамматических ошибок, они говорят либо о невнимательности соискателя (а какая может быть невнимательность в нашей профессии?), либо - о его безграмотности, что еще хуже. Если кандидат не умеет ясно и четко излагать свои мысли на русском языке, то чего ожидать от него на неродном языке - например, на С++?

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

(продолжение статьи на сайте TopRecruit.ru)