Полезные метрики включают: скорость выполнения задач (velocity), время цикла, время выполнения (lead time), процент завершенных функций, соотношение исправлений ошибок к новым функциям, коэффициент повторного использования кода. Важно, чтобы метрики отражали именно цели и ценностя команды и бизнеса, а не были формальными. Метрики должны быть простыми для понимания и непротиворечивыми по сбору данных.

При увеличении числа потоков ценности могут возникнуть несколько проблем: несравнимость результатов деятельности отдельных потоков (особенно если одни измеряются в финансовых показателях, а другие - в натуральных единицах), конфликты между командами за ресурсы и инвестиции. Например, в случае с Twitter после разделения на потоки Community, Advertising и Marketplace возникла сложность с измерением эффективности социальной сети (измеряется в натуральных единицах), в отличие от рекламы и торговой площадки (измеряются в деньгах). Также возникает вопрос о том, как делить ответственность и влияние между потоками, когда успех коммерческих потоков напрямую зависит от качества аудитории, которую формирует поток социальной сети.

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

При совмещении менеджером процесса управленческих и операционных обязанностей возникает несколько ключевых проблем. Во-первых, снижается фокус на стратегическом управлении процессом: менеджер вынужден делить время между операционными задачами и процессным развитием. Во-вторых, появляется конфликт интересов — сотрудник, руководящий конкретным отделом, принимает решения, исходя из интересов этого отдела, а не всей организации. В-третьих, увеличивается риск нарушения принципа разделения обязанностей (segregation of duties), что критически важно для аудиторских и регуляторных требований. Наконец, менеджер, погружённый в оперативную работу, может не находить времени на анализ данных, оптимизацию процессов и внедрение улучшений.

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

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

До конца текущего года запланирован выпуск еще одного релиза CleverENGINE. В план разработки уже включены новые требования, что указывает на активное продолжение развития продукта после выпуска версии 3.1.

На окончательное решение клиента прекратить сотрудничество с поставщиком влияют несколько ключевых факторов: степень серьёзности ошибки, её влияние на основную деятельность клиента, реакция поставщика на инцидент и готовность компенсировать ущерб. Если ошибка критично нарушает процесс работы клиента (например, невыплата страховой суммы по КАСКО после ДТП), а поставщик демонстрирует безразличие или пытается уйти от ответственности, это становится решающим фактором. Также важна степень доверия, которое было построено ранее — если до этого были многолетние позитивные отношения, клиент может простить ошибку, но если доверие уже было подорвано, даже небольшой инцидент может стать последней каплей. Важно, что клиент оценивает не только факт ошибки, но и то, как она отражается на его репутации, бизнес-процессах и внутренней атмосфере коллектива.

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

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