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

Уровень влияния инцидента напрямую определяет его вес в системе расчета приоритета проблемы. Инциденты с высоким уровнем влияния (например, "Критичный") вносят больший вклад в суммарный вес проблемы, что повышает её приоритет. Точное определение уровня влияния является ключевым фактором для корректной расстановки приоритетов.

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

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

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

Общие задачи включают: 1) Четкое разграничение ответственности, 2) Установление параметров качества выполнения работ, 3) Определение принципов передачи работ между группами, 4) Внедрение централизованного контроля. Эти меры помогут избежать ситуаций, когда каждая группа уверена, что выполнила свою часть работы, но общий результат не достигнут.

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

Для объяснения используется пример заказа торта на день рождения: Output — сам торт, который готовит и предоставляет пекарня; Outcome — это восторг именинника и удовлетворённость гостей, которые съели торт. Также применяются другие примеры: Output таксиста — спортивный автомобиль, а Outcome — быстрая и комфортная доставка пассажира до места назначения.

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

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