Тонкости проектной терминологии

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

Суть проблемы

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

Для уточнения значений слов используется либо контекст, либо дополнительные уточняющие слова (ключ, ну тот, который от замка).
Рассмотрим другой пример. Электронная почта — инструмент, к которому все привыкли. Допустим, я написал письмо на два адреса, Васе и Пете. Сколько писем стало в итоге? Возможны варианты.

1. Одно письмо. Уникальный текст и тема, дата отправления;
2. Два письма — у Васи и Пети свои копии, которые могут различаться атрибутами, например, датами получения. Если, например, Петя стоял в скрытой копии, то Вася не узнает, что Петя получил копию, то есть, письма отличаются!
3. Три письма — ещё одна копия сохранилась у отправителя в исходящих, я всегда могу найти текст, если необходимо. Я не уверен, что Петя и Вася получили мое письмо, но у меня оно тоже есть, я могу обратиться к тексту, если потребуется.

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

необходимо отображать список тех фиговин, которые агрегируют ссылки на те самые штуки, по которым мы ведем мониторинг

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

Предпосылки

Когда пора вводить новый термин

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

Что обзывать

Какие понятия приходится именовать в процессе разработки информационных систем и требований к ним:

• объекты (структуры данных);
• состояния объектов;
• атрибуты;
• операции.

Какими должны быть хорошие термины

Критерии

Задача термина — повышение эффективности общения. Повышение эффективности складывается из двух составляющих:

• повышение точности;
• упрощение речи (снижение речевого трафика).

Исходя из этих целей, качество терминов определяется следующими критериями:

• однозначность;
• произносимость;
• интуитивность;
• стиль.

Однозначность

Термин должен точно определять понятие, исключая все возможные коллизии — в этом основная задача термина: сократить количество слов и не снизить при этом точность описаний и однозначность фраз в процессе общения.
Хороший пример — термин "подкаст" — аудиозапись речи с информацией по определенной тематике. Слово "подкаст" однозначно в широком контексте и не требует каких-то дополнительных пояснений.
Например, у видеоблоггеров нет такого термина и от этого возникает путаница. Ролики видеоблоггеров называют по-разному: выпуск, пост, а чаще всего просто словом "видео" — всё это плохие термины с точки зрения однозначности. Ведь выпуск может означать выпуск новостей или журнала, пост может быть и ВКонтакте, а видео — это совершенно абстрактное слово. В условиях конкретного проекта, возможно, термин "видео" и может существовать, но он далеко не идеален.
Итак, в идеале термин должен быть однозначным в широком контексте и не означать ничего другого. Если не получается добиться однозначности в широком контексте, то хотя бы в контексте проекта однозначность обязательно должна достигаться.

Произносимость

Цель ввода термина — упростить общение. Если мы назовем объект опциональный инвалидационный центр, то люди будут ломать язык от такого термина. Скорее всего, будет использоваться некорректный, но более удобный в произношении термин. Так происходит и в естественном языке, например, вместо "стеклоочистители" куда проще сказать "дворники" или "щетки".

Интуитивность

Если термин просачивается наружу — в пользовательский интерфейс, то желательно, чтобы пользователь понял смысл термина, не читая определения. Хороший пример — название "корзина" в интернет-магазинах: возникает ассоциация с продуктовой корзиной в супермаркете. Хотя на иконках нарисована как правило ашановская тележка, замечали? Предполагаю, что термин придуман за пределами России, а на их языке эти два понятия обозначаются одним словом — cart.

Стиль

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

Приоритеты критериев

Часто не получается добиться хороших терминов по всем критериям. Я перечислил критерии в порядке их важности. Недопустимо жертвовать однозначностью в угоду интуитивности — это наиболее распространенная ошибка. Из-за того, что ввод новых терминов — затратная операция, авторы пытаются добиться в первую очередь интуитивности, чтобы термин не пришлось объяснять. Это в корне неверный подход. Цель ввода терминов — повышение эффективности общения; ввод неоднозначного термина не имеет смысла, ведь он опять потребует уточнения, либо приведет к ошибкам. В контексте проекта термин должен иметь единственное значение, пусть даже он не понятен сразу стороннему наблюдателю, менеджеру или пользователю. Это дело небольшого погружения в контекст, только и всего, не стоит бояться этого процесса. На моей практике было много примеров, когда термин, казавшийся поначалу уродливым и непонятным, настолько укоренялся в умах, что люди просто не могли потом представить, как они обходились без этого термина раньше. На проекте мониторинга соцсетей, например, словом "невод" назвали множество ключевых лингвистических запросов, описывающих объект мониторинга. Термин построен на базе ассоциации (методы генерации описаны ниже): невод — это та структура, которая позволяет вылавливать из множества сообщений соцмедиа только полезные. Применение спецтермина намного более ёмко позволяет выразить мысль, хотя к предметной области проекта это слово не имеет вообще никакого отношения.

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

Методы генерации терминов

Для того, чтобы ввести термин, его нужно придумать. Рассмотрим основные методы генерации терминов.

Аббревиатуры

Один из самых простых способов генерации термина — сложить аббревиатуру из слов, описывающих понятие. Например, правую кнопку мыши часто обозначают "ПКМ". Далеко не обязательно, чтобы расшифровка аббревиатуры имела какой-то смысл. Например, популярные понятия в мире банковских карт — PIN и CVV2. Если PIN ещё кто-то может расшифровать, то до того, как расшифровывается CVV всем давно пофиг, хотя эта аббревиатура совершенно однозначно определяет код на оборотной стороне пластиковой карты. Задача выполнена: эффективность описаний повышена.

Калькирование

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

Ассоциация

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

Внедрение терминов

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

По нажатию на иконку отображается содержимое корзины (список выбранных товаров для покупки)

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

Интеграция

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

Вывод

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