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

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

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

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

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

Использование метрик FLR (First Line Resolution) и FCR (First Contact Resolution) в работе службы поддержки даёт несколько ключевых преимуществ. Оно помогает увеличить количество обращений, разрешаемых на первой линии, что приводит к снижению стоимости обработки обращений за счёт использования более дешёвых ресурсов первой линии. Кроме того, это повышает удовлетворённость пользователей, так как сокращается время обработки обращений – отсутствие эскалации на вторую или третью линию означает, что пользователь не тратит время на ожидание реакции других специалистов. Эти метрики также позволяют выявлять слабые места в работе первой линии и планировать обучение персонала.

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

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

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

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