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

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

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

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

ITIL рекомендует определять приоритеты изменений через конкретные критерии: оценку влияния на бизнес и жёсткие временные рамки. Например, если бизнес требует реализовать изменение к определённому сроку («завтра»), это напрямую задаёт временные ограничения. Второй критерий — степень влияния изменения на ключевые процессы: если отсутствие правки приведёт к остановке бизнес-операций, это автоматически получает высший приоритет. Такой подход исключает субъективность и позволяет выстраивать очередь изменений на объективной основе, избегая злоупотребления термином «срочность».

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

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

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

Срочное изменение в ITIL v2 — это любое изменение, которое необходимо выполнить настолько быстро, что часть стандартных этапов процесса управления изменениями для него либо пропускается, либо выполняется в сокращенном виде, либо проводится задним числом. Например, пропуск тестирования в тестовой среде (тестирование проводится в продуктивной среде), сокращенная процедура согласования или оформление операций после фактического внедрения. При этом причина срочности не ограничивалась в ITIL v2: это могло быть как устранение ошибки, так и реализация срочной бизнес-потребности.

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