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

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

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

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

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

Связь обеспечивается через этапы: бизнес-заказчик с помощью BRM формирует Change proposal, который содержит бизнес-обоснование и стратегическую цель, затем после утверждения разрабатываются конкретные RFC, детализирующие технические изменения. BRM выступает как посредник, гарантирующий соответствие конечного результата изначальным бизнес-требованиям и поддержку заказчика на всех этапах.

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

Управление рисками и постоянное совершенствование услуг (CSI) тесно связаны. Согласно Чарльзу Бетцу, обе сущности (риск и зона улучшения) требуют отслеживания и часто включают эквивалентные активности по исследованию. На практике деятельность в рамках непрерывного совершенствования часто приводит к идентификации новых рисков, а идентифицированные риски, в свою очередь, запускают новые циклы улучшений в рамках CSI. Это создает взаимоусиливающую связь, где управление рисками становится неотъемлемой частью процесса постоянного совершенствования услуг, обеспечивая более обоснованные управленческие решения и более предсказуемые результаты.

ITIL и ISO/IEC 20000 ориентированы на управление ИТ-услугами с точки зрения потребителя, где ключевым аспектом является обеспечение функционирования системы для пользователя в нужный момент. ГОСТ 27.002-89 и ГОСТ Р 53480-2009 разработаны для технической надежности оборудования, где акцент делается на внутренние параметры системы. Разница обусловлена предметными областями: ИТ-услуги требуют учета внешних процессов, а техническая надежность — внутренних характеристик компонентов.

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