В гибких методологиях Scrum и SAFe роль руководителя проекта отсутствует, так как ее функции равномерно распределены между другими ролями. В Scrum ключевые обязанности перераспределяются между владельцем продукта, который отвечает за приоритизацию и ценность продукта, и скрам-мастером, который фокусируется на процессах и удалении препятствий для команды. Методология SAFe (Scaled Agile Framework) устанавливает собственную иерархию работ и ответственности через уровни Epic - Capability - Feature - Story, где каждому уровню соответствуют свои ответственные лица и методы работы. Таким образом, традиционный набор задач руководителя проекта в гибких подходах естественным образом делегируется разным ролям без необходимости выделять отдельного координатора проекта.

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

Парадигма ITSM традиционно воспринималась как более формализованный и структурированный подход, тогда как DevOps и Agile фокусируются на гибкости и скорости. Однако современные версии ITSM (такие как ITIL 4) активно интегрируют принципы Agile и DevOps, сочетая структурированное управление услугами с гибким подходом к развитию ИТ-систем. Это проявляется в упоре на сотрудничество между командами, непрерывное улучшение, автоматизацию процессов и сокращение времени вывода новых сервисов на рынок. Современное понимание ITSM не противоречит Agile и DevOps, а предоставляет рамки, в которых эти подходы могут эффективно функционировать, сохраняя контроль над качеством и стабильностью услуг.

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

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

Определение значения N для расчёта метрик FLR и FCR является сложной задачей, потому что далеко не все обращения возможно разрешить на первой линии. Часть заявок физически невозможно решить удалённо, часть нельзя обрабатывать из-за ограничений регламентов или политик, а часть требует уровня доступа, которым не обладают сотрудники первой линии. Если учитывать все обращения в расчёте, это приведёт к искажению результатов, так как первая линия не может влиять на те обращения, которые технически не могут быть разрешены на её уровне. Это делает показатель плохо применимым для объективной оценки эффективности работы первой линии.

Полезные метрики включают: скорость выполнения задач (velocity), время цикла, время выполнения (lead time), процент завершенных функций, соотношение исправлений ошибок к новым функциям, коэффициент повторного использования кода. Важно, чтобы метрики отражали именно цели и ценностя команды и бизнеса, а не были формальными. Метрики должны быть простыми для понимания и непротиворечивыми по сбору данных.

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

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

Чтобы избежать постоянной смены приоритетов, работу следует организовывать иначе. Необходимо работать с небольшими порциями задач, так как чем меньше средний размер задачи, тем ниже вероятность попасть в ситуацию, когда потребуется смена приоритетов. Следует отказаться от менять приоритеты задач и проектов, к которым уже приступили - такой инструмент управления должен быть исключен. Можно организовать работу четко, ритмично и предсказуемо, зная среднюю скорость работы потока задач. Если проект становится нежизнеспособным, лучше разрешить ему 'умереть', а не отнимать ресурсы у других проектов. Важно не пытаться решать проблемы через 'революции' и 'цифровые трансформации' в условиях уже существующего хаоса, а сначала создать устойчивую основу управления. Главный принцип: при рассмотрении смены приоритета следует фокусироваться не на том, что поднимается вверх, а на том, что остальное будет автоматически сдвинуто вниз.