В области IT эффект Даннинга-Крюгера проявляется в нескольких аспектах. Например, существуют проекты разработки программного обеспечения, где команды считают нормальным писать «лучший в Галактике код», но при этом не могут выйти на продуктивную эксплуатацию в течение 3-5 лет. Есть команды, которые выпускают релизы раз в месяц, игнорируя современные практики ежедневных релизов. Также встречаются разработчики, которые не понимают CI/CD и настаивают на ручном тестировании, администраторы, считающие всех разработчиков некомпетентными, и консультанты, которые без глубокого понимания процитируют Agile-литературу. Все эти ситуации указывают на то, что многие профессионалы неадекватно оценивают свои знания и навыки.

Для предотвращения деградации CI/CD процесса после внедрения необходимо установить четкие правила, что 'назад пути нет, а половины конвейера не бывает'. Следует договориться, что конвейер работать должен всегда, без исключений, и нет других способов доставки изменений в эксплуатационную среду кроме как через него. Нужно удалить административные права на объекты инфраструктуры у всех, кроме конвейера. Рекомендуется стремиться к полному Continuous Deployment вместо менее совершенных вариантов (CI или CD), чтобы убрать 'волшебный рубильник', когда человек принимает решение о ручном релизе. Это означает, что все изменения, прошедшие через конвейер, автоматически попадают в рабочую среду без ручного одобрения. Такой подход не оставляет места для временного отключения части системы, например, автотестов, и гарантирует устойчивость процесса в долгосрочной перспективе.

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

ISO 22301:2012 (Societal security – Business continuity management systems – Requirements) - это основной международный стандарт по управлению непрерывностью бизнеса, который статус международного стандарта получил в 2012 году. Ранее, до принятия в качестве международного стандарта, он был известен как BS 25999 (британский стандарт). Стандарт вводит важную терминологию и предъявляет требования к планированию, проектированию, внедрению, сопровождению, оценке и постоянному совершенствованию системы управления непрерывностью бизнеса.

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

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

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

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

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

Ассоциация DASA выделяет шесть основных принципов DevOps: 1) Деятельность должна быть ориентирована на заказчика (Customer-Centric Action), включая постоянные инвестиции в продукты и услуги, обеспечивающие максимальную удовлетворённость заказчика, короткие циклы обратной связи и деятельность в духе Lean-стартапов с постоянными инновациями. 2) Ориентация на конечный результат (Create with the End in Mind), что означает отказ от водопадного подхода и процессно-ориентированных моделей в пользу продуктовой ориентации, когда все сотрудники понимают, что создают продукты для реальных заказчиков. 3) Ответственность от начала до конца (End-To-End Responsibility), подразумевающая, что команды отвечают за полный жизненный цикл продукта от концепции до вывода из эксплуатации. 4) Кросс-функциональные автономные команды (Cross-Functional Autonomous Teams), которые должны быть полностью независимыми на протяжении всего жизненного цикла, иметь сбалансированный набор компетенций и T-образные профили специалистов. 5) Постоянное совершенствование (Continuous Improvement), включающее адаптацию к изменяющимся обстоятельствам, сокращение потерь, оптимизацию скорости и затрат, упрощение поставки и постоянное совершенствование продуктов и услуг через экспериментирование и обучение на ошибках. 6) Автоматизируйте всё, что можете (Automate Everything You Can), что охватывает автоматизацию процессов разработки программного обеспечения (непрерывная поставка, непрерывная интеграция, непрерывное развёртывание) и всего инфраструктурного ландшафта (инфраструктура как код).