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

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

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

Продуктовые команды сталкиваются с двумя основными проблемами при внедрении CI/CD. Первая проблема связана со строгими требованиями конвейера развёртывания к другим областям разработки. Например, для успешного внедрения CI/CD необходима правильная работа с исходным кодом: единство и дисциплина в использовании Git, отсутствие множества долгоживущих веток и проблем с мержами. Также требуется культура создания и постоянного обновления автоматизированных тестов, и если команда до сих пор сомневается в необходимости автотестов, процесс внедрения будет затруднён. Кроме того, конвейер требует частых релизов, в то время как многие команды привыкли к редким выпускам (раз в месяц или квартал), и изменение этой привычки представляет собой отдельную сложность. Вторая проблема — деградация процесса: после первоначального внедрения команды часто начинают отключать части конвейера (например, автотесты), ссылаясь на срочность задач или дедлайны, что в конечном итоге разрушает весь процесс.

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

Для объяснения используется пример заказа торта на день рождения: Output — сам торт, который готовит и предоставляет пекарня; Outcome — это восторг именинника и удовлетворённость гостей, которые съели торт. Также применяются другие примеры: Output таксиста — спортивный автомобиль, а Outcome — быстрая и комфортная доставка пассажира до места назначения.

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

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

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

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