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

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

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

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

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

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

Автоматизация играет ключевую роль в определении завершения работы по концепции DevOps, так как она обеспечивает: 1) надежность и воспроизводимость процессов; 2) минимизацию человеческого фактора; 3) быстрое выявление и исправление ошибок; 4) непрерывную доставку изменений; 5) возможность частых и безопасных обновлений продукта. В финальной ступени Definition of Done автоматизация сборки, тестирования и развертывания является обязательным условием для признания работы завершенной, что позволяет командам сосредоточиться на улучшении продукта, а не на рутинных операциях.

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

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

Четвертый шаг цикла Деминга (Act) заключается в принятии решений относительно дальнейших действий после проверки результатов изменений. Он включает ответ на вопрос: 'Что делать дальше?'. Это может означать внедрение успешных улучшений в стандартную практику, игнорирование неудачных результатов без дополнительных изменений или запуск нового цикла PDCA с учетом полученного опыта. Act фокусируется на итоговой корректировке подхода и определении дальнейшей стратегии улучшений, что отличает его от этапа планирования, который предваряет непосредственное выполнение изменений.