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

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

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

Google использовала несколько методов для анализа эффективности менеджеров в рамках Project Oxygen: интервью с сотрудниками, анализ данных по методу «360 градусов» за несколько лет, специальные опросы уходящих из компании сотрудников, оценку поставленных KPI – оценку эффективности деятельности и оценку менеджера сотрудниками. Эти методы позволили получить комплексное представление о том, какие качества руководителей влияют на результаты команды, а какие приводят к снижению эффективности. Многократные проверки данных помогли определить восемь ключевых компетенций, которые теперь используются при обучении и оценке менеджеров в Google.

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

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

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

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

Необходимо: 1) Чётко разделять сценарии создания инцидентов (внешние сбои) и проблем (анализ корневых причин по группе инцидентов); 2) Внедрить отдельные этапы для проблем (диагностика, утверждение решения); 3) Обучить персонал специфике процессов; 4) Настроить ITSM-систему для поддержки уникальных атрибутов проблем (например, этапы обработки); 5) Ввести метрики, отличные от инцидент-менеджмента. Ключевой момент — не создавать запись о проблеме 'для галочки' после инцидента, а запускать полноценный анализ причин.

Эволюция Definition of Done прошла несколько этапов: 1) "Совсем, совсем плохо": работа считается завершенной, когда разработчик заявил, что все работает (на его локальной среде); 2) Улучшенный подход: завершено, когда тестировщик подтвердил работоспособность; 3) Agile-подход: завершено после принятия результата владельцем продукта; 4) DevOps-подход: завершено, когда код успешно работает в продуктивной среде; 5) Финальная ступень: завершено, когда код работает в продуктиве, а вся сборка, тестирование и развертывание выполнены автоматическими средствами. С каждым этапом критерии завершения становятся все более строгими и приближенными к реальным условиям использования продукта.