<<
>>

Детализация задач

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

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

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

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

центе выполнения.

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

Здесь существует еще одно интересное обстоятельство — РП может уверенно рапортовать о сделанных 80 % работы, хотя реально на оставшиеся 20 % нужно еще 80 % ресурсов.

Это известная и постоянно присутствующая проблема «грязных данных» [9].

Именно поэтому статистика для принятия решений на базе освоенного объема может быть реально недостоверной [9].

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

Вот почему наш гуру в области УП Либерзон [9] совершенно справедливо рекомендует Mile Stones, в которых должны быть получены необходимые артефакты (желательно принятые клиентом).

Например: «Спецификация написана и принята», «Модуль закодирован, тестирование оборудования или програмного модуля успешно прошло».

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

Кстати, технологические стадии (фазы) в проектах, выполняемых по одной технологии, должны быть одинаковые. Например, все виды IT-проектов прекрасно ложатся в четыре фазы RUP,

<< | >>
Источник: Ильин, Владислав Владимирович.. Руководство качеством проектов. Практический опыт. 2006

Еще по теме Детализация задач:

  1. 1.2. Задачи криминалистики
  2. 1 Ключевые задачи
  3. ЗАДАЧИ ПЛ. КАПИЦЫ
  4. Задачи
  5. ЗАДАЧЕ-ОРИЕНТОРОВАННЫЙ
  6. 2.1. Задачи ранжирования альтернатив
  7. 13. ЗАДАЧИ И УПРАЖНЕНИЯ
  8. 1.1. Цели и задачи
  9. Задачи аудита
  10. Задачи для контроля
  11. 2. Определение задачи (ГБ
  12. 4.1. Задачи порядковой классификации альтернатив
  13. III. ЗАДАЧИ
  14. Задача философии
  15. 1.2. Задачи и система показателей