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

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

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

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

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

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

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

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

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

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