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

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

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

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

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

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

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

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

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

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