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

Продуктовые команды сталкиваются с двумя основными проблемами при внедрении CI/CD. Первая проблема связана со строгими требованиями конвейера развёртывания к другим областям разработки. Например, для успешного внедрения CI/CD необходима правильная работа с исходным кодом: единство и дисциплина в использовании Git, отсутствие множества долгоживущих веток и проблем с мержами. Также требуется культура создания и постоянного обновления автоматизированных тестов, и если команда до сих пор сомневается в необходимости автотестов, процесс внедрения будет затруднён. Кроме того, конвейер требует частых релизов, в то время как многие команды привыкли к редким выпускам (раз в месяц или квартал), и изменение этой привычки представляет собой отдельную сложность. Вторая проблема — деградация процесса: после первоначального внедрения команды часто начинают отключать части конвейера (например, автотесты), ссылаясь на срочность задач или дедлайны, что в конечном итоге разрушает весь процесс.

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

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

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

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

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

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

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

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