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

Сфера ответственности координатора релизов

Сразу уточним – в ITIL роль “Координатор релизов” не описана. Вопрос про сферу ответственности возник у слушателей курса ITIL RCV при обсуждении соответствующего раздела. Почему такой вопрос возник, в целом понятно. По аналогии с процессами управления изменениями или управления инцидентами при управлении релизами напрашивается необходимость фиксации так называемой “сквозной” ответственности за релиз. То есть выделения роли, отвечающей за координацию деятельности в рамках релиза на всём протяжении его жизненного цикла – от планирования до закрытия. По аналогии с “Координатором изменений” хочется назвать её “Координатор релизов”. Однако в ITIL V3 подобная роль не выделена.

Справедливости ради следует отметить, что роли “Координатор изменений”, которую мы обычно описываем в регламентах, в ITIL тоже нет, а роль “Практик изменений” (Change practitioner) похожа на неё не до конца. В частности, задача по координации ему не вменяется – в перечне типовых обязанностей практика изменений упоминаются только мониторинг и проверка (reviewing) полноты и корректности выполнения работ в рамках изменения. Сама же “координация” упоминается не в разделе про роли, а в главе 4.2.5, где описаны активности, методики и техники процесса. И вменяется в обязанности некоего “change management”, под которым понимается в целом процесс управления изменениями, а кто конкретно – не всегда зафиксировано чётко. В зависимости от специфики и размера организации, а также от конкретной ситуации это могут быть: менеджер процесса, практик изменений, участники CAB, ответственные за авторизацию.

При этом в отношении изменений есть следующее упоминание: если изменение является частью релиза, то его построение, тестирование и развёртывание координируются процессом управления релизами. Кто же конкретно должен заниматься координацией релизов? Давайте посмотрим на роли процесса управления релизами, как они описаны в ITIL V3, и разберёмся, за кем может быть закреплена “сквозная” ответственность. Особенно с учётом того факта, что роли процесса управления релизами по большей части “технические”, о чём прямо говорится в книжке.

В разделе 6.4.8 книги Service Transition описаны следующие роли, в обязанности которых входят какие-либо виды координации:

  • Менеджер процесса – координирует ресурсы, необходимые для построения, тестирования и развёртывания каждого релиза; контролирует получение необходимой авторизации; координирует взаимодействие с другими процессами;
  • Практик развёртывания – координирует подготовку документации по релизу и проведение обучения.

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

Исходя из описания, можно сделать вывод, что “сквозная” ответственность за отдельные релизы вменяется менеджеру процесса. При этом мы все понимаем, что в реальности объём работы по отдельным направлениям может быть таков, что один человек окажется не в состоянии координировать релизы по всем направлениям. Если релизы по разным направлениям (разным услугам/системам) выполняются разными специалистами, то вполне правомерным видится выделение роли “Координатор релизов”, которой будут частично (в рамках направления) делегированы полномочия менеджера процесса. Обязанности по координации в рамках направления будут охватывать управление ресурсами, которые выполняют роли так называемых Практиков, к которым относятся:

  • Практик пакетирования и построения релизов
  • Практик развёртывания релизов
  • Практик первичной (early life) поддержки

Интересно было бы познакомиться со спецификой распределения ответственности за координацию релизов в ваших организациях, коллеги! Будем признательны за комментарии. 

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Добавить комментарий

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;