Бэклог-мясорубка — это условный (а иногда реальный) механизм классификации задач, поступающих в поток создания ценности. Задачи оцениваются на предмет их влияния на общий результат команды, после чего распределяются в соответствующие процессы обработки: конвейеры развития, исследованиям, проверке гипотез. Цель — обеспечить, чтобы каждая задача направлялась в оптимальный для нее процесс, сохраняя целостность достижения общей ценности.

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

Чтобы предотвратить выполнение работы подчиненными под чужим руководством без контроля со стороны прямого руководителя, необходимо: 1. При работе с RACI- или RASCI-матрицей четко определить и зафиксировать, кто является ответственным за организацию работы (это может отличаться от ответственного за конечный результат). 2. Если вы находитесь в позиции S (Supports - поддерживающий), рекомендуется делегировать непосредственное исполнение задачи, сохранив за собой роль в информационном потоке (I - Informed) или консультативную роль (C - Consulted). 3. Убедиться, что для всех задач, в которых участвуют ваши подчиненные, определены точки контроля, через которые вы сможете отслеживать прогресс и качество выполнения. 4. Установить четкие правила информирования о ходе выполнения задач, даже если непосредственное руководство осуществляется другим менеджером. Это гарантирует, что вы будете в курсе происходящего и сможете вмешаться при необходимости, не позволяя ситуации выйти из-под контроля.

Подходы управления цепочками поставок могут быть эффективно применены к непрофильным ресурсам в компании, которые не формируют основную ценность для потребителя, но необходимы для поддержки основных потоков. Поскольку многие ресурсы (например, услуги по обеспечению compliance или тестированию надежности инфраструктуры) могут рассматриваться как самостоятельные отчуждаемые результаты, их можно приобретать у третьих сторон, аналогично тому, как это делается в традиционных цепочках поставок. Для этого необходимо: 1) четко определить требования к качеству и количеству ресурса; 2) разработать метрики для измерения соответствия поставок этим требованиям; 3) установить надежные каналы коммуникации с поставщиками; 4) создать механизмы управления запасами ресурсов, чтобы обеспечить их постоянную доступность без излишков; 5) внедрить систему оценки и мониторинга поставщиков для поддержания качества поставок на необходимом уровне. Применение подходов управления цепочками поставок позволяет компании фокусироваться на своем основном бизнесе, снижая издержки и повышая гибкость в управлении непрофильными функциями.

В контексте зрелости процессов «гарантия» подразумевает уверенность в том, что процесс будет стабильно обеспечивать свою пользу даже при изменяющихся условиях. Это включает предсказуемость результатов, надежность выполнения процесса, устойчивость к внешним воздействиям и способность к масштабированию. Высокая зрелость процессов указывает на то, что он хорошо документирован, имеет чёткие процедуры и управление, что снижает риски и повышает его надёжность. Таким образом, гарантия в данном контексте — это аналог понятия warranty в ITIL, применительно к процессам управления.

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

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

Основное отличие заключается в том, как определяется следующий шаг в обработке инцидента. При произвольном маршруте специалист самостоятельно принимает решение о дальнейшем направлении инцидента на основе результатов диагностики. Например, инцидент, связанный с отказом информационной системы, может быть направлен администраторам ЦОД или в сетевую группу в зависимости от выявленной причины. При фиксированном маршруте для каждой услуги заранее установлена четкая последовательность линий поддержки и их ответственность. Это означает, что инцидент последовательно передается от L2 к L3 и затем к L4, без возможности отклонения от установленного маршрута, даже если требуется привлечь смежные специалисты. В таком случае привлечение смежников происходит через отдельный инцидент или задание.

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

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