Терминология IT

Оргинал: Defining Metrics for Problem Management

By Stuart Rance | Originally published on June 24, 2014 in ITIL | Updated on November 28, 2017

Это перевод второй статьи на тему определения показателей для процессов Управления ИТ- услагами. Ценность ее в применении техники формулирования показателей на основе требований к результатам процесса (здесь и далее курсивом выдлелены комментарии переводчика).

Многие подбирают ключевые показатели (KPIs) для своих процессов Управления ИТ услугами по книгам (таких как ITIL Service Operation) или копируя метрики, используемые в других компаниях. Это редко приводит к хорошим результатам, потому что дословно KPIs - это дословно Показатели Результативности Ключевых задач, которыми вы занимаетесь. Хуже только ITSM процессы с огромным количеством одинаково названных показателей, которые измеряются, по ним пишутся отчеты, но результаты этого никто не использует ни для изменения деятельности в рамках процессах, ни для улучшения бизнес результатов. 

Ранее я уже писал заметку "Как определять метрики для процесса Управления изменениями" (перевод, оригинал) , в которой я описывал, как можно создать ключевые показатели (KPIs), которые поддерживают именно ваши цели. Читатели (оригинала) после прочтения просили привести примеры, как выделять ключевые показатели (KPIs) для остальных процессов управления ИТ-услугами. В результате я решил написать эту статью для показателей процесса Управления проблемами (problem management), потому что в большинстве компаний, где я работал, у этого процесса были очень куцые показатели.

Напоминаю, что не стоит бездумно копировать приводимые здесь результаты процесса (outcomes), его критичные факторы успешности (CSFs) и ключевые показатели (KPIs). Содержание статьи стоит использовать только для понимания подхода и методологии, которые мною используются. И задуматься о том, что важно именно для вас, выделить метрики, для измерения задачи, за которые вы отвечаете. 

Оригинал Defining Metrics for Change Management

By Stuart Rance | Originally published on April 28, 2014 in ITIL | Updated on September 12, 2017

Начало цикла из 3-х статей про процесс определение показателей для оценки практик управления предоставления ИТ услуг. Чем может быть интересна? Ходом рассуждений автора. (здесь и далее курсивом комментарии переводчика).

Недавно я работал с заказчиками, и они спросили какие ключевые показатели результативности (key performance indicators, KPIs) им использовать для измерения результатов ИТ-процесса Управления изменениями (change management). После обдумывания я предложил им несколько вариантов. И сейчас хочу поделиться ими здесь, потому что это может быть еще кому-нибудь полезно . Только, пожалуйста, бездумно не копируйте себе предлагаемые показатели (KPIs), ведь они  предложены под конкретных заказчиков, но внимательно просмотрите за процессом их опеределения и задумайтесь, а что стоит измерять в вашей ситуации.

• Пишут-то много, но каков профессиональный уровень этих текстов? Он вас удовлетворяет?
• Новых слов много, но кто их понимает?
• И, вообще, прогресс есть или нет? Где результат?
• Если нет, то «кто виноват и что делать»?
• Куда смотрит государство и что регулирует?
• ГОСТов много, но кто их использует? И кто их пишет? И вообще, какой от них толк?
• Не пора ли, если не точно определить основные понятия, то хотя бы прийти к консенсусу?

Новая подборка по переводческим решениям для еще одного популярного слова в ИТ- и бизнес-литературе. Смотрите, пользуйтесь.

Синонимы

decide

Начнется все с самого простого, например с выбора фильма для просмотра.
It starts with simple things, like deciding which movie to watch.

Когда Великобритания оказалась перед выбором, выходить из ЕС или нет…
… when Britain needed to decide whether it should leave the EU…

Недавно в ПО для видеоконференций Microsoft Teams наконец появилась функция поднятия руки, но внимательных русскоязычных пользователей позабавит ее подпись: Поднимите руку. Глаголы рядом подписаны в неопределенной (инфинитивной) форме: Показать, Включить, Начать. А здесь использовано повелительное наклонение (императив), как будто программа нам приказывает: Поднимите руку! Как так получилось?

Казалось бы, база данных она и в Африке database, но читая аутентичную техническую литературу по СУБД (которую русские переводчики традиционно переводят как DBMS — database management system), я ни разу этот термин — DBMS — там не увидел (не исключаю, что плохо смотрел, но ей-богу не вру).

Получается, этот термин выдуман? И много ли такого самопала?

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

Итак, поехали.

Какие бывают?

Объектные базы данных появились в конце 1980-х — начале 1990-х годов и снова вышли из моды.
Object databases came and went again in the late 1980s and early 1990s.

В начале 2000-х появились базы данных XML, но нашли только узкое применение.
XML databases appeared in the early 2000s, but have only seen niche adoption.

Есть еще один куст слов, по которому в голову большинства переводчиков (я в их числе) в голову лезет только один дежурный набор вариантов:
участник/участие > take part/participate/participant.

Как обычно, мы посмотрели несколько переведенных с английского книг по бизнесу и ИТ (список книг внизу), развернули направление перевода (стало русско-английским), вытащили около 300 вариантов перевода, отбросили те, которые с дежурным переводом, и разложили по полочкам наиболее интересные и применимые.

Поехали.

Трансформации. Пропуск

Здесь необходимо участие обеих сторон.
It takes two to tango.

Единство мнений других участников рынка отражает цена.
That’s because the consensus view is baked into the price.

Если в переводном тексте кто-то что-то где-то начинает — то у меня сразу всплывают три дежурных варианта: begin/beginning, start/starting, first/firstly.

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

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

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

Поехали.

Слова-синонимы

Через последовательность действий

Я принял все предложения без споров и оправданий и начал действовать.
I accepted their advice without arguing or defending and acted on it.

Теория (+её производные) — ещё одно слово, на котором у меня включается творческий тупик: в голову ничего кроме theory/theoretical/theoretically не лезет. Поэтому его мы тоже с коллегами решили покрутить и так, и этак — посмотреть, как обыгрывают эту концепцию носители.
Среди примеров вы обязательно увидите мой любимый — не переводить вообще (раздел «Трансформации. Пропуски»).
В конце будет раздел «Бонус» — использование theory в необычных контекстах.

Principle

В этой книге обсуждаются как теоретические, так и практические вопросы построения компьютерных сетей.
This book discusses both the principles and practice of computer networking.

То, что я вляпался в болото, стало понятно часа через 4 после начала раскопок этой пары терминов (и это я еще финансовый смысл не рыл — interest rate) — примеров получилось неожиданно больше, так что извините, будет «много букв».

На первый взгляд интерес = interest — полные эквиваленты, однако во фразе «интервьюеры обычно интересуются, сколько памяти занимает структура данных» — interest лезет с большим скрипом (мне фантазии не хватило).

Или бывает автор, сам того не замечая, пишет несколько слов подряд с этим корнем — и как тогда это отрабатывать в переводе? А вот как! Смотрите примеры.