Десять лучших рекомендаций по управлению изменениями

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

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

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

С помощью Jira Service Management можно настроить подтверждения и рабочие процессы под конкретную организацию. Задайте желаемую степень гибкости и автоматизации процессов. Возможно, стоит автоматизировать процессы с низким уровнем риска, а более изощренные — защитить подтверждениями.

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

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

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

1. Проанализируйте изменения за последние несколько месяцев.
   • Какие изменения вносятся чаще всего?
   • Какие изменения считаются стандартными?
   • На какие услуги они влияют?
   • Какие изменения оказались успешными?
   • Сколько времени понадобилось в среднем на внедрение таких изменений?
   • Какие изменения были запрошены командами разработчиков?
2. Выберите от трех до пяти стандартных изменений в качестве кандидатов для автоматизации.
3. В программном обеспечении службы поддержки создайте типы запросов самообслуживания, которые будут использоваться для стандартных изменений.
   • Добавьте описание с указанием предназначения и области применения стандартных запросов на изменения.
   • Укажите основные сферы, в которые вносятся изменения (например, система, приложение или сервис).
   • Создайте правила автоматизации для предварительного подтверждения изменений, смены состояния и уведомления сотрудников.
4. Проинструктируйте сотрудников ИТ-отдела и команду разработки о том, как использовать эту новую возможность.
5. Отследите производительность за последние несколько месяцев.
   • Подумайте, как можно улучшить имеющиеся предложения.
   • Определите, какие еще стандартные изменения можно автоматизировать.

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

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

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

Чем проще процесс, тем легче добиться расположения сотрудников (и сохранять его).

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

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

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

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

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

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

Некоторые не любят ITIL. Говорят, что положения ITIL слишком ограничивают возможности и являются устаревшими. Тем не менее ITIL предлагает много полезного ИТ-командам, включая адептов культуры DevOps. И проблема не в строгости ITIL. Проблема в том, как мы используем рекомендации.

Если воспринимать ITIL как набор строгих правил для неукоснительного следования, то, конечно, он покажется слишком ограничительным. Относитесь к ITIL как к набору рекомендаций, на базе которых ваша компания может выстраивать свои рабочие процессы. И тогда, занимаясь разработкой методов управления изменениями, вы убедитесь, что ITIL — ваш верный помощник.

Это применимо к любой среде и любым идеологическим предпочтениям. ITIL, lean, DevOps, Agile, CD... Ни одна методика, как бы вы ее ни любили, не решит все ваши проблемы одним махом. Очень часто мы ищем решение внутренних проблем, пытаясь использовать для этого систему методик или инструментов, тогда как нужно смотреть совсем в другую сторону — на культуру совместной работы.

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

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

Продукт Jira Service Management спроектирован так, чтобы объединять усилия команд для ускоренного выполнения целей, в данном случае — оперативного внесения изменений без инцидентов. Сплоченность и высокая скорость работы команд достигается за счет механизма взаимодействия. Прозрачная платформа, оснащенная инструментами, подобными Confluence, интегрированными средствами чата и видеоконференций, а также настраиваемыми рабочими процессами, позволяет каждому вносить свой вклад удобным способом и полностью владея контекстом.

Инженерия хаоса — это новый подход к проверке устойчивости, при котором выводятся из строя или отключаются компоненты продукта или сервиса. Аналогичным образом инженерия отказоустойчивости позволяет выяснить все возможные причины нарушения нормальной работы системы. Для этого систему, например, нагружают мощным трафиком или большим числом пользователей.

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

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

Сотрудники Atlassian отслеживают изменения при помощи Jira Service Management. Платформа Jira объединяет команды разработчиков и операционные отделы, обеспечивая прозрачность и отслеживание контекста со времени написания кода разработчиками и до развертывания изменений.