PRB (Problem Review Board) необходим для обсуждения сложных проблем с участием экспертов, но его роль не сводится к реакции на major-инциденты. PRB анализирует глубинные причины, планирует стратегии решений и утверждает временные обходные пути. Ошибочное применение PRB только после критических инцидентов (вместо регулярного анализа) искажает процесс — PRB должен функционировать как постоянно действующий орган для координации сложных проблем, а не как экстренная группа.

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

Модель зрелости канбан-системы (KMM) описывает уровни развития практик. Второй уровень включает явное отображение требований к процессу, введение WIP-лимитов и управление блокерами на регулярных встречах. Третий уровень предполагает количественную оценку потока и измерение ключевых метрик, таких как время выполнения задач. Что касается обработки возвратов, на втором уровне их обычно отображают явным возвратом задачи на предыдущий этап, тогда как на четвертом и пятом уровнях (еще более зрелых) предпочитают использовать комбинацию основной и дочерней задач для исправлений, что позволяет более точно анализировать причины возвратов и совершенствовать систему.

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

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

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

Сравнение показывает, что предполагаемые затраты времени на ведение учета (5-10% рабочего времени) значительно завышены по сравнению с реальными (0,32% за 2014 год). Это доказывает, что распространенные опасения относительно трудоемкости учета времени необоснованны и что введение системы учета не приведет к значительным потерям рабочего времени, как часто предполагают сотрудники и менеджеры.

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

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

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