Управление проблемами существенно влияет на сокращение времени решения инцидентов, хотя часто его значение недооценивают. Если уменьшить общее количество инцидентов путем выявления и устранения их первопричин, это приведет к снижению нагрузки на персонал поддержки. Даже при одинаковой производительности сотрудников, меньшее количество инцидентов существенно снизит среднее время их решения из-за снижения очереди. Например, при 24 инцидентах в день (при условии их одновременного поступления утром) среднее время решения возрастает до 4 часов 10 минут, а при 12 инцидентах - падает до 2 часов 10 минут. Таким образом, управление проблемами влияет на процесс косвенно, сокращая поток инцидентов, что особенно важно с учетом неравномерного распределения инцидентов в течение дня (пиковой нагрузки в определенные часы).

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

Основные причины следующие: 1. Дочерним аутсорсерам не разрешают получать адекватную прибыль или применяется схема cost plus (1-2%), что мотивирует руководство аутсорсера на снижение эффективности для формирования запасов ресурсов. 2. Отсутствие жестких планов коммерческой деятельности на открытом рынке, что лишает аутсорсера стимулов к повышению качества и развития бизнеса, делая его инертным. 3. Вывод в аутсорсинг уникальных услуг, связанных с глубоким пониманием бизнес-процессов материнской компании. Это создает монополию на специализированные и базовые услуги, позволяя манипулировать ценами.

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

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

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

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

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

В тексте упомянуты четыре основные проблемы управления рабочим временем: 1. Объем работы: задач поступает больше, чем есть времени на их выполнение. После перехода из клиентской компании в консалтинг и запуска собственного бизнеса рабочая загрузка возросла до 120-160%, что создало острую нехватку времени. 2. Противоречие интересов: существует разница между тем, что хочется делать (интересная работа) и тем, что необходимо выполнять (обязательные задачи, например, бухгалтерский и налоговый учёт). 3. Приоритизация: рутинные оперативные вопросы занимают всё рабочее время, в то время как на стратегическое развитие компании и личностный рост времени не хватает. 4. Размытость границ: в современных условиях сложно отделить рабочее время от личной жизни. Гибкий график и постоянное погружение в работу приводят к тому, что приходится успевать и профессиональные, и семейные обязанности.

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