Эффект Даннинга-Крюгера — это когнитивное искажение, при котором люди с низким уровнем компетентности в определенной области не осознают своей некомпетентности и, наоборот, переоценивают свои способности. В контексте ИТ-отделов это проявляется в том, что разработчики или члены бизнес-команды не понимают глубины своих знаний, что приводит к ошибочным решениям, несоответствию ожиданий и реальности, а также к неэффективным процессам. Например, в тексте описывается случай, когда разработчик заявил: «Да что там разбираться?! Пока не читал. Сели и пишем, чего там», что явно демонстрирует иллюзию компетентности и приводит к снижению качества работы и задержкам.

Продуктовым командам помогают принципы Site Reliability Engineering (SRE), методики разработки, повышающие надёжность, такие как Test-Driven Development (TDD), сквозное автоматизированное тестирование на всех этапах разработки, интеграции и доставки, а также своевременный контроль и устранение технического долга. Эти подходы позволяют минимизировать риски сбоев при внесении изменений, поддерживать эксплуатационные характеристики приложений и сокращать время поставки за счёт автоматизации и строгого контроля качества на каждом этапе.

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

Зоны ответственности нужно определить так, чтобы для каждой задачи была указана конкретная группа, отвечающая за ее выполнение, а также явно прописано, где заканчивается эта зона ответственности и начинается зона другой команды. Например, в случае с CMDB можно закрепить за прикладниками ответственность за создание и поддержание связей с ПО после установки, а за инфраструктурщиками — за настройку сервера и сети. Такая фиксация в регламенте предотвратит споры о том, кто должен был выполнить работу.

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

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

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

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

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

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