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

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

## [Почему в некоторых случаях может быть рационально не устранять корневую причину проблемы полностью?](https://cleverics.ru/digital/kb-qa/pochemu-v-nekotorykh-sluchayakh-mozhet-byt-ratsionalno-ne-ustranyat-kornevuyu-prichinu-problemy-poln/)

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

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

Рейтинг: 868

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

## [Как важно проактивное информирование сотрудников о негативных последствиях преобразований на этапе размораживания?](https://cleverics.ru/digital/kb-qa/kak-vazhno-proaktivnoe-informirovanie-sotrudnikov-o-negativnykh-posledstviyakh-preobrazovaniy-na-eta/)

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

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

Рейтинг: 868

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

## [Почему практика ведения каталога технических услуг и OLA не применима ко всем компаниям?](https://cleverics.ru/digital/kb-qa/pochemu-praktika-vedeniya-kataloga-tekhnicheskikh-uslug-i-ola-ne-primenima-ko-vsem-kompaniyam/)

Практика ведения каталога технических услуг и OLA не применима ко всем компаниям, потому что сервисный подход вообще реализован лишь в небольшом количестве организаций, и только к очень небольшой доле этих организаций применима именно практика ведения каталога технических услуг и OLA. Это связано с тем, что такие документы и практики значительно влияют на другие процессы, отношения между подразделениями и оргструктуру, и их введение может быть избыточным или неоправданным в компаниях с простой структурой или без четкого сервисного подхода. О необходимости быть осторожнее с внедрением таких практик уже писали Pink Elephant (около 2006 года) и IT Skeptic (около 2011 года).

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

Рейтинг: 868

Теги: управление релизами, управление уровнем услуг, SLM

## [Как эффект Даннинга-Крюгера проявляется в ИТ-сфере?](https://cleverics.ru/digital/kb-qa/kak-effekt-danninga-kryugera-proyavlyaetsya-v-it-sfere/)

В области IT эффект Даннинга-Крюгера проявляется в нескольких аспектах. Например, существуют проекты разработки программного обеспечения, где команды считают нормальным писать «лучший в Галактике код», но при этом не могут выйти на продуктивную эксплуатацию в течение 3-5 лет. Есть команды, которые выпускают релизы раз в месяц, игнорируя современные практики ежедневных релизов. Также встречаются разработчики, которые не понимают CI/CD и настаивают на ручном тестировании, администраторы, считающие всех разработчиков некомпетентными, и консультанты, которые без глубокого понимания процитируют Agile-литературу. Все эти ситуации указывают на то, что многие профессионалы неадекватно оценивают свои знания и навыки.

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

Рейтинг: 867

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

## [Почему большая часть обращений в ИТ-поддержку требует помощи второй линии и как это связано с компетенциями сотрудников первой линии?](https://cleverics.ru/digital/kb-qa/pochemu-bolshaya-chast-obrashcheniy-v-it-podderzhku-trebuet-pomoshchi-vtoroy-linii-i-kak-eto-svyazan/)

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

Автор: Михаил Тобурдановский

Рейтинг: 867

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

## [Какие принципы гибкого управления важны для команды разработки?](https://cleverics.ru/digital/kb-qa/kakie-printsipy-gibkogo-upravleniya-vazhny-dlya-komandy-razrabotki/)

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

Автор: Светлана Сапегина

Рейтинг: 867

Теги: Agile и гибкие методы разработки ПО, ISO 20000, бизнес, ценность, бизнес-заказчик, командная работа, общие вопросы менеджмента, постоянное улучшение, совершенствование, CSI, PDCA, управление процессами, ИТ-процессы, эффективность, оптимизация

## [Какие основные проблемы возникают у компаний при внедрении CXM?](https://cleverics.ru/digital/kb-qa/kakie-osnovnye-problemy-voznikayut-u-kompaniy-pri-vnedrenii-cxm/)

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

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

Рейтинг: 867

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

## [Как связаны высокий спрос и качество сервиса в российских компаниях?](https://cleverics.ru/digital/kb-qa/kak-svyazany-vysokiy-spros-i-kachestvo-servisa-v-rossiyskikh-kompaniyakh/)

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

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

Рейтинг: 867

Теги: ISO 20000, бизнес, ценность, бизнес-заказчик, постоянное улучшение, совершенствование, CSI, PDCA, эффективность, оптимизация

## [Как связаны понятия 'риск' и другие аспекты управления проектами в PRINCE2®?](https://cleverics.ru/digital/kb-qa/kak-svyazany-ponyatiya-risk-i-drugie-aspekty-upravleniya-proektami-v-prince2/)

Риск в PRINCE2® рассматривается как возможное событие или набор событий, реализация которых может повлиять на достижение целей проекта по всем другим аспектам: срокам, затратам, охвату, качеству и выгодам. Например, наступление рискового события может привести к увеличению затрат, срыву сроков или ухудшению качества. Хотя риски влияют на другие аспекты, они выделяются как отдельный аспект управления, потому что требуют специфического подхода и механизмов управления. Сравнивая различные варианты реализации проекта, организации часто выбирают не самый дешевый или быстрый вариант, а тот, который имеет приемлемый уровень рисков, даже если он немного дороже или дольше.

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

Рейтинг: 867

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

## [Кто должен нести ответственность за понимание технических аспектов проекта — бизнес или ИТ-специалисты?](https://cleverics.ru/digital/kb-qa/kto-dolzhen-nesti-otvetstvennost-za-ponimanie-tekhnicheskikh-aspektov-proekta-biznes-ili-it-spetsial/)

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

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

Рейтинг: 867

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