Продуктовый подход предлагает множество практик и инструментов: Customer Development (CustDev) для понимания потребностей клиентов; Customer Journey Map для визуализации взаимодействия пользователей с продуктом; дорожные карты продуктов для планирования развития; MVP (Minimum Viable Product) для проверки гипотез с минимальными затратами; продуктовые метрики (MAU, DAU, retention) для измерения успеха и принятия решений. Эти инструменты помогают фокусироваться на создании ценности для пользователей, адаптироваться к изменяющимся условиям рынка и принимать обоснованные решения на основании данных. Однако важно применять эти инструменты осознанно и только там, где они действительно уместны.

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

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

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

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

В тексте приведен пример с копанием канавы: владелец процесса определяет задачу ('Надо выкопать канаву вооон от того забора до завтрашнего обеда'), а менеджер процесса отвечает за её выполнение — покупает лопаты, следит за работой копателей и контролирует сроки. Этот пример помогает понять разницу между стратегическим управлением (владелец) и оперативным выполнением (менеджер).

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

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

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

При наличии нескольких заказчиков у одной ИТ-услуги существуют три основных варианта решения: 1) Заключение SLA сразу с несколькими заказчиками, что может серьезно усложнить переговорный процесс и привести к размыванию ответственности бизнес-подразделений; 2) Рассмотрение одного подразделения как заказчика ИТ-услуги, а другого - как потребителя, с заключением SLA только с заказчиком, при этом предполагается, что договоренность с потребителем - это обязанность заказчика, однако это тоже может усложнить переговоры и не всегда устраивает бизнес; 3) Выделение для разных заказчиков отдельных ИТ-услуг, что приводит к росту каталога услуг и необходимости построения более сложных связей между ними, но обеспечивает большую ясность в аллокационной модели. Последний вариант, хотя и создает более сложный каталог ИТ-услуг, часто является наиболее предпочтительным с точки зрения четкого распределения ответственности и аллокации затрат.