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

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

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

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

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

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

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

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

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

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