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

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

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

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

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

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

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

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

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

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