Выделяют четыре уровня командной осознанности: 1) Детский сад - недавно сформированная группа, не способная самостоятельно выявлять проблемы и решать их, где основная работа организуется извне; 2) Пубертат - команда, ощутившая свободу, но не осознающая полностью ответственности, способная к самоорганизации против «внешнего врага», но плохо идентифицирующая причины проблем; 3) Яркая молодость - зрелая самоорганизованная команда с устоявшимися партнерскими отношениями, эволюционирующим рабочим процессом и конструктивным подходом к решению конфликтов; 4) Зрелость - команда как агент изменений на уровне компании, контролирующая свой рабочий процесс и несущая ответственность за продукт на уровне P&L, стремящаяся расширять зону влияния.

Цели для каждого ITSM-процесса формулируются через его уникальное назначение. Например, для управления инцидентами цель: 'Сократить время устранения инцидентов на 10% к концу квартала'. Для управления проблемами: 'Уменьшить количество повторяющихся инцидентов на 15% через внедрение анализа корневых причин'. Все цели должны быть измеримыми, конкретными и напрямую влиять на качество ИТ-услуг, соответствуя принципам SMART и ориентируясь на потребности конечных пользователей.

Бизнес-бенефиты (раздел Business benefits в нижнем левом квадранте) должны отвечать на вопрос, как результаты проекта будут полезны бизнесу в целом. Нужно указать, на какие вопросы руководства компании позволит ответить внедрение проекта, какие проблемы бизнеса будут решены. Например, можно указать: «Численные KPI для оценки качества операционной деятельности ИТ-подразделения», «Сокращение времени простоя системы за счет улучшенного управления инцидентами», «Повышение удовлетворенности клиентов за счет быстрого реагирования на запросы». Важно показать конкретную пользу для бизнеса, а не только для ИТ-отдела.

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

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

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

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

Эффект Даннинга-Крюгера — это когнитивное искажение, при котором люди с низкой компетентностью в какой-либо области склонны переоценивать свои знания и навыки. В профессиональной среде это проявляется тем, что сотрудники или команды уверены в наличии у них современных практик и инструментов, хотя на самом деле их реализация неполная или устаревшая. Например, команда программистов может считать, что у них есть конвейер CI/CD, но фактически развертывание происходит раз в две-три недели с множеством ручных операций. Искажение восприятия границы нормального создает ситуацию, когда то, что для одних компаний является стандартом, для других кажется излишеством или нереализуемым.

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

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