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

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

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

Своевременность решения инцидентов в размере более 95% превышает отраслевую статистику, которая составляет в среднем 82%. Согласно данным Pink Elephant за 2013 год, только 13% компаний достигают уровня своевременности в диапазоне 96-100%. Этот показатель часто позиционируется как достижение, хотя его реальная ценность зависит от сопутствующих параметров, таких как целевое время решения и восприятие пользователями.

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

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

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

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

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

При планировании мощностей в CMDB должны учитываться такие типы данных, как вычислительные мощности, объём хранимых данных, места в стойках, сетевые порты и другие показатели, характеризующие потребность в ресурсах. Эти данные должны быть связаны с соответствующими функциональными ролями ресурсов и переноситься через связи между элементами системы. Например, потребность в вычислительных мощностях, связанная с уровнем service, должна быть корректно распределена между всеми поддерживающими её ресурсами, такими как CPU, память и дисковое пространство. Это позволяет создавать более точные прогнозы и планы развития инфраструктуры.