Портал №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) поддержки

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

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

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

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

  • Рубрики

  •  
  • Самое свежее

    • Определяем полюс потребителя
      При анализе и построении «путешествия заказчика» (customer journey) одной из важнейших задач является получение ответов на ряд вопросов, а именно: кто конкретно …
    • Семь распространённых мифов о DevOps
      В сообществе разработчиков бытует множество мифов о DevOps. И это и неудивительно, учитывая, сколько новшеств привнесла эта концепция за последние годы. DevOps — это …
    • Разрешение конфликтов в Agile-командах
      Большинство людей предпочло бы избегать конфликтов. Как специалисты по проектам, мы знаем, что это неизбежно, и мы также знаем, что несогласие может быть конструктивным. Но при …
    • Очередность прохождения курсов ITIL 4
      Имеет ли значение, в каком порядке проходить курсы по ITIL? Рассказывает аккредитованный тренер по ITIL 4 Игорь Фадеев. Cleverics — первая в России и одна из первых в …
    • 1 октября конференция «Роботизация бизнес-процессов 2020»
      1 октября 2020 издательство «Открытые системы» проведет ежегодную конференцию «Роботизация бизнес-процессов 2020» https://www.osp.ru/iz/rpa2020, где на одной площадке будут …
    • ITIL® 4 DITS — огонь, вода и медные трубы
      Мы уже писали о скором релизе последнего экзамена в сертификационной линейке ITIL 4 Digital and IT Strategy (DITS). Сейчас стоит добавить следующее (из информации, которую можно …
    • Как бизнес-аналитику встроиться в гибкую среду?
      Есть ли роль бизнес-аналитика в гибкой среде? Я уже довольно давно работаю бизнес-аналитиком, и этот вопрос возникает постоянно. Бизнес-аналитики  зачастую считают, что они должны …
    • Деловая игра Grab@Pizza: вкусный кейс
      Деловые игры – один из наиболее эффективных видов тренинга, позволяющий на основе близкого к реальному кейса попрактиковаться в выстраивании любой работы. Участники деловой игры …
    • ITAM & SAMday пройдёт в Москве 2 октября
      ITAM & SAMday  – всероссийская независимая конференция, посвященная вопросам управления ИТ-активами и программными активами — пройдёт в Москве 2 октября в режиме …
    • Бэклог! — Как много в этом слове ...
      Команды, работающие над развитием различных продуктов, имеют одну общую цель: обеспечить максимальную скорость изменения своего продукта для реализации возникающих потребностей …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT