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

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

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

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

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

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

Для демонстрации недостатка показателя SPI в методике EVM используется пример проекта рытья канавы длиной 20 метров. Изначально с двумя рабочими проект должен был быть выполнен за пять дней (при производительности 2 метра в день на человека). Когда один рабочий заболел и производительность упала вдвое, SPI корректно показывал 50% отставания в начале проекта. Однако по мере завершения работ, даже с задержкой, SPI постепенно приближался к 100%, и на момент окончания проекта становился равным 1, несмотря на то, что проект был завершён с двукратным превышением сроков, что иллюстрирует неспособность SPI адекватно оценивать соблюдение сроков завершённых проектов.

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

AARM представляет собой структурированный подход к измерению успеха продукта через четыре ключевые области: Acquisition (привлечение пользователей и доказательство наличия интереса к продукту), Activation (измерение процесса приобретения и получения возможности использования продукта), Retention (уровень заинтересованности потребителя после первого использования продукта) и Monetization (финансовые метрики, связанные с продуктом и его потребителями). Эта модель позволяет компаниям систематически оценивать различные аспекты успешности продукта. Для потребительских (B2C) продуктов данная модель работает наиболее эффективно благодаря наличию большой пользовательской базы, что упрощает сбор данных и анализ. В государственных и некоммерческих проектах AARM также применим, хотя метрики монетизации могут быть менее важны, а акцент смещается на измерение пользовательского путешествия и удовлетворенности. В B2B и инховз-продуктах применение AARM сложнее из-за ограниченной пользовательской базы и различий между покупателем и конечным пользователем, однако основные принципы модели сохраняются.

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