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

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

Сравнение выявляет сильные и слабые стороны проекта по отношению к другим. Так как наш проект является внутренним для подразделения, он противостоит аналогичным проектам. Менеджер вправе спросить, каким образом наша методология соотносится с методологией подразделения А, которое в компании считается наиболее подготовленным к управлению проектами. Сравнение показывает, что наша методология короче; более того, она лучше отражает корпоративную культуру. В технологической компании высоко ценятся краткая документация и собственная культура – это и станет основным направлением работы по улучшению методологии подразделения А. В чем тогда суть сравнения? В определении возможностей для улучшения. Это, в частности, очень важно при сравнении нового продукта компании с продуктами конкурентов.

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

Остановка или продолжение. Многие проекты используют только функции качества: это позволяет встроить требования заказчика в процесс планирования. Забегая вперед, скажем, что в крупных проектах приветствуется уточнение нужд заказчика на протяжении всей работы над проектом. С этой целью стоятся еще три дома качества (рис. 4.8). Здесь требования проекта (как сделать) из первого дома перемещаются на место требований заказчика (что сделать) во втором и т. д. Основная цель данной процедуры – соотнести требования заказчика с последовательными низкоуровневыми сокращениями проектных работ, полностью переведя их на операционный уровень. Логика тут похожа на иерархическую структуру (WBS): нужно дойти до уровня совокупности работ – уровня, на котором работа выполнена. Такой подход гарантирует, что требования заказчика будут встроены в самое основание блоков, образующих проект. По мере построения четырех домов качества их необходимо анализировать и корректировать.

Рис. 4.8. Четыре функции качества

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

Время использования. Время, необходимое для построения дома качества, зависит от его размеров и числа людей, вовлеченных в этот процесс. Небольшой дом (см. рис. 4.7) могут создать три человека в течение 45 минут. Для построения большого (10 x 10) дома качества потребуются усилия пяти-шести членов команды и пять-шесть часов работы.

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

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

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

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

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

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

• затраты времени. Некоторые члены команды воспринимают работу по созданию дома качества как интерфейсную (Frontend) для проекта.

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