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

Коммуникация между бизнесом и ИТ-отделом часто страдает из-за различий в восприятии компетенций и ожиданий. Бизнес зачастую судит о качестве разработчиков по внешним признакам (например, стереотипный образ «типичного» разработчика в растянутом свитере), а не по реальным навыкам. С другой стороны, ИТ-специалисты могут не уметь в простой форме объяснить бизнесу сложные технические аспекты, что усугубляется эффектом Даннинга-Крюгера. В тексте приводится пример, когда новый сотрудник, нанятый бизнесом, отказался изучать документацию, что привело к замедлению разработки. Недостаток общего понимания целей, терминологии и процессов ведет к несоответствию ожиданий и результатов.

Заказчики не понимают такой компромисс, потому что ожидают от ITSM гарантии времени разработки новых функций и улучшений. Для них SLA (соглашение об уровне услуг) кажется бессмысленным, если поставщик ИТ-услуг не может обеспечить улучшение существующих возможностей или гарантировать сроки новых разработок. Они задают вопросы вроде: «Зачем мне SLA, если текущая функциональность уже работает, а вы не можете гарантировать её улучшения?»

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

Команда на уровне «Яркая молодость» представляет собой зрелую самоорганизованную команду (не обязательно работающую по Scrum). Для нее характерны устоявшиеся партнерские отношения с заказчиками и внешним миром, эволюционирующий рабочий процесс, большое количество инициатив и экспериментов, зрелый подход к решению конфликтов. Команда учится правильно следовать первому принципу Agile Manifesto: понимает, что изменение требований приветствуется не как повод переписать все заново, а как возможность для конструктивного диалога и серьезного исследования. Роль лидера на этом этапе - быть «мотором-метрономом», поддерживающим скорость и ритмичность работы. Важно помогать команде развивать продуктовые компетенции, чтобы она могла быть полноправным партнером для заказчика и говорить с ним на одном языке. Лидер-слуга на этом уровне востребован на 100%.

Доверительный интервал для результатов опроса можно рассчитать в MS Excel 2010 следующим образом: стандартное отклонение вычисляется с помощью функции СТАНДОТКЛОН.В(...), доверительный интервал получается вызовом функции ДОВЕРИТ.СТЬЮДЕНТ(a; S; n), где a - уровень значимости, S - стандартное отклонение, n - размер выборки, а коэффициент Стьюдента - функцией СТЬЮДЕНТ.ОБР.2Х(a; n-1). Это позволяет определить границы, в которых с заданной вероятностью будет находиться истинное среднее значение всей генеральной совокупности.

Приоритет проблемы определяется суммой весов привязанных к ней инцидентов, где вес каждого инцидента зависит от его уровня влияния. Проблема с инцидентами высокого уровня влияния (например, "Критичный") получает больший приоритет, чем проблема с множеством инцидентов низкого уровня влияния (например, "Низкий"). Однако, если количество "Низких" инцидентов становится достаточным, их суммарный вес может превысить вес нескольких критических. Точность расстановки приоритетов зависит от корректного определения весов инцидентов и уровней влияния.

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

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

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