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

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

## [Как определить оптимальный размер задач в организации для минимизации необходимости их переприоритизации?](https://cleverics.ru/digital/kb-qa/kak-opredelit-optimalnyy-razmer-zadach-v-organizatsii-dlya-minimizatsii-neobkhodimosti-ikh-pereprior/)

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

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

Рейтинг: 989

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

## [Почему важно осознанно выбирать стратегию внедрения организационных изменений, а не действовать спонтанно?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-osoznanno-vybirat-strategiyu-vnedreniya-organizatsionnykh-izmeneniy-a-ne-deystvovat-s/)

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

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

Рейтинг: 988

Теги: организационные изменения, агенты изменений, стратегия, управление релизами, управление рисками

## [Чем отличается роль формального менеджера от неформального лидера в проектной команде?](https://cleverics.ru/digital/kb-qa/chem-otlichaetsya-rol-formalnogo-menedzhera-ot-neformalnogo-lidera-v-proektnoy-komande/)

Роль формального менеджера и неформального лидера в проектной команде отличаются по источнику авторитета и способу влияния на команду. Формальный менеджер имеет официальный статус, назначенный руководством, и обладает правом давать указания, распределять задачи и оценивать результаты работы. Он обычно отвечает за соблюдение сроков, бюджета и качества проекта. Неформальный лидер, напротив, приобретает авторитет благодаря личным качествам, опыту или уважению со стороны коллег, и его влияние строится на доверии и уважении, а не на должностных полномочиях. Неформальный лидер может возникнуть на любой роли в команде, даже на позиции, не предполагающей руководства (например, как руководитель каменоломни в игре 'Египет'). В то время как формальный менеджер часто фокусируется на процессах и выполнении задач, неформальный лидер может сильнее влиять на мотивацию и командный дух.

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

Рейтинг: 988

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

## [Какие критерии оценки используются в пост-имплементационном обзоре (PIR)?](https://cleverics.ru/digital/kb-qa/kakie-kriterii-otsenki-ispolzuyutsya-v-post-implementatsionnom-obzore-pir/)

В PIR применяются количественные и качественные критерии: соблюдение бюджета и сроков, достижение целевых метрик (например, рост производительности на 15%), уровень удовлетворенности пользователей, соответствие требованиям и анализ рисков. Также оцениваются непредвиденные последствия и влияние на другие процессы. Для каждого критерия устанавливаются пороговые значения, и на основе их сравнения с фактическими результатами определяется успешность внедрения.

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

Рейтинг: 988

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

## [Как создать условия для эффективной самоорганизации команды в ИТ-разработке?](https://cleverics.ru/digital/kb-qa/kak-sozdat-usloviya-dlya-effektivnoy-samoorganizatsii-komandy-v-it-razrabotke/)

Для эффективной самоорганизации команды необходимо создать комфортную и безопасную рабочую среду, обеспечить прозрачность процессов и поддерживать высокий уровень вовлеченности и мотивации. Согласно Agile-манифесту, «над проектом должны работать мотивированные профессионалы», которым нужно предоставить условия и поддержку, полностью доверяя их профессионализму. Самоорганизация возможна, когда участники команды четко понимают общую цель и значимость своего вклада, а процессы позволяют оценивать результаты каждого. Менеджеры должны фокусироваться на управлении самим процессом, а не людьми, обеспечивая прозрачность, поддержку и устраняя препятствия, что позволяет команде балансировать между разными групповыми эффектами и достигать стабильных результатов.

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

Рейтинг: 988

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

## [Как правильно установить "финишный флажок" в процессе создания ценности при гибком управлении?](https://cleverics.ru/digital/kb-qa/kak-pravilno-ustanovit-finishnyy-flazhok-v-protsesse-sozdaniya-tsennosti-pri-gibkom-upravlenii/)

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

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

Рейтинг: 988

Теги: бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, общие вопросы менеджмента, поддержка пользователей, Service Desk, Help Desk, поток создания ценности (Value Stream)

## [Какой процент экстренных изменений считается нормальным в компаниях?](https://cleverics.ru/digital/kb-qa/kakoy-protsent-ekstrennykh-izmeneniy-schitaetsya-normalnym-v-kompaniyakh/)

Согласно аналитике Pink Elephant, более половины компаний имеют долю экстренных изменений в пределах 10%. У почти 20% компаний этот показатель превышает 15%. Таким образом, доли экстренных изменений до 10% можно считать приемлемым уровнем, хотя идеалом является их минимальное количество. Если доля экстренных изменений превышает 30% и не снижается, это указывает на неполноценное или отсутствующее управление изменениями.

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

Рейтинг: 988

Теги: управление изменениями

## [Как меняется организация при переходе на продуктовый подход?](https://cleverics.ru/digital/kb-qa/kak-menyaetsya-organizatsiya-pri-perekhode-na-produktovyy-podkhod/)

При переходе на продуктовый подход в организации появляются продуктовые роли: менеджеры, владельцы продуктов (product owners). Меняется структура отчётности и, возможно, подчинённости. Может быть проведена реорганизация структуры - например, создание продуктовых департаментов, где объединяются различные подразделения, работа которых ориентирована на конкретный продукт. В организации изменяется фокус управления: вместо оценки прибыльности отдельных проектов начинает учитываться жизненный цикл продукта и его общая прибыльность. Могут также появиться новые организационные механизмы, отвечающие за развитие продуктов.

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

Рейтинг: 988

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

## [Какие меры контроля рекомендуется применять для инцидентов, закрытых с кодом "Нет решения"?](https://cleverics.ru/digital/kb-qa/kakie-mery-kontrolya-rekomenduetsya-primenyat-dlya-intsidentov-zakrytykh-s-kodom-net-resheniya/)

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

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

Рейтинг: 988

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

## [Почему коммуникационные барьеры между командами усугубили проблему поддержки ИТ-услуг?](https://cleverics.ru/digital/kb-qa/pochemu-kommunikatsionnye-barery-mezhdu-komandami-usugubili-problemu-podderzhki-it-uslug/)

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

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

Рейтинг: 988

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