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

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

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

При первоначальном внедрении процесса управления уровнями обслуживания (SLM) обычно используются следующие типичные подходы: - Запуск процесса не на всех услугах, а только на наиболее критичных, где существует большая потребность и лучшее понимание со стороны бизнеса. - Проведение предварительной оценки необходимости внедрения SLM, так как этот процесс управления не требуется или не обоснован для всех организаций (в отличие от процесса поддержки пользователей). - Начало с хорошо понятных и уже проработанных бизнес-требований, таких как требования к резервному копированию и восстановлению данных. - Проведение аудита текущих "как есть" (as is) процедур и определение требований, если они были зафиксированы ранее. - Постепенное расширение покрытия процессами управления уровнями обслуживания, начиная с конкретных и понятных областей. Эти подходы помогают снизить сопротивление бизнеса и увеличить шансы успешного внедрения процесса SLM.

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

Наличие этапа 'Отложено' в потоке создания ценности приводит к следующим дисфункциям: размытой ответственности, так как команда перекладывает вину на внешние факторы; повышенным требованиям к контролю, поскольку процесс становится менее предсказуемым; управлению через жесткие дедлайны, что создает стресс и искусственно ускоряет работу; управлению дефектами как отдельной активностью, так как отложенные задачи теряют контекст и качество; смещению фокуса с создания ценности на простое выполнение работы без результативности. Все это приводит к тому, что команда может быть постоянно занята делами, но конечные результаты будут неудовлетворительными.

Для учета различного влияния инцидентов на бизнес при расчете метрики времени реакции можно использовать два подхода: первый - выполнять расчет метрики отдельно для каждого уровня влияния или приоритета инцидента, что позволяет проанализировать эффективность реакции на каждый категорий инцидентов; второй - использовать формулу взвешенного среднего, где весом (Wi) выступает уровень влияния или приоритет инцидента: Rw = (Σ(Ti*Wi)) / (Σ((Ti+Qi)*Wi)). Это позволяет получить более точную оценку общей эффективности процесса с учетом бизнес-значимости каждого инцидента.

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

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

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