Проблему карьерного роста можно решить, создав параллельные карьерные треки: технический и менеджерский. В техническом треке продвижение может основываться на экспертных способностях, влиянии на качество кода, наставничестве и способности решать сложные технические проблемы, а не на управленческих обязанностях. Введение ступеней вроде Senior Developer, Staff Engineer, Principal Engineer позволяет признавать техническую экспертизу без необходимости перехода к управлению людьми. Также важно создавать возможности для неформального лидерства, где влияние определяется компетентностью и мудростью принятия решений, а не должностными полномочиями.

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

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

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

ITIL 4 не упоминает приоритизацию в процессе решения инцидента (Incident handling and resolution), потому что она переквалифицирована из отдельного шага процесса в фактор успеха всей практики управления инцидентами. Приоритизация остается важной, но теперь рассматривается как более широкая концепция, которая необходима для достижения основной цели практики — минимизации негативного влияния инцидентов. Поскольку приоритизация может происходить многократно и на разных этапах работы с инцидентами, её нецелесообразно ограничивать одним отдельным шагом в процессе. Вместо этого она представляется как элемент, который требуется для эффективного выполнения всей практики в целом.

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

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

Ценность, которую создает продукт, следует считать разнородной и требующей разделения на разные потоки, если она различается по своей природе для разных групп потребителей или в разных контекстах использования. Критерием является различие в том, как потребитель воспринимает и получает эту ценность. Например, в Twitter выделяются два разных вида ценности: 'легко и удобно коммуницировать, делиться информацией' (для обычных пользователей) и 'получить устойчивую конверсию заинтересованной аудитории в выручку' (для компаний). Эти ценности принципиально отличаются по характеру и измеряются разными показателями (аудитория/активность против финансовых результатов), что указывает на необходимость разделения на разные потоки ценности.

Автоматизация управлении доступом решает проблему ручной обработки запросов и длинных цепочек согласований. Важно выбирать решения с широким охватом задач процесса, при этом оптимально использовать специализирование системы Service Desk для обработки запросов вместо построения отдельных конвейеров в IDM-системе. Автоматизация позволяет сократить время обработки запросов до требуемых бизнесом сроков, снизить количество ошибок, обеспечить прозрачность и аудируемость процесса. Для успешной автоматизации часто требуется помощь внешних экспертов в интеграции различных систем и создании коннекторов к управляемым ИТ-ресурсам, особенно когда внутренних компетенций недостаточно.

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