Особо важными soft skills для успешного агента изменений являются широта ума, открытость, чёткость мысли и готовность к диалогу. Специалист должен быть гибким для встраивания в организацию, достаточно умным, чтобы понять сложные процессы во всех их аспектах, и достаточно мотивированным для проведения изменений. Знание методологий (таких как agile) и опыт работы важны, но могут не компенсировать отсутствие необходимых социальных навыков, таких как чуткость к команде и внимательность к реальным проблемам организации.

Статус 'Ожидание' используется для откладывания обрабатываемого объекта (инцидента, обращения, задания) в сторону, когда его обработка невозможна по объективным причинам. Основные случаи применения: ожидание возвращения пользователя из отпуска, ожидание поставки техники, получение ответа от другой службы или специалиста. Цель статуса - структурировать рабочий процесс, отделяя задания, требующие активных действий, от тех, которые временно невыполнимы без внешнего воздействия.

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

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

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

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

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

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

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

Увеличение размера внедрения (Release size) приводит к нескольким негативным эффектам. Во-первых, большие релизы сложнее планировать, контролировать и тестировать, что повышает Change Risk (риск неудачного внедрения). Во-вторых, крупные изменения чаще приводят к ошибкам и сбоям, требующим дополнительных изменений для их исправления, что увеличивает Backlog Size (размер очереди изменений). В-третьих, когда Backlog Size становится большим, это приводит к усилению стремления 'укрупнять' последующие внедрения, создавая замкнутый цикл. Крупные релизы также увеличивают Process Time (время работы над изменением) и Queue Time (время ожидания), что в совокупности приводит к росту Time to market. Таким образом, увеличение Release size запускает несколько негативных усиливающих петлей обратной связи, которые со временем усугубляют проблемы в ИТ-системе и могут привести к нисходящей спирали, описанной как Core Chronic Conflict.