Учёт возвратов на доработку индивидуально по группам необходим, потому что если учитывать их на уровне всего обращения (инцидента), это может привести к неверным результатам. Например, если после возврата на доработку в группу А инцидент был переназначен в группу В, которая решила его с первого раза, то при уровне всего инцидента возврат снизит метрику не только группы А, но и группы В, хотя вина за возврат лежит только на первой группе. Также одно обращение может быть возвращено несколько раз в разные группы, и при общем учёте результаты расчёта будут искажены.

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

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

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

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

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

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

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

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

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