Заметки консультанта

Шамрай Александр Владимирович

Posts Tagged ‘project’

CMMI DEV v1.3 – Количественное Управление Проектом

Posted by Шамрай Александр на Ноябрь 28, 2013

Перевод Шамрай А.В.

Процессная область Управления Проектом уровня зрелости 4

Назначение

Назначением Количественного Управления Проектом (КУП) является управление проектом на основе количественных показателей для достижения целей качества и выполнения процесса проекта.

Вступительный комментарий

Процессная область Количественное Управление Проектом включает в себя следующие мероприятия:

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

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

Определенный процесс проекта — это набор взаимосвязанных подпроцессов, которые образуют комплексный и последовательный процесс для проекта. Практики Комплексного Управления Проектом описывают установку определенного процесса проекта с использованием выбора и доводки процессов из набора стандартных процессов организации. (См. определение «определенный процесс» в глоссарии).

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

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

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

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

Таким образом количественное управление включает статистическое мышление и правильное использование различных статистических методов. (См. определение «количественное управление» в глоссарии).

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

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

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

  • Функции проверки качества или контроля качества
  • Определение и улучшение процесса
  • Функции внутреннего исследования и разработки
  • Функции идентификации и управления рисками
  • Функции технологий исследования
  • Исследования рынка
  • Оценка удовлетворенности заказчиков
  • Проблемы отслеживания и отчетности

Связанные процессные области

См. процессную область Анализ Причин и Принятие Решений для получения дополнительной информации о выявлении причин выбранных результатов и принятие мер для улучшения выполнения процесса.

См. процессную область Комплексное Управление Проектом для получения дополнительной информации о создании определенного процесса проекта.

См. процессную область Измерения и Анализ для получения дополнительной информации о мероприятиях обеспечения измерений и анализа и предоставления результатов измерений.

См. процессную область Определение Организационных Процессов для получения дополнительной информации о создании активов организационных процессов.

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

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

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

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

Перечень специфических целей и практик

  • СЦ 1 Подготовить Количественное Управление
    • СП 1.1 Устанавливайте Цели Проекта
    • СП 1.2 Составляйте Определенный Процесс
    • СП 1.3 Выбирайте Подпроцессы и Атрибуты
    • СП 1.4 Выбирайте Меры и Техники Аналитики
  • СЦ 2 Количественно Управлять Проектом
    • СП 2.1 Отслеживайте Выполнение Выбранных Подпроцессов
    • СП 2.2 Управляйте Выполнением Проекта
    • СП 2.3 Выполняйте Анализ Корневых Причин

Специфические практики по целям

СЦ 1 Подготовить Количественное Управление

Проведена подготовка для количественного управления.

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

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

СП 1.1 Устанавливайте Цели Проекта

Создавайте и поддерживайте проектные цели качества и выполнения процесса.

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

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

Пример рабочих продуктов

1. Проектные цели качества и выполнения процесса

2. Оценка риска не достижения целей проекта

Подпрактики

1. Анализируйте организационные цели для качества и выполнения процесса.

Эта оценка гарантирует, что члены проекта понимают более широкой бизнес-контекст, в котором существует проект. Цели проекта для качества и выполнения процесса разрабатываются в контексте этих всеобъемлющих организационных целей.

См. процессную область Показатели Организационных Процессов для получения дополнительной информации об установке целей качества и выполнения процесса.

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

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

Примеры атрибутов качества и выполнения процесса, для которых могут быть определены потребности и приоритеты, включают в себя следующее:

  • Продолжительность
  • Предсказуемость
  • Надежность
  • Ремонтопригодность
  • Удобство использования
  • Своевременность
  • Функциональность
  • Точность

3. Определяйте и документируйте измеряемые цели качества и выполнения процесса для проекта.

Определение и документирование целей проекта включают следующее:

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

Примеры поддающихся измерению атрибутов качества включают следующее:

  • Среднее время между сбоями
  • Количество и важность дефектов в выпущенном продукте
  • Использование критических ресурсов
  • Число и важность обращений заказчиков, относительно предоставляемых услуг

Примеры поддающихся измерению атрибутов выполнения процесса включают следующее:

  • Время цикла
  • Процент времени переработки
  • Процент дефектов удаленных путем мероприятий верификации продукта (возможно по типу верификации, таких как коллегиальные оценки и тестирование)
  • Уровень исправления дефектов
  • Количество и важность дефектов (или инцидентов) найденных в первый год после поставки продукта (или запуска сервиса)

Примеры проектных целей качества и выполнения процесса включают в себя:

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

4. Определяйте промежуточные цели для мониторинга прогресса в достижении целей проекта.

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

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

5. Определяйте риски, которые влияют на достижение проектных целей качества и выполнения процесса.

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

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

Модели выполнения процесса могут помочь выявить конфликты и способствовать тому, что решение конфликтов не вводит новые конфликты или риски.

Разрешение конфликтов предполагает следующие виды мероприятий:

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

7. Устанавливайте трассировку проектных целей качества и выполнения процесса к их источникам.

Примеры источников цели включают следующее:

  • Требования
  • Цели качества и выполнения процесса организации
  • Цели качество и выполнения процесса заказчика
  • Бизнес-цели
  • Обсуждение с заказчиками и потенциальными заказчиками
  • Обследование рынка
  • Архитектура продукта

Пример метода, позволяющего выявлять и отслеживать эти потребности и приоритеты, — развертывание функций качества (QFD).

8. Определяйте и согласовывайте цели качества и выполнения процесса для поставщиков.

9. Пересматривайте проектные цели качества и выполнения процесса по мере необходимости.

СП 1.2 Составляйте Определенный Процесс

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

См. процессную область Комплексное Управление Проектом для получения дополнительной информации о создании определенного процесса проекта.

См. процессную область Определение Организационных Процессов для получения дополнительной информации о создании активов организационных процессов.

См. процессную область Показатели Организационных Процессов для получения дополнительной информации о создании базовых показателей выполнения и модели.

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

Пример рабочих продуктов

1. Критерии, используемые для оценки альтернатив для проекта

2. Альтернативные подпроцессы

3. Подпроцессы, которые должны быть включены в определенный процесс проекта

4. Оценка риска, влияющего на достижение целей проекта

Подпрактики

1. Устанавливайте критерии для использования при оценке альтернатив процесса для проекта.

Критерии могут быть основаны на следующем:

  • Цели качества и выполнения процесса
  • Доступность данных о выполнении процесса и важность данных для оценки альтернатив
  • Знакомство с альтернативой или альтернативными вариантами, аналогичными составляемым
  • Наличие моделей выполнения процессов, которые могут быть использованы в оценке альтернатив
  • Стандарты линейки продукта
  • Модели жизненного цикла проекта
  • Требования заинтересованных сторон
  • Законы и правила

2. Определяйте альтернативные процессы и подпроцессы для проекта.

Выявление альтернатив может включать одно или несколько из следующих действий:

  • Анализ базовых показателей выполнения организационных процессов для определения кандидата в подпроцессы, которые помогли бы достичь проектные цели качества и выполнения процесса
  • Выявление подпроцессов из набора стандартных процессов, а также с учетом процессов в библиотеке активов процессов, которые могут помочь в достижении целей организации в
  • Выявление процессов из внешних источников (например, других организаций, профессиональных конференций, научных исследований)
  • Регулировка уровня или глубины интенсивности, с которой применяется подпроцесс (описано более подробно в подпрактике ниже)

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

  • Количество и тип коллегиальных оценок, которые состоятся и когда
  • Количество усилий или календарного времени, затрачиваемого на конкретные задачи
  • Число и выбор вовлекаемых людей
  • Требования к уровню квалификации для выполнения конкретных задач
  • Избирательное применение специализированных методов сборки или верификации
  • Повторное использование решений и связанных с ними стратегий для смягчения последствий рисков
  • Атрибуты продуктов и процессов для измерения
  • Частота дискретизации для управления данными

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

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

Анализ взаимодействия даст понимание относительных преимуществ и недостатков конкретных альтернатив. Этот анализ может поддерживаться калибровкой моделей выполнения процесса организации с данными выполнения процесса (например, как охарактеризовано в базовых показателях выполнения процесса).

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

4. Оценивайте альтернативные вспомогательные критерии.

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

См. процессную область Анализ и Принятие Решений для получения дополнительной информации об оценке альтернатив.

5. Выбирайте альтернативные подпроцессы, которые лучше всего соответствуют критериям.

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

6. Оценивайте риски не достижения целей качества и выполнения процесса для проекта.

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

См. процессную область Управление Рисками для получения дополнительной информации об идентификации и анализе рисков.

СП 1.3 Выбирайте Подпроцессы и Атрибуты

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

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

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

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

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

Пример рабочих продуктов

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

2. Выбранные подпроцессы

3. Атрибуты выбранных подпроцессов, которые помогают прогнозировать будущее выполнение проекта

Подпрактики

1. Анализируйте как подпроцессы, их атрибуты, другие факторы и результаты выполнения проекта связанные друг с другом.

Анализ корневых причин, анализ чувствительности или модель выполнения процесса могут помочь идентифицировать подпроцессы и атрибуты, которые наиболее способствуют достижению результатов определенного выполнения (и различия в результатах выполнения) или которые являются полезными показателями для будущего достижения результатов выполнения.

См. процессную область Анализ Причин и Принятие Решений для получения дополнительной информации об определении причин выбранных результатов.

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

Примеры критериев, используемых для выбора подпроцессов:

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

3. Выбирайте подпроцессы с помощью определенных критериев.

Исторические данные, модели выполнения процесса и базовые показатели выполнения процесса могут помочь в оценке кандидата подпроцесса на основе критериев отбора.

См. процессную область Анализ и Принятие Решений для получения дополнительной информации об оценке альтернатив.

4. Определяйте атрибуты продукта и процесса, которые должны контролироваться.

Эти атрибуты были определены в рамках выполнения предыдущих подпрактик.

Атрибуты, которые дают представление о текущем или будущем выполнении подпроцессов, являются кандидатами для мониторинга, находятся или нет связанные подпроцессы под контролем проекта. Кроме того, некоторые из этих же атрибутов могут служить для других ролей (например, помочь в мониторинге прогресса и выполнения проекта, как описано в Мониторинге и Контроле Проекта [МКП]).

Примеры атрибутов продукта и процесса включают в себя следующее:

  • Усилия, применяемые для выполнения подпроцесса
  • Скорость, на которой выполняется подпроцесс
  • Время цикла для элементов процесса, которые составляют подпроцесс
  • Ресурсы или материалы, использованных в качестве входных для подпроцесса
  • Уровень квалификации сотрудника, выполняющего подпроцесс
  • Качество рабочей среды, используемой для выполнения подпроцесса
  • Объем артефактов подпроцесса на выходе (например, промежуточные рабочие продукты)
  • Качество атрибутов подпроцесса на выходе (например, надежность, тестируемость)

СП 1.4 Выбирайте Меры и Техники Аналитики

Выбирайте меры и аналитические методы для использования в количественном управлении.

См. процессную область Измерения и Анализ для получения дополнительной информации о мероприятиях обеспечения измерений и анализа и предоставлении результатов измерений.

Пример рабочих продуктов

1. Определения мер и аналитических техник для использования в количественном управлении

2. Трассировка мер с проектными целями качества и выполнения процесса

3. Цели качества и выполнения процесса для выбранных подпроцессов и их атрибутов

4. Базовые показатели выполнения процесса и модели для использования в рамках проекта

Подпрактики

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

См. процессную область Определение Организационных Процессов для получения дополнительной информации о создании активов организационных процессов.

См. процессную область Показатели Организационных Процессов для получения дополнительной информации о создании базовых показателей и моделей выполнения.

Общие меры могут классифицироваться линейкой продукта или другими критериями стратификации.

2. Определяйте дополнительные меры, которые могут быть необходимы для покрытия важнейших атрибутов продукта и процесса выбранных подпроцессов.

В некоторых случаях меры может быть получены на основе исследований. Такие меры должны быть четко определены.

3. Определяйте меры, которые будут использоваться в управлении подпроцессов.

При выборе мер, имейте в виду следующие соображения:

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

4. Указывайте операционные определения мер, их точки сбора в подпроцессах и каким образом будет определяться целостность мер.

5. Анализируйте взаимосвязь выявленных мер и проектных целей качества и выполнения процесса, и производные цели качества и выполнения процесса для подпроцессов, которые задают целевые значения (например, пороговые значения, диапазоны) для каждого измеряемого атрибута каждого выбранного подпроцесса.

Примеры производных целей качества и выполнения процесса для подпроцессов включают в себя следующее:

  • Поддержка уровня рецензирования кода от 75 до 100 строк кода в час
  • Выдерживать длительность сессий сбора требования до трех часов
  • Выдерживать скорость тестирования на указанное количество тестовых случаев в день
  • Поддержка уровень переделки ниже указанного процента
  • Поддержка производительности в генерировании вариантов использования на один день
  • Выдерживать сложность проектирования (уровень разветвления) ниже заданного порогового значения

6. Определяйте статистические и другие количественные методы для использования в количественном управлении.

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

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

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

Примеры графических отображений:

  • Диаграммы рассеивания
  • Гистограммы
  • Ящик с усами
  • Графики выполнения
  • Диаграммы Исикавы

Примеры из других методов, используемых для анализа выполнения процесса, включают в себя следующее:

  • Учетные листы
  • Схемы классификации (например, Ортогональная Классификация Дефектов)

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

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

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

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

8. Инструментируйте для организационных сред или среды поддержки проекта для поддержки сбора, деривации и анализа мер.

Этот инструментарий основан на следующем:

  • Описании набора стандартных процессов организации
  • Описании определенного процесса проекта
  • Возможностях организационной или среды поддержки проекта

9. Пересматривайте меры и методы статистического анализа по мере необходимости.

СЦ 2 Количественно Управлять Проектом

Проект управляется количественно.

Количественное управление проектом включает в себя использование статистических и других количественных методов для выполнения следующих задач:

  • Мониторинг выбранных подпроцессов с использованием статистических и других количественных методов
  • Определение удовлетворены ли проектные цели качества и выполнения процесса
  • Выполнение анализа корневых причин выбранных проблем для устранения недостатков

СП 2.1 Отслеживайте Выполнение Выбранных Подпроцессов

Отслеживайте выполнение выбранных подпроцессов с использованием статистических и других количественных методов.

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

Пример рабочих продуктов

1. Естественные границы выполнение процесса для каждого выбранного атрибута подпроцессов

2. Действия, необходимые для устранения недостатков в стабильности процесса или возможностей каждого выбранного подпроцесса

Подпрактики

1. Собирайте данные, как это определено выбранными мерами, подпроцессов по мере их выполнения.

2. Контролируйте колебания и стабильность выбранных подпроцессов и устраняйте недостатки.

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

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

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

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

3. Отслеживайте возможности и выполнение выбранных подпроцессов и устраняйте недостатки.

Назначение этой подпрактики заключается в выявлении действий, которые следует предпринять, чтобы помочь подпроцессу достичь его цели качества и выполнения процесса. Будьте уверены, что выполнение подпроцессов является стабильным по отношению к выбранной мере (предыдущая подпрактика) перед сравнением его возможностей для целей качества и выполнения процесса.

Примеры действий, которые могут быть приняты, когда выполнение отдельных подпроцессов не удовлетворяет его целям, включают следующее:

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

Некоторые действия могут включать использование анализа корневых причин, который описан далее в СП 2.3.

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

СП 2.2 Управляйте Выполнением Проекта

Управляйте проектом с использованием статистических и других количественных методов для определения будут ли удовлетворены цели проекта для качества и выполнения процесса.

См. процессную область Измерение и Анализа для получения дополнительной информации о мероприятиях обеспечения измерений и анализа и предоставлении результатов измерений.

См. процессную область Управление Организационными Показателями для получения дополнительной информации об управлении показателями бизнеса.

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

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

Пример рабочих продуктов

1. Результаты прогнозов достижения относительно целей качества и выполнения процесса проекта

2. Графическое отображение и табулирование данных для других подпроцессов, поддерживающих количественное управление

3. Оценка рисков не достижения целей качества и выполнения процесса проекта

4. Действия, необходимые для устранения недостатков в достижении целей проекта

Подпрактики

1. Периодически оценивайте выполнение подпроцессов.

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

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

2. Отслеживайте и анализируйте прогресс поставщиков в достижении их целей качества и выполнения процесса.

3. Периодически рассматривайте и анализируйте фактические результаты, достигнутые в отношении установленных временных целей.

4. Используйте модели выполнения процесса калиброванные с данными проекта для оценки прогресса в достижении проектных целей качества и выполнения процесса.

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

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

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

5. Определяйте и управляйте рисками не достижения проектных целей качества и выполнения процесса.

См. процессную область Управления Рисками для получения дополнительной информации о выявлении и анализе рисков, и снижении рисков.

Примеры источников рисков включают следующее:

  • Подпроцессы, которые имеют неадекватное выполнение или возможности
  • Поставщики, которые не обеспечивают их цели качества и выполнения
  • Отсутствие прозрачности в возможностях поставщиков
  • Неточности в модели выполнения процесса, используемой для прогнозирования выполнения
  • Недостатки в выполнении прогнозируемого процесса (по оценкам прогресса)
  • Другие выявленные риски, связанные с выявленными недостатками

6. Определяйте и реализуйте действия, необходимые для устранения недостатков в достижении проектных целей качества и выполнения процесса.

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

Примеры действий, которые могут быть предприняты для устранения недостатков в достижении целей проекта, включают следующее:

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

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

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

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

СП 2.3 Выполняйте Анализ Корневых Причин

Выполняйте анализ корневых причин выбранных проблем для устранения недостатков в достижении проектных целей качества и выполнения процесса.

Адресуемые проблемы включают в себя недостатки стабильности и возможностей подпроцессов и недостатки в выполнении проекта относительно его целей.

Анализ корневых причин выбранных проблем лучше всего проводить вскоре после того, как проблема впервые выявлена, т.к. события произошли недавно, они могут быть тщательно исследованы.

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

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

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

Часто бывает трудно понять, сколько времени потребуется, если не провести первоначальный анализ недостатков.

См. процессную область Анализ Причин и Принятие Решений для получения дополнительной информации о выявлении причин выбранных результатов и принятие мер для улучшения выполнения процесса.

См. процессную область Измерения и Анализ для получения дополнительной информации о мероприятиях обеспечения измерения и анализа и предоставлении результатов измерений.

Пример рабочих продуктов

1. Измерения и анализ (включая статистический анализ) выполнения подпроцесса и проекта записанные в организационном репозитории мер

2. Графическое отображение данных, используемое для понимания результатов и тенденции выполнения подпроцесса и проекта

3. Выявленные корневые причины и потенциальные мероприятия

Подпрактики

1. Выполняйте по необходимости анализ корневых причин для диагностики недостатков выполнения процесса.

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

Использование моделей выполнения процесса в прогнозировании будущего выполнения проекта и процесса описана в подпрактике предыдущей специфической практике.

2. Выявляйте и анализируйте потенциальные мероприятия.

3. Реализуйте выбранные мероприятия.

4. Оценивайте воздействие принимаемых мер на выполнение подпроцессов.

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

Реклама

Posted in CMMI, Стандарты и методологии | Отмечено: , , , | Leave a Comment »

CMMI DEV v1.3 –Комплексное Управление Проектом

Posted by Шамрай Александр на Декабрь 6, 2011

Перевод Шамрай А.В.

Процессная область Управления Проектом уровня зрелости 3

Назначение

Назначением Комплексного Управления Проектом (КУП) является установка и управление проектом и участие соответствующих заинтересованных сторон в соответствии с комплексным и определенным процессом, который адаптирован из набора стандартных процессов организации.

Вступительный комментарий

Комплексное управление проектом включает в себя следующие мероприятия:

  • Установка определенного процесса проекта на начало проекта с использованием адаптации набора стандартных процессов организации
  • Управление проектом с использованием определенного процесса проекта
  • Установка рабочей среды для проекта, основанного на стандартах рабочей среды организации
  • Создание команды, которой поручено достичь цели проекта
  • Использование и способствование активам организационного процесса
  • Обеспечение возможности соответствующим заинтересованным сторонам быть определенными, принятыми во внимание и, при необходимости, привлеченными в ходе проекта
  • Обеспечение того, чтобы соответствующие заинтересованные стороны (1) выполняли свои задачи координировано и своевременно; (2) были согласованы с требования проекта, планами, целями, проблемами и рисками; (3) выполняли свои обязательства по выполнению; и (4) выявляли, отслеживали и решали проблемы координации

Комплексный и определенный процесс, который адаптирован из набора стандартных процессов организации, называется определенный процесс проекта. (См. определение «проект» в глоссарии.)

Управление трудозатратами проекта, затратами, сроками, персоналом, рисками и другими факторами связанно с задачами определенного процесса проекта. Реализация и управление определенным процессом проекта, как правило, описаны в плане проекта. Некоторые виды деятельностей могут быть включены в другие планы, которые влияют на проект, например, план обеспечения качества, стратегия управления рисками и план управления конфигурацией.

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

Эта процессная область также рассматривает координацию всех мероприятий, связанных с проектом, таких как следующие:

  • Мероприятия по разработке (например, разработка требований, проектирование, верификация)
  • Сервисные мероприятия (например, поставка, служба обслуживания, операции, контакты с клиентами)
  • Мероприятия по приобретению (например, предложения, мониторинг соглашений, передача в эксплуатацию)
  • Мероприятия по поддержке (например, управление конфигурацией, документация, маркетинг, обучение)

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

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

Связанные процессные области

См. процессную область Верификация для получения дополнительной информации о выполнении коллегиальных оценок.

См. процессную область Измерение и Анализ для получения дополнительной информации об обеспечении мероприятий измерения и анализа и предоставлении результатов измерений.

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

См. процессную область Мониторинг и Контроль Проекта для получения дополнительной информации о мониторинге проекта в соответствии с планом.

См. процессную область Планирование Проекта для получения дополнительной информации о разработке плана проекта.

Перечень специфических целей и практик

  • СЦ 1 Использовать Определенный Процесс Проекта
    • СП 1.1 Устанавливайте Определенный Процесс Проекта
    • СП 1.2 Используйте Активы Организационного Процесса для Планирования Проектных Мероприятий
    • СП 1.3 Устанавливайте Рабочую Среду Проекта
    • СП 1.4 Объединяйте Планы
    • СП 1.5 Управляйте Проектом Используя Объединенные Планы
    • СП 1.6 Устанавливайте Команды
    • СП 1.7 Содействуйте Активам Организационного Процесса
  • СЦ 2. Координировать и Сотрудничать с Соответствующими Заинтересованными Сторонами
    • СП 2.1 Управляйте Участием Заинтересованных Сторон
    • СП 2.2 Управляйте Зависимостями
    • СП 2.3 Решайте Проблемы Координации

Специфические практики по целям

СЦ 1 Использовать Определенный Процесс Проекта

Проект проводится с использованием определенного процесса адаптированного из множества стандартных процессов организации.

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

Процессы жизненного цикла продукта, такие как производство продукта и вспомогательные процессы, разрабатываются параллельно с продуктом.

СП 1.1 Устанавливайте Определенный Процесс Проекта

Создавайте и поддерживайте определенный процесс проекта от начала проекта и в течение всего срока проекта.

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

См. процессную область Фокусирование на Организационных Процессах для получения дополнительной информации о развертывании активов организационных процессов и внедрении стандартных процессов.

Определенный процесс проекта состоит из определенных процессов, которые формируют комплексный, последовательный жизненный цикл проекта.

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

Определенный процесс проекта основывается на следующих факторах:

  • Требования заинтересованных сторон
  • Обязательства по выполнению
  • Потребности и цели организационного процесса
  • Набор стандартных процессов организации и принципы адаптации
  • Операционная среда
  • Бизнес-среда

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

Пример рабочих продуктов

1. Определенный процесс проекта

Подпрактики

1. Выберите модель жизненного цикла из тех, которые доступны в активах организационных процессов.

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

  • Размер и сложность проекта
  • Стратегия проекта
  • Опыт и знания персонала в реализации процесса
  • Ограничения, такие как время цикла и приемлемые уровни дефектов
  • Наличие заказчиков для ответов на вопросы и обеспечение обратной связи для инкрементов
  • Ясность требований
  • Ожидания заказчика

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

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

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

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

4. Используйте другие артефакты из библиотеки активов процессов организации по мере необходимости.

Другие артефакты могут включать в себя следующее:

  • Документы с извлеченными уроками
  • Шаблоны
  • Примеры документов
  • Модели оценки

5. Документируйте определенный процесс проекта.

Определенный процесс проекта охватывает все виды деятельности по проекту и его интерфейсы для соответствующих заинтересованных сторон.

Примеры проектной деятельности включают следующее:

  • Планирование проекта
  • Мониторинг проекта
  • Управление поставщиками
  • Обеспечение качества
  • Управление рисками
  • Анализ и принятие решений
  • Разработка требований
  • Управление требованиями
  • Управление конфигурацией
  • Разработка и поддержка продукта
  • Рецензирование кода
  • Предложения

6. Проводите коллегиальные оценки определенного процесса проекта.

См. процессную область Верификация для получения дополнительной информации о выполнении коллегиальных оценок.

7. Пересматривайте определенный процесс проекта по мере необходимости.

СП 1.2 Используйте Активы Организационного Процесса для Планирования Проектных Мероприятий

Используйте активы организационных процессов и хранилище измерений для оценки и планирования мероприятий по проекту.

См. процессную область Определение Организационных Процессов для получения дополнительной информации о создании активов организационных процессов.

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

Пример рабочих продуктов

1. Оценки проекта

2. Планы проекта

Подпрактики

1. Используйте задачи и рабочие продукты определенного процесса проекта в качестве основы для оценки и планирования мероприятий по проекту.

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

2. Используйте хранилище измерений организации для оценки планирования параметров проекта.

Эта оценка обычно включает в себя следующее:

  • Соответствующие исторические данные из этого проекта или аналогичных проектов
  • Сходства и различия между текущим проектом и теми проектами, исторические данные которых будут использованы
  • Утвержденные исторические данные
  • Обсуждения, предположения и обоснования для выбора исторических данных
  • Обсуждения в широком круге опытных участников проекта

Примеры параметров, которые рассматриваются для определения сходства и различия, включают в себя следующее:

  • Рабочий продукт и атрибуты задачи
  • Область применения
  • Опыт людей
  • Подходы проектирования и разработки
  • Условия эксплуатации

Примеры данных, содержащихся в хранилище измерений организации, включают следующее:

  • Размер рабочих продуктов или другие атрибуты рабочих продуктов
  • Трудозатраты
  • Стоимость
  • Рабочий график
  • Кадровое обеспечение
  • Время отклика
  • Сервисные мощности
  • Работы поставщиков
  • Дефекты

СП 1.3 Устанавливайте Рабочую Среду Проекта

Устанавливайте и поддерживайте рабочую среду проекта, основанную на организационных стандартах рабочей среды.

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

Рабочая среда проекта может включать условия для интеграции продукта, верификации и валидации или они могут быть как отдельные среды.

См. специфическую практику Устанавливайте Среду Интеграции Продукта процессной области Интеграция Продукта для получения дополнительной информации об установке и поддержке среды интеграции продукта для проекта.

См. специфическую практику Устанавливайте Среду Валидации процессной области Валидация для получения дополнительной информации об установке и поддержке среды валидации для проекта.

См. специфическую практику Устанавливайте Среду Верификации процессной области Верификация для получения дополнительной информации об установке и поддержке среды верификации для проекта.

См. специфическую практику Устанавливайте Стандарты Рабочей Среды процессной области Определение Организационных Процессов для получения дополнительной информации о стандартах рабочей среды.

Пример рабочих продуктов

1. Оборудование и инструменты для проекта

2. Руководства по инсталляции, эксплуатации и обслуживанию для рабочей среды проекта

3. Пользовательские опросы и результаты

4. Журналы использования, выполнения и обслуживания

5. Сервисы поддержки для рабочей среды проекта

Подпрактики

1. Планируйте, проектируйте и инсталлируйте рабочую среду для проекта.

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

Может быть необходим поиск компромисса между атрибутами качества, затратами и рисками. Ниже приведены примеры каждого из них:

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

Примеры оборудования и инструментов включают в себя следующее:

  • Офисное программное обеспечение
  • Программного обеспечения поддержки принятия решений
  • Инструменты для управления проектами
  • Оборудование тестирования и оценки
  • Инструменты разработки и управления требованиями
  • Инструменты для управления конфигурацией
  • Инструменты оценки
  • Инструменты интеграции
  • Инструменты автоматизированного тестирования

2. Обеспечивайте текущее обслуживание и операционную поддержку рабочей среды проекта.

Обслуживание и поддержка рабочей среды может быть выполнена внутренними возможностями организации или заказанными за пределами организации.

Примеры подходов обслуживания и поддержки включают в себя следующее:

  • Прием на работу людей для выполнения обслуживания и поддержки
  • Обучение людей для выполнения обслуживания и поддержки
  • Контрактное обслуживание и поддержка
  • Подготовка опытных пользователей для отдельных инструментов

3. Поддерживайте квалификацию компонентов рабочей среды проекта.

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

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

Примеры действий, которые могут быть приняты, включают следующее:

  • Добавление новых инструментов
  • Получение дополнительных сетей, оборудования, обучения и поддержки

СП 1.4 Объединяете Планы

Интегрируйте план проекта и другие планы, которые затрагивают проект, для описания определенного процесса проекта.

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

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

См. процессную область Планирование Проекта для получения дополнительной информации о разработке плана проекта.

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

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

Пример рабочих продуктов

1. Объединенные планы

Подпрактики

1. Объединяйте другие планы, которые влияют на проект, с планом проекта.

Другие планы, которые влияют на план проекта, могут включать в себя следующее:

  • План обеспечение качества
  • Стратегия управления рисками
  • Планы валидации и верификации
  • Планы перехода в эксплуатацию и поддержку
  • Планы управления конфигурацией
  • Планы документирования
  • Планы обучения персонала
  • Планы обеспечения средствами и логистики

2. Интегрируйте в план проекта определения мер и мероприятий измерений по управлению проектом.

Примеры мер, которые могут быть включены, включают следующие:

  • Общие комплекс мер организации
  • Дополнительные специфические для проекта меры

См. процессную область Измерение и Анализ для получения дополнительной информации о разработке и поддержки возможности измерений, используемых для поддержки потребностей в области управления информацией.

3. Выявляйте и анализируйте риски интерфейсов проекта и продукта.

См. процессную область Управление Рисками для получения дополнительной информации о выявлении и анализе рисков.

Примеры рисков интерфейсов продукта и проекта включают следующее:

  • Неполные описания интерфейса
  • Отсутствие инструментов, поставщиков или оборудования тестирования
  • Отсутствие готовых коммерческих компонентов
  • Недостаточное или неэффективное командное взаимодействие

4. Готовьте календарные планы для задач в последовательности, которая учитывает критическую разработку, факторы поставки и риски проекта.

Примеры факторов, которые учитываются при планировании, включают следующее:

  • Размер и сложность задач
  • Потребности заказчиков и конечных пользователей
  • Наличие критических ресурсов
  • Наличие ключевых сотрудников
  • Интеграция и тестирование проблем

5. Включайте планы для проведения коллегиальных оценок по рабочим продуктам определенного процесса проекта.

См. процессную область Верификация для получения дополнительной информации о выполнении коллегиальных оценок.

6. Включайте обучение, необходимое для выполнения определенного процесса проекта, в планы проектного обучения.

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

7. Устанавливайте объективные входные и выходные критерии для авторизации начала и завершения задач, описанных в структуре декомпозиции работ (СДР).

См. процессную область Планирование Проекта для получения дополнительной информации об оценке границ проекта.

8. Убедитесь, что план проекта соответствующим образом совместим с планами соответствующих заинтересованных сторон.

Обычно план и изменения в план должны быть рассмотрены на совместимость.

9. Определяйте, как будут решены конфликты, которые возникают между соответствующими заинтересованными сторонами.

СП 1.5 Управляйте Проектом Используя Объединенные Планы

Управляйте проектом с помощью плана проекта, других планов, которые влияют на проект и определенный процесс проекта.

См. процессную область Определение Организационных Процессов для получения дополнительной информации об установке активов организационных процессов.

См. процессную область Фокусирование на Организационных Процессах для получения дополнительной информации об установке потребностей организационных процессов, развертывании активов организационных процессов и развертывании стандартных процессов.

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

См. процессную область Управление Рисками для получения дополнительной информации о выявлении и анализе рисков и смягчении рисков.

Пример рабочих продуктов

1. Рабочие продукты, созданные путем выполнения определенного процесса проекта

2. Собранные меры (например, фактические) и информация или отчеты о состоянии

3. Пересмотренные требования, планы и обязательства по выполнению

4. Объединенные планы

Подпрактики

1. Реализуйте определенный процесс проекта, используя библиотеку активов организационных процессов.

Эта задача обычно включает в себя следующие мероприятия:

  • Включение артефактов из библиотеки активов организационных процессов в проект по мере необходимости
  • Использование извлеченных уроков из библиотеки активов организационных процессов для управления проектом

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

Эта задача обычно включает в себя следующие мероприятия:

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

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

3. Получайте и анализируйте выбранные измерения для нужд управления проектом и организационной поддержки.

См. процессную область Измерение и Анализа для получения дополнительной информации о получении данных измерений и анализа данных измерений.

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

Эта оценка включает в себя согласование с потребностями и целями процесса организации.

Примеры действий, которые обеспечивают соответствие, включают следующее:

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

5. Рассматривайте причины выбранных проблем, которые могут повлиять на цели проекта.

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

СП 1.6 Устанавливайте Команды

Устанавливайте и поддерживайте команды.

Управление проект выполняется с использованием команд, которые отражают организационные правила и руководящие принципы для структурирования, формирования и функционирования команды. (См. определение «команда» в глоссарии.)

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

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

Один из лучших способов для обеспечения координации и сотрудничества с соответствующими заинтересованными сторонами это включение их в команду.

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

Пример рабочих продуктов

1. Документальное общее видение

2. Список членов назначенных в каждой команде

3. Устав команды

4. Периодические отчеты о состоянии команды

Подпрактики

1. Устанавливайте и поддерживайте общее видение проекта.

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

2. Устанавливайте и поддерживайте структуры команд.

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

3. Устанавливайте и поддерживайте каждую команду.

Установление и поддержка команды включает в себя выбор руководителей и членов команды и установка уставов команды для каждой команды. Также включается обеспечение ресурсов, необходимых для выполнения задач, поставленных перед командой.

4. Периодически оценивайте структуру и состав команды.

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

СП 1.7 Дополняйте Активы Организационного Процесса

Включайте опыт, относящийся к процессу, к активам организационных процессов.

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

См. процессную область Фокусирование на Организационных Процессах для получения дополнительной информации о включении опыта в активы организационных процессов.

Это специфическая практика затрагивает включаемую информацию от процессов из определенных процессов проекта в активы организационных процессов.

Пример рабочих продуктов

1. Предложения о совершенствовании активов организационных процессов

2. Фактические меры процесса и продукта собранные из проекта

3. Документация (например, примерные описания процесса, планы, учебные программы, контрольные списки, полученные уроки)

4. Артефакты процесса, связанные с адаптацией и реализацией набора стандартных процессов организации на проект

Подпрактики

1. Предлагайте усовершенствования активов организационных процессов.

2. Сохраняйте меры процессов и продуктов в хранилище измерений организации.

См. процессную область Измерение и Анализ для получения дополнительной информации о получении данных измерений.

См. процессную область Мониторинг и Контроль Проекта для получения дополнительной информации о мониторинге параметров планирования проекта.

См. процессную область Планирование Проекта для получения дополнительной информации о планировании управления данными.

Эти меры процесса и продукта обычно включают в себя следующее:

  • Плановые данные
  • Перепланированные данные

Примеры данных, записанных в рамках проекта, включают следующее:

  • Описание задач
  • Предположения
  • Оценки
  • Пересмотренные оценки
  • Определения записанных данных и мер
  • Меры
  • Контекстная информация, которая относится к измерению выполняемой деятельности и производимым рабочим продуктам
  • Связанная с этим информация необходимая для восстановления оценки, оценки их обоснованности, а также получения оценки для новой работы

3. Отправляйте документацию для возможного включения в библиотеку активов процессов организации.

Примеры документации включают следующее:

  • Примеры описания процесса
  • Материалы обучения
  • Примеры планов
  • Шаблоны контрольных списков
  • Шаблоны проектных хранилищ
  • Конфигурации инструментов

4. Документируйте уроки, извлеченные из проекта, для включения в библиотеку активов процессов организации.

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

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

СЦ 2 Координация и Сотрудничество с Соответствующими Заинтересованными Сторонами

Ведется координация и сотрудничество между проектом и соответствующими заинтересованными сторонами.

СП 2.1 Управляйте Участием Заинтересованных Сторон

Управление вовлечением соответствующих заинтересованных сторон в проекте.

Участие заинтересованных сторон управляется в соответствии с комплексным планом проекта и определенным процессом.

См. процессную область Планирование Проекта для получения дополнительной информации о планировании участия заинтересованных сторон и получении обязательств выполнения по плану.

Пример рабочих продуктов

1. Программа и календарные графики для совместной деятельности

2. Рекомендации по решению проблем соответствующих заинтересованных сторон

3. Документированные проблемы (например, проблемы с требованиями заинтересованных сторон, требованиями к продукту и компонентам продукта, архитектурой продукта, проектированием продукта)

Подпрактики

1. Координируйте с соответствующими заинтересованными сторонами кто должен участвовать в мероприятиях проекта.

Соответствующие заинтересованные стороны уже должны быть определены в плане проекта.

2. Проверяйте, соответствуют ли рабочие продукты, которые производятся для удовлетворения обязательств по выполнению, требованиям получателей.

См. процессную область Верификация для получения дополнительной информации о верификации отдельных видов рабочих продуктов.

Рабочие продукты, производимые для удовлетворения обязательств по выполнению, могут быть услугами.

Эта задача обычно включает в себя следующее:

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

3. Разрабатывайте рекомендации и координируйте действия для разрешения недоразумений и проблем с требованиями.

СП 2.2 Управляйте Зависимостями

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

Пример рабочих продуктов

1. Дефекты, проблемы и действия, получаемые в результате обзоров с соответствующими заинтересованными сторонами

2. Критические зависимости

3. Обязательства по выполнению для решения важнейших зависимостей

4. Состояние критических зависимостей

Подпрактики

1. Проводите обзоры с соответствующими заинтересованными сторонами.

2. Определяйте каждую критическую зависимость.

3. Устанавливайте желаемые сроки и плановые сроки для каждой критической зависимости на основе календарного графика проекта.

4. Рассматривайте и получайте согласие на обязательства по выполнения для каждой критической зависимости с теми, кто несет ответственность за предоставление или получение рабочего продукта.

5. Документируйте критические зависимости и обязательства по выполнению.

Документация обязательств по выполнению, как правило, включает следующее:

  • Описание обязательства по выполнению
  • Определение кто взял на себя обязательство по выполнению
  • Определение кто несет ответственность за удовлетворение обязательств по выполнению
  • Определение, когда обязательства по выполнению будут выполнены
  • Определение критериев для определения было ли обязательство по выполнению выполнено

6. Отслеживайте критические зависимости и обязательства по выполнению и предпринимайте корректирующие действия в случае необходимости.

См. процессную область Мониторинг и Контроль Проекта для получения дополнительной информации о мониторинге обязательств по выполнению.

Отслеживание критических зависимостей обычно включает в себя следующее:

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

СП 2.3 Решайте Проблемы Координации

Решайте проблемы с соответствующими заинтересованными сторонами.

Примеры вопросов координации включают следующее:

  • Требования к продукту и компонентам продукта и дефекты проектирования
  • Запаздывающие критические зависимости и обязательства по выполнению
  • Проблемы на уровне продукта
  • Недоступность критических ресурсов или персонала

Пример рабочих продуктов

1. Проблемы координации с соответствующими заинтересованными сторонами

2. Состояние проблем координации соответствующих заинтересованных сторон

Подпрактики

1. Выявляйте и документируйте проблемы.

2. Уведомляйте о проблемах соответствующие заинтересованные стороны.

3. Решайте проблемы с соответствующими заинтересованными сторонами.

4. Эскалируйте на соответствующих менеджеров проблемы, которые не были решены с соответствующими заинтересованными сторонами.

5. Отслеживайте проблемы до их закрытия.

6. Сообщайте соответствующим заинтересованным сторонам о состоянии и решении возникших проблем.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , , , | Leave a Comment »

CMMI DEV v1.3 – Мониторинг и Контроль Проекта

Posted by Шамрай Александр на Январь 13, 2011

Перевод Шамрай А.В.

Процессная область Управления Проектом уровня зрелости 2

Назначение

Назначением мониторинга и контроля проекта (МКП) заключается в обеспечении понимания прогресса проекта для того, чтобы можно было предпринять соответствующие корректирующие действия, когда выполнение проекта значительно отклоняется от плана.

Вступительный комментарий

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

Термин «план проекта» используется в этой процессной области как общий план для контроля проекта.

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

Связанные процессные области

См. процессную область Измерения и Анализ для получения дополнительной информации о спецификации измерений.

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

Перечень специфических целей и практик

  • СЦ 1 Мониторинг Проекта на Основе Плана
    • СП 1.1 Выполняйте Мониторинг Параметров Планирования Проекта
    • СП 1.2 Выполняйте Мониторинг Обязательств по Выполнению
    • СП 1.3 Выполняйте Мониторинг Рисков Проекта
    • СП 1.4 Выполняйте Мониторинг Управления Данными
    • СП 1.5 Выполняйте Мониторинг Участия Заинтересованных Сторон
    • СП 1.6 Проводите Анализ Выполнения
    • СП 1.7 Проводите Анализ Вех
  • СЦ 2 Управление Корректирующими Действиями до Их Закрытия
    • СП 2.1 Анализируйте Проблемы
    • СП 2.2 Принимайте Корректирующие Действия
    • СП 2.3 Управляйте Корректирующими Действиями

Специфические практики по целям

СЦ 1 Мониторинг Проекта на Основе Плана

Реальный прогресс и выполнение проекта контролируется на основе плана проекта.

СП 1.1 Выполняйте Мониторинг Параметров Планирования Проекта

Выполняйте мониторинг фактических значений параметров планирования проекта по отношению к плану проекта.

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

Мониторинг, как правило, предполагает измерение фактических значений параметров планирования проекта, сравнение фактических значений со значениями в плане, а также выявление существенных отклонений. Запись фактических значений параметров планирования проекта включает в себя запись контекстно-связанной информации для облегчения понимания измерений. Анализ последствий значительных отклонений для определения корректирующих действий выполняется в специфической цели 2 и ее специфическими практиками в текущей процессной области.

Пример рабочих продуктов

1. Отчеты по выполнению проекта

2. Отчеты по значительным отклонениям

3. Финансовые отчеты

Подпрактики

1. Выполняйте мониторинг выполнения на основе рабочего графика.

Мониторинг выполнения обычно включает в себя следующее:

  • Периодические замеры фактического завершения работ и вех
  • Сравнение фактического завершения работ и вех с рабочим графиком плана проекта
  • Выявление существенных отклонений от оценок в графике плана проекта

2. Контролируйте стоимость проекта и выполненных трудозатрат.

Мониторинг трудозатрат и стоимости обычно включает в себя следующее:

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

3. Выполняйте мониторинг атрибутов рабочих продуктов и задач.

См. процессную область Измерения и Анализ для получения дополнительной информации о разработке и поддержке возможностей измерения, используемых для поддержки информационных потребностей управления.

См. процессную область Планирования Проекта для получения дополнительной информации о создании оценки атрибутов рабочих продуктов и задач.

Мониторинг атрибутов рабочих продуктов и задач, как правило, включает следующее:

  • Периодические замеры фактических атрибутов рабочих продуктов и задач, таких как размер, сложность и уровень сервиса (и изменений к этим атрибутам)
  • Сравнение фактических атрибутов рабочих продуктов и задач (и изменений к этим атрибутам) с оценками плана проекта
  • Выявление существенных отклонений от оценок плана проекта

4. Выполняйте мониторинг предусмотренных и используемых ресурсов.

См. процессную область Планирования Проекта для получения дополнительной информации о планировании ресурсов проекта.

Примеры ресурсов:

  • Физические объекты
  • Компьютеры, периферийные устройства и программное обеспечение
  • Сети
  • Обеспечение безопасности
  • Сотрудники проекта
  • Процессы

5. Выполняйте мониторинг знаний и навыков сотрудников проекта.

См. процессную область Планирования Проекта для получения дополнительной информации о планировании необходимых знаний и навыков.

Мониторинг знаний и навыков сотрудников проекта обычно включает в себя следующее:

  • Периодические замеры приобретенных знаний и навыков сотрудниками проекта
  • Сравнение фактической подготовки с тем, что описано в плане проекта
  • Выявление существенных отклонений от оценок плана проекта

6. Документируйте значительные отклонения в параметрах планирования проекта.

 

СП 1.2 Выполняйте Мониторинг Обязательств по Выполнению

Выполняйте мониторинг взятых обязательств по выполнению работ в отношении с определенными работами в плане проекта.

Пример рабочих продуктов

1. Отчеты по анализу обязательств по выполнению

Подпрактики

1. Регулярно проводите анализ обязательств по выполнению (как внешних, так и внутренних).

2. Определите какие обязательства не были выполнены или какие имеют значительный риск их невыполнения.

3. Документируйте результаты анализа обязательств по выполнению.

 

СП 1.3 Выполняйте мониторинг Рисков Проекта

Выполняйте мониторинг рисков на основе тех, которые указаны в плане проекта.

См. процессную область Планирования Проекта для получения дополнительной информации о выявлении рисков проекта.

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

Пример рабочих продуктов

1. Отчеты по мониторингу рисков проекта

Подпрактики

1. Периодически анализируйте документацию по рискам в контексте текущего состояния и обстоятельств проекта.

2. Пересматривайте документацию по рискам при появлении дополнительной информации.

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

3. Сообщайте о состоянии рисков соответствующим заинтересованным лицам.

Примеры состояний риска:

  • Изменение вероятности того, что риск возникнет
  • Изменение приоритета риска

СП 1.4 Выполняйте Мониторинг Управления Данными

Выполняйте мониторинг управления проектными данными в соответствие плану проекта.

См. специфическую практику Планирование Управления Данными процессной области Планирование Проекта для получения дополнительной информации об определении типов данных для управления и как планировать их управление.

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

Пример рабочих продуктов

1. Отчеты по управлению данными

Подпрактики

1. Периодически анализируйте деятельность по управлению данными в отношении их описания в плане проекта.

2. Выявляйте и документируйте важные проблемы и их последствия.

Примером серьезной проблемы может быть, когда заинтересованные стороны не имеют доступа к данным проекта, к которым они должны иметь доступ в соответствии с их ролью.

3. Документируйте результаты анализа мероприятий по управлению данными.

 

СП 1.5 Выполняйте Мониторинг Участия Заинтересованных Сторон

Выполняйте мониторинг участия заинтересованных сторон в соответствие плану проекта.

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

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

В Agile среде постоянное участие клиентов и потенциальных конечных пользователей в разработке продукта проекта может иметь решающее значение для успеха проекта, поэтому участие клиентов и конечных пользователей в проектной деятельности должно отслеживаться. (См. «CMMI при использовании Agile подходов» в части I.)

Пример рабочих продуктов

1. Отчеты по участию заинтересованных сторон

Подпрактики

1. Периодический анализируйте состояния участия заинтересованных сторон.

2. Выявляйте и документируйте важные проблемы и их последствия.

3. Документируйте результаты анализа состояния участия заинтересованных сторон.

 

СП 1.6 Проводите Анализ Прогресса

Периодически выполняйте анализ прогресса, выполнения и проблем проекта.

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

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

Пример рабочих продуктов

1. Документальные результаты анализа проекта

Подпрактики

1. Регулярно сообщайте состояние назначенных задач и рабочих продуктов соответствующим заинтересованным сторонам.

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

2. Анализируйте результаты собранных и проанализированных замеров для контроля проекта.

Рассматриваемые измерения могут включать в себя уровень удовлетворенности клиентов.

См. процессную область Измерение и Анализ для получения дополнительной информации о совмещении мероприятий по измерению и анализу и предоставлении результатов измерений.

3. Выявляйте и документируйте важные проблемы и отклонения от плана.

4. Документируйте запросы на изменение и проблемы, выявленные в рабочих продуктах и процессах.

См. процессную область Управления Конфигурацией для получения дополнительной информации об отслеживании и контроле изменений.

5. Документируйте результаты анализа.

6. Отслеживайте запросы на изменение и ведите отчеты о проблемах до их закрытия.

 

СП 1.7 Проводите Анализ Вех

Анализируйте достижения и результаты проекта в отдельных вехах проекта.

См. специфическую практику Установка Бюджета и Графика процессной области Планирование проекта для получения дополнительной информации об определении основных вех.

Вехи – это предварительно запланированные мероприятия или моменты во времени, в которых проводится тщательный анализ состояния с целью понять, насколько хорошо удовлетворяются требования заинтересованных сторон (Если проект включает в себя веху разработки, то анализ проводится с целью обеспечения того, что предположения и требования, ассоциированные с этой вехой, удовлетворяются). Вехи могут быть связаны с проектом в целом или с конкретным видом услуг или экземпляра. Таким образом, вехи могут на основе событий или на основе календаря.

Анализ вехи планируется во время планирования проекта и, как правило, это формальные проверки.

Анализ прогресса и анализ вехи не обязательно должны проводиться отдельно. Одним анализом можно провести два. Например, один запланированный анализ может оценить прогресс, проблемы и выполнение через планируемый период времени (или веху) на соответствие ожиданиям плана.

В зависимости от проекта, анализ вех может покрывать фазы «Запуск проекта» и «Закрытие проекта».

Пример рабочих продуктов

1. Документальные результаты анализа вехи

Подпрактики

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

С руководителями, сотрудниками, клиентами, конечными пользователями, поставщиками и другими соответствующими заинтересованными сторонами, включаемыми в анализ вехи по мере необходимости.

2. Анализируйте обязательства по выполнению, планы, состояния и риски проекта.

3. Выявляйте и документируйте важные проблемы и их последствия.

4. Документируйте результаты анализа, действий и решений.

5. Отслеживайте действия до их закрытия.

СЦ 2 Управление Корректирующими Действиями до Их Закрытия

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

СП 2.1 Анализируйте Проблемы

Собирайте и анализируйте проблемы, определяйте корректирующие действия по их устранению.

Пример рабочих продуктов

1. Список проблем, требующих корректирующих действий

Подпрактики

1. Собирайте проблемы для анализа.

Проблемы собираются на основе анализа и выполнения других процессов.

Примеры проблем:

  • Проблемы, обнаруженные при проведении технического анализа, проверки и утверждения
  • Значительные отклонения в параметрах планирования проекта от оценок в плане проекта
  • Обязательства по выполнению (внутренние или внешние), которые не были выполнены
  • Существенные изменения в состоянии риска
  • Проблемы доступа к данным, сбора, конфиденциальности или безопасности
  • Проблемы представления и участия заинтересованных сторон
  • Предложения по продукту, инструменту или среды передачи (или другие предложения клиентов или поставщиков), которые не были достигнуты

2. Анализировать проблемы для определения необходимости принятия корректирующих действий.

См. специфическую практику Установка Бюджета и Графика процессной области Планирование Проекта для получения дополнительной информации о критериях для корректирующих действий.

Корректирующие действия требуются по проблеме в том случае, если по этой проблеме ничего не будет предпринято, то не будут достигнуты цели проекта.

 

СП 2.2 Принимайте Корректирующих Действий

Принимайте меры по исправлению выявленных проблем.

Пример рабочих продуктов

1. Планы корректирующих действий

Подпрактики

1. Определяйте и документируйте соответствующие действия, необходимые для решения выявленных проблем.

См. процессную область Планирования Проекта для получения дополнительной информации о разработке плана проекта.

Примеры возможных действий:

  • Изменение Технического Задания
  • Изменение Требований
  • Пересмотр оценок и планов
  • Новое согласование обязательств по выполнению
  • Добавление ресурсов
  • Изменение процессов
  • Пересмотр рисков проекта

2. Анализируйте и согласовывайте с соответствующими заинтересованными сторонами действия, которые необходимо принять.

3. Согласовывайте изменения внутренних и внешних обязательств по выполнению.

 

СП 2.3 Управляйте Корректирующими Действиями

Управляйте корректирующими действиями для их закрытия.

Пример рабочих продуктов

1. Результаты корректирующих действий

Подпрактики

1. Выполняйте мониторинг корректирующих действий для их завершения.

2. Анализируйте результаты корректирующих действий для определения их эффективности.

3. Определяйте и документируйте соответствующие действия для исправления отклонений от запланированных результатов по выполнению корректирующих действий.

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

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , | 2 комментария »

CMMI DEV v1.3 – Планирование проекта

Posted by Шамрай Александр на Январь 11, 2011

Перевод Шамрай А.В.

Процессная область Управления Проектом уровня зрелости 2

Назначение

Назначением Планирования Проекта (ПП) является формирование и поддержка планов, которые определяют проектную деятельность.

Вступительный комментарий

Один из ключевых моментов эффективного управления проектом является планирование проекта. Процессная область Планирование Проекта включает в себя следующие мероприятия:

  • Разработка плана проекта
  • Взаимодействие с соответствующими заинтересованными сторонами на надлежащем уровне
  • Получение обязательств по реализации плана
  • Поддержка плана

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

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

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

Для линейки продукта, существует различный набор мероприятий, которые выиграют от использования практик этой процессной области. Эти мероприятия включают в себя создание и поддержку основных активов, разработку продуктов с использованием основных активов и организацию общих трудозатрат для поддержки и координации операций взаимосвязанных рабочих групп и их деятельности. В Agile среде инкрементальная разработка включает в себя планирование, мониторинг, контроль и перепланировке чаще, чем в традиционной разработке. Хотя план на высоком уровне для всего проекта или трудозатрат обычно создается, команды оценивают, планируют и обеспечивают фактическое выполнение инкремента или итерации все время. Обычно команды не прогнозируют то, что вне проекта или итерации, за исключением прогнозирования рисков, основных событий и крупномасштабных воздействий и ограничений. Оценки отражают итерационные и командные факторы, которые влияют на время, трудозатраты, ресурсы и риски для выполнения итерации. Команда планирует, отслеживает и корректирует планы во время выполнения каждой итерации так часто, на сколько это требуется (например, ежедневно). Обязательства по выполнению в плане обеспечиваются, когда задачи назначены и приняты во время планирования итерации, пользовательские истории разработаны или оценены и итерации составлены из задач, содержащихся в журнале работ. (См. «CMMI при использовании Agile подходов» в части I.)

Связанные процессные области

См. процессную область Разработка Требований для получения дополнительной информации о выявлении, анализе и создании требований заказчика, требований к продукту и к компонентам продукта.

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

См. процессную область Измерения и Анализ для получения дополнительной информации о спецификации измерений.

См. процессную область Управление Требованиями для получения дополнительной информации о управлении требованиями.

См. процессную область Управление Рисками для получения дополнительной информации о выявлении и анализе рисков, смягчении рисков.

Перечень специфических целей и практик

  • СЦ 1 Сформировать Оценки
    • СП 1.1 Оценивайте Масштаб Проекта
    • СП 1.2 Формируйте Оценки Атрибутов Рабочих Продуктов и Задач
    • СП 1.3 Определяйте Фазы Жизненного Цикла Проекта
    • СП 1.4 Оценивайте Трудозатраты и Стоимость
  • СЦ 2 Разработать Плана Проекта
    • СП 2.1 Формируйте Бюджет и График
    • СП 2.2 Определяйте Риски Проекта
    • СП 2.3 Планируйте Управление Данными
    • СП 2.4 Планируйте Ресурсы Проекта
    • СП 2.5 Планируйте Необходимые Знания и Навыки
    • СП 2.6 Планируйте Участие Заинтересованных Сторон
    • СП 2.7 Создайте План Проекта
  • СЦ 3 Получить Обязательства Выполнения по Плану
    • СП 3.1 Пересматривайте Планы, Которые Затрагивают Проект
    • СП 3.2 Согласовывайте Объемы Работы и Ресурсы
    • СП 3.3 Получайте Обязательства Выполнения по Плану

Специфические практики по целям

СЦ 1 Сформировать Оценки

Оценки параметров планирования проекта сформированы и поддерживаются.

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

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

Факторы, которые следует учитывать при оценке этих параметров, включают требования к проекту, в том числе требования к продукту, требования, предъявляемые организацией, требования, предъявляемые заказчиком, и другие требования, которые влияют на проект.

Документация по обоснованию оценивания и поддержки данных должна быть рассмотрена и утверждена в планах заинтересованными сторонами и должна выдерживаться в планах по мере выполнения проекта.

СП 1.1 Оценивайте Масштаб Проекта

Создавайте структуру декомпозиции работ (СДР) верхнего уровня для оценки масштаба проекта.

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

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

Некоторые проекты используют термин «контрактная СДР», т.е. часть СДР размещается в контракте (возможно, вся СДР). Не все проекты имеют контрактную СДР (например, внутренне финансируемые разработки).

Пример рабочих продуктов

1. Описания задач

2. Описания рабочего пакета

3. СДР

Подпрактики

1. Разрабатывайте СДР.

СДР обеспечивает схему для организации работ проекта. СДР должна обеспечивать идентификацию следующих пунктов:

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

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

СДР верхнего уровня предназначена для того, чтобы помочь оценить трудозатраты проектных работ для задач, организационных ролей и обязанностей. Уровень детализации СДР на этом уровне помогает разработке реалистичных рабочих графиков и тем самым сводит к минимуму необходимость выделения резерва.

3. Определяйте продукты и компонентов, необходимые для внешней закупки.

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

4. Определяйте рабочие продукты, которые можно повторно использовать.

СП 1.2 Формируйте Оценки Атрибутов Рабочих Продуктов и Задач

Обеспечивайте и поддерживайте оценивание атрибутов рабочих продуктов и задач.

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

Примеры атрибутов для оценки:

  • Количество и сложность требований
  • Количество и сложность интерфейсов
  • Объем данных
  • Количество функций
  • Функциональные единицы
  • Количество строк кода
  • Количество классов и объектов
  • Количество таблиц базы данных
  • Количество полей в таблицах данных
  • Архитектурные элементы
  • Опыт работы участников проекта
  • Объем кода, который необходим для обеспечения повторного использования вместо новой разработки
  • Командная производительность и сложность
  • Количество страниц
  • Количество входных и выходных элементов
  • Количество технических рисков
  • Количество логических соединений для интеграционных схем
  • Количество частей (например, печатных плат, компонентов, механических частей)
  • Физические ограничения (например, вес, объем)
  • Географическое распределение участников проекта
  • Близость клиентов, конечных пользователей и поставщиков
  • Как сложно или легко договориться с клиентом
  • Качество и «чистота» существующего кода

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

Пример рабочих продуктов

1. Размер и сложность задач и рабочих продуктов

2. Оценка моделей

3. Атрибут оценки

4. Технический подход

Подпрактики

1. Определяйте технический подход к проекту.

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

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

Методы определения размера и сложности должны быть основаны на утвержденных моделях или исторических данных.

Методы определения атрибутов развиваются с пониманием отношений характеристик продукта к его атрибутам.

3. Оценивайте атрибуты рабочих продуктов и задач.

Примеры рабочих продуктов, для которых выполняется оценка размера:

  • Поставляемые и непоставляемые рабочие продукты
  • Документы и файлы
  • Операционное и поддерживающее оборудование, микропрограммы и программное обеспечение

СП 1.3 Определяйте Фазы Жизненного Цикла Проекта

Определяйте фазы жизненного цикла проекта, которые обеспечат границы планирования.

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

Понимание жизненного цикла проекта имеет решающее значение при определении границ планирования и сроков для первоначального планирования, а также сроков и критериев (критических вех) для перепланирования.

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

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

Пример рабочих продуктов

1. Фазы жизненного цикла проекта

СП 1.4 Оценивайте Трудозатраты и Стоимость

Оценивайте трудозатраты проекта и стоимость рабочих продуктов и задач на основании обоснованных оценок.

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

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

Пример рабочих продуктов

1. Обоснование оценки

2. Оценка трудозатрат проекта

3. Оценка стоимости проекта

Подпрактики

1. Собирайте модели или исторические данные, которые будут использоваться для преобразования атрибутов рабочих продуктов и задач в оценки рабочего времени и стоимости.

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

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

2. Включайте поддержку инфраструктурных потребностей при оценке трудозатрат и стоимости.

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

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

Примеры инфраструктурных ресурсов:

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

3. Оценивайте трудозатраты и стоимость с использованием моделей, исторических данных или комбинации обоих.

Примеры рабочих продуктов, которые обычно используются для оценки трудозатрат и стоимости:

  • Оценки, выполняемые экспертом или группой экспертов (например, метод Дельфи, Игра по планированию в Экстремальном программировании)
  • Риски, в том числе, в какой степени трудозатраты являются беспрецедентным
  • Критические компетенции и роли, необходимые для выполнения работы
  • Перемещение
  • СДР
  • Выбранная модель жизненного цикла проекта и процессов
  • Оценки стоимости жизненного цикла
  • Уровень квалификации руководителей и сотрудников, необходимых для выполнения работы
  • Необходимые знания, навыки и обучение
  • Прямые трудовые затраты и накладные расходы
  • Соглашение об обслуживании для колл-центров и гарантийных работ
  • Уровень безопасности, необходимый для задач, рабочих продуктов, оборудования, программного обеспечения, персонала и рабочего окружения
  • Необходимые средства (например, офис, помещения для совещаний и рабочие станции)
  • Требования к продукту и компонентам продукта
  • Оценки размера рабочих продуктов, задач и ожидаемых изменений
  • Стоимость внешне приобретенных продуктов
  • Возможности производственных процессов
  • Потребности в инженерных средствах
  • Возможности инструментов, используемых в инженерной среде
  • Технический подход

СЦ 2 Разработать План Проекта

План проекта создан и поддерживается в качестве основы для управления проектом.

План проекта является формальным, утвержденным документом, который используется для управления и контроля исполнения проекта. Он основан на требованиях проекта и установленных оценках.

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

СП 2.1 Формируйте Бюджет и График

Формируйте и поддерживайте бюджет и график проекта.

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

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

Пример рабочих продуктов

1. Рабочие графики проекта

2. Графики зависимостей

3. Бюджет проекта

Подпрактики

1. Определяйте основные вехи.

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

2. Определяйте предположения по графику.

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

3. Определяйте ограничения.

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

4. Определяйте зависимости задачи.

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

Примеры инструментов и материалов, которые могут помочь определить оптимальный порядок задач:

  • Метод критического пути (CPM)
  • Техники оценки и анализа программы (PERT)
  • Планирование с ограниченными ресурсами
  • Приоритеты клиента
  • Рыночные возможности
  • Значение для конечных пользователей

5. Формируйте и поддерживайте бюджет и график.

Формирование и поддержка бюджета проекта и графика обычно включает в себя следующее:

  • Определение наличия подтвержденных или ожидаемых ресурсов и средств
  • Определение времени фаз мероприятий
  • Определение срывов подчиненных графиков
  • Определение зависимостей между различными видами деятельности (связи с предшественниками или последователями)
  • Определение рабочего графика мероприятий и вех для поддержки мониторинга и контроля проекта
  • Определение вех, релизов или инкрементов на поставку продуктов для клиентов
  • Определение мероприятий для соответствующей продолжительности
  • Определение вех для соответствующего разделения времени
  • Определение резерва в планировании на основе уровня достоверности в выполнении графика и бюджета
  • Использование соответствующих исторических данных для проверки графика
  • Определение потребности в инкрементном финансировании
  • Документирование проектных предположений и обоснований

6. Создавайте критерии корректирующих действий.

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

СП 2.2 Определяйте Риски Проекта

Выявляйте и анализируйте риски проекта.

См. специфические практики Мониторинг Рисков Проекта в процессной области Мониторинг и Контроль Проекта для получения дополнительной информации о мониторинге рисков.

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

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

Планирование идентификации и анализа рисков в проекте обычно включает в себя следующее:

  • Выявление рисков
  • Анализ рисков для определения воздействия, вероятности возникновения и временных рамок, в которые проблемы могут возникнуть
  • Приоритезация рисков

Пример рабочих продуктов

1. Выявленные риски

2. Воздействия риска и вероятности возникновения

3. Приоритеты рисков

Подпрактики

1. Выявляйте риски.

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

Примеры инструментов для выявления и анализа рисков:

  • Таксономия рисков
  • Оценка рисков
  • Контрольные списки
  • Структурированные интервью
  • Мозговой штурм
  • Процессные, проектные и модели эффективности продукта
  • Стоимостные модели
  • Сетевой анализ
  • Анализ факторов качества

2. Документируйте риски.

3. Анализируйте и согласовывайте с соответствующими заинтересованными сторонами документированные риски на полноту и правильность.

4. Пересматривайте риски по мере необходимости.

Примеры, когда выявленные риски, возможно, должны быть пересмотрены:

  • Когда выявлены новые риски
  • Когда риски станут проблемами
  • Когда риски удаляются
  • Когда обстоятельства проекта значительно изменились

СП 2.3 Планируйте Управление Данными

Планируйте управление данными проекта.

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

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

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

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

Пример рабочих продуктов

1. План управления данными

2. Главный список управляемых данных

3. Описание содержания и формата данных

4. Списки требований к данным для покупателей и поставщиков

5. Конфиденциальные требования

6. Требования к безопасности

7. Процедуры обеспечения безопасности

8. Механизмы для получения, воспроизведение и распространение данных

9. Расписание для сбора данных проекта

10. Список собираемых данных проекта

Подпрактики

1. Устанавливайте требования и процедуры для обеспечения конфиденциальности и безопасности данных.

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

2. Создавайте механизм для архивирования данных и доступа к архивным данным.

Информация по доступу должна быть в понятной форме (например, в электронном или компьютерном виде из базы данных) или предоставлена в первоначальном виде.

3. Определяйте данные проекта, которые будут выявляться, собираться и распространяться.

4. Определяйте требования для обеспечения доступа и распределения данных для соответствующих заинтересованных сторон.

Анализ других элементов плана проекта может помочь определить, кто нуждается в доступе или получению данных проекта, а также, какие данные необходимы.

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

СП 2.4 Планируйте Ресурсы Проекта

Планируйте ресурсы для выполнения проекта.

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

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

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

Пример рабочих продуктов

1. Рабочие пакеты

2. Словарь задач СДР

3. Требования к персоналу в зависимости от размера и масштаба проекта

4. Список критически важных средств и оборудования

5. Диаграммы и описания процессов и последовательности работ

6. Список требований администрирования проекта

7. Отчеты о состоянии

Подпрактики

1. Определяйте требования к процессу.

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

2. Определяйте требования к каналам связи.

Эти требования адресованы к механизмам, которые будут использоваться для общения с клиентами, конечными пользователями, сотрудниками проекта и другими соответствующими заинтересованными сторонами.

3. Определяйте требования к персоналу.

Кадровое обеспечение проекта зависит от декомпозиции проектных требований на задачи, роли и обязанности для выполнения требований проекта, как указано в рабочих пакетах СДР.

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

4. Определяйте требования к средствам, оборудованиям и компонентам.

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

Лучше всего заблаговременно выявить такие элементы и определить, как они будут решаться. Даже тогда, когда требуемые активы не являются уникальными, составление списка всех средств, оборудования и компонентов (например, количество компьютеров для сотрудников, работающих над проектом, программные приложения, офисные помещения) дает представление об аспектах, которые часто забывают.

5. Определяйте другие постоянные потребности в ресурсах.

Помимо определения процессов, форм отчетности, кадрового обеспечения, объектов и оборудования, может быть постоянная потребность в других видах ресурсов для эффективного осуществления деятельности по проектам, в том числе следующие:

  • Расходные материалы (например, электричество, канцелярские товары)
  • Доступ к интеллектуальной собственности
  • Доступ к перевозке (для людей и оборудования)

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

СП 2.5 Планируйте Необходимые Знания и Навыки

Планируйте знания и навыки, необходимые для выполнения проекта.

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

Знания поставляются в проекты с помощью обучения персонала проекта и приобретения знаний из внешних источников.

Кадровые требования зависят от знания и навыков, необходимых для оказания поддержки реализации проекта.

Пример рабочих продуктов

1. Перечень необходимых навыков

2. Планы кадрового обеспечения и найма новых сотрудников

3. Базы данных (например, навыки, обучение)

4. Планы тренингов

Подпрактики

1. Определяйте знания и навыки, необходимые для выполнения проекта.

2. Оценивайте доступные знания и навыки.

3. Выбирайте механизмы для обеспечения необходимых знаний и навыков.

Примеры механизмов:

  • Внутреннее обучение (как организационное, так и проектное)
  • Внешнее обучение
  • Кадровое обеспечение и набор новых сотрудников
  • Внешнее приобретение навыков

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

4. Включайте выбранные механизмы в план проекта.

СП 2.6 Планируйте Участие Заинтересованных Сторон

Планируйте участие выявленных заинтересованных сторон.

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

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

Примеры материалов, которые должны быть включены в план участия заинтересованных сторон:

  • Список всех соответствующих заинтересованных сторон
  • Обоснование для участия заинтересованных сторон
  • Отношения между заинтересованными сторонами
  • Ресурсы (например, обучение, материалы, время, финансирование), необходимые для обеспечения взаимодействия с заинтересованными лицами
  • График для взаимодействия заинтересованных сторон
  • Роли и обязанности соответствующих заинтересованных лиц по отношению к проекту по фазам жизненного цикла проекта
  • Относительная важность заинтересованных сторон для успешной реализации проекта по фазам жизненного цикла проекта

Реализация этой специфической практики основывается на общедоступной информации или информации общей с предыдущей специфической практикой Планирование Необходимых Знаний и Навыков.

Пример рабочих продуктов

1. План участия заинтересованных сторон

СП 2.7 Создайте Плана Проекта

Создайте и поддерживайте общий план проекта.

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

План, разработанный для проекта, определяет все аспекты, связывая следующее в логической последовательности:

  • Решения по жизненному циклу проекта
  • Задачи проекта
  • Бюджеты и рабочие графики
  • Вехи
  • Управление данными
  • Выявление рисков
  • Требования к ресурсам и квалификации
  • Выявление и взаимодействие с заинтересованными лицами
  • Инфраструктурные решения

Инфраструктура решения включают ответственность и полномочия отношений для организации сотрудников проекта, управления и поддержки.

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

Для программного обеспечения документ планирования может быть одним из следующих:

  • План разработки программного обеспечения
  • План проекта программного обеспечения
  • План программного обеспечения

Для оборудования, документ планирования часто называют план разработки аппаратных средств. Мероприятия по подготовке к производству могут быть включены в план разработки аппаратных средств или внесены в отдельный производственный план.

Примеры планов, которые использовались в Министерстве обороны США:

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

Пример рабочих продуктов

1. Общий план проекта

СЦ 3 Получить Обязательства Выполнения по Плану

Обязательства выполнения по плану проекта сформированы и поддерживаются.

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

СП 3.1 Пересматривайте Планы, Которые Затрагивают Проект

Просматривайте все планы, которые влияют на проект, чтобы понять обязательства по выполнению проекта.

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

Пример рабочих продуктов

1. Отчет по результатам пересмотра планов, которые влияют на проект

СП 3.2 Согласовывайте Объемы Работ и Ресурсов

Выполняйте регулирование плана проекта для согласования доступных и предполагаемых ресурсов.

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

Пример рабочих продуктов

1. Пересмотренные методы и соответствующие параметры оценки (например, более совершенные инструменты, использование готовых компонентов)

2. Пересмотренные бюджеты

3. Пересмотренные рабочие графики

4. Пересмотренный список требований

5. Пересмотренные соглашения с заинтересованными сторонами

СП 3.3 Получите Обязательства Выполнения по Плану

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

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

Пример рабочих продуктов

1. Документированные запросы на подтверждение обязательств по выполнению

2. Документированные обязательства по выполнению

Подпрактики

1. Определяйте необходимую поддержку и получить обязательства выполнения от соответствующих заинтересованных сторон.

СДР могут быть использованы в качестве контрольного списка для обеспечения того, что обязательства по выполнению полученные для всех задач.

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

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

Обязательства должны быть документированы для обеспечения полного взаимопонимания, для отслеживания и обслуживания проекта. Предварительные обязательства должны сопровождаться описанием связанных рисков.

3. Пересматривайте внутренние обязательств выполнения с руководством по мере необходимости.

4. Пересматривайте внешние обязательств выполнения с руководством по мере необходимости.

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

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

Четко определенные спецификации взаимодействия формируют основу для принятия обязательств выполнения.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , | 2 комментария »

Записки мистера Томпкинса из романа об управлении проектами «Deadline»

Posted by Шамрай Александр на Август 17, 2010

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

Безопасность и перемены

  1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
  2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
  3. Неуверенность заставляет человека избегать риска.
  4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
  5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.

Отрицательная мотивация

  1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
  2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
  3. Более того, если люди не справятся, вам придется выполнить свои обещания.

Части тела, необходимые для управления проектами

  1. Для руководства нужны сердце, нутро, душа и нюх
  2. Так что:
    • руководить надо сердцем;
    • чувствовать нутром;
    • вкладывать в команду и проект душу;
    • иметь нюх на всякую ерунду и бессмыслицу.

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

  1. Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (по большей части последнее).
  2. Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
  3. Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
  4. Попросите наводку — тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
  5. Больше слушайте, меньше говорите.
  6. И все это сработает еще лучше, если вы слегка подтасуете колоду.

Повышение производительности

  1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
  2. Повышение производительности — результат долгосрочных усилий.
  3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко» .

Управление рисками

  1. Чтобы управлять проектом, достаточно управлять его рисками.
  2. Создайте список рисков для каждого проекта.
  3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
  4. Оцените вероятность возникновения и стоимость каждого риска.
  5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
  6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
  7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.

Играй в защите

  1. Сокращайте потери.
  2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
  3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
  4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
  5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
  6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
  7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
  8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.

Моделирование процесса разработки

  1. Моделируйте свои предположения и догадки о том, как пойдет процесс работы.
  2. Обсуждайте эти модели вместе с партнером, чтобы лучше понимать процесс работы и вносить необходимые исправления.
  3. Предсказывайте результаты работы с помощью модели.
  4. Сравнивайте результаты, полученные в процессе моделирования, с реальными.

Извращенная политика

  1. В любой момент нужно быть готовым отказаться от работы и попросить расчет…
  2. …однако это не означает, что тем самым вы сумеете избежать последствий извращенной политики.
  3. Извращенная политика достанет вас везде, даже в самой здоровой и чистой организации.
  4. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании.
  5. Это может произойти даже тогда, когда личные цели напрямую противоречат целям организации.
  6. Один из побочных эффектов извращенной политики: иметь хорошо укомплектованную команду становится небезопасно.

Сбор метрических данных

  1. Определяйте размер каждого проекта.
  2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
  3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
  4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
  5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
  6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
  7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
  8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.

Процесс разработки и его улучшение

  1. Хороший процесс разработки и его постоянное улучшение — весьма достойные цели.
  2. Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.
  3. Формальные программы, направленные на улучшение существующего процессе разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
  4. Можно надеяться получить положительный результат от одного какого-нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
  5. Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего приведут к тому, что сроки только увеличатся.
  6. Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
  7. Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).

Делать работу по-другому

  1. Есть только один способ сократить время на разработку, когда его и без того мало — уменьшить сроки отладки программы.
  2. Проекты с высокой производительностью требуют гораздо меньше времени на отладку и исправление ошибок.
  3. Проекты с высокой производительностью требуют гораздо больше времени на проектирование.
  4. Нельзя заставить людей делать что-то по-другому, если ты о них не заботишься, если ты ими не интересуешься. Чтобы они изменились, ты должен понимать (и ценить) их самих, что они делают и к чему стремятся.

Что дает давление сверху

  1. Люди не начнут быстрее соображать, если руководство будет давить на них.
  2. Чем больше сверхурочной работы, тем ниже производительность.
  3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
  4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
  5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.

Сердитый начальник

  1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
  2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
  3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).

Туманные спецификации

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

Конфликт

  1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
  2. Процесс создания и распространения программных систем — прямо таки рассадник всевозможных конфликтов.
  3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
  4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
  5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
  6. Тяжело договариваться. Гораздо легче выступать посредником.
  7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
  8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.

Кто такой катализатор проекта

  1. Существуют люди катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
  2. Посредничество — еще одна сфера, в которой люди катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
  3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»

Человеку свойственно ошибаться

  1. Нам кажется, что самое страшное — не знать чего то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.

О персонале

  1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую то работу).
  2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
  3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
  4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
  5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!

Проблемы социологии

  1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
  2. Каждому проекту нужна какая то церемония или ритуал.
  3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
  4. Защищайте людей от оскорблений и ругани Начальства.
  5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего то очень боятся.
  6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)

О патологической политике (еще раз)

  1. Эту патологию невозможно вылечить снизу.
  2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.
  3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
  4. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.

Злоба и скупость

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

Основы здравого смысла

  1. У проекта должно быть два срока сдачи — запланированный и желаемый.
  2. Эти сроки должны быть разными.

Posted in Книги, Разное | Отмечено: , , , | Leave a Comment »

 
%d такие блоггеры, как: