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

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

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

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

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

SLA (Service Level Agreement) означает Соглашение об уровне обслуживания (сервисное соглашение). Это документ, в котором фиксируются обязательства одного подразделения перед другим по количественным и качественным показателям предоставляемых услуг. SLA определяет, что конкретно должно быть поставлено, в какие сроки, в каком объеме и качестве. Такие соглашения изначально применялись в ИТ-сфере между ИТ-отделом и бизнес-подразделениями, но сегодня распространились на многие другие области бизнеса.

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

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

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

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