[an error occurred while processing the directive]
[an error occurred while processing the directive]

9.2 Управляй качеством / Приемы

Поймите характеристики качества для своего проекта

(9.2.P1)

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

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

Качество продукта

Качество услуги

Продукт проекта:
Надежен
Удобен в использовании
Удобен в обслуживании
Доступен, когда необходимо
Адаптируем под перспективные потребности
Рентабелен
Интуитивно понятен и легок в освоении
Безопасен
Хорошо документирован
Достаточно бездефектен (не обязательно идеален)
Соответствует потребностям клиента

Люди, оказывающие услугу:
Отзывчивы
Компетентны
Доступны
Обходительны и доброжелательны
Эффективно общаются
Вызывают доверие
Хорошо осведомлены о клиенте
Обязательны и надежны


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

(9.2.P2)

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

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

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


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

(9.2.P3)

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

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

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

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


Имейте ясность в отношении стоимости качества

(9.2.P4)

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


Избегайте "золочения" (выполнения большего объема требований, чем запросил клиент)

(9.2.P5)

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

Термин "золочение" относится как раз к тому случаю, когда Вы превышаете требования клиента. Это вовсе не так хорошо, как Вам может показаться. Даже скорее плохо, причем по двум причинам. Во-первых, основное внимание в проекте должно, все же, уделяться тому, как выполнить заказанное клиентом - вовремя и в пределах бюджета. Добавляя не оговоренные с клиентом работы, Вы повышаете риск превышения установленных сроков или бюджета. Если это произойдет, Вы вряд ли найдете понимание, объясняя клиенту, что сделали больше, чем он хотел.

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

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


Управление качеством должно концентрироваться на процессах, а не на людях

(9.2.P6)

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

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


Убеждайте, что качество – обязанность каждого

(9.2.P7)

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


Разъясняйте, что качество – это тип мышления, а не событие

(9.2.P8)

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

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


Выявляйте и минимизируйте переделки

(9.2.P9)

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

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


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

(9.2.P10)

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


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

(9.2.P11)

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

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

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

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


[Пред. стр. - Разреш. проблем с кач-вом ]   [След. стр. - Стоим. и выгоды кач-ва ]