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

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

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

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

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

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

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

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

Causal Loop Diagram (CLD) помогает в верификации набора метрик, позволяя визуализировать взаимосвязи между ключевыми элементами системы управления. Анализируя CLD, можно убедиться, что все элементы управления охвачены метриками. Например, при рассмотрении DevOps-процессов, CLD отражает такие факторы, как время выхода на рынок, среднее время обработки, размер очереди изменений, уровень стандартизации, успешность внедрений и другие. Соотнося элементы CLD с предлагаемыми метриками, можно определить, достаточно ли текущих показателей для оценки состояния системы и где есть пробелы.

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