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

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

Лидерство-служение (servant leadership) - это подход к руководству, при котором лидер ставит команду на первый план, создавая условия для максимальной реализации потенциала членов команды. Лидер-слуга фокусируется на потребностях других членов команды больше, чем на собственных. Он признает интересы других людей, предоставляет необходимую поддержку для выполнения работы и достижения целей, вовлекает в процесс принятия решений, где это нужно, и формирует чувство общности внутри команды. Концепция была описана Робертом Гринлифом в 1970 году в эссе «Слуга как лидер» и противоречила тогдашним представлениям о менеджменте.

Аспект 'Потоки создания ценности и процессы' относится как к системе создания ценности в целом, так и к предоставлению отдельных услуг. Он включает все виды деятельности, рабочие процессы, средства управления и процедуры для достижения согласованных целей. Данный аспект рассматривает, как интегрировать и координировать различные части бизнеса для повышения ценности продуктов и услуг через создание операционной модели более высокого уровня - цепочки создания ценности. Поток создания ценности (value stream) - это последовательность шагов, которые предпринимает организация для создания и предоставления продуктов и услуг потребителю. Он представляет собой комбинацию видов деятельности цепочки создания ценности. Процессы - это набор взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы, и они являются частью потоков создания ценности. Например, поток создания ценности для поддержки пользователей может включать практики управления инцидентами, службы поддержки, управления проблемами и другими процессами. Важно рассматривать процессы не изолированно, а как последовательность действий в потоке создания ценности, и определять такие потоки для каждого продукта и услуги.

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

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

Система постоянного улучшения на основе ITIL (Continual Service Improvement) строится по следующему алгоритму: во-первых, определите ключевые показатели эффективности (KPI) для каждой ИТ-услуги, ориентированные на бизнес-результаты. Затем регулярно (ежемесячно или ежеквартально) проводите анализ данных по этим KPI, сравнивая с целевыми значениями. Обеспечьте сбор обратной связи от всех заинтересованных сторон - бизнес-подразделений, пользователей и технических специалистов. Создайте циклический процесс из четырех этапов: Measure (измерение текущего состояния), Analyze (анализ данных и выявление проблем), Improve (внедрение улучшений), Review (оценка результатов изменений). Назначьте ответственных за CSI из руководителей ИТ-подразделений и бизнес-лидеров. Проводите регулярные сессии по выявлению возможностей для улучшения, используя техники мозгового штурма и анализ основных причин. Внедрите систему приоритизации улучшений на основе их влияния на бизнес и сложности реализации. Убедитесь, что результаты улучшений измеряются и доводятся до сведения всех заинтересованных сторон, что создаст мотивацию для дальнейших улучшений. Важно, чтобы процесс CSI был частью повседневной культуры организации, а не разовым проектом.

Полная автоматизация в Definition of Done согласно DevOps дает следующие преимущества: 1) Снижение ошибок, вызванных человеческим фактором; 2) Ускорение циклов разработки и развертывания; 3) Повышение надежности и воспроизводимости процессов; 4) Раннее обнаружение и исправление дефектов; 5) Упрощение процесса масштабирования; 6) Повышение удовлетворенности команды за счет уменьшения рутинных операций; 7) Возможность непрерывного улучшения продукта через регулярные небольшие обновления. Такой подход позволяет фокусироваться на создании ценности для пользователей, а не на организационных и технических сложностях процесса доставки.

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

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