Портал №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