Портал №1 по управлению цифровыми
и информационными технологиями

Обновленный глоссарий ITIL: меньше демократии, больше слов

Практически одновременно с выходом новой версии, тьфу, редакции ITIL должен был выйти в свет обновленный глоссарий (в новой редакции на русском — словарь) на двадцати трех языках. Пока вышел на семи, включая русский. Обновленный глоссарий доступен на официальном сайте ITIL и, конечно, будет доступен на сайте itSMF Россия. В этот раз вместо публичного обсуждения под эгидой форума проходило закрытое обсуждение в составе небольшой экспертной группы (список участников — на второй странице глоссария). Получилось быстрее и, хочется надеяться, лучше, чем в прошлый раз. Огромный, как теперь принято говорить, респект Кириллу Иванову, взявшему на себя координацию работы группы и вообще львиную долю труда в этом проекте. 

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

ITIL 4 Foundation, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от соавторов ITIL 4

Комментариев: 27

  • Павел

    А как планируется постепенно совершенствовать?

    Вот мне например не нравится, что некоторые термины фактически не переведены, а выполнена их транскрипция.

    Вот, например, функция. Я и в прошлый раз предлагал перевести function, как функциональная группа или функциональное подразделение (можно ещё поработать над этим, и тщательнее поискать аналоги в русском языке).

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

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

    • Павел, привет!

      Кстати, я не забыл наших споров, твоего мнения и его отразил его в обсуждении. Но опять было не понято 😎

  • Павел

    Вот кстати ещё вопросик, про ПРОБЛЕМУ.

    если посмотреть на практику русского языка, то в обиходе принято пользоваться понятием ПРОБЛЕМА для описания того, что в ITIL принято называть ИНЦИДЕНТ.

    Если мы делаем перевод, а не транслитерацию, то такие вещи тоже нужно как-то учитывать.

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

    • Георгий

      В корне не согласен. почти 99% пользователей при возниконовении более-менее критичного инцидента пользуются вовсе не словом ПРОБЛЕМА, а гораздо более распространенным в обиходе, намного более емким, но не очень цензурным словом.

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

      • Павел

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

        • Георгий

          Это просто шутливый пример того, как далеко можно зайти в попытках «адаптации» слов и выражений, не больше и не меньше.

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

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

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

            • Георгий

              Давай цитируй! 🙂 надо внедрить в массы 🙂

              • Там есть такой замечательный термин: excitement factor 😉

                Официальный перевод — фактор восхищения. Кто помнит Поколение П т-ща Пелевина, тот легко переведет.

                • Георгий

                  ешкин крот. я даже не помню такого термина в книгах 🙂 хотя интуитивно понимаю к чему и как он относится 🙂

                  твой перевод лучше. что там интересно цензорам не понравилось

    • Павел, а как бы вы предложили называть то, что ITIL называет проблемой?

      • Павел

        Да вобщем-то напрашивается не мудрить, а называть всё своими именами.

        Посмотрите на определение, которое дано в глоссарии: Проблема — это причина одного или нескольких инцидентов. Так стоит ли переопределять значения? Можно так и называть «Причина».

        Если уж такой простой ход совсем не по душе, можно использовать термин, принятый в обслуживании оборудования, «Дефект».

        • Причина — слишком многозначное слово, конечно. «Процесс управления причинами» — несколько самонадеянно звучит, согласитесь...

          «Дефект» мне нравится гораздо больше.

          Собственно, я не удержался от вопроса только потому, что сам очень не люблю термин «проблема»: мне кажется, он формирует неверное представление о сути процесса.

          Но в целом я согласен с Георгием. О чем писал ниже (12.09, 19:00). Тот документ, который мы в этом году назвали «словарь» (вместо иноземного «глоссарий») — в первую очередь способ интеграции нашего сообщества в мир ITIL, а не способ создания или формализации своего собственного понятийного аппарата. К сожалению или нет — сложно сказать...

          • Георгий

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

            P.S. Ваш спор все больше напоминает извечное «западники» и «славянофилы» 🙂

            • Вот-вот. Особенно я не люблю этот термин за обороты типа «проблема, имеющая корневую причину» 🙂

              Что же до пользователей — что ж, процесс это все больше внутренний. Можно и потешить немного техподдержку. Это если шутить.

              Если делать серьезное лицо, то недостаточный уровень подготовки пользователей — это часто не их дефект, а наш. Это мы их неправильно приготовили.

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

              • Георгий

                Рома, ты прав 100%. особенно про пользователей и дефект

      • Павел

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

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

        • Георгий

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

          Для примера -то что пользователь называет проблемой «по-русски» — почти никогда для Ит-шника «проблемой» не является. Ит-шник говорит «проблема», когда реально не знает чт происходит и в чем дело. Когда выяснет это — говорит «дефект», «ошибка» итп. ITIL писали и пишут ИТ-шники, у них такой словарь. у русских в том числе. Сорри, меня не убедили

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

          • Павел

            Спору нет. Народ давно сказал: Что русскому хорошо, немцу смерть.

            Я собственно в очередной раз решил постебаться над лозунгом: Давайте говорить на языке бизнеса (но на своём языке).

            Всколыхнул волну... 🙂

  • Павел С.

    Понимаете ли Георгий, шутливыми примерами можно отшутиться от чего угодно.

    Чтобs увидеть проблему, надо смотреть на систему извне, изнутри увидеть проблему сложно.

    • Георгий

      ну на перевод я как раз смотрю извне и он мне нравится 🙂

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

      • Павел С.

        Так глоссарий же не как вещь в себе, глоссарий должен служить неким соглашением о терминологии, которому все будут следовать. И тут вариант нам (неким ITSM-щикам) придумать свою терминологию, или подстроиться под какую-то устоявшуюся (более или менее).

        • Георгий

          Если на секунду перестать шутить, то, сорри, но.

          Павел, мне кажется вы слегка опоздали. С выходом еще первой версии ITIL — «мы» (ITSM-щики), в лице авторов первых книг, ПРИДУМАЛИ терминологию. Уже. Факт.

          За прошедшие годы этой терминологией стали пользоваться все. Не зря ITIL называли и называют стандартом «де-факто». Тоже уже и тоже факт.

          У сообщества ITSM в РФ есть (вернее было) два пути:

          1. Перевести придуманный зарубежом глоссарий и пользоваться им

          2. Придумать свой, базируясь или нет (второй вопрос) на зарубженом

          Насколько я понимаю, выбран был первый (как выбирали, кто итп — лучше всего знает Алекасандр Жилинский и другие авторы перевода, я не знаю). В силу выбранного варианта, предлагать новые «русифицированные» термины противоречащие по сути англоязычным — не имеет смысла

          Offtop. Пару лет назад я, в качестве руководителя комитета по стандартам НП АСТРА стоял перед похожим выбором. Сделал в итоге выбор отличный от ITSMf, но уж какой сделал. Тем не менее, теперь уже назад не повернуть ни ITSMf-у, ни НП АСТРА.

          • Павел С.

            При переводе очередного глоссария, всегда можно пойти по другому пути. Будет больно, будет много споров и шуму. Но пойти можно.

            Нужно или нет, сложно сказать...

            • Павел, а зачем?

              У проекта «перевод глоссария» — две цели: реальная и виртуальная.

              Реальная — открыть возможность локализации экзаменов и других официальных материалов APMG (боюсь сказать — книг ITIL).

              Виртуальная — дать русскоязычному ITSM-сообществу общую терминологию.

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

              Подход «Придумать свой, базируясь или нет (второй вопрос) на зарубежном», возможно, решает первую и, возможно, вторую. А возможно, что ни одной.

              Споры о «правильных терминах» длились бы бесконечно, общего языка все равно не возникло бы, а путаницы было бы много. Так что с практической точки зрения первый подход и результативнее, и рациональнее. Почему и был выбран (imho).


Добавить комментарий для ПавелОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM