Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Метрика First Time Resolution (FTR) в разрезе рабочих групп рассчитывается по формуле: FTR = (Nj - Sj) / Nj. Здесь Nj — количество обращений (инцидентов), обработанных j-той группой и закрытых без рекламаций (Cj), плюс количество возвратов на доработку в эту группу (Sj). Sj — это количество объектов, возвращенных на доработку в j-тую группу. Расчёт производится за период, когда завершена процедура проверки решения инцидента, а не фактическое решение задачи. Важно учитывать возвраты индивидуально по каждой группе, так как одно обращение может быть переназначено в другую группу или возвращено несколько раз в разные группы.
Эффективность команды определяется контекстом, включающим структуру задачи и окружающую среду. Коллектив профессионалов, ориентированных на выполнение задачи за вознаграждение, показывает хорошие результаты при работе с понятными, стабильными задачами, требующими индивидуальной экспертизы. Их эффективность обеспечивается четким пониманием результата и стабильными правилами игры. Такие команды устойчивы в негативной внешней среде. В свою очередь, команда-«семья» с сильными социальными связями эффективна при высокой неопределенности, когда задача требует нестандартных решений, творческого подхода и выхода за рамки стандартных процедур. Для выполнения задач, требующих сложных договоренностей, взаимного доверия и высокой ответственности, лучше подходят команды с сильными эмоциональными связями, особенно в благоприятной внешней среде.
Микросервисная архитектура представляет собой структуру приложения в виде облака небольших автономных сервисов, каждый из которых выполняет одну конкретную функцию. В отличие от монолитной архитектуры, где приложение выглядит как единый объект с определенными характеристиками, микросервисный подход разбивает приложение на множество изолированных компонентов. Эти сервисы могут различаться по версиям, иметь свои требования к входным данным и параметры производительности. Создание и удаление таких сервисов происходит автоматизированно с использованием контейнеров, что обеспечивает их независимость и гибкость.
Контроль и доверие могут быть как взаимоисключающими, так и взаимодополняющими подходами. Считается, что в условиях высокой мотивации и ответственности сотрудников контроль может снижать их эффективность, заменяясь доверием. Однако там, где отсутствует мотивация и ответственность, контроль становится необходимым. Оптимальная практика предполагает сочетание обоих подходов: использование контроля для укрепления доверия, когда это необходимо, и доверия для повышения мотивации, когда сотрудники демонстрируют высокую ответственность.
Дефект в разработке ПО - это несоответствие поведения ИТ-системы документированным требованиям к ней. Это проверяемое утверждение, которое минимизирует субъективность: если существует разница между описанным ожидаемым поведением системы и наблюдаемым фактическим поведением, то это дефект. Если такой разницы нет, дефекта также нет. Это определение позволяет выстраивать управление дефектами, хотя оно может быть ограничено в случаях, когда не все ожидания зафиксированы в требованиях.
Информационные технологии создают новые способы привлечения и обслуживания клиентов благодаря электронным каналам коммуникации и эффективному использованию информации. Они снижают зависимость от традиционной инфраструктуры, что уменьшает барьеры входа на рынок и ускоряет бизнес-изменения. Это приводит к появлению новых конкурентов даже в не-ИТ-сферах, вынуждая традиционные бизнесы трансформироваться. Примеры таких изменений видны в деятельности компаний как Google, Amazon, Uber, Spotify и Netflix, которые меняют целые отрасли, заставляя другие компании включаться в технологическую гонку.
Для решения проблемы, когда различные группы участников работают по своим правилам вследствие специфики деятельности, необходимо создать высокоуровневый процесс, состоящий из общих обязательных этапов. Внутри каждого этапа участники могут действовать в соответствии со своими особенностями. Например, для лебедя, щуки и рака из басни общим регламентом будет последовательность действий: загружаем-впрягаемся-тянем-выгружаем. А детали выполнения (влететь на определенную высоту для лебедя, нырнуть на глубину для щуки, ползти назад для рака) учитывают специфику каждого участника. Таким же образом можно описать общий процесс управления изменениями в ИТ-среде, добавив модели изменений для учета специфики каждой отдельной информационной системы.
Концентрация важна при многозадачности потому, что постоянные переключения между делами существенно снижают эффективность выполнения каждого из них. Способность фокусироваться на одной задаче позволяет глубже погружаться в процесс, избегать ошибок и завершать работу более качественно и быстро. Особенно это актуально для людей, сталкивающихся с большим объемом различных обязанностей, где навык концентрации становится фундаментальным для поддержания высокой производительности.
В гибких методологиях Scrum и SAFe роль руководителя проекта отсутствует, так как ее функции равномерно распределены между другими ролями. В Scrum ключевые обязанности перераспределяются между владельцем продукта, который отвечает за приоритизацию и ценность продукта, и скрам-мастером, который фокусируется на процессах и удалении препятствий для команды. Методология SAFe (Scaled Agile Framework) устанавливает собственную иерархию работ и ответственности через уровни Epic - Capability - Feature - Story, где каждому уровню соответствуют свои ответственные лица и методы работы. Таким образом, традиционный набор задач руководителя проекта в гибких подходах естественным образом делегируется разным ролям без необходимости выделять отдельного координатора проекта.
Жесткие лимиты численности персонала создают риски увеличения операционных затрат из-за вынужденного использования дорогостоящего аутстаффинга вместо прямого найма. Также возникает проблема снижения качества управления проектами, так как внешние сотрудники могут не обладать достаточной вовлеченностью и знанием внутренних процессов компании. Кроме того, такие ограничения мешают адаптации подразделений к меняющимся бизнес-требованиям, что ведет к неэффективному распределению ресурсов и потере гибкости.