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

Согласно ISO 31000, риск - это влияние неопределенности на цели. Риск-менеджмент, соответственно, представляет собой скоординированные действия по направлению и контролю организации в отношении рисков. В контексте ИТ-управления это означает, что управление проводится не собственно рисками, а организацией с учетом рисков. Управление рисками в ИТ-сфере - это управление организацией с учетом неопределенности. Чем лучше эта неопределенность проработана (корректно идентифицирована, проанализирована и оценена), тем более обоснованные управленческие решения можно принимать и тем более предсказуемые результаты получать. В этом смысле управление рисками становится неотъемлемой частью работы любого менеджера в ИТ-сфере.

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

Точки взаимодействия — это конкретные моменты, когда клиент контактирует с компанией: сайт, соцсети, телефонные звонки, точки продаж и т.д. Чтобы спроектировать их эффективно, необходимо: 1) понять, какая ценность предоставляется в каждой точке, 2) обеспечить их согласованность между собой для плавного перехода клиента к следующему этапу, 3) учитывать, что даже небольшие изменения контекста могут кардинально повлиять на восприятие. Точки должны быть не просто функциональными, но и мотивирующими клиента двигаться дальше по его путешествию. Если ценность точки неочевидна, это сигнал к её переработке.

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

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

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

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

Практические примеры нарушения лицензионных соглашений включают установку бесплатного Adobe Reader на сервер, несмотря на запрет в лицензии, и использование Infranviewer в коммерческих целях, тогда как лицензия разрешает его применение только в некоммерческих (например, дома, а не в офисе). Эти примеры показывают, что формальное соблюдение количества экземпляров еще не гарантирует полного соответствия условиям лицензий.

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