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

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

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

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

В комбинированной модели количество необходимых ролей рассчитывается как 2 в степени количества статических атрибутов, а количество атрибутных правил - как 2 в степени количества динамических атрибутов. Например, в системе с 7 статическими и 3 динамическими атрибутами потребуется 2^7 = 128 ролей и 2^3 = 8 атрибутных правил, что значительно меньше 1024 ролей, необходимых в классической ролевой модели с 10 атрибутами. Это объясняется тем, что комбинированная модель разделяет ответственность: статические атрибуты управляются через роли, а динамические - через атрибутные правила.

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

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

Игра Grab@Pizza демонстрирует несколько ключевых аспектов взаимодействия бизнеса и ИТ: важность эффективной работы связки Business-SLM-Change для успеха бизнеса, сложность оценки и приоритизации ИТ-инициатив без их обоснования бизнес-выгодами, необходимость активной позиции технической поддержки в получении информации о предстоящих изменениях, а также использование финансовой системы координат как общего инструмента для согласования позиций бизнеса и ИТ. Игра также показывает, что успех бизнеса во многом зависит от способности ИТ-отдела управлять инцидентами и поддерживать стабильность инфраструктуры.

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

Согласно исследованию Google Project Oxygen, восемь ключевых качеств хорошего менеджера включают: быть хорошим коучем; раздавать ответственность, избегая микроменеджмента; проявлять заинтересованность в успехах сотрудников, включая личные аспекты; быть нацеленным на результативность и достижение целей; обладать навыками эффективной коммуникации; помогать в карьерном росте подчинённых; иметь чёткое видение и стратегию для команды; обладать важными техническими компетенциями, позволяющими поддерживать команду. Эти качества были сформулированы после многократных опросов, анализа данных по методу «360 градусов» и интервью с уходящими сотрудниками, что позволило определить, какие характеристики наиболее существенно влияют на результативность работы подчинённых.