На этапе перехода услуги в эксплуатацию (Service Transition) основные обязанности BRM включают обеспечение адекватного уровня вовлечения заказчика и пользователей в процесс. BRM должен гарантировать участие заказчика в тестировании, передаче/приемке услуги в эксплуатацию и, при необходимости, обучении. На этом этапе заказчик часто стремится устраниться, считая свою работу завершенной, но это может привести к отклонению от правильного направления и несоответствию ожиданиям. BRM участвует в координации действий между заказчиком и сервис-провайдером, обеспечивая правильное внедрение услуги и соответствие требованиям. BRM также следит за тем, чтобы процесс перехода проходил гладко и все стороны были хорошо информированы о своих задачах и ответственности.

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

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

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

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

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

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

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

Для изучения путешествий применяют картографирование клиентских путей (customer journey mapping), наблюдение за реальными сценариями использования, глубинные интервью с акцентом на контекст и мотивы, анализ поведенческих данных (например, кликов в приложении), и составление persona-клиентов. Важно фиксировать не только точки взаимодействия, но и эмоциональные реакции, барьеры и неочевидные потребности. Также используют A/B-тестирование гипотез улучшений и сбор обратной связи через инструменты типа встроенных опросов в продукте. Ограничение таких техник в том, что они отражают лишь часть реального опыта, поэтому требуется постоянная итерация.

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