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

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

Лучше всего подходят метрики, которые сложно повлиять искусственно. Например, вместо количества закрытых задач стоит учитывать удовлетворенность клиентов, качество решений или объем повторных обращений. Также полезно комбинировать автоматизированные данные с обратной связью от пользователей через опросы и интервью, чтобы получить более полную и объективную картину.

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

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

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

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

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

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

Содержание процесса управления релизами в подразделении разработки/сопровождения включает следующие этапы: анализ требований к изменению информационной системы, разбивку требований на логические группы, планирование с учетом политик релизов, организацию разработки, квалификационное тестирование и выпуск (передачу к внедрению в продуктивную среду). На выходе этого процесса формируется релиз, который затем передается в подразделение эксплуатации для внедрения через процесс управления изменениями.