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

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

## [Каковы ключевые различия в подходах к оптимизации и созданию избыточности между управлением доступностью и управлением непрерывностью?](https://cleverics.ru/digital/kb-qa/kakovy-klyuchevye-razlichiya-v-podkhodakh-k-optimizatsii-i-sozdaniyu-izbytochnosti-mezhdu-upravlenie/)

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

Автор: Павел Дёмин

Рейтинг: 704

Теги: аллокация затрат, расчёт себестоимости услуг, аутсорсинг, интеграция услуг, бюджетирование, планирование затрат, управление доступностью, управление инцидентами, управление непрерывностью, экономика и финансы, эффективность, оптимизация

## [Почему переход на подход Zero Known Defects представляет сложности для команд?](https://cleverics.ru/digital/kb-qa/pochemu-perekhod-na-podkhod-zero-known-defects-predstavlyaet-slozhnosti-dlya-komand/)

Переход на подход Zero Known Defects представляет сложности для команд, потому что он требует значительных изменений в мышлении и процессах. Команды должны отказаться от традиционной парадигмы 'дефекты устраним когда-нибудь в зависимости от их критичности' и изменить приоритеты, ставя устранение дефектов выше разработки новых функций. Это приводит к таким сложностям, как отсутствие понятия приоритета дефекта, невозможность начинать новую разработку пока в бэклоге есть дефекты, и необходимость пересмотра планирования работы. Особенно сложно это реализовать на проектах, которые уже существуют долгое время, на 'чистом поле' (green field) переход проще.

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

Рейтинг: 704

Теги: Agile и гибкие методы разработки ПО, командная работа, общие вопросы менеджмента, разработка ПО, управление проектами, PRINCE2, управление процессами, ИТ-процессы

## [Как различаются подходы к учету рабочего времени при расчете Flow Efficiency?](https://cleverics.ru/digital/kb-qa/kak-razlichayutsya-podkhody-k-uchetu-rabochego-vremeni-pri-raschete-flow-efficiency/)

При расчете Flow Efficiency возникает вопрос, какое рабочее время учитывать. Если команда состоит из сотрудников с разными графиками работы (например, аналитики в Новосибирске, разработчики в Москве, тестировщик на неполную ставку), возникает сложность выбора календаря. Можно было бы использовать календарь отдельного сотрудника, но в случае совместной работы над задачей это не отражает реальную ситуацию. В результате многие команды прибегают к упрощенным оценкам или договоренностям, которые дают неточные результаты, а не строгий расчет. Это приводит к ситуации, когда формально рассчитанная Flow Efficiency может отличаться от реальной эффективности в несколько раз.

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

Рейтинг: 704

Теги: измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, Канбан, WIP-лимиты, командная работа, общие вопросы менеджмента, экономика и финансы, эффективность, оптимизация

## [Какой следующий этап развития Definition of Done после проверки тестировщиком?](https://cleverics.ru/digital/kb-qa/kakoy-sleduyushchiy-etap-razvitiya-definition-of-done-posle-proverki-testirovshchikom/)

После этапа, когда работа считается завершенной после подтверждения тестировщиком, следующим этапом в эволюции Definition of Done является Agile-подход, при котором работа считается завершенной после того, как владелец продукта принял результат разработки. В соответствии с подходами, такими как SAFe, владелец продукта является единственным членом команды, который может принимать истории как выполненные, что включает проверку соответствия критериям Definition of Done. Для больших организаций этот процесс усложняется дополнительными уровнями приемки: на уровне команды, системы, решения и релиза.

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

Рейтинг: 704

Теги: Agile и гибкие методы разработки ПО, командная работа, управление продуктами, продуктовый подход, управление релизами, эффективность, оптимизация

## [Что происходит с себестоимостью при увеличении интенсивности труда?](https://cleverics.ru/digital/kb-qa/chto-proiskhodit-s-sebestoimostyu-pri-uvelichenii-intensivnosti-truda/)

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

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

Рейтинг: 704

Теги: аллокация затрат, расчёт себестоимости услуг, мониторинг, поддержка пользователей, Service Desk, Help Desk, экономика и финансы, эффективность, оптимизация

## [Какие трудности возникают при установлении ключевых практик для процесса измерения?](https://cleverics.ru/digital/kb-qa/kakie-trudnosti-voznikayut-pri-ustanovlenii-klyuchevykh-praktik-dlya-protsessa-izmereniya/)

При установлении ключевых практик для процесса измерения возникают следующие трудности: сложно определить комплекс практик, необходимых для реализации назначения процесса; рекомендации из фреймворков, таких как CSF в ITIL или Key Practices в COBIT5, могут быть слишком общими или не полностью соответствовать специфике конкретной организации; даже после определения ключевых практик и разработки для них метрик могут оставаться сомнения в полноте покрытия всех аспектов управления процессом. Эти трудности требуют дополнительного анализа и адаптации стандартных подходов под конкретные условия.

Автор: Павел Дёмин

Рейтинг: 704

Теги: COBIT, ITIL, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление процессами, ИТ-процессы

## [Какие методы используются для корректного определения общего количества релевантных обращений для расчёта метрик?](https://cleverics.ru/digital/kb-qa/kakie-metody-ispolzuyutsya-dlya-korrektnogo-opredeleniya-obshchego-kolichestva-relevantnykh-obrashch/)

Для корректного определения общего количества релевантных обращений для расчёта метрик FLR и FCR применяются несколько методов. Один из распространённых подходов предполагает, что специалисты второй или третьей линии при закрытии инцидента отмечают, мог ли он быть решён на первой линии. Для запросов на обслуживание заранее определяется, какая линия должна их решать, или применяется аналогичный подход с отметками специалистов. Также используется более "красивое" решение – применение моделей инцидентов, в которых заранее определяется, на какой линии должны решаться подобные инциденты. Этот атрибут затем используется для фильтрации инцидентов при формировании отчётности.

Автор: Дмитрий Хруслов

Рейтинг: 704

Теги: измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, управление запросами на обслуживание, управление инцидентами

## [Какие категории конфигурационных единиц обычно исключаются из управления активами?](https://cleverics.ru/digital/kb-qa/kakie-kategorii-konfiguratsionnykh-edinits-obychno-isklyuchayutsya-iz-upravleniya-aktivami/)

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

Автор: Артём Мукосеев

Рейтинг: 704

Теги: управление ИТ-активами, ITAM, SAM, управление конфигурациями, CMDB

## [Каковы ключевые практики для управления доступностью и непрерывностью ИТ-услуг в соответствии со стандартом ISO/IEC 20000?](https://cleverics.ru/digital/kb-qa/kakovy-klyuchevye-praktiki-dlya-upravleniya-dostupnostyu-i-nepreryvnostyu-it-uslug-v-sootvetstvii-so/)

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

Автор: Павел Дёмин

Рейтинг: 703

Теги: ISO 20000, SLA, общие вопросы менеджмента, управление доступностью, управление рисками, управление уровнем услуг, SLM

## [Как избежать превращения разработчиков в роботов, выполняющих монотонные задачи?](https://cleverics.ru/digital/kb-qa/kak-izbezhat-prevrashcheniya-razrabotchikov-v-robotov-vypolnyayushchikh-monotonnye-zadachi/)

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

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

Рейтинг: 703

Теги: бизнес, ценность, бизнес-заказчик, командная работа, поддержка пользователей, Service Desk, Help Desk, управление продуктами, продуктовый подход