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

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

Основные недостатки ABAC связаны со сложностью управления и аудита. Из-за использования множества атрибутов и условий правила становятся запутанными, требуют постоянного обновления и сложны в поддержке. В отличие от RBAC, где права явно привязаны к ролям, в ABAC невозможно быстро определить, какие именно привилегии имеет конкретный пользователь, так как модель не оперирует понятием «права». Это делает ABAC неэффективным для аудита и управления правами на уровне отдельных пользователей.

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

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

Эффективность потока - это отношение времени производства (Touch Time, непосредственно время выполнения работы над задачей) ко времени в системе (System Lead Time), выраженное в процентах. Для обычных команд разработки этот показатель находится в диапазоне от 3% до 10%, что означает, что от 90% до 97% времени задача находится в ожидании. Нормальным показателем для команд, управляющих работой в потоке, считается эффективность в 30%, что достигается за счет сокращения количества задач в системе и фокусировки на завершении текущих задач вместо начала новых.

В типичных командах разработки для отдельной задачи из всего времени, которое она находится в системе, в среднем 90% составляет время ожидания. Для большого количества команд эта цифра еще выше - 95-97%. Это означает, что отношение реального времени работы над задачей (Touch Time) ко времени в системе (System Lead Time), называемое эффективностью потока, находится в диапазоне от 3% до 10% для обычных команд.

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

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

Основные проблемы классификации включают неоднозначность определения границ между инцидентом и сервисным запросом, что приводит к дискуссиям на тему "А замена картриджа принтера? А сброс забытого пароля?". Эта неоднозначность не только создает сложности для теоретиков, но и затрудняет работу специалистов на практике. Кроме того, если эти типы обращений относятся к разным процессам управления (и, возможно, к разным менеджерам), вопрос классификации превращается в вопрос ответственности: "кто за это отвечает". Это создает организационные трения и может негативно сказаться на эффективности процесса.