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

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

## [Почему важно, чтобы опытные разработчики могли объяснять свои действия простым языком для нетехнических специалистов?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-chtoby-opytnye-razrabotchiki-mogli-obyasnyat-svoi-deystviya-prostym-yazykom-dlya-nete/)

Важность способности объяснять сложные технические аспекты простым языком обусловлена необходимостью эффективной коммуникации между IT и бизнесом. Опытные разработчики (миддл и сеньор) должны уметь излагать смысл своей деятельности, трудности, с которыми они сталкиваются, и обосновывать выбор решений, потому что: 1) это помогает бизнесу понимать ценность и стоимость технических решений; 2) предотвращает накопление технического долга из-за непонимания логической структуры системы; 3) современное программирование становится более верхнеуровневым и близким к человекопонятному языку, поэтому это должно быть проще. В тексте прямо указано, что это «the must», особенно учитывая, что части технического долга возникают из-за несостыковок в логической продуманности системы.

Автор: Сандра Урядова

Рейтинг: 772

Теги: бизнес, ценность, бизнес-заказчик

## [Какие действия рекомендуется предпринять менеджеру процесса при анализе инцидентов с кодом закрытия "Нет решения"?](https://cleverics.ru/digital/kb-qa/kakie-deystviya-rekomenduetsya-predprinyat-menedzheru-protsessa-pri-analize-intsidentov-s-kodom-zakr/)

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

Автор: Евгений Шилов

Рейтинг: 772

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

## [Что означает «нормальная работа услуги» в контексте управления инцидентами?](https://cleverics.ru/digital/kb-qa/chto-oznachaet-normalnaya-rabota-uslugi-v-kontekste-upravleniya-intsidentami/)

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

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

Рейтинг: 772

Теги: управление инцидентами, управление конфигурациями, CMDB, управление уровнем услуг, SLM

## [Почему консультанты и интеграторы уделяют больше внимания обучению, чем сотрудники заказчиков?](https://cleverics.ru/digital/kb-qa/pochemu-konsultanty-i-integratory-udelyayut-bolshe-vnimaniya-obucheniyu-chem-sotrudniki-zakazchikov/)

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

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

Рейтинг: 772

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

## [Почему переход на подход 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) переход проще.

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

Рейтинг: 772

Теги: 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 может отличаться от реальной эффективности в несколько раз.

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

Рейтинг: 772

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

## [Какие преимущества даёт пилотное внедрение процесса в «бумажном» формате?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-pilotnoe-vnedrenie-protsessa-v-bumazhnom-formate/)

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

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

Рейтинг: 772

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

## [Как влияет зрелость учета на оценку трудозатрат для сопровождения CMDB?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-zrelost-ucheta-na-otsenku-trudozatrat-dlya-soprovozhdeniya-cmdb/)

Зрелость учета в CMDB значительно влияет на оценку трудозатрат для его сопровождения. На начальных уровнях зрелости, когда охват учета ограничен и в основном управляется выделенными специалистами («библиотекарями»), оценка трудозатрат относительно проста. По мере роста зрелости учета, когда CMDB охватывает все больше и разных типов конфигурационных единиц (ИТ-системы, бизнес-приложения, технологические элементы бизнес-приложений, инфраструктура), возрастает сложность оценки трудозатрат. С увеличением зрелости привлекается больше специалистов различных категорий, каждый из которых решает свои задачи с разной степенью ресурсоемкости и стоимость их рабочего времени различается. Структура информации и источники ее получения также становятся более разнообразными. Это требует детальной разбивки оценки трудозатрат по группам конфигурационных единиц и выполняемым задачам, а также учета требований к компетенциям исполнителя, что существенно усложняет процесс оценки.

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

Рейтинг: 772

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

## [Почему внутренние проекты более уязвимы к отпускам сотрудников, чем проекты консультантов?](https://cleverics.ru/digital/kb-qa/pochemu-vnutrennie-proekty-bolee-uyazvimy-k-otpuskam-sotrudnikov-chem-proekty-konsultantov/)

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

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

Рейтинг: 772

Теги: ISO 20000, мотивация персонала, стимулирование, управление проектами, PRINCE2

## [В чём заключается ошибка сервис-провайдера при работе "проактивно" без понимания целей заказчика?](https://cleverics.ru/digital/kb-qa/v-chem-zaklyuchaetsya-oshibka-servis-provaydera-pri-rabote-proaktivno-bez-ponimaniya-tseley-zakazchi/)

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

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

Рейтинг: 771

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