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

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

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

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

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

Альтернативный метод оценки эффективности потока заключается в проведении практического упражнения: представить поток и для каждого этапа процесса прикинуть, сколько времени задача проводит на этом этапе и сколько времени на ней фактически выполняется работа. Суммируя эти показатели и разделив суммарное время работы на суммарное время всего процесса, можно получить оценку эффективности потока. Хотя это не точный расчет, такие оценки часто удивляют команды, показывая реальный уровень эффективности в 10-25%, в то время как субъективные ощущения предполагают гораздо более высокие показатели (75-80%). Такой подход помогает выявить проблемные зоны, даже не обладая точными данными.

Оценка эффективности потока обычно предполагает экспертное приближение: команды интуитивно или на основе наблюдений определяют, сколько времени задачи проводят в активной работе и сколько времени в ожидании. Точный расчет же требует сбора и анализа конкретных данных по времени каждой задачи. В реальности большинство попыток «точного» расчета Flow Efficiency оказываются упрощенными оценками из-за сложности точного измерения Touch Time и Time in Process. Как правило, результаты оценки дают более реалистичные и полезные для команды показатели (в районе 10-25%), тогда как «точные» расчеты могут приводить к абсурдно высоким значениям (90% и более), не отражающим действительное положение дел.

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

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

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