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

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

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

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

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

•описание содержания и СДР.

¹ Индекс легкости чтения Флеша (Flesch Reading Ease). Психолингвистический параметр. Подсчитывается по среднему числу слогов в слове и слов в предложении. Варьируется от 0 до 100. Чем выше значение, тем легче прочесть текст и тем большему числу читателей он будет понятен. – Прим. ред.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Распределение областей ответственности, определение расписания.Идентификация задач по обеспечению качества ставит перед нами два вопроса: кто и когда должен эти задачи выполнять (см. врезку «У нас есть группа обеспечения качества!»). Чтобы встроить в систему обеспечения качества ответственность и подотчетность, необходимо определить, кто из сотрудников и что именно будет делать для решения данной задачи (см. пример на рис. 8.2). Здесь потребуется матрица ответственности, являющаяся частью программы обеспечения качества и включающая в себя различные типы ответственности: «Выполнение», «Утверждение» и «Необходимость консультации». Когда обязанности будут четко определены и для каждой задачи по обеспечению качества будет установлена своя временная шкала, уравнение, лежащее в основе программы, может считаться решенным. Очевидно, что программа обеспечения качества проекта содержит матрицу ответственности и расписание (обычно в виде диаграммы Гантта). Некоторые менеджеры считают это излишеством: ведь уже есть матрица ответственности и расписание для всего проекта – и часто спрашивают, должны ли матрица и расписание браться из программы обеспечения качества и соединяться с матрицей и расписанием проекта? Ответ на оба вопроса – нет. Если взглянуть на типичные матрицу ответственности и расписание проекта, то на них наверняка не окажется задач по обеспечению качества. О чем это говорит? О том, что мы до сих пор не рассматриваем качество как приоритетную задачу проекта и предпочитаем иметь отдельную программу обеспечения качества со своей матрицей ответственности и своим расписанием до тех пор, пока не построим иную систему оценки.

Когда использовать.Успех проекта сегодня определяется заказчиком [10]. Удовлетворенные заказчики представляют собой реальный актив компании, что важно с точки зрения экономической отдачи. Согласно проводившемуся в 1997 году исследованию удовлетворенности американских заказчиков, компании, характеризующиеся более высоким значением данного показателя, имели вдвое большую долю акционерного капитала, чем компании, характеризующиеся низким индексом [11]. Итак, заказчики выкладывают деньги с большей готовностью, когда они удовлетворены качеством продукта или услуги, а значит, любой проект – большой или малый – может выиграть от использования программы обеспечения качества. Планирование качества окупается (см. врезку «На планирование качества нужно затрачивать больше усилий»). Если в распоряжении менеджера проекта имеется больший бюджет и ресурсы, разрабатывать программу обеспечения качества следует на самых ранних стадиях и неукоснительно выполнять ее вплоть до завершения проекта. В случае малых проектов нужно сосредоточиться на таких программах обеспечения качества, которые являются допустимыми с точки зрения имеющегося времени и содержат лишь несколько наиболее важных пакетов работ.

В больших проектах, где есть достаточно ресурсов и профессиональных менеджеров, понимающих, что такое качество, налицо тенденция к выполнению действий, необходимых в рамках программы обеспечения качества. Однако по мере уменьшения размера и сложности проекта эта тенденция постепенно сходит на нет и сменяется сопротивлением в адрес данной программы. В одном случае оправдание звучало так: «У нас есть группа обеспечения качества. Пусть она и контролирует качество». Если принять эту позицию, то отсутствие чувства сопричастности и недостаточное стремление к предотвращению нежелательных ситуаций ухудшат качество проектов. Проектная команда знает эти операции лучше всего и потому может с наибольшей вероятностью выявить и устранить ошибки в операциях. Членов команды нужно наделить полномочиями как исполнителей, так и создателей, имеющих право решать проблемы проекта. В таком случае они будут разрабатывать программу обеспечения качества, определять «владельцев» соответствующих задач, выявлять и корректировать дефекты. Выполняя эти функции, они будут использовать превентивный подход, постоянно совершенствовать рабочий процесс и поднимать его на все более высокий уровень, тем самым повышая качество продукта. А вот группа обеспечения качества так действовать не будет. Во-первых, эта группа не обладает теми знаниями операций, которыми обладает проектная команда. Во-вторых, у нее отсутствует чувство сопричастности к тому, что делает команда. Соответственно лучшее, что они могут сделать, – положиться на инспекцию, то есть на корректирующую, а не предупреждающую меру, выявляя ошибки, когда они уже совершены. Без чувства сопричастности по отношению к программе обеспечения качества и без превентивного подхода (а так оно и будет в случае создания группы обеспечения качества) качество проекта будет ниже среднего. Иначе говоря, группу обеспечения качества следует использовать лишь как вспомогательный ресурс.

Джозеф Джуран (Joseph Juran), корифей в области управления качеством, разработал трилогию обеспечения качества (Quality Trilogy) – свод рекомендаций по планированию, контролю и улучшению качества (рис. 8.3). Планирование качества начинается с идентификации списка заказчиков [1], поскольку члены проектной команды должны знать, кто использует продукты их проекта. Далее следует выяснить нужды клиентов и перевести их на язык проекта. Устанавливается также способ измерения нужд заказчиков. Выяснение, перевод на язык проекта и измерение нужд может выполняться при помощи инструментов работы с голосом заказчика (см. главу 4). Следующий шаг выполняется в ответ на требования клиента и представляет собой разработку целей и характеристик продукта, что обычно является частью определения содержания проекта. Далее наступает время для составления интегрального набора процессов, предназначенного для проектирования, разработки и поставки продукта. Очевидно, что выяснение нужд заказчика в сочетании с разработкой и поставкой продукта под эти являют собой суть планирования качества. Как только Джозеф обнаружил, что в организациях преобладает контроль (корректирующий подход), а вовсе не планирование качества (превентивный подход), он пришел к выводу о том, что на планирование нужно затрачивать больше усилий.

Рис. 8.3.Основные шаги процесса планирования качества по Джурану

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

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

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

Среди недостатков программы можно назвать:

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

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

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

Убедитесь, что программа обеспечения качества проекта:

• показывает стандарты качества для пакетов работ;

• отображает задачи обеспечения качества, выполнение которых необходимо для поддержки соответствия каждому стандарту;

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

• определяет временную шкалу для задач обеспечения качества.

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