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

Рис. 4.4. Выборка

Сбор необходимой информации. На качество выборки влияют два источника информации:

• целевой план;

• организационная схема заказчика.

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.5. Рекомендации для переговоров

Соберите необходимую информацию. Основной входной информацией для данного инструмента являются целевой план и выборка, служащие ориентиром для выбора тем и формулирования вопросов рекомендации.

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

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

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

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

Заметим, что многие вопросы уже были обозначены во время мозгового штурма при выяснении тем. Теперь, зная три наиболее важные темы, мы можем оценить, каких вопросов не хватает. Это полезно для составления ясного и полного списка. Как правило, в одну тему может входить от пяти до десяти ключевых и дополнительных вопросов. Ключевые вопросы должны быть записаны в середине, а дополнительные – в первой части рекомендаций для переговоров (см. рис. 4.5). Результативность такой работы полезно проверить в ролевой игре: один участник команды задает остальным вопросы из рекомендации. Подтверждение правильного выбора вопросов не задействованными в проекте людьми также является выигрышной тактикой. Это поможет команде более точно сформулировать вопросы и оценить последовательность тем.

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

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

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

Вариации. Рекомендации для переговоров можно модифицировать, например представить их в качестве простого списка тем и подтем для обсуждения или сценария [2]. У организаций, исследующих рынок, есть собственные форматы, обычно называемые рекомендациями по темам.

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

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

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

Рис. 4.6. Функция качества

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

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

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

Пять необходимых условий были выделены при анализе длинного списка требований, которым интервьюируемые уделяли особое внимание. Небольшое количество значимых требований обеспечивают простоту построения дома качества. Большая часть компаний, использующих функции качества, ограничивают список потребностей десятью пунктами. О работе с большим списком рассказывается во врезке «Кошмар 2500-й ячейки».

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

Рис. 4.7. Функции качества проекта

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

• ограничить количество страниц в документе методологии;

• проводить интервью с менеджерами проектов и управляющими для анализа их работы и просмотра проектной документации;

• использовать корпоративную терминологию при написании документа;

• писать в четком и понятном стиле;

• рассматривать этапы методологии через этапы жизненного цикла проекта.

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

Рассмотрим пример. Через проведение интервью и обследований мы изучаем корпоративный язык, который помогает при написании методологии. Вероятно, данная связь является положительной. С другой стороны, при поэтапном описании методологии неизбежны повторения, в частности на каждом этапе потребуется анализ развития. Это увеличит объем методологии, что недопустимо. Очевидно, что два условия противоречат друг другу.

Почему мы анализируем взаимосвязи и строим крышу? Потому что эти отношения показывают столкновение требований и возможность нахождения компромисса между ними. Мы видели это на примере связи требования ограничения объема страниц и проведения интервью. Построение крыши дома качества позволяет увидеть условия проекта в совокупности, а не по отдельности [12].

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

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

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

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

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