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

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

## [Как можно объяснить суть концепции деления задач через пример слона?](https://cleverics.ru/digital/kb-qa/kak-mozhno-obyasnit-sut-kontseptsii-deleniya-zadach-cherez-primer-slona/)

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

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

Рейтинг: 864

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

## [Почему важна адекватная интерпретация термина DevOps при описании содержания курса?](https://cleverics.ru/digital/kb-qa/pochemu-vazhna-adekvatnaya-interpretatsiya-termina-devops-pri-opisanii-soderzhaniya-kursa/)

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

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

Рейтинг: 864

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

## [Какие проблемы возникают при смешении понятий purpose, goals и objectives в управлении процессами?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-pri-smeshenii-ponyatiy-purpose-goals-i-objectives-v-upravlenii-protsessami/)

Смешение понятий назначения (purpose), целей (goals) и задач (objectives) в управлении процессами приводит к: - Путанице в формулировках: цели нечётко связаны с бизнес-требованиями, назначение дублирует оперативные задачи. - Сложностям управления: если цели фиксируются в регламенте, а не в текущих планах, документ становится устаревшим после каждого пересмотра целей. - Проблемам с ответственностью, так как дизайнер процесса вместо определения базового назначения начинает формулировать краткосрочные цели. - Несоответствию процесса бизнес-целям: без чёткой связи между стратегическим назначением и оперативными задачами сложно измерить вклад процесса в бизнес-результаты. - Отсутствию иерархии: руководители пытаются управлять стратегическими и оперативными аспектами одновременно, тратя ресурсы на нерелевантные задачи.

Автор: Дмитрий Исайченко

Рейтинг: 864

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

## [Почему в ИТ-проектах особенно важно следить за балансом между активностью и аналитикой?](https://cleverics.ru/digital/kb-qa/pochemu-v-it-proektakh-osobenno-vazhno-sledit-za-balansom-mezhdu-aktivnostyu-i-analitikoy/)

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

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

Рейтинг: 864

Теги: управление продуктами, продуктовый подход, управление проектами, PRINCE2

## [Как можно предотвратить выполнение работы подчиненных под чужим руководством без контроля со стороны прямого руководителя?](https://cleverics.ru/digital/kb-qa/kak-mozhno-predotvratit-vypolnenie-raboty-podchinennykh-pod-chuzhim-rukovodstvom-bez-kontrolya-so-st/)

Чтобы предотвратить выполнение работы подчиненными под чужим руководством без контроля со стороны прямого руководителя, необходимо: 1. При работе с RACI- или RASCI-матрицей четко определить и зафиксировать, кто является ответственным за организацию работы (это может отличаться от ответственного за конечный результат). 2. Если вы находитесь в позиции S (Supports - поддерживающий), рекомендуется делегировать непосредственное исполнение задачи, сохранив за собой роль в информационном потоке (I - Informed) или консультативную роль (C - Consulted). 3. Убедиться, что для всех задач, в которых участвуют ваши подчиненные, определены точки контроля, через которые вы сможете отслеживать прогресс и качество выполнения. 4. Установить четкие правила информирования о ходе выполнения задач, даже если непосредственное руководство осуществляется другим менеджером. Это гарантирует, что вы будете в курсе происходящего и сможете вмешаться при необходимости, не позволяя ситуации выйти из-под контроля.

Автор: Дмитрий Исайченко

Рейтинг: 864

Теги: Канбан, WIP-лимиты, обучение сотрудников, учебные курсы, тренинги, общие вопросы менеджмента, управление процессами, ИТ-процессы

## [Как интегрировать стандартные изменения в каталог поддержки?](https://cleverics.ru/digital/kb-qa/kak-integrirovat-standartnye-izmeneniya-v-katalog-podderzhki/)

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

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

Рейтинг: 864

Теги: SLA, архитектура ИТ, TOGAF и IT4IT, аудит, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, обучение сотрудников, учебные курсы, тренинги, поддержка пользователей, Service Desk, Help Desk, управление запросами на обслуживание, управление изменениями, управление конфигурациями, CMDB, управление уровнем услуг, SLM

## [Зачем в ITIL необходимо разделять запросы на изменения и предложения об изменении?](https://cleverics.ru/digital/kb-qa/zachem-v-itil-neobkhodimo-razdelyat-zaprosy-na-izmeneniya-i-predlozheniya-ob-izmenenii/)

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

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

Рейтинг: 864

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

## [Какие методы описания последствий рисков предлагает PMBOK?](https://cleverics.ru/digital/kb-qa/kakie-metody-opisaniya-posledstviy-riskov-predlagaet-pmbok/)

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

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

Рейтинг: 864

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

## [В чем разница в подходах к ограничениям в водопадной методологии и Agile?](https://cleverics.ru/digital/kb-qa/v-chem-raznitsa-v-podkhodakh-k-ogranicheniyam-v-vodopadnoy-metodologii-i-agile/)

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

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

Рейтинг: 863

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

## [Как эффективно контролировать результаты внедрения мер по повышению своевременности обработки запросов?](https://cleverics.ru/digital/kb-qa/kak-effektivno-kontrolirovat-rezultaty-vnedreniya-mer-po-povysheniyu-svoevremennosti-obrabotki-zapro/)

Для эффективного контроля результатов необходимо: 1. Систематически отслеживать выполнение запланированных мер ответственными лицами 2. Проводить постоянный мониторинг ключевых показателей эффективности с фокусом на ранее выявленные 'болевые точки' 3. Учитывать, что разные меры могут давать как мгновенный, так и отложенный эффект 4. Анализировать изменения в структуре поступающих обращений и выявлять новые потенциальные проблемы 5. Регулярно сверять фактические результаты с плановыми показателями 6. Поддерживать прозрачность ситуации для всех заинтересованных сторон, используя объективные данные 7. Быть готовым скорректировать план в случае недостаточной эффективности принятых мер Ключевым элементом успешного контроля является непрерывность и внимание к деталям, а также полагаться на данные, а не на экспертные оценки, чтобы избежать субъективности и скрытых проблем.

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

Рейтинг: 863

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