Эволюция Definition of Done прошла несколько этапов: 1) "Совсем, совсем плохо": работа считается завершенной, когда разработчик заявил, что все работает (на его локальной среде); 2) Улучшенный подход: завершено, когда тестировщик подтвердил работоспособность; 3) Agile-подход: завершено после принятия результата владельцем продукта; 4) DevOps-подход: завершено, когда код успешно работает в продуктивной среде; 5) Финальная ступень: завершено, когда код работает в продуктиве, а вся сборка, тестирование и развертывание выполнены автоматическими средствами. С каждым этапом критерии завершения становятся все более строгими и приближенными к реальным условиям использования продукта.

На объединенном радаре линия результативности показывает текущую пользу, которую процессы приносят организации, измеряемую по шкале от 0 до 100%. Эта линия отражает фактическую эффективность выполнения процессов в свете бизнес-целей. Линия зрелости, в свою очередь, характеризует уверенность в том, что организация сможет продолжать получать эту пользу даже при изменяющихся условиях. Это показывает, насколько надежно процессы построены и документированы, и насколько легко их можно масштабировать или адаптировать. Другими словами, результативность — это «функциональность», а зрелость — это «гарантия», аналогично известной концепции ITIL.

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

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

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

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

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

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

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

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