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

Если в процессе не используется понятие 'переоткрытый инцидент', показатель First Time Resolution (FTR) можно получить, анализируя долю инцидентов, с которыми связаны более поздние инциденты, при условии, что система автоматизации процесса управления инцидентами позволяет связывать инциденты друг с другом. Если связь инцидентов используется и для других целей, анализ может стать несколько сложнее, но остается возможным. Также можно формировать полную систему оценки, в которой FTR не учитывается отдельно, поскольку переоткрытые инциденты влияют на другие показатели, например TCR (Ticket Closure Rate).

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

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

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

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

Согласно мини-опросу, проведённому на портале, операционные затраты составляют 67-68% от общего объёма затрат на ИТ. В банках этот показатель достигает 76-79% (по данным за 2015 год), тогда как международная статистика (Computer Economics) указывает на 73%. Затраты на персонал в операционных расходах варьируются от 40-60% в российских компаниях до 30-40% в западных. Эти данные подчёркивают необходимость детального анализа структуры затрат для их оптимизации.

Между Sev-5 (самый низкий уровень) и Sev-1 (самый высокий уровень) находятся промежуточные коды приоритетов, порядок которых возрастает от наименьшей к наибольшей степени срочности. Хотя в тексте не указаны конкретные названия или описания каждого уровня, можно предположить, что они представляют собой плавную шкалу от условно-технических проблем до критически важных событий, требующих полной мобилизации ресурсов. Каждый следующий уровень предполагает увеличение скорости реакции и вовлеченности руководства.

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

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