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

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

Метод анализа 5-Why's предполагает многократное задавание вопроса «почему» (пять раз) для выявления корневой причины проблемы. В процессе управления проблемами ITIL метод позволяет последовательно углубляться в анализ каждой последующей причины предыдущего явления. Например, при анализе неработающего принтера такой подход выявляет цепочку: неисправный нагревательный элемент → перепады напряжения → нестабильная работа подстанции → её устаревание → отсутствие модернизации. Цель метода — определить первопричину, хотя на практике часто останавливаются на том этапе, где обнаруживается граница зоны влияния поставщика услуг.

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

На уровне «Яркая молодость» лидер выступает в роли «мотора-метронома», поддерживающего скорость и ритмичность работы команды. Лидер-слуга на этом этапе наиболее востребован (на 100%), помогая команде поддерживать устоявшиеся партнерские отношения с заказчиками, развивать эволюционирующий рабочий процесс и конструктивно решать конфликты. Важная задача лидера - способствовать развитию у команды продуктовых компетенций, чтобы она могла стать полноправным партнером для заказчика и вести диалог на одном языке. Лидер помогает команде правильно интерпретировать первый принцип Agile Manifesto, понимая, что изменение требований приветствуется не как повод переписать все заново, а как возможность для конструктивного диалога и серьезного исследования. На этом уровне лидер фокусируется на усилении команды, а не на управлении ею директивно.

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

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

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

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

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