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

Операнд Nj при расчёте First Time Resolution (FTR) для рабочих групп включает два компонента: Cj — количество обращений (инцидентов), обработанных j-той группой и закрытых без рекламаций, и Sj — количество объектов, возвращённых на доработку в эту группу. Таким образом, Nj = Cj + Sj. В знаменатель формулы FTR (Nj) попадают только те обращения, по которым завершена процедура проверки решения, а не просто фактический этап решения задачи.

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

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

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

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

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

Укрупнённые схемы ИТ-систем, показывающие только общие компоненты (например, «ERP-система»), недостаточны для расчёта себестоимости услуг, потому что не учитывают различия в потреблении ресурсов различными группами пользователей. Например, одни пользователи могут постоянно работать в системе, другие использовать её редко для отчётов, третьи — обрабатывать большие объёмы данных. Себестоимость услуг зависит от профиля использования, который определяется бизнес-процессами. Для точного расчёта необходима детализация до уровня подсистем, отражающая, как именно разные пользователи потребляют ресурсы.

На этапе Act цикла Деминга возможны три основных варианта действий: 1) Внедрение успешных улучшений в постоянную практику, если результаты проверки показали положительный эффект; 2) Игнорирование изменений и остановка цикла, если результаты проверки показали, что изменения не привели к улучшению или улучшения незначительны; 3) Запуск нового цикла PDCA с учетом полученного опыта, если результаты посредственные или требуют дальнейших изменений. Этот этап служит точкой принятия решения относительно дальнейшего развития процесса.

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