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

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

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

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

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

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

Задачи процесса управления доступностью пересекаются со следующими процессами: создание плана доступности может быть частью стратегического плана инфраструктуры (SIP) или пересекаться с управлением мощностями; диагностика и решение инцидентов и проблем относится к их специализированным процессам; оценка влияния изменений на доступность является задачей управления изменениями; отслеживание уровня доступности и анализ отклонений входят в зону ответственности SLM. Это вызывает вопрос о уникальности задач управления доступностью как отдельного процесса.

Баланс между высоким уровнем контроля изменений (Change Control Level) и необходимостью ускорения процессов достигается через оптимизацию размера и частоты релизов. Высокий Change Control Level обычно приводит к увеличению времени обработки изменений (Process Time), поскольку требует тщательного планирования, оценки и тестирования. Однако, переход к частым малым релизам (высокий Release rate и низкий Release size) позволяет поддерживать высокий уровень контроля без значительного увеличения рисков и времени вывода решений. Частые малые внедрения уменьшают сложность каждого отдельного изменения, что делает процесс контроля более эффективным. Также повышение Change capability за счет накопленного опыта и автоматизации стандартных процессов (Standardization/automation) позволяет поддерживать высокий Change Control Level при снижении Process Time. В итоге, вместо жесткого выбора между контролем и скоростью, организация может достичь состояния, где высокий уровень контроля сочетается с высокой скоростью внедрения благодаря оптимизации процессов и непрерывному обучению.

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

Пять основных областей применения руководителя проектов при переходе к гибким методам: 1) Управление работами команды - но эта роль обычно отводится владельцу продукта; 2) Построение работы команды - обычно осуществляется лидером команды или agile-коучем; 3) Управление проектом создания продукта - временная роль, необходимая только до создания MVP; 4) Управление результатами на более высоком уровне - в методологиях типа SAFe для этого разработаны другие механизмы; 5) Построение взаимодействия между старым и новым мирами - именно в этой области руководитель проектов может принести наибольшую ценность, обеспечивая координацию, синхронизацию, развитие и сопровождение процессов между традиционными и гибкими методологиями, особенно в бимодальных ИТ-средах.