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

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

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

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

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

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

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

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

Для расчета общего интегрального показателя при большом числе KPI рекомендуется применять многоступенчатый подход. Сначала разбивают все KPI на логические группы, для каждой из которых рассчитывают отдельный интегральный показатель (используя подходящий метод агрегирования). Затем полученные групповые показатели объединяют для формирования общего интегрального показателя. Например, при оценке качества множества услуг можно создать три группы: mission-critical, business-critical и обычные услуги. Для каждой категории рассчитывают свой интегральный показатель, после чего общий результат получают через среднее арифметическое или геометрическое (с возможным применением весовых коэффициентов, отражающих важность каждой группы).

После того как команда смогла достичь стабильной частоты релизов раз в две недели вместо запланированных еженедельных, существуют четыре основных сценария: 1) Согласиться с текущим положением как улучшением по сравнению с прошлым и продолжать пассивно пытаться улучшить ситуацию, но не предпринимая активных действий. 2) Продолжать активно работать над улучшением процесса, выявляя корневые причины и применяя изменения. 3) Зафиксировать текущую частоту как новую норму и планировать дополнительные внеплановые релизы. 4) Установить амбициозную цель ежедневных релизов, используя принципы DevOps и идя на радикальные изменения в процессах.