# Бесплатная экспертная база знаний по управлению ИТ

Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами

## [Что такое среднее время поставки (Lead time) и почему оно является ключевой метрикой для команд разработки информационных систем?](https://cleverics.ru/digital/kb-qa/chto-takoe-srednee-vremya-postavki-lead-time-i-pochemu-ono-yavlyaetsya-klyuchevoy-metrikoy-dlya-koma/)

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

Автор: Андрей Труфанов

Рейтинг: 2863

Теги: DevOps, CI/CD, Lean, бережливое производство, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, командная работа, поддержка пользователей, Service Desk, Help Desk, управление релизами, эффективность, оптимизация

## [Что такое поток создания ценности с точки зрения управления системами?](https://cleverics.ru/digital/kb-qa/chto-takoe-potok-sozdaniya-tsennosti-s-tochki-zreniya-upravleniya-sistemami/)

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

Автор: Андрей Труфанов

Рейтинг: 1982

Теги: DevOps, CI/CD, Lean, бережливое производство, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, Канбан, WIP-лимиты, командная работа, поток создания ценности (Value Stream), эффективность, оптимизация

## [Какие технические улучшения необходимы для перехода к более частым релизам в ИТ-проекте?](https://cleverics.ru/digital/kb-qa/kakie-tekhnicheskie-uluchsheniya-neobkhodimy-dlya-perekhoda-k-bolee-chastym-relizam-v-it-proekte/)

Для перехода к более частым релизам необходимы следующие технические улучшения: внедрение полной автоматизации процесса сборки и развёртывания; создание достаточного количества тестовых сред для параллельной работы; увеличение покрытия кода автоматическими тестами (юнит-тесты, интеграционные тесты, end-to-end тесты); внедрение практик непрерывной интеграции для немедленного обнаружения проблем; применение принципов разработки с малыми циклами изменений (small batches); создание системы мониторинга и обратной связи для быстрой реакции на проблемы; оптимизация процесса выделения ИТ-ресурсов под различные задачи; реализация стратегии feature toggles для безопасного включения новых функций. Эти изменения позволяют минимизировать риски и увеличить надёжность процесса доставки.

Автор: Олег Скрынник

Рейтинг: 1957

Теги: DevOps, CI/CD, мониторинг, постоянное улучшение, совершенствование, CSI, PDCA, стратегия, управление продуктами, продуктовый подход, управление проектами, PRINCE2, управление процессами, ИТ-процессы, управление релизами, управление рисками, эффективность, оптимизация

## [Какой принцип одного изделия в потоке (one piece flow) проявился в практике DevOps при использовании канбана?](https://cleverics.ru/digital/kb-qa/kakoy-printsip-odnogo-izdeliya-v-potoke-one-piece-flow-proyavilsya-v-praktike-devops-pri-ispolzovani/)

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

Автор: Игорь Гутник

Рейтинг: 1742

Теги: DevOps, CI/CD, Канбан, WIP-лимиты, командная работа, мониторинг, управление проектами, PRINCE2, эффективность, оптимизация

## [Как влияет уровень автоматизации на частоту успешных релизов в ИТ-командах?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-uroven-avtomatizatsii-na-chastotu-uspeshnykh-relizov-v-it-komandakh/)

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

Автор: Олег Скрынник

Рейтинг: 1507

Теги: DevOps, CI/CD, командная работа, управление продуктами, продуктовый подход, управление процессами, ИТ-процессы, управление релизами, управление рисками, эффективность, оптимизация

## [Какие элементы включает типичное SLA между отделом маркетинга и отделом продаж?](https://cleverics.ru/digital/kb-qa/kakie-elementy-vklyuchaet-tipichnoe-sla-mezhdu-otdelom-marketinga-i-otdelom-prodazh/)

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

Автор: Олег Скрынник

Рейтинг: 1480

Теги: DevOps, CI/CD, SLA, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, мониторинг, управление уровнем услуг, SLM

## [Что такое work in progress лимит и как он влияет на скорость работы команды?](https://cleverics.ru/digital/kb-qa/chto-takoe-work-in-progress-limit-i-kak-on-vliyaet-na-skorost-raboty-komandy/)

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

Автор: Андрей Труфанов

Рейтинг: 1397

Теги: DevOps, CI/CD, Канбан, WIP-лимиты, командная работа, мониторинг, эффективность, оптимизация

## [Почему бизнесу важно кратное увеличение скорости поставки, а не небольшой прирост?](https://cleverics.ru/digital/kb-qa/pochemu-biznesu-vazhno-kratnoe-uvelichenie-skorosti-postavki-a-ne-nebolshoy-prirost/)

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

Автор: Павел Капусткин

Рейтинг: 1380

Теги: DevOps, CI/CD, аллокация затрат, расчёт себестоимости услуг, бизнес, ценность, бизнес-заказчик, командная работа, трансформация, ускорение, Time-to-Market, управление релизами, экономика и финансы

## [Почему важно не только устранение ошибок в продукте, но и выявление отклонений в работе процесса DevOps?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-ne-tolko-ustranenie-oshibok-v-produkte-no-i-vyyavlenie-otkloneniy-v-rabote-protsessa/)

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

Автор: Игорь Гутник

Рейтинг: 1332

Теги: DevOps, CI/CD, Lean, бережливое производство, управление проблемами, управление продуктами, продуктовый подход

## [Какие изменения в подходе к релизам необходимы для эффективного CI/CD?](https://cleverics.ru/digital/kb-qa/kakie-izmeneniya-v-podkhode-k-relizam-neobkhodimy-dlya-effektivnogo-ci-cd/)

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

Автор: Олег Скрынник

Рейтинг: 1319

Теги: DevOps, CI/CD, бизнес, ценность, бизнес-заказчик, командная работа, общие вопросы менеджмента, управление конфигурациями, CMDB, управление релизами