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

В современных ИТ-организациях, особенно при переходе на гибкие методы разработки, роль руководителя проектов существенно меняется. В простых случаях (до 5 команд, десятков сотрудников) управление проектами может быть избыточным или даже вредным. В крупных организациях (500+ сотрудников, сотни ИТ-систем) существует пять основных областей, где может быть полезен руководитель проектов: управление работами команды, построение работы команды, управление проектом создания продукта, управление результатами на более высоком уровне, и построение взаимодействия между старым и новым мирами. Однако ценность руководителя проектов проявляется главным образом в последней области - координации между традиционными и гибкими методологиями, особенно в бимодальных ИТ-средах, где часть систем переводится на новые методы, а часть остается в традиционном режиме работы.

Для сокращения среднего времени решения инцидентов необходимо проанализировать этапы их обработки, выявить узкие места и оптимизировать процессы. Согласно ITIL методологии, стоит использовать подход Expanded incident lifecycle для детализации этапов решения инцидента и поиска возможностей для ускорения на каждом этапе. Также критически важно внедрять процесс управления проблемами, так как его влияние на сокращение количества инцидентов часто недооценивают. Даже при одинаковой производительности персонала, сокращение общего числа инцидентов благодаря управлению проблемами существенно снизит среднее время решения, так как уменьшает очередь и перегрузки, связанные с неравномерным поступлением инцидентов.

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

RBAC (Role-Based Access Control) — это ролевая модель управления доступом, в которой доступ предоставляется не напрямую к объектам и операциям, а к определённым группам прав, объединённым по функциональному признаку (например, 'администратор системы', 'пользователь модуля N'). Основные преимущества RBAC по сравнению с другими моделями: наглядность (права структурированы по бизнес-ролям), простота назначения (администраторы работают с целыми группами прав, а не с отдельными объектами), соответствие бизнес-процессам и организационной структуре, возможность запрета использования смежных ролей для разделения полномочий, иерархия ролей (построение связок 'родительская-дочерняя') для наследования прав. В отличие от мандатной модели (MAC), где доступ зависит от уровня допуска пользователей и классификации информации, RBAC не требует жёсткой привязки к грифам секретности, что обеспечивает большую гибкость. В отличие от дискреционной модели (DAC), где настраиваются разрешения для каждого пользователя отдельно, RBAC избегает избыточной детализации и упрощает администрирование за счёт группировки прав в роли.

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

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

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

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

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