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

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

Управление ветками в Git напрямую влияет на успешность CI/CD, поскольку конвейер развёртывания требует определенного уровня дисциплины и стандартизации подходов к работе с кодом. Если команда работает с Git «кое-как», создает десятки долгоживущих веток кода по каждому поводу и имеет постоянные проблемы с мержами, зависящие от одного «очень умного парня», это серьезно затруднит построение эффективного конвейера. У успешных CI/CD практик обычно используются стратегии ветвления, такие как Git Flow или его упрощенные варианты, с четкими правилами о том, когда и как создавать ветки и как их мержить обратно. Долгоживущие ветки затрудняют интеграцию изменений и увеличивают сложность выявления и устранения конфликтов, что противоречит принципам непрерывной интеграции, где изменения должны регулярно объединяться в основную ветку и проверяться автоматически.

Одним из эффективных подходов к освоению новых практик при внедрении CI/CD является планомерное и ритмичное внедрение изменений в рамках выделенного времени, например, так называемого «налога в 20%». Это означает, что команда регулярно выделяет часть своего времени (примерно пятую часть) для постепенного внедрения необходимых технических изменений и улучшений процессов. Важно, чтобы команда сама проходила этот путь, возможно, с временной сторонней помощью, но при этом самостоятельно осваивала новые практики и отказывалась от старых. Такой подход позволяет команде не только технически реализовать изменения, но и глубоко понимать их ценность. Команда сама себе объясняет, почему теперь она делает что-то иначе — это создает внутреннее принятие новых процессов и устойчивость изменений в долгосрочной перспективе. Постепенное внедрение также снижает стресс от масштабных перемен и позволяет корректировать процесс на ходу, основываясь на получаемом опыте.

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

Согласно предложению текста, руководители ИТ при переходе в бизнес могут занимать роль владельца продукта, который зависит от ИТ. Это означает, что руководитель становится бизнес-владельцем продукта, заинтересованным в его успехе настолько, что от продукта зависит P&L (прибыль и убытки), а от P&L - личный бонус руководителя. Такой подход позволяет руководителю ИТ глубоко погрузиться в бизнес-проблемы и лучше понять, как ИТ может поддерживать и развивать бизнес.

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

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

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

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