Управление изменениями: роли и обязанности в команде

Менеджер/координатор изменений

Менеджеры изменений, также иногда называемые координаторами, как правило, отвечают за управление всеми аспектами внедрения ИТ-изменений. Они назначают приоритет запросов на изменения, оценивают их влияние, после чего принимают или отклоняют изменения. Кроме того, они документируют процессы управления изменениями и планы изменений. Что важно, такие сотрудники осуществляют подготовку, организацию собраний CAB и сами их проводят. Успех менеджера изменений, как правило, оценивается исходя из достижения целей по срокам и бюджету.

Контролер изменений

Контролер изменений — это сотрудник, принимающий или отклоняющий изменения. Иногда это один человек, например менеджер или директор. Иногда это группа сотрудников, входящая в совет по изменениям. А иногда это коллега, выступающий в роли рецензента. В соответствии с ITIL 4, «в динамичных организациях, как правило, подтверждение изменений происходит децентрализованно, поэтому эффективность организации в большей степени зависит от решений привлекаемых экспертов-рецензентов».

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

Заинтересованные лица со стороны предприятия

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

Например, если изменение негативно повлияло на скорость связи между программным обеспечением учета платежей в бухгалтерии и CRM в отделе продаж, может понадобиться, чтобы представители бухгалтерии и отдел продаж участвовали в собраниях CAB и принятии окончательных решений касательно изменения.

Инженеры/разработчики

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

Агенты службы поддержки

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

Менеджеры по эксплуатации

Сотрудники на этой должности отвечают за ежедневное поддержание систем в рабочем состоянии, поэтому они делятся своими комментариями по поводу рисков и зависимостей.

Менеджеры по работе с клиентами

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

Специалисты по информационной безопасности и сетевые инженеры

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

Что такое CAB?

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

По этой причине, а также из-за утомительных собраний, длинных бэклогов запросов на изменения и простоя основной работы отношение к CAB среди сотрудников компаний зачастую пренебрежительное. К счастью, сегодня многие CAB идут в ногу со временем и поддерживают гибкость поставки ПО, выполняя, скорее, стратегическое консультирование. CAB становятся консультативным органом, ответственным за отслеживание тенденций, рекомендацию соответствующих методик, а также за поиск методов оптимизации предоставления услуг и снижения рисков.

Задача, стоящая перед CAB

Бытует мнение, что собрания CAB — неприятное мероприятие. Мы жестко критикуем их за потерю времени, за недостижение целей, привлечение большого числа случайных людей и за то, что они вообще проводятся, несмотря на возможность переписки по электронной почте. Отчасти это происходит из-за того, что на CAB традиционно возлагается слишком много ответственности.

Проиллюстрируем эту ситуацию, сравнив ее с работой диспетчерской вышки в аэропорту. Представьте себе, что CAB — это контрольная вышка на летном поле. Ее функция — давать пилотам разрешение на посадку. Вряд ли кто-то делегировал бы диспетчерам вышки оценку конструкционной безопасности самолетов или проверку наличия у пилотов летных лицензий, так как соответствие этим требованиям уже подтверждено FAA и другими авиационными ведомствами.

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

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

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

CAB как консультационный орган по стратегическим вопросам

Чтобы изменить роль CAB, нужно, прежде всего, отказаться от идеи, что всесторонняя власть CAB в вопросах применения изменений приводит к положительным результатам. По данным отчета State of DevOps Report 2019, процессы, требовавшие подтверждения со стороны CAB, негативно отразились на скорости предоставления программного обеспечения, а среди респондентов, следовавших таким процедурам, оказалось в среднем в 2,6 раза больше тех, чья эффективность была низкой. Кроме того, выяснилось, что наличие формальной процедуры подтверждения изменений никоим образом не снижает количество неудачных изменений!

Поэтому сегодня в командах принимаются следующие меры по оптимизации CAB.

Отказ от унифицированного отношения к запросам на изменения.

Каждый запрос на изменение — это возможность найти и собрать информацию. Мы можем выяснить, каков процент успеха, какие произошли инциденты и каковы их причины. По мере накопления данных станет возможным предварительное подтверждение и автоматизация все большего числа изменений. Только наиболее рискованные изменения должны подтверждаться непосредственно членами CAB.

Совместное управление изменениями и релизами

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

Применение прогрессивных релизов для тестирования и итерации

Постепенное развертывание с этапом промежуточного тестирования небольшой группой пользователей позволяет убедиться в стабильности релиза перед его полным развертыванием. Такой подход позволяет ограничить влияние потенциального инцидента и доказывает важность пробного развертывания перед официальным выпуском.

Использование автоматизации и инструментов для упрощения управления изменениями

В высокоскоростных командах специалисты начали пересматривать устоявшиеся модели подтверждения. Вместо того чтобы еженедельно обрабатывать большие бэклоги с запросами на изменения, присутствуя на собрании лично, можно взаимодействовать удаленно. Например, можно заранее отправлять запросы на изменения по электронной почте, чтобы участники CAB могли анализировать их еще до собрания. Кроме этого, заявки Jira и страницы Confluence позволяют проверяющим получить сопутствующие данные, необходимые для асинхронного взаимодействия и подтверждения изменений. В Jira Service Management команды получают возможность такого взаимодействия, а при необходимости могут даже провести видеоконференцию или создать специальный канал Slack. При любых способах связи, выбранных командой, весь обмен информацией централизован, а потому все участники остаются в курсе происходящего.

Устаревшие инструменты ITSM усложняют создание запросов на изменения разработчиками, операционными командами и специалистами по инфраструктуре. Следует применять автоматизацию и современное ПО, чтобы приходилось вводить вручную меньше данных об изменениях. Разработчик не должен тратить время на то, чтобы заполнять заявки в громоздкой изолированной системе, если это можно автоматизировать. Система автоматизации Jira Service Management позволяет командам оптимизировать процесс внедрения изменений, а также свести к минимуму риски и время простоя.

Управление изменениями должно быть более открытым по отношению к тем, для кого они предназначены

Одна из самых популярных стратегий, используемых вместо CAB (полностью или частично), заключается в привлечении экспертов-рецензентов. При этом задача выявления проблем в коде возлагается на тех, кто лучше всего в нем разбирается. Согласно ITIL 4, «в динамичных организациях, как правило, подтверждение изменений происходит децентрализованно, поэтому эффективность организации в большей степени зависит от решений привлекаемых экспертов-рецензентов». Аналогичным образом, в отчете 2019 State of DevOps report организациям рекомендуется «сместить фокус на подтверждение изменений с привлечением экспертов-рецензентов».

Чтобы обеспечить соответствие нормативным требованиям при использовании такого подхода, необходимо тщательно документировать все данные, и в этом поможет, например, система Bitbucket, автоматически отслеживающая данные авторов и экспертные рецензии и предотвращающая внедрение изменений без выполнения необходимой процедуры.
В Atlassian экспертное рецензирование является ключевым этапом процесса подтверждения. Как сказал один из наших экспертов по ИТ-рискам и соответствию требованиям, «весь код Atlassian хранится в Bitbucket. Если разработчику нужно внести изменение, он извлекает код из Bitbucket и работает с ним на своем ноутбуке. При возврате кода в репозиторий Bitbucket, вместо того чтобы сразу обновить код, система запрашивает экспертную рецензию. Только после такой проверки подтвержденный код возвращается в репозиторий. Что если код не был подтвержден? В этом случае он отправляется первоначальному разработчику с замечаниями от эксперта-рецензента. Разработчик исправляет недочеты и отправляет код на повторную проверку».

Привлекайте экспертов, чтобы соответствовать передовым стандартам

По мере усложнения структуры организаций возрастает необходимость быстрого обмена информацией и координирования работы команд. Вместо подтверждения отдельных запросов на изменения CAB могут сконцентрировать усилия на оптимизации подходов к работе. Взяв на себя эту функцию, CAB может предоставлять рекомендации по совершенствованию методик, привлекать специалистов с более подходящими компетенциями и предоставлять ресурсы и инструменты, повышающие эффективность. Это позволяет расширить сферу влияния CAB и тем самым избежать замедления продвижения компании на рынке.

Даже в более традиционных ИТ-организациях CAB может стать источником оригинальных решений. Например, в среде университета с консервативным отношением к рискам, где используются устаревшие инструменты и методы ITSM, нужно было найти способ проинформировать студентов о том, что важная услуга будет недоступна. CAB превратился в настоящий форум с обсуждением новых подходов к обмену информацией. В итоге было решено распространять конфеты и постеры в рамках кампании, по сути отклоняющей поступающие запросы о запланированном обновлении системы.