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

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

## [Как определить источники проблем с соблюдением сроков обработки запросов?](https://cleverics.ru/digital/kb-qa/kak-opredelit-istochniki-problem-s-soblyudeniem-srokov-obrabotki-zaprosov/)

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

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

Рейтинг: 1133

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

## [Как определить, что является дефектом, а что - частью функциональности?](https://cleverics.ru/digital/kb-qa/kak-opredelit-chto-yavlyaetsya-defektom-a-chto-chastyu-funktsionalnosti/)

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

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

Рейтинг: 1130

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

## [Как прозрачность способствует принятию изменений в организации?](https://cleverics.ru/digital/kb-qa/kak-prozrachnost-sposobstvuet-prinyatiyu-izmeneniy-v-organizatsii/)

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

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

Рейтинг: 1125

Теги: командная работа, лидерство, мотивация персонала, стимулирование, организационные изменения, агенты изменений, постоянное улучшение, совершенствование, CSI, PDCA, разработка ПО, трансформация, ускорение, Time-to-Market, эффективность, оптимизация

## [Как DevOps изменил традиционное понимание завершения разработки по сравнению с методологиями Agile?](https://cleverics.ru/digital/kb-qa/kak-devops-izmenil-traditsionnoe-ponimanie-zaversheniya-razrabotki-po-sravneniyu-s-metodologiyami-ag/)

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

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

Рейтинг: 1086

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

## [Что такое доступность ИТ-услуги и как она определяется?](https://cleverics.ru/digital/kb-qa/chto-takoe-dostupnost-it-uslugi-i-kak-ona-opredelyaetsya/)

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

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

Рейтинг: 1078

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

## [Как отличить управление дефектами от простой работы над дефектами?](https://cleverics.ru/digital/kb-qa/kak-otlichit-upravlenie-defektami-ot-prostoy-raboty-nad-defektami/)

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

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

Рейтинг: 1060

Теги: Agile и гибкие методы разработки ПО, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, командная работа, общие вопросы менеджмента, разработка ПО

## [Какова основная цель внедрения гибких практик в разработке ПО?](https://cleverics.ru/digital/kb-qa/kakova-osnovnaya-tsel-vnedreniya-gibkikh-praktik-v-razrabotke-po/)

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

Автор: Павел Капусткин

Рейтинг: 1058

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

## [Чем опасен накопленный технический долг для проекта?](https://cleverics.ru/digital/kb-qa/chem-opasen-nakoplennyy-tekhnicheskiy-dolg-dlya-proekta/)

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

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

Рейтинг: 1033

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

## [Как можно определить опережающие показатели для прогнозирования успеха процесса изменений?](https://cleverics.ru/digital/kb-qa/kak-mozhno-opredelit-operezhayushchie-pokazateli-dlya-prognozirovaniya-uspekha-protsessa-izmeneniy/)

Для определения опережающих показателей используется анализ причинно-следственных связей через Causal Loop Diagram. Опережающие показатели находятся на ранних этапах причинно-следственной цепочки и влияют на конечные результаты. Например, для прогнозирования успеха процесса изменений опережающими показателями могут служить Release size (размер релиза), Emergency change rate (доля аварийных изменений), Backlog size / Queue Time (управление бэклогом), Standard Change Rate (уровень стандартизации). Эти показатели позволяют прогнозировать такие конечные результаты, как Change Risk (риск изменений) и Time to Market (время выхода на рынок) до того, как эти результаты будут фактически достигнуты или проблемы проявятся.

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

Рейтинг: 1030

Теги: разработка ПО, трансформация, ускорение, Time-to-Market, управление процессами, ИТ-процессы, управление релизами, управление рисками

## [Какие последствия имеет игнорирование дефектов в программном обеспечении?](https://cleverics.ru/digital/kb-qa/kakie-posledstviya-imeet-ignorirovanie-defektov-v-programmnom-obespechenii/)

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

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

Рейтинг: 1028

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