<<
>>

РАЗРАБОТКА ПРОГРАММЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ПРОЕКТА

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

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

политики и процедуры в области качества (обеспечение качества, управление им); •

голос заказчика; •

описание содержания и СДР. ПРОГРАММА ОБЕСПЕЧЕНИЯ КАЧЕСТВА

Название проекта: SMP-1 Ревизия: 1 Дата: 10.05.2001 Подготовил: Боб Максвелл Лист: 2 из 3 1 2 3 4 5 6 Обозначение по СДР Элемент

СДР Стандарт

качества Задача

обеспечения

качества Матрица

ответственности Расписание май/июнь 2001 г., неделя h

К

С Алан Перри Ким DZM Я IN

ю 5/14 5/21 5/28 6/4 6/14 6/21 2.03 руководство по управлению проектами Легкость чтения по Флешу24 Выполнение тестов и переписывание D ЕЗО 9000 Пересмотр D D D А — РМВОК Пересмотр D — Краткость

указаний Проверка и коррекция D — Организационные политики по части написания руководств Пересмотр D А — Обозначения: D — выполнение А — утверждение

Глава 8

336

Рис. 8.2. Пример программы обеспечения качества

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

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

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

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

Планирование качества

337

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

Установка стандартов качества. Каковы стандарты качества для пакета работ, показанного на рис. 8.2, и зачем они нужны? Для этого пакета мы определили пять стандартов. Заказчик хочет, чтобы «Руководство» и описываемый в нем процесс соответствовали международному стандарту ISO 9000 и американскому стандарту PMBOK25 Guide. Для того чтобы данное «Руководство» могли использовать проектные команды, оно должно соответствовать трем принятым в компании стандартам: •

краткости (максимум пять страниц); •

совместимости с организационными политиками в части написания руководств; •

легкости чтения по Флешу (индекс должен быть более 70 пунктов).

Эти примеры помогают ответить на ряд вопросов: зачем нужны стандарты качества, кто их устанавливает и каковы они. Хотя существует множество различных определений качества, мы считаем, что качество есть удовлетворение или превышение ожиданий заказчика (см. врезку «Каково ваше определение качества?»). Мы применили инструменты работы с голосом заказчика, идентифицировав ожидания по части конкретного пакета работ, и теперь нам необходимо измерить их и отреагировать (см. врезку «На планирование качества нужно затрачивать больше усилий» в разделе «Использование программы обеспечения качества проекта»). Таким образом, цель использования стандартов в программе обеспечения качества состоит в измерении ожиданий: чтобы выполнить пакет работ («Руководство по управлению проектами») согласно ожиданиям заказчика, нужно обеспечить его соответствие установленным стандартам качества. В силу того что качество оценивают заказчики, их необходимо вовлекать в процесс разработки и принятия стандартов.

Глава 8

338

В примере, посвященном руководству по управлению проектами, мы использовали международные, национальные и корпоративные стандарты. Первые два стандарта в силу своего повсеместного распространения стали привычными и наиболее простыми в использовании. Однако в большинстве случаев проекты вынуждены учитывать стандарты, принятые внутри компании. В случае, когда такие стандарты носят количественный характер — например, учитывается показатель легкости чтения по Флешу, равный 70 баллам (из 100 возможных), — применять их легче. Но иногда устанавливаются стандарты качественного или перцепционного (относящегося к восприятию) характера, например насколько заказчик удовлетворен своевременностью выполнения работ. В последнем случае полезна перцепционная шкала, или шкала Ликерта, содержащая значения от 1 (Не удовлетворен) до 10 (В высшей степени удовлетворен). Учтите: чтобы сделать шкалу максимально показательной, следует четко определить значения всех остальных чисел. Тщательно разработанная шкала весьма надежна (даже в статистическом смысле) и широко используется.

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

Определение задач обеспечения качества. После того как стандарты качества установлены, нужно определить, что делать для того, чтобы соответствовать этим стандартам и выполнить пакет работ согласно ожиданиям заказчика. Вначале следует выявить задачи, которые мы должны решить, чтобы соответствовать стандарту качества. Возьмем, например, наш пакет работ «Руководство по управлению проектами». Для стандарта «Легкость чтения по Флешу более 70 баллов» задача может быть повторяющейся: по мере написа-

КАКОВО ВАШЕ ОПРЕДЕЛЕНИЕ КАЧЕСТВА?

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

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

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

Определение качества Используется

Трансцендентное Заказчиками

Ориентированное на продукт Заказчиками

Ориентированное на пользователя Маркетинговым отделом

Ориентированное на производство Производственным отделом

Ориентированное на ценность Отделом проектирования

Планирование качества

339

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

Например, оба программных пакета - Primavera и MS Project - работоспособны и применяются на практике - но различными менеджерами проектов, имеющими разные нужды и, как следствие, разные стандарты качества.

Соответствие спецификациям представляет собой ориентированное на производство определение качества, согласно которому спецификации включают как целевые значения (например, толщина детали 30 см), так и допустимые отклонения (например, 30 см + 0,01).

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

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

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

Глава 8

340

Распределение областей ответственности, определение расписания. Идентификация задач по обеспечению качества ставит перед нами два вопроса: кто и когда должен эти задачи выполнять (см. врезку «У нас есть группа обеспечения качества!»). Чтобы встроить в систему обеспечения качества ответственность и подотчетность, необходимо определить, кто из сотрудников и что именно будет делать для решения данной задачи (см.

пример на рис. 8.2). Здесь потребуется матрица ответственности, являющаяся частью программы обеспечения качества и включающая в себя различные типы ответственности: «Выполнение», «Утверждение» и «Необходимость консультации». Когда обязанности будут четко определены и для каждой задачи по обеспечению качества будет установлена своя временная шкала, уравнение, лежащее в основе программы, может считаться решенным. Очевидно, что программа обеспечения качества проекта содержит матрицу ответственности и расписание (обычно в виде диаграммы Гантта). Некоторые менеджеры считают это излишеством: ведь уже есть матрица ответственности и расписание для всего проекта — и часто спрашивают, должны ли матрица и расписание браться из программы обеспечения качества и соединяться с матрицей и расписанием проекта? Ответ на оба вопроса — нет. Если взглянуть на типичные матрицу ответственности и расписание проекта, то на них наверняка не окажется задач по обеспечению качества. О чем это говорит? О том, что мы до сих пор не рассматриваем качество как приоритетную задачу проекта и предпочитаем иметь отдельную программу обеспечения качества со своей матрицей ответственности и своим расписанием до тех пор, пока не построим иную систему оценки.
<< | >>
Источник: Драган 3. Милошевич. Набор инструментов для управления проектами / — М.: Компания АйТи; ДМК Пресс. — 729 с.. 2008

Еще по теме РАЗРАБОТКА ПРОГРАММЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ПРОЕКТА:

  1. 17.2. Фандрайзинг в финансировании научных программ
  2. 3.2. Команда проекта
  3. Планирование качества
  4. РАЗРАБОТКА ПРОГРАММЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ПРОЕКТА
  5. ИСПОЛЬЗОВАНИЕ ПРОГРАММЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ПРОЕКТА
  6. Связь между инструментами управления проектами и РМВОК
  7. Связь между наборами инструментов управления проектами и семейством проекта
  8. Связь между наборами инструментов управления проектами и типом проекта
  9. 23.5 СРАВНИТЕЛЬНЫЙ АНАЛИЗ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ УПРАВЛЕНИЯ ПРОЕКТАМИ
  10. 17.2. Фандрайзинг в финансировании научных программ
  11. Планирование качества
  12. РАЗРАБОТКА ПРОГРАММЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ПРОЕКТА
  13. ИСПОЛЬЗОВАНИЕ ПРОГРАММЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ПРОЕКТА
  14. Связь между инструментами управления проектами и РМВОК