Использование технологии Semantic Web в системе поиска несоответствий в текстах документов

Андреев А.М. Березкин Д.В. Рымарь В.С. Симаков К.В.
НПЦ "ИНТЕЛТЕК ПЛЮС"
arka@inteltec.ru

Аннотация

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

Введение

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

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

Обзор существующих технологий и стандартов

Задачи хранения, извлечения, получения и анализа знаний решаются в рамках направления, получившего названия Semantic Web [2]. В обоих случаях необходимо иметь структурированные хранилища информации и множества правил вывода, которые компьютеры бы использовали для автоматических рассуждений [3]. Учитывая многолетний опыт разработки, стандартизации и развития технологий Semantic Web в рамках World Wide Web Consortium[4], использование существующих разработок в этой области является закономерным.

Сейчас уже создан ряд важнейших технологий (представленных на рисунке 1): Расширенный Язык Разметки (Extensible Markup Language, XML) [5], Система Описания Ресурсов (Resource Description Framework, RDF)[6], Язык Сетевых Онтологий (On-tology Web Language, OWL)[1], используемых для описания, хранения и распространения знаний. Так же стоит выделить SPARQL Язык запросов к RDF (SPARQL Query Language for RDF)[7], который 6 апреля 2006 года стал кандидатом к рекомендации W3C, так же ведутся работы по стандарту протокола SPARQL для RDF и стандарта, определяющего XML-формат представления результатов обработки SPARQL-запросов.

Рис. 1. Рекомендации W3C касательно Semantic Web.

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

Система семантического контроля текстов редактируемых документов

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

Предложена система, решающая указанные задачи, структура которой представлена на рисунке 2. На рисунке 2 показаны АРМы пользователей системы, а также отмечены средства разработки отдельных модулей системы.

Рис. 2. Структура системы семантического контроля текстов.

С точки зрения работы с системой можно выде-лить 4 АРМ:

• Пользователь,

• Администратор "Правил извлечения",

• Администратор "Онтологии",
• Администратор "Серверов анализа текста и базы данных".

АРМ - администратор "Серверов анализа текста и базы данных". Функции этого АРМ сводятся к первоначальной настройке (или дополнительной настройке) серверов базы данных и анализа текста.

АРМ - администратор правил извлечения. Задача данного АРМ - формирование правил извлечения, используемых модулем анализа текстов сервера.

АРМ - администратор "Онтологии". Основная функция - управления онтологией. В частности создание, удаление, наполнение, выгрузка области онтологии. Функции:

АРМ - Пользователь. Пользователи системы работают в текстовом редакторе (например, MS Word). С помощью этого АРМа конечные пользователи реализуют такие функции системы как:

автоматическое (по команде пользователя) выделение в тексте терминов и словосочетаний, присутствующих в онтологии;

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

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

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

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

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

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

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

Модель знаний системы основана на онтологии, записанной на языке OWL. Базовый строительный блок модели данных - утверждение, представляющее собой тройку: ресурс (экземпляр класса для OWL), именованное свойство и его значение. В терминологии RDF эти три части утверждения называ-ются соответственно: субъект, предикат и объект [6]. Под свойством следует понимать некий аспект, характеристику, атрибут или отношение, используемое для описания ресурса. Каждое свойство имеет свой специфический смысл, допустимые значения, тип ресурсов, к которым оно может быть применено, а также отношения с другими свойствами. Согласно спецификации, значение свойства может иметь один из двух типов. Первый - это ресурс (экземпляр некоторого класса), задаваемый некоторым URI. Второй тип - литерал - есть некоторое текстовое значение характеристики. Впрочем, литерал может выражать собой значение любого примитивного типа данных, присутствующего в XML. Таким образом, свойства P языка OWL являются бинарными отношениями на C V или C C, где C являются классами, V литеральными значениями. Свойства первого типа связывают экземпляры классов с конкретными значениями, свойства второго типа связывают экземпляры классов друг с другом. Задача извлечения знаний при таких условиях сводится к созданию экземпляров классов, распознаванию значений и распознаванию свойств в естественно-языковых текстах. В общем случае в текстах можно найти упоминание о том или ином экземпляре класса только в рамках некоторого свойства. В этом случае удобно говорить о роли экземпляра в рамках свойства.

С учетом OWL ограничения о бинарности свойств, экземпляр класса может играть либо роль субъекта свойства, либо роль объекта. Для свойств типа C V экземпляр может выступать только в роли субъекта. Таким образом, извлекаемыми элементами являются либо тройки вида <i,p,t>, либо тройки вида <c1_i,p,c2_j>. Тройка <c_i,p,t> указывает на наличие в тексте свойства p типа C X V некоторого экземпляра i класса c, выраженного текстовым фрагментом t. Тройка <c1_i,p,c2_j> указывает на наличие свойства p типа C X C между извлеченным ранее экземпляром i класса c1 и экземпляром j класса c2.

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

Рис. 3. Пример анализа текста.

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

Рис. 4. Факты, выявленные из текста.

Особенности проектирования онтологии системы

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

Рис. 5. Онтология логически разделена на локальные области.

В рамках данной статьи рассматривается локальная область "Кадровая база". Для нее в качестве источника используется XML файл. На основе анализа этого источника данных были выявлены основные понятия данной предметной области и связи между ними, далее определены для них классы и создана таксономия классов. На рисунке 6 представлен фрагмент таксономия классов предметной области "Кадровая база".
Заметим, что каждый экземпляр в мире OWL является членом класса owl:Thing. Таким образом, каждый определенный нами класс автоматически является подклассом owl:Thing. На рисунке 7 представлен фрагмент онтологии "Кадровая база" без учета таксономии классов.

Рис. 6. Фрагмент таксономии классов.

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

Рис. 7. Пример онтологии "Кадровая база".

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

Модуль логического вывода

Основной задачей системы является выявление несоответствий извлеченных фактов и фактов, содержащихся в базе знаний. Она реализуется модулем логического вывода, который производит сопоставление фактов, извлекаемых из текста, фактам, содержащимся в базе знаний.
Рассмотрим подробнее логику работы модуля логического вывода. Как уже отмечалось, на вход поступает несколько вариантов извлечения (набор цепочек фактов). Необходимо рассмотреть все варианты извлечения и на основе наиболее "подходящего" сделать вывод о достоверности фактов. Как уже отмечалось, из текста извлекаются цепочки троек двух типов - факты, описывающие свойства - значения и свойства - объекты. Тогда наш анализ можно разделить на несколько стадий:
Опираясь на свойства - значения идентифицируем в онтологии экземпляры. Факты, описывающие такие свойства, имеют вид <Class_Id,PropertyId,Value>. Тогда в онтологии необходимо найти экземпляр класса с именем Class, у которого свойство - значение с именем PropertyId имеет значение Value. Заметим, что для некоторых экземпляров может существовать несколько определяющих их свойств - значений. Например,
<Functionary_1,hasName,"Иванов">
<Functionary_1,hasPatronymic," Иванович">
<Functionary_1,hasSurName,"Иванов">
В таких ситуациях выполняется поиск экземпляра, у которого описанные свойства имеют соответствующие значения. С другой стороны для некоторого количества свойств-значений может быть идентифицировано несколько экземпляров какого-то класса. Например, по тройке <Function-ary_1,hasSurName,"Иванов"> может быть найдено несколько экземпляров класса Functionary (функционер), у которых свойство hasSurName (имеет фамилию) имеет значение "Иванов".
Для всех идентифицированных экземпляров проверяем справедливость свойств - объектов, имеющих вид <Class1_Id1,PropertyId,Class2_Id2>. Каждый такой факт устанавливает связь (свойство - объект с именем PropertyId) между двумя экземплярами разных классов. Если на первом шаге было выявлено несколько экземпляров, необходимо произвести такой поиск для всех возможных вариантов.
Заметим, что на первом шаге можем идентифицировать не все объекты, тогда на втором шаге проверяем справедливость свойств - объектов только для найденных экземпляров. Рассмотрим подробнее анализ одной цепочки троек. На рисунке 8 проиллюстрирован алгоритм работы модуля логического вывода и показаны возможные варианты при рассмотрении одной цепочки фактов (варианта извлечения).
Рассмотрим каждый из вариантов:

1. Найдены все экземпляры, но не все связи между ними подтверждены. На основании только этого варианта извлечения можно сделать вывод о том, что в анализируемом фрагменте текста существует возможное нарушение семантических связей, дальнейший анализ этого фрагмента можно не проводить.
2. Найдены все экземпляры, и все связи между ними подтверждены. На основании только этого варианта извлечения можно сделать вывод о том, что в анализируемом фрагменте текста нет нарушения семантических связей, т.е. все извлеченные факты подтверждены фактами из онтологии. И дальнейший анализ такого фрагмента можно не проводить.
3. Не найдено ни одного экземпляра. Это говорит либо о неправильном извлечении фактов из текста, либо о неактуальности онтологии (онтология неполная или содержащаяся в ней информация устарела). В любом случае это необходимо зафиксировать в Log-файле для дальнейшего анализа.
4. Найдены не все экземпляры, и при этом не все связи между ними подтверждены. То, что не найдены все экземпляры говорит о неактуальности онтологии или об ошибках извлечения. Это необходимо зафиксировать в Log-файле для дальнейшего рассмотрения, но при этом дальнейший анализ можно проводить по найденным экземплярам. Т.к. не все связи между найденными экземплярами установлены, то предположительно в анализируемом фрагменте текста существует нарушение семантических связей. Т.к. идентифицированы не все экземп-ляры, необходим дальнейший анализ этого фрагмента, т.е. необходимо рассмотреть другие варианты извлечения.
5. - Найдены не все экземпляры, но все связи между ними подтверждены. То, что не найдены все экземпляры говорит о неактуальности онтологии или об ошибках извлечения. Это необходимо зафик-сировать в Log-файле для дальнейшего рассмотрения, но при этом дальнейший анализ можно проводить по найденным экземплярам. Т.к. все связи между найденными экземплярами установлены, то предположительно в анализируемом фрагменте текста нет нарушения семантических связей. Т.к. идентифицированы не все экземпляры, необходим дальнейший анализ этого фрагмента, т.е. необходимо рассмотреть другие варианты извлечения.

Теперь рассмотрим, как сделать вывод о нарушении или отсутствия нарушения семантических связей для всего набора цепочек.
Если при анализе одного варианта извлечения (одной цепочки) получается вариант 1 или 2, то можем сделать вывод обо всем рассматриваемом фрагменте текста и другие цепочки не рассматривать. Другой вариант, если при анализе всех цепочек получали только варианты 3, 4 или 5. Получение варианта 3 для всех цепочек говорит об ошибках извлечения или неактуальности онтологии, делать вывод на основе такого анализа невозможно, поэтому просто фиксируем этот факт в Log-файл. Если при рассмотрении всех цепочек (всех вариантов извлечения) для данного фрагмента встретился хотя бы один вариант 5 (т.е. остальные 3 или 4), то делаем вывод, что предположительно в данном фрагменте нет нарушения семантических связей. При наличии только вариантов 4 и, возможно, некоторых 3, делаем вывод о наличии возможного нарушения семантических связей. Таким образом, рассмотрены все возможные варианты, полученные при анализе каждой из цепочек.
Остановимся подробнее на формировании SPARQL запросов для поиска в онтологии модулем накопления. Рассмотрим два вида запросов: для свойств - значений и свойств - объектов.
Запрос для тройки, описывающей свойство - значение. Например, для тройки, извлеченной из фрагмента текста <Functionary_1,hasName,"Иванов"> сформируем SPARQL запрос к онтологии. Нам необходимо найти экземпляр или экземпляры класса Functionary, у которых свойство hasName имеет значение "Иван".

Рис. 8. Работа модуля логического вывода.

Это можно выполнить, например, с помощью следующего запроса:
SELECT ?x WHERE
{
?x rdf:type .
?x < hasName> "Иван"^^xsd:string.
}
В ответ на этот запрос мы получим список имен экземпляров класса Functionary, например, Functionary_765, Functionary_8765, Functionary_8766. Или ничего, если нет ни одного экземпляра, у которого свойство hasName имеет значение "Иван".
Запрос для тройки, описывающей свойство - объект. Например, для тройки <Function-ary_765,isMemberOf,Committee_2424> сформируем SPARQL запрос к онтологии. Это можно выполнить, например, с помощью запроса:
ASK WHERE
{
Functionary_765
< isMemberOf >
Committee_2424.
}
В ответ на этот запрос получим ответ в формате "YES"/"NO", что говорит о наличии/отсутствии такой связи (свойства-объекта) в онтологии.
Таким образом, цепочку троек свойств - значений делим на несколько частей, каждая из которых описывает один конкретный экземпляр. Затем, на основе каждой из частей генерируем SPARQL [7] запрос, который исполняется с помощью модуля накопления. В ответ на каждый запрос получаем список экземпляров (возможно пустой). После этого для всех свойств - объектов формируем запросы со всеми возможными вариантами найденных экземпляров. После выполнения всех таких запросов можем присвоить этой цепочке троек один из номеров варианта решения (от 1 до 5, см. рисунок 8). Исходя из варианта решения для текущей цепочки, анализируем остальные цепочки троек или делаем вывод о возможном нарушении семантических связей.
Таким образом, на основе набора вариантов извлечения модуль логического вывода принимает решение о возможном нарушении семантических связей.

Другие модули системы

Сервер базы данных выполняет две основные функции. Во-первых, хранение/обновление онтологии и выполнение к ней запросов. Во-вторых, разграничение прав доступа к онтологии. Так же важными функциями является ведение журнала доступа к серверу базы данных и возможность резервного копирования базы знаний. На сервере анализа текста предусмотрен так же модуль накопления. Он решает две задачи: обеспечивает взаимодействие с сервером базы данных, а так же формирует запросы для работы с онтологией. Это позволит использовать базы сторонних разра-ботчиков с минимальными изменениями в коде сер-вера анализа текста, локализованными в одном мо-дуле.
Так же существуют независимые прикладные программы. Например, программы управления онтологиями, предназначенные для ведения онтологии: создание, изменение, удаление. Каждая программа ведёт свою область онтологии, опираясь на конкретный источник. В качестве источников информации в общем случае могут выступать структурированные текстовые файлы (XML, HTML), базы данных, редакторы онтологий и т.д.
Таким образом, мы описали полный цикл работы системы - от загрузки и управления онтологией, до непосредственного выявления неэквивалентности фактов в тексте и в базе знаний.

Выбор средств разработки

Для эффективной разработки готовых систем в современных условиях с жесткими требованиями по времени необходимо использовать готовые компоненты и модули сторонних разработчиков. Особенно это актуально при использовании стандартизированных технологий. В нашем случае это работа с онтологией на языке OWL, выполнения запросов на языке SPARQL к RDF нотации этой онтологии. Для возможности использования компонентов сторонних разработчиков, необходимо чтобы они удовлетворяли нескольким требованиям: обладать API для работы с OWL онтологией, иметь возможность выполнять SPARQL запросы, иметь парсер для работы с онтологией, а так же использовать для хранения и работы с онтологией СУБД. Всем этим требованиям удовлетворяет Jena [9], разработанная HP Labs[10]. Jena - это набор свободно распространяемых библиотек, написанных на Java.
Jena включает:

• RDF API;
• Чтение/запись документов RDF в RDF/XML формате;
• OWL API;
• Хранилища онтологий в памяти и в СУБД;
• Выполнение SPARQL запросов.

В качестве СУБД, при работе с Jena, предлагается использовать MySQL, Oracle, PostgreSQL. В данной разработке сделан выбор в пользу MySQL [11], как надежной, быстродействующей, свободно распространяемой СУБД.
Таким образом, в качестве платформы разработки выбирана Java, в качестве сервера базы данных используется MySQL. Доступ к этой СУБД из Java программ осуществляется стандартными средствами MySQL (JDBC). Для работы с онтологиями используются средства Jena, библиотеки которой позволяют выполнять все необходимые нам операции. Заметим, что библиотеки Jena используются в модуле накопления сервера анализа текста и в аналогичных модулях прикладных программ управления онтологией.
В системе также имеется возможность создания и ведения области онтологии в ручном режиме с помощью редакторов онтологии. Существуют как коммерческие, так и свободно распространяющиеся редакторы онтологий. Среди платных стоит выделить Altova's SemanticWorks[12], среди бесплатных - Protege [13].
Как уже отмечалось, с развитием технологий, относящихся к Semantic Web, следует ожидать появления новых и дальнейшего развития уже существующих средств разработки.

Заключение

В настоящее время создана и внедряется в Совете Федерации Федерального Собрания Российской Федерации первая очередь информационной системы "Семантический контроль текстов редактируемых документов", описанная в данной статье. Она используется специалистами Управления информационного и документационного обеспечения аппарата Совета Федерации для проверки правильности расшифровки стенограмм и проверки редакций различных типов документов на предмет их соответствия эталонным словарям и базам данных. Онтология, используемая системой, создана на основе кадровой базы Совета Федерации, в настоящий момент содержит 6 классов, общее количество экземпляров по всем 6-ти классам составляет 1183, суммарное количество свойствзначений по этим экземплярам - 3785, общее количество свойств-объектов, связывающих экземпляры онтологии, - 755.
В качестве направления развития системы можно указать на необходимость использовать более сложные механизмы логические вывода и анализа, например, языков логического вывода (SWRL[14], RuleML[15]). Также увеличение сложности и объемов хранимых в онтологии знаний, добавление новых логических областей, очевидно, потребует совершенствования средств работы с онтологией.

Литература

[1] Web Ontology Language (OWL), http://www.w3.org/2004/OWL/
[2] Semantic Web, http://www.w3.org/2001/sw/http://www.w3.org/2001/sw/.
[3] Tim Berners-Lee, James Hendler and Ora Lassila, The Semantic Web, http://www.scientificamerican.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21&catID=2.
[4] The Extensible Markup Language (XML), http://www.w3.org/XML/
[5] Resource Description Framework (RDF), http://www.w3.org/RDF/
[6] SPARQL Query Language for RDF, http://www.w3.org/TR/rdf-sparql-query/
[7] Владимир Шрайбман, Выражение семантики данных. RDF против XML, http://www.citforum.ru/internet/xml/rdf_xml/
[8] World Wide Web Consortium (W3C), http://www.w3.org/
[9] Jena - A Semantic Web Framework for Java, http://jena.sourceforge.net/
[10] HP Labs Semantic Web Research, http://www.hpl.hp.com/semweb/index.html
[11] MySQL, http://www.mysql.com
[12] SemanticWorks, http://www.altova.com/products_semanticworks.html
[13] Protege, http://protege.stanford.edu/
[14] SWRL: A Semantic Web Rule Language Combin-ing OWL and RuleML, http://www.w3.org/Submission/SWRL/
[15] The Rule Markup Initiative, http://www.ruleml.org/
[16] Андреев А.М., Березкин Д.В., Симаков К. В. Особенности проектирования модели и онтоло-гии предметной области для поиска противоре-чий в правовых электронных библиотеках. 6-ая Всероссийская научная конференция RCDL'2004.

Using Semantic Web technology for the task of inconsistency detection in natural language texts

The primary purpose of this article is to show main technological decisions was made during developing the system of inconsistency detection in natural language texts of some domain. For this task we use the ontology as etalon knowledge base. We present the architecture of the system and describe the logic of its working.

юмор

Действительно реальный вопрос на тесте по химии в NUI Maynooth (Kildare, Irland).Ответ одного студента был настолько "глубоким", что профессор решил поделиться им в сети.

ВОПРОС: Как бы Вы описали ад - как экзотермичную (отдает тепло), или как эндотермичную (абсорбирует тепло) систему?

Большинство студентов пытались описать ад с помощью закона Бойля-Мариотта, типа газ при расширении охлаждается и температура при давлении падает и пр.
Один из студентов написал: "Сначала мы должны выяснить, как изменяется масса ада с течением времени. Для этого нужно знать, сколько душ прибывает в ад и сколько душ его покидает. Я считаю, что если уж душа попала в ад, покинуть его она не может. На вопрос, сколько душ прибывает в ад, нам помогут ответить различные религии, существующие сегодня в мире. Большинство из этих религий утверждает, что души людей, не принадлежащих их церкви, однозначно попадают в ад. Поскольку человек не может принадлежать больше чем одной религии, можно однозначно утверждать, что ВСЕ души попадают в ад. Приняв во внимание индексы рождаемости и смертности, можно предполагать, что число душ в аду растет экспоненциально. Рассмотрим теперь вопрос изменения объема ада. Чтобы в аду поддерживать одинаковую температуру и давление, объем его должен увеличиваться пропорционально увеличению количества душ -! согласно закону Бойля...
Иначе говоря, имеем два варианта:
1. Если ад расширяется медленнее, чем растет число прибывающих душ, то температура и давление там будут расти до тех пор, пока ад просто не развалится.
2. Если же ад расширяется быстрее, тогда температура и давление падают - ад замерзнет.
Какой из вариантов правильный?
Взяв за основу предсказание Сандры на первом курсе, что "в аду настанет зима, прежде чем я лягу с тобой в постель", а также тот факт, что она вчера со мной спала - мы придем к однозначному выводу, что ад замерз. Из этого следует, что ад не в состоянии более принимать души. Остается только рай - что и подтверждает наличие Бога. Этим, видимо, и объясняется тот факт, что Сандра всю прошлую ночь кричала "О, Боже!"
Студент получил "отлично" - единственный на курсе.

Великие раскопки и великие вызовы

Леонид Левкович-Маслюк
Опубликовано 23 марта 2007 года

---

© 2006, Издательский дом «КОМПЬЮТЕРРА» | http://www.computerra.ru/
Журнал «Компьютерра» | http://www.computerra.ru/
Этот материал Вы всегда сможете найти по его постоянному адресу: http://www.computerra.ru/features/311656/

---

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

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

Вот где-то между этими молотом и наковальней и зародился современный датамайнинг (data mining, буквально - раскопки данных, или добыча чего-то из данных), в котором научные и индустриальные компоненты трудно разделить. В 1998 году научную зрелость этой отрасли подтвердило создание Special Interest Group (SIG), Группы особых интересов, в рамках авторитетной международной организации по компьютерным исследованиям ACM (Association for Computing Machinery, Ассоциация по вычислительным машинам).

Что такое SIG? Вспомним о самой популярной из подобных групп - SIGGRAPH. Ежегодные мегаконференции, на которых делаются доклады, читаются лекции и демонстрируются высшие достижения компьютерной графики, анимации и сопутствующей всему этому математики, других наук и технологий, известны далеко за пределами сообщества специалистов. Другие SIG’и (сейчас их тридцать четыре, в том числе SIGART [искусственный интеллект], SIGMOD [базы данных], SIGPLAN [языки программирования], SIGSOFT [разработка ПО] и др.) не так знамениты среди широкой публики, но заслужили уважение специалистов, а проводимые ими конференции, издаваемые журналы являются индикаторами качества в своих областях.

Цифра

Агентство IDC прогнозирует, что объем цифровой информации в мире достигнет тысячи экзабайт к 2010 году, то есть по сравнению с 2006 годом увеличится в 6 раз (1 экзабайт = 2^60 байт, или миллиард гигабайт).

На наши вопросы о теории и практике датамайнинга ответил Григорий Пятецкий-Шапиро (Gregory Piatetsky-Shapiro), основатель и председатель SIGKDD - Группы особых интересов, посвященной "открытию знаний в данных" (Knowledge Discovery in Data).

Какие новые разделы датамайнинга (ДМ) появились в последние годы? Какие из них самые перспективные для бизнеса, для исследовательской работы?

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

Огромный прогресс виден и в майнинге текста (большинство программных комплексов [suites] для датамайнинга теперь включают компоненты для текст-майнинга), а также в майнинге мультимедиа. И то и другое - прекрасные области для исследований.

Распределение областей применения датамайнинга согласно опросу посетителей kdnuggets.com

Датамайнинг широко применяется в больших компаниях, особенно работающих в электронной коммерции. Amazon, Yahoo - примеры таких компаний (мой коллега Усама Файяд занимает должность руководителя по обработке данных [Chief Data Officer] в Yahoo, он первым в индустрии е-коммерции получил такой титул). Вот неполный список областей применения датамайнинга:

• реклама;
• биоинформатика;
• связь с клиентами (CRM);
• маркетинг;
• выявление мошенничества (fraud detection);
• е-коммерция;
• здравоохранение;
• инвестиции/ценные бумаги;
• управление производством;
• развлечения и спорт;
• телекоммуникации;
• изучение веба.

Если говорить об успехах индустрии датамайнинга, то самый яркий пример здесь - Google. Oба его сооснователя в Стэнфорде занимались исследованиями в этой области, и ранняя история самого Google связана с датамайнингом.

Рекомендации на сайте Amazon.com ("покупатели, купившие/искавшие/посмотревшие X, купили также Z") привели к огромному росту продаж. Высококачественные рекомендации такого типа обеспечили успех компании Netflix, занимающейся прокатом видео.

Например, если вам понравилась знаменитая абсурдистская комедия "Монти Пайтон и священный Грааль" ("Monty Python and the Holy Grail"), то вы получите от Netflix рекомендацию посмотреть "This is Spinal Tap"¹, известную пародию на документальный фильм о гастролях экстравагантной рок-группы. Netflix придает такое значение датамайнингу, что в прошлом году учредила приз в миллион долларов за улучшение алгоритма выработки рекомендаций.

Истоки KDD

Как развивалась ваша карьера? Как вы заинтересовались датамайнингом?

- С детства у меня была склонность к математике, очевидно унаследованная от папы, крупного математика Ильи Пятецкого-Шапиро. Живя в Москве, я учился в известной Второй математической школе, принимал участие в математических олимпиадах - но поскольку перенял от папы лишь малую часть математического таланта, то уже в школе понял, что чистая математика не для меня. Я открыл для себя компьютеры в 1974 году, на первом курсе в Технионе, когда эмигрировал в Израиль, и сразу заинтересовался ими. Меня особенно увлекали вопросы искусственного интеллекта. Первую интересную программу я написал в 1974 году на языке АПЛ - она была предназначена для игры в "морской бой". Сыграв с ней одну партию, я безоговорочно уступил своей же программе. Желание продолжать игру исчезло - зато усилилось желание писать программы. Потом была учеба в аспирантуре в США, тоже с концентрацией на задачах искусственного интеллекта. Темой диссертации стало приложение искусственного интеллекта к работе с базами данных.

Датамайнингом я заинтересовался, работая в Лабораториях GTE (организация, подобная знаменитой Bell Labs, только поменьше) над крупными коммерческими базами данных. Оказалось, что если найти определенные правила, некоторые запросы к этим базам можно ускорить на несколько порядков. Я заинтересовался вопросом - можно ли находить такие правила автоматически, и занялся применением идей искусственного интеллекта к большим базам данных. Побывав в 1988 году на встрече (workshop) по этой теме (в рамках конференции AAAI ’88), я понял, что этому мероприятию нужна более четкая фокусировка. По молодости лет я не представлял себе, каких усилий стоит организовать такую встречу, и поэтому в 1989 взялся за организацию воркшопа сам. Термин "датамайнинг" я считал недостаточно завлекательным (sexy) и вместо него предложил назвать тему "открытие знаний в базах данных" (Knowledge Discovery in Databases, KDD). Это название подчеркивало, что конечная цель работы - знания, и намекало на дух первооткрывательства, сопутствующий поиску знаний. Тогда же я начал новый проект в GTE Labs, и это был первый в мире проект по KDD.

Воркшоп прошел в 1989 году с большим успехом, и с тех пор я продолжаю работать в этой области. В 1993 году начал рассылку "Knowledge Discovery Nuggets", чтобы помочь в установлении связей между исследователями, занятыми этой проблематикой (первыми ее получили пятьдесят участников KDD-93). В 1994 году, с началом массового распространения веба, я создал один из первых сайтов по датамайнингу, из которого вырос мой нынешний сайт KDnuggets.com. Я очень рад, что вовремя сообразил, что в одиночку не потяну организацию воркшопов, и подключил к этому делу Усаму Файяда (Usama Fayyad), ставшего председателем оргкомитета KDD-94. С ним и еще несколькими коллегами мы превратили KDD в полномасштабную конференцию, а при поддержке Вон Кима (Won Kim) создали в 1998 году SIGKDD - исследовательское общество по открытию знаний и датамайнингу. В 2007 году в Сан-Хосе (Калифорния) пройдет уже 13-я конференция KDD. Воркшоп KDD в 1989 году был единственным в мире, а сейчас каждый год собирается дюжина конференций и встреч по этой теме.

Кто заказывает вашей фирме KDnuggets датамайнинговые проекты? Насколько они масштабны (по количеству участников, ресурсам, времени выполнения)? Требуют ли разработки нового ПО специально для каждого проекта?

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

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

Оценка

Удачные статистические модели позволили выявить потенциальные "налоговые убежища" обеспеченных американцев объемом в сотни миллионов долларов.

К сожалению, многие успешные датамайнинговые проекты, в том числе и часть моих, связаны с деликатными вопросами бизнеса - такими, как выявление мошенничества и обмана, - и поэтому о них нельзя подробно рассказать в прессе. Однако недавно состоялся воркшоп, специально посвященный "историям успеха" технологий датамайнинга. Там были представлены статьи, против публикации которых заказчики проектов не возражали. Лучшей была признана работа Бхарата Рао (Bharat Rao) из Siemens, в которой описывалась очень интересная система. Она позволяет автоматически повысить качество лечения и ухода за пациентами кардиологических отделений благодаря тому, что извлекает важную медицинскую информацию из невнятно написанных и неточных записей в историях болезни².

Кандидаты в великие

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

• Провести аннотацию 1000 Часов цифрового видео в течение одного часа. Согласно автору предложения Шабану Джерабе (Chabane Djeraba), в настоящее время это требует тысяч человеко-часов при ручной работе. Под аннотацией подразумевается краткое описание происходящего. Например, сегодня невозможно без выполненной человеком аннотации выделить в записи баскетбольного матча эпизоды атаки и обороны каждой команды. Ручная аннотация одной фотографии для Национального географического общества требует двадцать минут.

• Википедия-тест

  (Lise Getoor, Лиз Гетур). По сборнику статей, созданному либо в режиме партисипативной журналистики (то есть по принципу наполнения Википедии), либо с использованием автоматических инструментов поиска линков по требуемой тематике, определить, какой из этих двух методов использовался: то есть составлен ли сборник машиной или людьми (и в каком случае качество оказалось выше)? Автор предложения указывает на связь этого вызова с другим, брошенным специалистам по сжатию информации: сжать 100 мегабайт Википедии до 18 мегабайт, не потеряв ни единого бита (за это уже назначен приз Хаттера в 50 тысяч долларов).

• Оценить миллиард прогнозирующих моделей

  (Robert Grossman, Роберт Гроссман). В ходе многолетней практики датамайнинга было построено великое множество статистических моделей для различных типов и конкретных ансамблей данных. Во многих случаях для одних и тех же массивов данных строится несколько моделей, чтобы ухватить их характеристики разных видов. Пример: имеется информация от 833 датчиков движения транспорта в Чикаго. Задача состоит в автоматическом определении ситуаций, когда в транспортном потоке возникают аномалии, происходит что-то необычное (но не простая пробка!). Данные сегментировались по дням, часам и участкам дороги, что приводило к появлению 7х24х250 = 42000 автоматически генерируемых статистических моделей - хотелось бы значительно сократить их число! Подобная ситуация возникает и в онлайновом маркетинге (отдельная модель поведения для каждого клиента), в перспективных подходах к оценке эффективности лекарств на основе индивидуального генотипа и т. д. Так что миллиард набирается легко - вопрос в том, как радикально уменьшить это число.

• Разработка систем анализа текстов (text mining), способных сдать обыЧные экзамены на понимание текста SAT, GRE, GMAT

  (Ronen Feldman, Ронен Фелдман). Эту задачу с оптимизмом комментирует в своих ответах Григорий Пятецкий-Шапиро. Она покруче даже стандартного теста Тьюринга (определить, машина или человек отвечает на ваши вопросы), по поводу которого тоже было много оптимизма, в том числе и у его гениального автора. Однако не будем забывать, что этот вызов - лишь планка, которую автор предложения поднимает так высоко в надежде на достижение более приземленных практических целей: довести точность реализации реляционных запросов с нынешних 70–80% до 98–100%, причем в самой общей ситуации.

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

Ну а для полноты картины упомянем и конкурс, который состоится на конференции KDD-2007. Участникам предоставляется тренировочный массив данных Netflix, в котором собрано больше 100 млн. рейтингов (по пятибалльной шкале) по 18 тысячам фильмов от 480 тысяч случайно выбранных анонимных пользователей Netflix (то есть людей, бравших у Netflix DVD напрокат), с 1998 по 2005 год. Вот одна из двух задач, по которым будет проводиться состязание:

Дан список из 100 тысяч пар вида "номер_пользователя, номер_фильма", относящийся к 2006 году (то есть не входящий в тренировочный массив). Для каждой такой пары нужно указать вероятность, что данный пользователь хоть как-то рейтинговал данный фильмв 2006 году.

Денежные призы не предусмотрены - в отличие от основного конкурса Netflix. Там, чтобы заработать миллион долларов, требуется превзойти точность действующей сейчас на фирме системы рекомендаций Cinematch™ всего лишь на 10% (на исторических данных); ежегодно разыгрывается приз в скромные 50 тысяч долларов просто за самое большое уточнение прогноза. Прогноз состоит в том, чтобы угадать по предшествующим оценкам фильмов клиентами, какие из фильмов они высоко оценят в будущем. По состоянию на 14 марта 2007 года лучший результат в конкурсе Netflix уже 6,75%, то есть две трети пути к миллиону пройдено.

Среди кандидатов в "Великие вызовы KDD" (см. врезку) есть задачи, близкие к тесту Тьюринга. Есть ли надежда, что техники ДМ помогут существенно продвинуться в решении такого рода классических проблем искусственного интеллекта? С другой стороны - можно ли в задачах протеомики надеяться на то, что только за счет ДМ появятся ответы на важные вопросы биологии?

- Из кандидатов в "Великие вызовы" ближе всего к Тьюринг-тесту предложение Ронена Фельдмана (Ronen Feldman) - выдвинуть в качестве вызова создание текст-майнинговых систем, которые смогут сдавать стандартные экзамены на понимание текстов, - SAT, GRE, GMAT, причем обучаться системы будут, исследуя веб.

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

Хорошая модель данных так же важна для дм, как двигатель для спорткара

Недавно Ларри Пейдж, сооснователь Google, объявил, что Google серьезно работает над ИИ, а использование сосредоточенной там вычислительной мощности и базы знаний может серьезно ускорить движение в сторону ИИ.

Для продвижения в биологии (протеомике, геномике) критически важно понимание предметной области. Однако и без инновационных алгоритмов датамайнинга прогресс там невозможен.

Как устроены системы датамайнинга? Много ли общего у этих технологий с технологиями поисковых машин типа Гугла?

- Системы датамайнинга устроены не так, как системы поиска по вебу (Google, Yahoo), поскольку датамайнинг работает обычно с цифровыми базами данных и задает другие вопросы, нежели Google. Обычно эти системы реализуют различные методы очистки и препроцессинга, а затем применяется основное ядро алгоритмов. Самые важные задачи, решаемые этими алгоритмами, - классификация, кластеризация, визуализация. Процесс датамайнинга требует множества итераций, как показано на рисунке. Важнейшая алгоритмическая часть - использование алгоритмов машинного обучения, то есть построение модели; для датамайнинговой системы это так же важно, как двигатель для спортивного автомобиля. Однако основные усилия обычно уходят на подготовку данных. Заинтересованных читателей приглашаю познакомиться с моими (свободно доступными) лекциями.

---

1. "Пункция спинномозговой жидкости". [вернуться]

2. Гм-гм. Недавно мы упоминали о том, как широко применяется распознавание речи при надиктовывании врачами историй болезни. Может быть, система Рао исправляет ошибки не только врачей, но и той системы, которая записывала их диктовку? - Л.Л.-М. [вернуться]

- Из журнала "Компьютерра"

---

Телефон редакции: (495) 232-2263
E-mail редакции: site@computerra.ru
По вопросам размещения рекламы обращаться к Елене Агапитовой по телефону +7 (495) 232-2263 или электронной почте reclama@computerra.ru

Резюме по-американски

Автор: Михаил Портнов, mikhail@portnov.com
Опубликовано: 2.9.2002

---

© 2002, Издательский дом «КОМПЬЮТЕРРА» | http://www.computerra.ru/
Журнал «КОМПЬЮТЕРРА» | http://www.computerra.ru/
Этот материал Вы всегда сможете найти по его постоянному адресу: http://www.computerra.ru/offline/2002/459/19923/

---

На этом месте должна была быть тема номера - о том, куда сегодня пойти учиться молодому человеку, чтобы лет через пять-восемь стать специалистом в ИТ-отрасли. К сожалению, материалы вовремя не поспели. Может быть, и к лучшему. Думать о выборе учебного заведения в начале учебного года или слишком рано, или слишком поздно. Тем не менее, сегодняшняя подборка материалов посвящена учебе. Перед вами - небольшой практикум по грамотному составлению резюме для тех, кто хочет устроиться на работу ТАМ, и для тех, кто ищет куда приложить свои усилия ЗДЕСЬ, - естественно, с учетом особенностей индустрии информационных технологий. А поскольку эти материалы сугубо практические и не претендуют на концептуальную полноту - мы их и разместили в рубрике «Как это сделать».

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

В.И.

---

В США и других странах с рыночной экономикой описание профессиональных достоинств кандидата в виде формального документа уже давно является неотъемлемой частью процесса найма. Сегодняшняя Россия не исключение. Этот документ называется резюме (resume). Но оно нужно не всегда и не каждому. На американском рынке труда есть немало вакансий, для занятия которых вообще не требуется письменного описания квалификации. Зачастую достаточно заполнить анкету или просто предоставить копию водительских прав и карточки социального страхования.

Ситуация резко меняется, когда речь заходит о найме специалистов - ученых, преподавателей, инженеров, административных работников и т. д. Программисту или инженеру нужно резюме. Преподаватель должен иметь curriculum vitae. Ученый может иметь как тот, так и другой документ. Если научный работник впервые приступает к поиску работы в США, то имеет смысл заранее узнать, ожидается от него резюме или curriculum vitae.

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

Требования рынка труда к содержанию и оформлению резюме в конечном счете задаются соотношением спроса на специалистов и предложения их услуг. Если человек рассылает резюме и оно вызывает заинтересованность потенциальных работодателей, то принято говорить, что «резюме работает». Но одно и то же описание квалификации может отлично «работать» в условиях экономического подъема и «отдыхать» в условиях спада. Когда в 2000 году в Силиконовой Долине на одно резюме приходилось в среднем десять открытых позиций, то даже с резюме, которое безобразно отформатировано, содержит грубейшие орфографические и грамматические ошибки и имеет очень скудный перечень навыков, можно было довольно быстро найти работу.

Я пишу эти строки в мае

2002 года, когда соотношение спроса и предложения по сравнению с осенью 2000 года ухудшилось в 10-30 раз. Сегодня на одну позицию программиста, владеющего Visual Basic, есть десять резюме, а разработчика баз данных на Oracle - три. Специалисты с пятилетним опытом не могут по полгода найти работу даже с существенным понижением в зарплате. Значит ли это, что их резюме никуда не годятся? Наша задача состоит в том, чтобы научиться составлять добротное резюме независимо от ситуации в экономике. Спады сменяются подъемами, а хорошее резюме увеличивает шансы на успех при любых обстоятельствах.

Исторически сложилось два типа резюме - хронологическое и функциональное. Хронологическое резюме для каждого места работы подробно расписывает, какие обязанности выполнялись, какие были проекты и т. д. Часто встречаются хронологические резюме на пять-шесть страниц, особенно от выходцев из Индии. Почему в них так много текста? Потому что подробно описываются 10-12 проектов, и на 80% эти описания повторяются.

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

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

Информация, представленная в резюме, организована в виде нескольких секций или разделов. Типовая комбинация для компьютерщика включает Contact Information, Objective, Summary, Skills, Work Experience, Education и Personal. Названия разделов могут слегка варьироваться. Например, вместо Summary можно с тем же успехом применить Summary of Experience, Summary of Qualifications или Summary of Relevant Skills and Qualifications.

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

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

Contact Information.

Раздел контактной информации должен содержать точную и исчерпывающую информацию о том, как связаться с владельцем резюме. Очевидно, что если резюме принадлежит иностранцу, это сразу видно и по имени, и по телефону, и по адресу, и по электронной почте. Если компания не интересуется наймом по Н1В, чтение можно не продолжать.

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

Вот типичная попытка «замаскироваться под местного». Программист Михаил Портнов (имя вымышленное) живет в Москве и работает в компании, выполняющей офшорные проекты. Он не хочет, чтобы его резюме отбросили после прочтения имени и адреса. Поэтому он и телефон, и адрес из резюме вообще исключает. Остается только имя и адрес электронной почты. Для почты используется почтовый ящик на бесплатном американском сервере, например Yahoo. Более того, имя тоже подправляется на американский манер. Можно написать Mike Portnoff или еще туманнее - Michael Port. В этом нет никакого нарушения американских правил игры. У меня есть знакомый американец Сэм, который повсеместно зовет себя «Пеперминт». Это имя у него и в резюме, и на почтовых конвертах, и даже на банковских чеках.

Далее будет понятно, что Michael Port ищет работу как разработчик приложений Oracle. Потом читатель узнает, что Майкл уже десять лет работает в индустрии, причем последние три года - в американской компании, может, и не в одной. Он даже узнает, что последняя компания находится в Сан-Франциско, и будет полагать, что кандидат живет где-то неподалеку. Но есть предыдущая работа в Москве, есть высшее образование, полученное в московском вузе. Маска «местного» быстро перестает работать. Она может слететь и раньше - просто в силу неуверенного английского, проглядывающего из каждой формулировки. Сразу возникают обычные для такой ситуации вопросы: есть ли у Майкла разрешение на работу? Находится ли он в стране легально? Да и находится ли он в стране вообще? В итоге цель не достигнута, но сама попытка маскировки, да еще такая примитивная, вызывает недоумение.

Общие советы по этому разделу:

• Не пользуйтесь таблицами для организации текста.

• Не надо давать больше одного адреса электронной почты. Этот адрес должен быть только личным. По американским нормам, использование служебного адреса для неслужебных дел, особенно поиска работы, недопустимо. Хорошо иметь адрес на привычном в США сервере (yahoo, hotmail, prontomail).

• Номер телефона лучше давать в формате, не требующем размышлений, то есть с указанием всех цифр. Например, если телефон в Москве 946-7092, то в резюме его лучше написать как 011-7-095-946-7092.

• Иногда можно увидеть в резюме пять-шесть телефонов. Это перебор. Достаточно двух или даже одного. Главное требование - надежность. Никто не будет десять раз перезванивать в надежде найти кандидата на месте.

Objective

Секция Objective нужна для того, чтобы кадровик или рекрутер знал, на какую должность (позицию) прислано резюме. Если в секции написано Software Developer/Database Administrator/ Technical Support Specialist, то не совсем понятно, что с таким резюме делать. Кроме того, зачастую у американцев возникает ощущение, что ни в одной из этих профессий соискатель толком не разбирается. Если человек может успешно работать по нескольким профессиям, ему есть смысл иметь несколько разных резюме. Четкая формулировка важна и потому, что готовит читателя к сфокусированному восприятию последующей информации о профессиональных навыках кандидата.

Среди ищущих работу в США с открытием визы Н1В есть такие, кто устал от многочисленных звонков, которые заканчиваются вежливым «sorry», как только речь заходит о спонсорстве визы. Чтобы отсеять эту категорию звонков, уместно именно в данном разделе написать H1B visa sponsorship required.

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

Summary

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

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

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

Следует ли модифицировать текст резюме под каждую конкретную позицию? Только при необходимости. Если можно отправить сто резюме в день, и в ответ будет 10-15 звонков, то нет смысла в переделках. Но если телефон не звонит, а по электронной почте приходят исключительно ответы почтовых роботов, есть смысл подогнать резюме под конкретные требования, что несомненно повышает его эффективность. В идеале правка не ограничится одной секцией. Если кандидат утверждает, что имеет опыт работы с Java, то из резюме должно быть ясно, где он это делал, в течение какого времени, на каком проекте, с какими проблемами сталкивался и как их преодолевал.

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

Наиболее характерные проблемы:

• Рассогласованность рекламируемых достоинств с позицией, заявленной в секции Objective. Например, для должности программиста 70% перечисленного относится не к программированию, а к поддержке пользователей и установке серверов.

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

• Если раздел разросся, перечисление сугубо технических навыков лучше вынести в отдельный раздел Skills или Technical Skills.

Skills

Раздел Skills может быть частью резюме, но может и отсутствовать - если у соискателя за плечами всего год-два работы, в секции Summary ему трудно написать больше нескольких строчек, да и сугубо технических навыков у него пока немного. Тогда можно обе секции объединить в одну. Просто потому, что две маленькие секции подряд плохо смотрятся на странице - много заголовков и мало содержания. Технические навыки обычно разбивают на группы и перечисляют внутри группы через запятую - операционные системы, языки программирования, технологии, базы данных и т. д.

Каждый технический специалист что-то в своей профессии знает очень глубоко. Еще что-то он знает хуже, а многие вещи - вообще поверхностно. Если все эти три категории знаний в резюме перечисляются через запятую, создается впечатление, что человек все знает примерно одинаково. Это опасно при прохождении интервью. Чтобы расставить все по местам уместно использовать такие слова и выражения, как Expert knowledge of… Extensive experience in … Familiar with… Training in…

Общие рекомендации по разделу:

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

  Operating Systems: Windows XP, Windows NT, Windows 2000, Unix (Sun Solaris), Mac.

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

• Не увлекайтесь перечислением версий того или иного инструмента или операционной системы, использованных в течение последних десяти лет. Это имеет смысл делать лишь тогда, когда в версиях есть принципиальные различия с точки зрения успешного выполнения работы в современных условиях. Например, Windows 3.0/3.1/3.11 сегодня мало кого заинтересуют и упоминание этих версий в тексте выглядит архаично.

• Исключите из рассуждений такие слова и словосочетания, как «очевидно» и «и так понятно». Перечислите всё, что использовали, детальнейшим образом. Исходите из того, что среди тех, кто читает резюме, многие просто фиксируют наличие необходимых ключевых слов.

Work Experience

Секция Work Experience предназначена в хронологическом резюме для перечисления мест работы с подробным описанием содержания труда. Составить ее не просто, особенно иностранцу. Давайте посмотрим на американского менеджера Саймона, подыскивающего программиста. Для определенности будем считать, что идет разработка программного продукта, используемого страховой компанией для ведения бухгалтерского учета. Нужно знание С++. При прочих равных желательно, чтобы программист знал как специфику работы страховых компаний, так и специфику бухгалтерских приложений. Саймон не понимает фразы: «да я разберусь, вы мне только дайте работу». Он смотрит в первую очередь на уже имеющиеся знания и только потом оценивает способность человека их быстро приобретать. Хорошо ли это? Не имеет значения. Примите как факт и научитесь использовать в своих целях.

Саймон смотрит на название компании, где работал претендент: RosGosStrakh, и оно ему ничего не говорит. Потом он видит, что тот работал в должности IT Manager, то есть явно не из тех, кто сам пишет код. Читает дальше и узнает, что претендент:

• участвовал в самых разных, но непонятно каких проектах;

• программировал, администрировал сеть, тестировал, устанавливал серверы и поддерживал пользователей;

• использовал в течение трех лет семь языков программирования;

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

Проколы резюме очевидны. Вместо бессмысленного названия компания нужно его сделать понятным, например RG Insurance Corp. Неточно? Не беда, зато гораздо понятнее. Далее надо определиться с должностью. Если человек ищет работу программиста, то должность IT Manager его явно дискредитирует. Software Developer будет выглядеть куда уместнее. Это не то, что у него написано в трудовой книжке? Зато не вводит никого в заблуждение. Кроме того, если ищется работа программиста, надо выкинуть из текста все, что к ней не имеет прямого отношения. А то, что имеет, - развернуть и сделать привлекательным.

Подробно опишите, что за приложения разрабатывались в «РосГосСтрахе», какие использовались технические средства, какие модули были написаны соискателем рабочего места, какие проблемы он разрешил. И лишь тогда отправляйте резюме Саймону.

Рекомендации:

• Самая последняя работа описывается первой. Затем предпоследняя и так далее. Обратный порядок затрудняет чтение и мешает сфокусироваться на самом актуальном - что человек делал в последнее время.

• Не надо приводить полный почтовый адрес компании - он никого не интересует.

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

  03/98-12/01 Sr. Software Developer, Digital Pumpkin Corp., Saratoga, CA.

• Если в одной компании выполнялись разные проекты, желательно о каждом сказать отдельно.

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

• Традиционно в этой секции каждая фраза начинается с глагола: developed… tested… installed… debugged… assisted… monitored… utilized… trained… communicated… и т. д.

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

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

• Сравните описание данного проекта с описанием других проектов и постарайтесь избежать повторов. Одни и те же вещи всегда можно сформулировать по-разному.

Отдельная проблема - как описать опыт, полученный в процессе совмещения работы и учебы. Часто встречаются резюме, где двадцатидвухлетний парень, закончивший вуз три месяца назад, пишет, что у него семь лет профессионального опыта. Это обязательно вызовет недоумение. В Америке многие совмещают работу и учебу, и удивить этим никого нельзя. Однако есть рамки, за пределами которых утрачивается достоверность. Я неоднократно слышал слова «но я действительно с пятнадцати лет выполнял проекты». Замечательно, но в данном случае речь идет совершенно о другом: правдивость резюме не должна вызывать сомнений. Например, если молодой человек начал работать в 17-18 лет, это в порядке вещей. Вместо семи лет опыта останется только четыре-пять, но их примут более или менее всерьез.

Education

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

• Избегайте переводить на английский трудно перевариваемые названия учебных заведений. Ваша задача не в точном переводе, а в ясном изложении того, какое образование вы получили. Лучше всего пользоваться терминологией, понятной читателю. Факультет АСУ в Московском институте машиностроения для легкой и пищевой промышленности прекрасно пойдет как BS in Information Systems, State University, Moscow, Russia.

• Соответствует высшее образование, полученное в России и СССР, американской степени бакалавра? А может, лучше сказать, что оно соответствует степени мастера? Эта тема - предмет нескончаемых дискуссий. Степени бакалавра обычно вполне достаточно. Но если очень хочется написать «Master» - не надо себе отказывать. Особенно во время рецессии. Что делать со степенью кандидата наук? Можно смело писать в резюме «PhD». Но нужно ли? Это скорее оттолкнет нанимателя, подыскивающего инженера. Есть термин «overqualified». Если имеются опасения, лучше указать «master degree». Но есть позиции, где ученая степень просто необходима. Читайте внимательно Job Description и там найдете ответ.

• Сертификаты таких компаний, как Microsoft или Cisco, украсят любое резюме, хотя слишком много надежд на это возлагать не надо. Опыт ценится гораздо выше.

• Сертификаты Brainbench ниже уровня мастера не ценятся высоко. Когда в резюме идет перечисление двух десятков мало кому понятных сертификатов, это не впечатляет.

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

Personal

В этой части резюме иногда конспективно, а иногда и развернуто кандидат описывает свои личные качества, которые, как он считает, отличают его других претендентов.

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

Я видел вполне обычные резюме, которые запоминались на всю жизнь одной фразой именно в этом разделе. Держу в руках нормальное добротное резюме тестировщика. А внизу написано: Passion for software quality. Или другой тестировщик пишет: Perfectionist who has learned how to survive in a real world. Лично я хочу обоих видеть на интервью прямо завтра.

Советы:

• Избегайте писать о здоровье, наличии семьи, количестве детей. В некоторых странах, например, в Израиле, такая информация в резюме предполагается. Но не в США.

• Очень легко растянуть эту секцию на половину листа. Не увлекайтесь. Трех-четырех строчек вполне достаточно. А можно обойтись и без них.

• Если вы не хотите сразу же заявлять в резюме, что вам нужна виза Н1В, но считаете, что сказать об ней все же надо, сделайте это именно тут. Многие до этого пункта просто не дочитают, ограничившись сугубо профессиональной его частью. Отдельной строчкой напишите: Employment Authorization: H1B sponsorship required.

Написание

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

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

Нужно ли иметь сопроводительное письмо (cover letter)? Этот вопрос беспокоит многих. Традиционно такое письмо ожидается от претендентов на должность в менеджменте, маркетинге, рекламе, то есть там, где литературный стиль и умение выгодно подать себя важны для работы. Слать сопроводительное письмо имеет смысл только непосредственно в нанимающую компанию. Посредническим агентствам оно не нужно. Ведь даже на беглый просмотр письма нужно время, которое есть не у всех и не всегда. Позволю себе дать совет: если есть возможность обратиться непосредственно к человеку, от которого что-то зависит, тогда это стоит делать. Но при одном непременном условии: сопроводительное письмо должно быть очень хорошо составлено и по содержанию, и в литературном плане. В противном случае лучше ограничиться резюме.

Основные правила:

• Сопроводительное письмо не дублирует резюме, а дополняет его, усиливает, объясняет, как кандидат может своим трудом улучшить дела именно в этой компании.

• Сопроводительное письмо - продукт штучный. Оно не пишется по шаблону с тривиальной заменой одного названия компании другим.

• Неудачное письмо дискредитирует кандидата.

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

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

Иногда рекомендателей перечисляют прямо в резюме. Ничего хорошего в этом нет, и подавляющее большинство людей так не делает. Обычно резюме просто завершается фразой «References available upon request» или «References will be furnished upon request». Это дает вам некоторую гибкость. Из людей, на которых вы рассчитывали, кто-то уехал в командировку и его невозможно найти, а кто-то просто не снимает трубку в течение недели. Оставьте себе возможность маневра. Кроме того, рассылать в тысячи адресов имена и телефоны людей, согласившихся вас рекомендовать, неэтично. Вы не знаете, кто и как захочет этой информацией воспользоваться. Будьте готовы дать список референсов (list of references) в течение минуты по факсу или по электронной почте. Для каждого референса необходимо указать его имя, должность, компанию, где он работает, телефон и адрес электронной почты.

Если есть возможность запастись рекомендательными письмами, неплохо иметь наготове два-три письма, написанных на хорошем английском и подробно расписывающих ваши достоинства. Резюме вместе с рекомендательными письмами можно рассылать по почте, а можно выложить на вашей личной страничке в Сети. В телефонном разговоре с представителями агентства или компании или при общении по электронной почте можно спросить, хотят ли они получить копию. Письма помогают агенту «продать» кандидата. Наличие рекомендательных писем будет выгодно отличать вас от конкурентов.

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

I Специализированные поисковые сайты. Dice, Monster, HotJobs и другие. Начать можно с тех шестидесяти сайтов, которые приводятся в разделе полезных ссылок на www.portnov. com, - я их держу для своих студентов и периодически обновляю. Есть большая коллекция и на сайте Павла Барабашкина. Со временем какие-то ресурсы станут для вас основными, другими вы будете пользоваться эпизодически. Почти каждый поисковый сайт может быть использован двояко. Там можно искать вакансии. Но там же можно и опубликовать свое резюме. И то и другое делать необходимо. Причем начать надо именно с опубликования резюме, чтобы рекрутеры и кадровики могли найти вас в тот момент, когда они ищут достойных кандидатов. Более того, резюме нужно как минимум раз в неделю «освежать». На таком сайте, как Dice, предупреждают, что резюме доступно для поиска в течение месяца с момента публикации. Но для этого рекрутер должен проводить поиск за месяц. По Силиконовой Долине поиск за месяц на «С++» приносит сегодня 1100 резюме. Рекрутеру работать с такими объемами невозможно, значит, список нужно сократить. Это делается либо за счет усиления требований к квалификации, либо за счет сокращения временного интервала, например, с месяца до трех дней. Не дайте вашему резюме оказаться за бортом через три дня.

II Поиск работы через знакомых. Это один из самых продуктивных каналов, и им нельзя пренебрегать. Знакомые могут быть не только по институту или по предыдущей работе. Очень часто могут помочь виртуальные знакомые, те, с кем вы общаетесь в чате или на форуме.

III Веб-сайты компаний. Очень эффективно извлекать информацию о найме с сайтов самих компаний. Это требует больше времени, но дает и более высокую отдачу. Ссылки на некоторые онлайновые директории хайтековских компаний приводятся ниже. Многие поисковые машины, например www.brassring.com, имеют внушительные списки ссылок на сайты компаний. Крупные выставки предоставляют каталоги с полным перечнем экспозиторов, где представлены фирмы, специализирующиеся в узких областях. В условиях рецессии очень эффективно рассылать резюме в те компании, которые твердо стоят на ногах. Один из способов найти их - работать с сайтами, посвященными стартапам. Там, в частности, есть информация о том, какие компании получили финансирование. Начните с www.ipo.com.

Золотые правила рассылки:

• Интенсивность. Стыдливая отправка десяти резюме в месяц не даст ничего. Контрпримеры имеют место, но являются слабым утешением. Рассуждения «я сначала пробую, как работает резюме» или «а вдруг мне придется потом что-то изменить в резюме?» практически хоронят затею.

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

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

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

• Отправляйте резюме в виде вордовского файла (формат RTF). Не поленитесь в тело сообщения поместить аккуратно отформатированный ASCII-вариант резюме. Бывает, что получатель не может прочесть файл.

• Рекрутер ежедневно получает сотни резюме. В его почтовом ящике каждое сообщение представлено всего одной строкой. Сделайте эту строку максимально содержательной, например: «Software Developer, C++, MFC, COM/DCOM». Это намного лучше, чем «Looking for a job». На некоторых сайтах позиции имеют специально присвоенные идентификаторы. Для найденной на HotJobs позиции заголовок сообщения будет выглядеть как «HotJobs ID: 12PG-49, Software Developer». Это поможет рекрутеру мгновенно соотнести описание ваших навыков и требования к кандидату на конкретную позицию.

• Очень хорошо завести персональную страничку в Сети и давать на нее ссылку. На страничке можно поместить и само резюме в разных форматах, и рекомендательные письма, и список референсов, и фотографию, и ссылки на портфолио, если таковое имеется. Помещать фотографию в файл с резюме не рекомендуется, как и лого фирменных сертификатов. Это резко увеличивает размер файла и тормозит загрузку почты. Рекрутеры на это часто жалуются. Если вы вывешиваете фото для обозрения, покажите его как минимум нескольким знакомым. Не берите первое попавшееся. Если оно выглядит, как фотография из советского паспорта, лучше обойтись совсем без него. Убедитесь, что ваша личная страничка грузится быстро. Ждать три минуты никто не будет.

Есть три-четыре крупных сервиса в Интернете, которые рассылают резюме за плату. За 50 долларов его отправят в пятьсот-шестьсот рекрутинговых компаний, а за 80 долларов - аж в две-три тысячи. Экономится много времени. Но нет никакой уверенности, что резюме отправится туда, где его действительно ждут. Если не жаль денег, можно попробовать, но во время рецессии рассчитывать на положительный результат не приходится.

Employment application

Одна из самых больших проблем для новичков - заполнение анкеты (employment application) отдела кадров. Это не удивительно: с одной стороны, анкеты являются отражением незнакомых реалий американского рынка труда, с другой - анкеты разных нанимателей сильно отличаются.

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

Общее соображение 1. Часто можно увидеть в анкетах просьбу: Please, print, что значит - пишите печатными буквами. Это и в ваших интересах. Неразборчивые записи даже при самом безобидном раскладе приведут к разночтениям в документах и потерянной корреспонденции.

Общее соображение 2. Если предлагается ответить на вопрос, не касающийся ваших профессиональных качеств, например просят поделиться подробностями вашего участия во Вьетнамской войне (имеется ввиду - на стороне США), то возле него стоит аббревиатура N.A. (происходит от Not Applicable).

Начнем с имени. Last Name - это фамилия, First Name - имя. Отчество не предусмотрено. Middle Initial в анкете надо просто игнорировать, то есть ничего в этом поле не писать. Очень часто возникает конфуз: в паспорте фамилия или имя написаны не так, как на карточке социального страхования и/или водительских правах. Какое из нескольких написаний использовать в анкете? Предпочтительнее то, которое указано в карточке социального страхования.

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

Дата (Date) в США пишется в таком порядке: месяц, число, год. Он отличается от принятого в России, так что будьте внимательны. Если специально не оговорено, дату можно писать как числами, так и с использованием слов: 4/15/02; 04-15-02; April 15, 2002.

Номер социального страхования (SSN, или Social Security Number). Первое, что вы сделаете, прибыв в страну на работу, отправитесь в местное отделение Social Security Administration и заполните небольшую анкету. Номер через 48 часов можно узнать по телефону, а карточка с вашим именем и номером приходит по почте через две-три недели. По номеру социального страхования ведется учет полученных денег, уплаченных налогов, купленных и проданных автомобилей, страховых полисов, одолженных в банке денег и пр. Если вас попросили заполнить анкету, а номер вы еще не получили - так и скажите работнику отдела кадров, только не забудьте проинформировать его сразу же по получении номера. Без него вам не могут начислить зарплату.

С номерами телефонов вы легко разберетесь сами. Только помните, что общепринятый формат выглядит так: (123) 876-5432. Код телефонной зоны (area code) пишут в круглых скобках. Реже ставят тире или точку в качестве разделителя 123.876.5432 или 123-876-5432. Наклонную черту не используют никогда.

В анкете всегда надо указывать адрес. Американский адрес состоит из четырех частей: Street Address (улица, номер дома, номер квартиры), City (название города), State (название штата), Zip Code (почтовый индекс). За редким исключением анкета содержит отдельные поля для каждой составляющей. Старайтесь писать только в отведенном месте, но если не получилось, не переживайте - обычное дело.

Закон требует от нанимателя удостовериться, что кандидат имеет право работать в США. Поэтому анкета в той или иной форме коснется этой темы. Например, Are you eligible to work in the US? Слово eligible не имеет прямого аналога в русском языке и обычно переводится как «иметь право». Виза Н1В позволяет работать только в одной компании, той, которая оформила визу (visa holder). Если анкета заполняется именно для этой компании, смело закрашивайте ручкой кружочек Yes. Для любой другой компании ответ будет отрицательным.

В анкете может быть вопрос о наличии гражданства США. Оно подтверждается либо свидетельством о рождении, либо сертификатом о натурализации (для тех, кто сменил гражданство на американское). Если вы не гражданин США, вас могут спросить, имеете ли вы Alien Registration Card, и попросят указать Alien Registration Number. Речь идет о так называемой белой карточке - форме I-94, которую вам приколят скрепкой к одной из страничек российского паспорта при въезде в США. Номер на этой карточке и есть «A-number». Если рядом с полем для номера есть поле Validity, то надо проставить в нем дату окончания пребывания в стране, которая есть в форме I-94.

Не всегда, но частенько в анкете встречается вопрос о судимости: Have you ever been convicted of a felony?

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

Есть в анкете раздел, посвященный образованию. Старайтесь заполнить его максимально близко к тому, что написано в резюме, ибо оба документа будут лежать в одной папке. Копии дипломов и их переводы будут там же, но вчитываться в русский текст мало кто станет. Слово Major в анкете означает специализацию, например кандидат имеет Master или Bachelor Degree, но major в Computer Science, Electric Engineering или Telecommunications.

Довольно много пространства отводится перечислению предыдущих мест работы. Надо указать названия компаний, их адреса, фамилии менеджеров, должность, характер выполняемых обязанностей и причину ухода. Собираясь в дорогу, не поленитесь заполнить такую анкету - очень пригодится. Убедитесь, что ее содержание не расходится с резюме. Самый каверзный вопрос - причины увольнения. Они могут быть уважительными или сомнительными. Уважительные: окончание проекта (end of project), переезд в другой город (moved to another city), сокращение штатов (lay off), закрытие компании (company went out of business).

Как правило, в анкете потребуется перечислить все рекомендации (References). Если у вас есть распечатанный на отдельной страничке List of References, можно приложить его к анкете.

Закон запрещает дискриминацию при найме по расовой, религиозной или национальной принадлежности. Кроме того, государственные учреждения и частные предприятия, выполняющие заказы для государства, являются Equal Opportunity Employer. Это значит, что там не просто отсутствует дискриминация, а, наоборот, создаются благоприятные условия для меньшинств. Требовать от вас информации о расовой или религиозной принадлежности не позволяет закон. Но собирать ее нужно для отчетности. Этот парадокс разрешают тем, что вместе с анкетой вы получите отдельный листок, где вас попросят добровольно ответить на несколько вопросов (на условиях полной конфиденциальности). Если вы приехали из России, то скорее всего пройдете по категории White (not Hispanic) или Asian.

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

В качестве еще одного приложения к анкете вам могут предложить подписать Authorization for Background Investigation. Обычно для сбора информации используют специальные агентства. Отдел кадров самостоятельно этим не занимается. В самом общем случае проверяются Criminal Record и ваша кредитоспособность. Особенно это характерно для банков и других финансовых учреждений. Отказ подписать разрешение скорее всего приведет к тому, что работать там вы не будете.

Если вы заполняете анкету для большой консалтинговой компании, которая намерена перебрасывать вас с проекта на проект, то частью анкеты может быть специальная форма для оценки уровня знаний в разных областях - Technical Assessment Form. Это очень внушительный список операционных систем, языков программирования, технологий, баз данных, сетевых протоколов и т. д. Для каждой позиции необходимо указать, как давно вы работаете с тем или иным продуктом и насколько хорошо им владеете (например, по десятибалльной шкале). Не расстраивайтесь, если 95% формы вы оставили незаполненной. Это нормально.

Полезно поупражняться в заполнении реальных форм. Достаточно сделать поиск в Yahoo.com на employment_application.pdf, jobapp.pdf или job_app.pdf.

Лексический минимум

Direct hire - прямой найм на работу без промежуточного звена. Зарплату платит тот, кто ставит производственную задачу. Нанимающая компания открывает визу Н1В.

Consulting - компания, преимущественно выполняющая заказную разработку для клиента. Может иметь собственные проекты (turn-key projects) для последующей продажи на свободном рынке. Нередко спонсирует визы Н1В и нанимает сотрудника-иностранца на Permanent position для работы в офисе клиента (on site) или в офисе самой компании (off site). Выступает спонсором визы Н1В и может спонсировать получение Green card.

Body shop - разновидность консалтинга c доминированием сотрудников на Н1В. Как правило, берет с клиентов почасовую оплату за работу сотрудников, с которыми рассчитывается на основе стабильной заработной платы.

HR (Human resources department) - отдел кадров.

Personnel department - отдел кадров, то же, что HR.

Startup company - молодая компания, как правило, не вышедшая на уровень самоокупаемости. Финансово поддерживается индивидуальными или корпоративными инвесторами

Public company - компания, акции которой открыто продаются на бирже. Обычно более стабильна, чем частные компании.

Well-established company - компания со стажем и стабильным положением.

Permanent position - постоянная позиция, не ограниченная заранее сроком окончания найма.

Temporary position - временная позиция. В момент найма оговаривается продолжительность.

Full-time position - работа с загрузкой не менее 30 часов в неделю.

Part-time position - работа с загрузкой менее 30 часов в неделю.

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

EBGC (employment based green card) - статус постоянного жителя, полученный на основе действий заинтересованного работодателя.

Visa transfer - процедура перевода визы Н1В из одной компании в другую.

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

1099 - налоговая форма. Используется в тех случаях, когда работник получает на руки все деньги и сам отвечает за уплату налогов. Найм по Н1В в таком варианте фактически запрещен.

401K - пенсионный план, спонсируемый работодателем. Предоставляет самые лучшие налоговые льготы, но ограничивает размеры годового взноса. Один из возможных вenefits.

Benefits - внеденежная форма оплаты труда в виде медицинской (health) и стоматологической (dental) страховки (insurance), пенсионного плана, страхования жизни, оплачиваемого отпуска и пр.

Bench time - буквально «время на скамейке запасных». Время консультанта между проектами. Для сотрудников на Н1В должно оплачиваться в полном размере. В реальной практике бодишопов это правило часто нарушается.

Overtime - сверхурочные. Могут оплачиваться или не оплачиваться в зависимости от политики компании. При найме инженеров на Н1В компания не обязана оплачивать сверхурочные. Консалтинги и бодишопы, как правило, получают деньги с клиентов на почасовой основе и имеют возможность оплачивать сверхурочные по той же шкале, что и обычные часы. Иногда оплата производится по прогрессивной шкале.

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

Stock purchase plan - benefit, доступный только в public company. Раз в квартал сотруднику предоставляется возможность приобрести акции компании на ограниченную сумму по льготной цене (например, на 15% ниже, чем меньшая из цен на первый и последний день квартала).

Lay-off - сокращение штатов. Увольнение, не связанное с плохой работой или нарушением трудовой дисциплины.

INS (Immigration and Naturalization Service) - служба Министерства юстиции США, ответственная, в частности, за выдачу виз и грин-карт.

DOL (Department of Labor) - Министерство труда США. Выдает формальное разрешение на найм иностранца по Н1В и на оформление грин-карты по EBGC.

---

Ресурсы

• www.geocities.com/resumes4it. На сайте Павла Барабашкина представлено более двухсот резюме по тринадцати профессиям. Специально отобраны автором на www.dice.com. Также приводится несколько сотен выражений для раздела Personal из коллекции автора.

• www.portnov.com. В разделе Useful Links есть больше шестидесяти ссылок на американские сайты по поиску работы, в том числе специализирующиеся на Н1В.

• www.za-granizza.org. Небольшой, но весьма компетентный русскоязычный форум, где вам сделают детальный анализ резюме и ответят практически на любые вопросы, связанные с поиском работы и обустройством на новом месте.

• Коллекции ссылок на сайты компаний: www.richdir.com, www.bayareacareers.com.

• Американское эмиграционное законодательство: www.shusterman.com, www.ins.usdoj.gov.

• Американское трудовое законодательство: www.dol.gov, www.nolo.com.