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

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

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

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

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

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

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

Негативное отношение сотрудников к метрикам обычно связано с тремя основными факторами: недоверием к прозрачности процессов (ранее мало кто знал о занятости сотрудника, а теперь появляется контроль); страхом, что результаты метрик будут напрямую влиять на материальное вознаграждение; и отсутствием понимания того, зачем нужны метрики и как они помогают в управлении процессами. Сотрудники могут воспринимать метрики как способ давления или наказания, а не как инструмент для улучшения работы.

Бэклог команды в иерархии Atlassian состоит из понятных команде конечных элементов, которые могут быть обработаны за один или несколько условных "тактов" (не более некоторого N). Такими элементами являются пользовательские истории и задачи/подзадачи. Эпики, инициативы и темы не входят в бэклог команды, так как они либо слишком велики для непосредственной обработки (эпики), либо служат управленческими группировками (темы), либо относятся к инвестиционному планированию (инициативы).

Настройка middleware считается важной компетенцией для внутренней команды, потому что именно она определяет, насколько эффективно и безопасно приложение будет работать в условиях реальной нагрузки и специфики бизнес-процессов. Middleware требуется глубокая экспертиза по настройке под конкретную нагрузку, взаимодействие различных компонентов и обеспечение безопасности. Стандартные решения, предоставляемые IaaS или SaaS, не учитывают специфику продукта, поэтому настройка и конфигурирование middleware остаются внутренней ответственностью. Без этой экспертизы, даже при наличии качественной базовой инфраструктуры, продукт не сможет функционировать должным образом, особенно если речь идет о кастомизированном решении или высоконагруженной системе.