Проблема общеупотребительных слов в слишком большой посторонней смысловой нагрузке. В результате мы получаем или длинные определения и неудобоваримые аббревиатуры, которые не приживаются в профессиональной среде. Изобретатели английской терминологии тоже сталкивались с этой проблемой. Зато в русском языке заимствованный термин чаще всего ничего не обозначает. И в него, вполне можно свернуть развернутое определение.
Сложнее всего с терминами, которые происходят из общеупотребительных английских слов, которые уже имеют по несколько устойчивых вариантов перевода. Например, так нам повезло со словом service.
Когда же возникает птичий язык? Как только в терминологии начинает активно использоваться инкапсуляция (т.е. в текстах перестает раскрываться значение используемых терминов), наследование (порождение одних непонятных терминов через другие), полиморфизм (использование одного и того же слова в совершенно разных значениях) — язык перестает быть понятным для каких-либо внешних пользователей не знакомых с контекстом.
Про email мы еще иногда говорим — электронная почта, а вот о том, что компьютер называется электронно-вычислительной машиной уже как то и забылось. Тем более и само слово компьютер все чаще заменяется более точными заимствованными словами: ноутбук, сервер, десктоп, рабочая станция. А какое слово более русское: брандмауэр, фаервол или межсетевой экран?
Иногда читаешь ИТ-текст и думаешь, лучше бы в нем совсем не было перевода: от русского языка остались предлоги и немногочисленные связующие слова, а все остальное кальки с английского. Для того чтобы понять смысл написанного приходится переводить в уме все обратно на английский.
Кому нужны все эти определения?
Может быть все непонятные термины — лишние? Слова возникают не на пустом месте. За ними стоят сущности, которые вводились весьма умными дядьками (в случае ITIL они были немного разрознены и непоследовательны, но это уже другой вопрос). И нужны они, прежде всего самим специалистам, в нашем случае ИТ-шникам. В предыдущем материале мы обсуждали три сущности в ITIL: services request, RFC и incident.
Можно конечно, все это называть request (запрос) или reaction (отклик). На какое-то время и на каком-то уровне развития процессов такой вариант устроит и ИТ и бизнес. Бизнес пользователи что-то захотели или у них что-то случилось — ИТ отреагировали. В чистом виде бихевиористская модель стимул-реакция. Впрочем, психология на бихевиоризме не остановилась, так что и у нас дальше начнется. И если в ИТ считают, что разные сущности ни к чему, то бизнес первым спросит, а почему одна и та же сущность стоит таких разных денег?
- Почему запрос на замену мышки на 1-2 компьютерах выполняется в течение часа, а вот такой же запрос, но на 100 мышек порождает кучу согласований и требует минимум несколько дней, если не недель.
- Почему заявку на подготовку компьютера для одного-двух новых сотрудников нужно отправить за день, а для 20 сотрудников в новом офисе за месяц и больше. К тому же почему-то при открытии нового офиса ИТ-служба начинает заново обсуждать ИТ-бюджеты.
Разные тонкие терминологические различения позволяют самим ИТ-шникам понять, что они делают, для чего, и в какой бизнес процесс при этом включены. И не в последнюю очередь то, насколько это важно для бизнеса:
- Инцидент — бросать все менее приоритетные задачи и срочно чинить.
- Запрос на обслуживание — вот тут ИТ служба может получить немного симпатий пользователя так, что основная задача не столько уложиться в SLA, сколько не испортить отношения с пользователями по совсем уж пустяковому поводу.
- Изменения — прежде всего, считать бюджеты и согласовывать, потом тестировать, потом уже развертывать в рабочей среде.
Хочет ли бизнес знать все эти слова? Конечно, нет! Чаще всего, кроме ярлыка «центр затрат» — ничего другого бизнес в ИТ видеть не хочет. Для бизнеса весь ИТ — это даже не EBITDA. (Термин довольно популярный, но ага у бизнеса, тоже есть свой «птичий язык»).Пользователи хотят, чтобы все работало и еще, чтобы их пожелания выполнялись максимально быстро. Им совершенно не интересно, какой процесс стоит за тем или иным пожеланием.
Кто же ему объяснит, что и почему он видит не так? Кто должен переводить с ИТ на человеческий, а лучше сразу на «бизнес» язык? И кто должен потом все эти бизнес-термины транслировать обратно в язык ИТ-систем? Очевидно, что это может быть только ИТ-директор или руководитель/продавец ИТ-компании и, как любой переводчик, он должен хорошо говорить и на том и на другом языке.
Почему? Потому что, поговорить о проблемах бизнеса на правильном языке — это единственный способ продать ИТ бизнесу. И в то же время, для того, чтобы правильно организовать ИТ нужно хорошо понимать откуда взялись те или иные термины и что же за ними стоит.
Самое худшее, когда человек на этой позиции ни понимает, ни тот ни другое языка. Со своим единственным человеческим и здравым смыслом он оказывается далек как от тех, так и от других реалий.