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

Показатель SPI (Schedule Performance Index) из методики EVM не подходит для оценки соблюдения сроков завершённых проектов, так как по окончании проекта, даже с большим запозданием, весь первоначальный объём считается освоенным, и значение SPI автоматически становится равным единице. Это приводит к тому, что SPI не отражает реальное отставание по срокам выполнения проекта. Например, при измерении проекта рытья канавы, когда работы завершаются с задержкой, SPI в конце проекта станет 100%, несмотря на то, что работа была выполнена дольше запланированного срока.

Успешность применения метода MBO в ITIL зависит от трех основных факторов: качества постановки целей верхнего уровня топ-менеджментом, которые затем декомпозируются на цели следующих уровней; качества анализа текущей ситуации и контекста, в котором организация должна достигать поставленных целей (часто с применением SWOT-анализа); наличия достоверной информации об операциях, позволяющей измерить текущее состояние и прогресс в совершенствовании, основываясь на реальных данных.

Disaster Recovery Institute International (DRII) выделяет 10 компонентов управления непрерывностью: запуск программы и управление, управление рисками и контроль, анализ влияния на бизнес-процессы, стратегии непрерывности бизнеса, реагирование в случае нештатной ситуации, внедрение плана и документирование, обучение и поддержание осведомленности, испытания, аудит и оценка плана, кризисные коммуникации, взаимодействие с внешними сторонами.

Термин "Гарантия" в бытовом смысле обычно связан с гарантийным периодом на товар или правом на бесплатный ремонт. Однако в управлении услугами по ITIL Warranty имеет более широкое и системное значение. Бытовое понимание гарантии не учитывает комплексный подход к оценке пригодности услуги к использованию через четыре компонента: доступность, мощность, безопасность и непрерывность. В управлении услугами важно не только то, что проблема будет исправлена после возникновения, но и то, как часто возникают проблемы, насколько они влияют на пользователей, как они предотвращаются, что критично для создания ценности услуги. Простое понимание гарантии как возможности бесплатного ремонта не позволяет полноценно управлять качеством и надежностью услуги.

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

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

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

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

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