К управлению изменениями и релизами часто относятся как к неизбежному злу. Бюрократическая полоса препятствий из контрольных списков, согласований, CAB-ов и пятнадцати разных «окончательных» планов. Где-то на этом пути мы убедили себя, что процесс создан для защиты и забыли, что настоящий успех измеряется результатами, а не бумажной работой.
Но изменения — это еще и эмоциональный процесс. И когда мы игнорируем человеческую сторону изменения услуги, мы обрекаем себя на тихий провал. Не в пламени катастрофы, но в трениях, неразберихе и медленной утрате доверия.
Давайте перестанем притворяться, что наша задача просто «ничего не сломать». Настоящая задача — делать вещи лучше и добиваться, чтобы эти улучшения приживались. Это означает относиться к изменениям и релизам не как к шлагбаумам, которые нужно миновать, а как к мостам, ведущим к чему-то более надежному. И их нужно строить с учетом людей, для которых они строятся.
Изменения связаны с эмоциями, даже внутри ИТ
Мы часто связываем сопротивление изменениям с конечными пользователями. Людьми, которые не хотят новый интерфейс, которых сбивают с толку обновления, которые просто хотят, чтобы всё оставалось по-старому. Но такое же эмоциональное сопротивление существует и внутри ИТ-отдела. Мы не так часто говорим об этом, но оно есть.
Отказ от старых методов требует большего, чем просто изменение процесса. Это требует эмоционального принятия. Это сдвиг в мышлении от «защиты системы» к «расширению возможностей организации». От контроля к содействию.
И речь идет не просто о «софт скиллах». Это реальная, практическая проблема. Если ИТ-команды не чувствуют поддержки в этом изменении, то они будут сопротивляться. Или, что еще хуже, они будут делать вид, что следуют процессу, но потеряют вовлеченность. Вот так мы и приходим к управлению изменениями, которое технически соответствует требованиям, но стратегически бесполезно.
Управление организационными изменениями — это не вопрос выбора
Каждое изменение и релиз влекут за собой определенную степень организационного воздействия. Новые способы работы. Новые взаимоотношения между командами. Новые обязанности. Это означает, что это не просто технические события, а организационные.
Поэтому мы не можем позволить себе относиться к Управлению организационными изменениями как к отдельной дисциплине. Оно должно быть встроено в то, как мы проектируем и реализуем управления изменениями и релизами.
Это не обязательно означает огромные программы обучения или месяцы планирования. Но это означает встраивание учета человеческого фактора в наше планирование. Предвидение сопротивления. Привлечение заинтересованных сторон на раннем этапе. Обеспечение четкой, контекстной коммуникации. И отношение к эмоциональной стороне изменения как к части критериев успеха.
Это то же самое, что мы делаем для больших программ, но масштабированное до того, что нам нужно менять каждый день.
Поддержка изменений — это больше, чем просто руководство
Одна из самых распространенных ловушек в Управлении изменениями — это чрезмерный акцент на руководстве, отношение ко всему процессу как к простому механизму контроля. В эту ловушку легко попасть. Управление рисками важно. Защитные меры важны. Но если всё, что вы делаете — это устанавливаете знаки «стоп», не удивляйтесь, когда люди начнут искать пути в обход.
Практика поддержки изменениям призвана делать больше, чем просто говорить «нет». Она также должно помогать людям добиваться успеха, когда говорит «да». Это та часть, которая теряется, когда мы думаем о поддержке изменений как о шлагбауме, а не как об услуге.
Как же выглядит поддержка изменений на практике? Это не какая-то мистическая идея. Она прагматична. Речь идет о предоставлении услуг, поддержки и необходимой структуры которые повысят вероятность успеха. И начинается это с простой идеи: сделать так, чтобы правильное действовать было легче, чем неправильно.
Например, если ваш процесс изменений настолько долог и мучителен, что команды начинают создавать теневые процессы, лишь бы уложиться в срок. Ваше руководство практикой, возможно, работает на бумаге, но на деле оно проваливается. Это не значит, что вы можете просто отбросить контроль. Вы должны построить систему, которая понимает человеческое поведение и работает с ним, а не против него.
Это также означает давать людям ясность, а не просто требовать соблюдение требований. Объясняйте, почему что-то меняется, а не только что меняется. Рассказывайте историю. Помещайте это в контекст вашей организации. Дайте командам причину, чтобы им было не всё равно. Если они поймут «почему», они с гораздо большей вероятностью будут следовать «как».
И еще есть момент последующих действий. Изменение не является успешным только потому, что оно было одобрено и развернуто. Если никто не использует новое решение, или если оно тихо создает больше проблем, чем решает, то это не победа. Ваш процесс изменений должен иметь обратную связь. Он должен спрашивать: «Сделало ли это что-либо на самом деле лучше?», а не просто: «Выполнили ли мы все шаги?».
Процесс внесения изменений, который защищает бизнес, но раздражает людей, выполняющих работу, в итоге сломается — либо из-за текучести кадров, сопротивления или тихих обходных путей. Цель состоит в том, чтобы и руководить, и поддерживать. Защищать то, что важно, не задушив при этом инициативы людей, пытающихся двигать дело вперед.
Если ваш процесс изменений кажется замедляющим работу, то люди не будут ему доверять. Но если они чувствуют, что он помогает им добиваться успеха, вот тогда Управление изменениями действительно становится ценным.
Передача в эксплуатацию — решающий момент
Как бы хорошо вы ни спроектировали процессы управления изменениями и релизами, они развалятся, если передача услуги в эксплуатацию будет неорганизованная. Именно в этот момент, при передаче от технической реализации к повседневной поддержке, наступает реальность.
Итак, как на практике выглядит правильная передача услуги в эксплуатацию?
Не существует универсального контрольного списка, который волшебным образом подходит для любой организации в любое время. Если вы ищете готовый шаблон, извините, но изменения так не работают. Передача услуги в эксплуатацию не означает заполнение формы или отметку обязательных пунктов. Нужно делать правильные вещи в правильное время, чтобы помочь окружающим вас людям добиться успеха. Это означает думать меньше о формальностях и больше о намерении.
Хороший план передачи услуги строится вокруг одной цели: уменьшить возможность возникновения различных неожиданностей. Для конечных пользователей, команд поддержки, заинтересованных сторон и даже для самих инициаторов решения. Никто не любит, когда его застают врасплох, особенно чем-то, что должно было облегчить ему жизнь.
Вот некоторые задачи, которые стоит рассмотреть при выполнении передачи любого сервиса в эксплуатацию:
- Раннее привлечение заинтересованных сторон, включая команды поддержки. Не за два дня до запуска. Не после того, как поступит первая заявка. А заранее. Привлекайте людей, которым предстоит жить с последствиями изменения, когда вы еще только формируете его, а не когда оно уже готово.
- Четкая документация того, что меняется, почему и каково будет влияние. Речь не о том, чтобы завалить людей техническими деталями. Речь о создании общего понимания. Если вы не можете объяснить, что меняется и почему это важно, простым языком, то это значит, что вы не готовы двигаться дальше.
- Контекстное обучение или инструктаж для затронутых пользователей и команд. Нет, не презентация из 75 слайдов. Подумайте об обучении «точно в срок», коротких обзорах, возможно, даже небольшом видео. Встречайтесь с людьми там, где они находятся, и давайте им то, что нужно для плавной адаптации.
- Обновленные статьи базы знаний, написанные теми, кто ближе всего знаком с изменением. Это очень важно. Люди, готовившие изменение, лучше всех понимают, что точно надо задокументировать. Оставлять это кому-то другому постфактум — верный способ получить расплывчатые, устаревшие или откровенно неверные статьи базы знаний.
- Мониторинг и обратная связь для раннего выявления проблем после внедрения. Не нажали кнопку «развернуть» и исчезли. Оставайтесь рядом, наблюдайте, слушайте. Обращайте внимание на то, что люди говорят (и о чем умалчивают), и будьте готовы скорректировать, если что-то пойдет не так.
- Участие инициаторов изменения в поддержке развертывания в течение некоторого времени. Передача услуги в эксплуатацию — это не разовое действие. Заложите в план время, в течение которого создатели изменения всё еще будут вовлечены — отвечают на вопросы, настраивают поведение системы, помогают командам поддержки войти в курс дела.
Ничто из этого не должно рассматриваться как лишние расходы. Это часть предоставления ценности. У вас может быть чистейшее с технической точки зрения развертывание в мире, но, если люди, использующие или поддерживающие услугу, растеряны, раздражены или перегружены, то изменение провалилось.
Так что составляйте карту процесса. Делайте это совместно. Помните о человеческом факторе.
Заключение
Управление изменениями и релизами не должно быть безжизненными ритуалами. Если ваш процесс похож на холодный контрольный список, он уже работает против вас.
На самом деле нам нужна живая практика. Та, которая оставляет место для людей, а не только для утверждений. Та, которая ценит общий успех выше галочек в списке. Та, которая помогает командам работать лучше, а не просто безопаснее.
Это означает принятие эмоциональной стороны изменений. Не в духе «всё ради хорошего настроения», а по-настоящему. Люди привносят в процессы изменения тревогу, гордость, сомнения и энергию. Если ваш процесс не учитывает этого, не удивляйтесь, когда его начнут обходить.
Избежать катастрофы — низкая планка для практики поддержки изменений. Настоящая цель — не просто предотвратить сбой, а раскрыть ценность. Обеспечить изменения, которые будут одновременно быстрыми и продуманными, безопасными и расширяющими возможности. Изменения, которые создают импульс, а не гасят его.
