Сформулируйте вопросы. После того как определены три основные темы, приступайте к заполнению рекомендаций для обсуждения (см. рис. 4.5). Начните с внесения выбранных тем в блоки слева. Далее сформулируйте вопросы, чтобы побудить заказчика к обсуждению обозначенных тем. Есть два вида вопросов: ключевые и дополнительные. Подобно двум сторонам одной медали, они обеспечивают понимание тем первого уровня, вместе с тем давая целостное видение темы.
Заметим, что многие вопросы уже были обозначены во время мозгового штурма при выяснении тем. Теперь, зная три наиболее важные темы, мы можем оценить, каких вопросов не хватает. Это полезно для составления ясного и полного списка. Как правило, в одну тему может входить от пяти до десяти ключевых и дополнительных вопросов. Ключевые вопросы должны быть записаны в середине, а дополнительные – в первой части рекомендаций для переговоров (см. рис. 4.5). Результативность такой работы полезно проверить в ролевой игре: один участник команды задает остальным вопросы из рекомендации. Подтверждение правильного выбора вопросов не задействованными в проекте людьми также является выигрышной тактикой. Это поможет команде более точно сформулировать вопросы и оценить последовательность тем.
Использование рекомендаций для переговоров
Когда использовать. Наиболее подходящее время для написания рекомендаций наступает сразу после составления выборки и до того, как произошла первая встреча. Очевидно, что крупные проекты будут нуждаться в более формальных и структурированных рекомендациях, в то время как небольшие потребуют неформального подхода.
Время использования. Собрание команды проекта – наиболее эффективный путь для разработки рекомендаций. Мероприятие может занять около часа (при более сложных задачах – до двух часов).
Выгоды. Пущенная на самотек встреча с заказчиком, как правило, заканчивается обсуждением проблем, совершенно не относящихся к проекту. В таком случае интервью с заказчиком не будет ни диалогом, ни дискуссией. Задача рекомендаций для обсуждения – не допустить такого развития событий. Более того, они должны превратить интервью в конференцию, чтобы позволить заказчику озвучить свои требования и указать на темы, играющие важную роль (см. врезку «Искусство задавать вопросы»). В процессе составления рекомендаций команды расставляют приоритеты для тем и вынуждены потом общаться со всеми заказчиками, используя одинаковый набор вопросов. Это делает встречи более продуктивными и исключает возможность ухода от главной темы, что часто сопровождается обсуждением предметов, не играющих роли для проекта.
Вариации. Рекомендации для переговоров можно модифицировать, например представить их в качестве простого списка тем и подтем для обсуждения или сценария [2]. У организаций, исследующих рынок, есть собственные форматы, обычно называемые рекомендациями по темам.
Время использования. Собрание команды проекта – наиболее эффективный путь для разработки рекомендаций. Мероприятие может занять около часа (при более сложных задачах – до двух часов).
Выгоды. Пущенная на самотек встреча с заказчиком, как правило, заканчивается обсуждением проблем, совершенно не относящихся к проекту. В таком случае интервью с заказчиком не будет ни диалогом, ни дискуссией. Задача рекомендаций для обсуждения – не допустить такого развития событий. Более того, они должны превратить интервью в конференцию, чтобы позволить заказчику озвучить свои требования и указать на темы, играющие важную роль (см. врезку «Искусство задавать вопросы»). В процессе составления рекомендаций команды расставляют приоритеты для тем и вынуждены потом общаться со всеми заказчиками, используя одинаковый набор вопросов. Это делает встречи более продуктивными и исключает возможность ухода от главной темы, что часто сопровождается обсуждением предметов, не играющих роли для проекта.
Вариации. Рекомендации для переговоров можно модифицировать, например представить их в качестве простого списка тем и подтем для обсуждения или сценария [2]. У организаций, исследующих рынок, есть собственные форматы, обычно называемые рекомендациями по темам.
ИСКУССТВО ЗАДАВАТЬ ВОПРОСЫАдаптация рекомендаций для обсуждения. Общие рекомендации принесут значительную пользу, но для большей эффективности их рекомендуется подстроить под конкретный проект. Ниже представлены некоторые способы такой адаптации.
Источник большинства ошибок – неправильная манера задавать вопросы на интервью с заказчиком. Чтобы избежать проблем:
• не включайте в вопрос собственные предубеждения;
• не используйте наводящих вопросов. Этот термин взят из судебной практики, где на вопрос необходимо получить ожидаемый ответ;
• не задавайте ограничивающих вопросов. Это мешает заказчику дать развернутый ответ.
Ниже приведен список вопросов, наиболее полезных при проведении интервью с заказчиком:
• не ограниченные временем вопросы. Такие вопросы позволяют заказчику высказать все свои требования. Если спросить, например: «Каковы три основные проблемы, встречающиеся в процессе сдачи проекта?» – заказчик сможет рассказать о проблемах, основываясь на своем восприятии и с учетом собственных приоритетов;
• визуализирующие вопросы. Эти вопросы помогают заказчику обрисовать потребности. «Что, если ваш компьютер мог бы уведомлять о задержках проекта и конфликте ресурсов?» Пока эта возможность не реализована в компьютере, заказчик будет думать рационализаторски;
• оборачивающие вопросы. Такие вопросы подразумевают ответ вопросом на вопрос. Например, если заказчик спросит: «Какие технологии вы будете использовать в новом проекте?» – мы ответим: «А какой должна быть технология, чтобы соответствовать вашим требованиям?»
Резюме
Описанный в данном разделе инструмент – рекомендации для переговоров – представляет собой список тем для обсуждения с заказчиком. Лучше всего разрабатывать рекомендации непосредственно перед началом переговоров. Таким образом, вы превратите интервью в конференцию для заказчиков, где они смогут описать свои потребности и определить важные темы. В результате команда проекта вынуждена обращаться ко всем представителям заказчика с одинаковым набором вопросов. Рекомендации принесут большую пользу при дальнейшей детализации специфических требований проекта, поэтому ниже речь пойдет о структурировании требований для заказчика.
Использование функции качества
Что такое функции качества?
Функция качества – это инструмент заказчика, который позволяет встроить его требования в проект. Цель этого инструмента – убедиться, что требования заказчика интегрированы в каждую часть проекта, от определения границ проекта через процесс его планирования до процесса контроля и закрытия. Функция качества позволяет выявить требования заказчика и перевести их на язык проекта.
Рис. 4.6. Функция качества
Процесс построения дома качества по этим этапам – очень сложная процедура, особенно в случае крупных проектов. Однако мы считаем, что этот инструмент должен быть легок в использовании: его отличительной особенностью станет быстрое развертывание, формальное или неформальное, удобное во множестве небольших проектов. Вот почему для примера мы возьмем проект продолжительностью несколько месяцев и с трудозатратами в 200 человекочасов. В рамки проекта включается разработка документа по стандартной методологии управления проектами для отдела технологической корпорации.
Подготовка требований заказчика. Требования заказчика – важнейшая информация при построении дома качества. Как правило, это самый сложный этап, поскольку необходимо выяснить наиболее значимые условия заказчика. В идеальном случае для определения требований используются инструменты, о которых мы говорили ранее: сетевой график заказчика, целевой план, выборка и рекомендации для обсуждения. Их задача – помочь получить информацию, касающуюся нужд заказчика. В терминологии дома качества такие требования заказчика принято называть «Whats» (Что), обозначая этим словом пожелания заказчиков (в случае требований, расставленных с учетом приоритетов).
Наш пример определяет пять наиболее важных требований (рис. 4.7). Здесь заказчик – группа из семи управляющих и менеджеров проектов подразделения – потребовал предоставить краткий документ, описывающий культуру компании, понятную конечному пользователю и относящуюся к уровню рабочей группы проекта. Методология также должна была базироваться на корпоративном понятии жизненного цикла проекта.
Пять необходимых условий были выделены при анализе длинного списка требований, которым интервьюируемые уделяли особое внимание. Небольшое количество значимых требований обеспечивают простоту построения дома качества. Большая часть компаний, использующих функции качества, ограничивают список потребностей десятью пунктами. О работе с большим списком рассказывается во врезке «Кошмар 2500-й ячейки».
Определение требований проекта. Заказчик выражает свои требования словами, и их нужно перевести на язык действий, при помощи которого команда планирует и реализует проект. Сформулированные таким образом требования проекта можно измерить, а позже сравнить с поставленными целями. Следует различать два вида требований проекта: условия заказчика и предложения команды для их выполнения.
Рис. 4.7. Функции качества проекта
В примере на рис. 4.7 представлены некоторые требования проекта. После непродолжительного мозгового штурма десять основных требований были отобраны и расставлены с учетом приоритетов, а в функцию качества занесены пять из них:
• ограничить количество страниц в документе методологии;
• проводить интервью с менеджерами проектов и управляющими для анализа их работы и просмотра проектной документации;
• использовать корпоративную терминологию при написании документа;
• писать в четком и понятном стиле;
• рассматривать этапы методологии через этапы жизненного цикла проекта.
Рассмотрим пример. Через проведение интервью и обследований мы изучаем корпоративный язык, который помогает при написании методологии. Вероятно, данная связь является положительной. С другой стороны, при поэтапном описании методологии неизбежны повторения, в частности на каждом этапе потребуется анализ развития. Это увеличит объем методологии, что недопустимо. Очевидно, что два условия противоречат друг другу.
Почему мы анализируем взаимосвязи и строим крышу? Потому что эти отношения показывают столкновение требований и возможность нахождения компромисса между ними. Мы видели это на примере связи требования ограничения объема страниц и проведения интервью. Построение крыши дома качества позволяет увидеть условия проекта в совокупности, а не по отдельности [12].
Связь условий заказчика и требований проекта. Основа дома качества – матрица отношений. Она использует подход, похожий на применяемый при построении крыши, для обозначения связи требований проекта и условий заказчика. При нехватке времени и необходимости упрощения процесса будем ставить крестик для обозначения сильной связи между требованиями (см. рис. 4.7). Например, использование корпоративного языка способствует как отражению корпоративной культуры, так и прозрачности методологии.
Отсутствие сильной связи указывает на то, что условия заказчика не перекрываются требованиями проекта – иными словами, при его выполнении могут возникнуть проблемы. С другой стороны, если проектное требование не поддерживает ни одного требования заказчика, оно считается избыточным. Большая часть функций качества, применяемых в сложных проектах, имеет тенденцию к усложнению видов отношений. Вместо крестика допустимо использовать другие символы, показывающие степень влияния. Их можно измерить и после умножения на степень важности задействовать для оценки значимости каждого требования проекта [1].
Сравнение. На этом этапе решаются две проблемы: каждому требованию заказчика присваивается степень важности и проект сравнивается с другими. В нашем примере мы не оценивали требования заказчика, считая их одинаково важными, – это правомерно в случае мелких проектов с ограниченными ресурсами. Крупные проекты выиграют от введения рангов, помогающих сосредоточиться на наиболее значимых для заказчика требованиях.
Сравнение выявляет сильные и слабые стороны проекта по отношению к другим. Так как наш проект является внутренним для подразделения, он противостоит аналогичным проектам. Менеджер вправе спросить, каким образом наша методология соотносится с методологией подразделения А, которое в компании считается наиболее подготовленным к управлению проектами. Сравнение показывает, что наша методология короче; более того, она лучше отражает корпоративную культуру. В технологической компании высоко ценятся краткая документация и собственная культура – это и станет основным направлением работы по улучшению методологии подразделения А. В чем тогда суть сравнения? В определении возможностей для улучшения. Это, в частности, очень важно при сравнении нового продукта компании с продуктами конкурентов.
Разработка целей. Мы уже говорили о важности измерения требований проекта. Обычно для этого внутри компании проводятся дискуссии, и условия проекта формулируются как конечные цели. В нашем примере (см. рис. 4.7) конечные цели ограничены десятью страницами методологии: мы убеждены в том, что при большем объеме наши занятые менеджеры ею не воспользуются. Кроме того, мы считаем, что опроса семи менеджеров достаточно для получения необходимой информации в сжатые сроки. В случае проведения проекта для внешнего заказчика данный подход позволяет оценить требования конкурирующих проектов и скорректировать конечные цели.
Остановка или продолжение. Многие проекты используют только функции качества: это позволяет встроить требования заказчика в процесс планирования. Забегая вперед, скажем, что в крупных проектах приветствуется уточнение нужд заказчика на протяжении всей работы над проектом. С этой целью стоятся еще три дома качества (рис. 4.8). Здесь требования проекта (как сделать) из первого дома перемещаются на место требований заказчика (что сделать) во втором и т. д. Основная цель данной процедуры – соотнести требования заказчика с последовательными низкоуровневыми сокращениями проектных работ, полностью переведя их на операционный уровень. Логика тут похожа на иерархическую структуру (WBS): нужно дойти до уровня совокупности работ – уровня, на котором работа выполнена. Такой подход гарантирует, что требования заказчика будут встроены в самое основание блоков, образующих проект. По мере построения четырех домов качества их необходимо анализировать и корректировать.
Рис. 4.8. Четыре функции качества
Процесс построения дома качества по этим этапам – очень сложная процедура, особенно в случае крупных проектов. Однако мы считаем, что этот инструмент должен быть легок в использовании: его отличительной особенностью станет быстрое развертывание, формальное или неформальное, удобное во множестве небольших проектов. Вот почему для примера мы возьмем проект продолжительностью несколько месяцев и с трудозатратами в 200 человекочасов. В рамки проекта включается разработка документа по стандартной методологии управления проектами для отдела технологической корпорации.
Подготовка требований заказчика. Требования заказчика – важнейшая информация при построении дома качества. Как правило, это самый сложный этап, поскольку необходимо выяснить наиболее значимые условия заказчика. В идеальном случае для определения требований используются инструменты, о которых мы говорили ранее: сетевой график заказчика, целевой план, выборка и рекомендации для обсуждения. Их задача – помочь получить информацию, касающуюся нужд заказчика. В терминологии дома качества такие требования заказчика принято называть «Whats» (Что), обозначая этим словом пожелания заказчиков (в случае требований, расставленных с учетом приоритетов).
Наш пример определяет пять наиболее важных требований (рис. 4.7). Здесь заказчик – группа из семи управляющих и менеджеров проектов подразделения – потребовал предоставить краткий документ, описывающий культуру компании, понятную конечному пользователю и относящуюся к уровню рабочей группы проекта. Методология также должна была базироваться на корпоративном понятии жизненного цикла проекта.
Пять необходимых условий были выделены при анализе длинного списка требований, которым интервьюируемые уделяли особое внимание. Небольшое количество значимых требований обеспечивают простоту построения дома качества. Большая часть компаний, использующих функции качества, ограничивают список потребностей десятью пунктами. О работе с большим списком рассказывается во врезке «Кошмар 2500-й ячейки».
Определение требований проекта. Заказчик выражает свои требования словами, и их нужно перевести на язык действий, при помощи которого команда планирует и реализует проект. Сформулированные таким образом требования проекта можно измерить, а позже сравнить с поставленными целями. Следует различать два вида требований проекта: условия заказчика и предложения команды для их выполнения.
В примере на рис. 4.7 представлены некоторые требования проекта. После непродолжительного мозгового штурма десять основных требований были отобраны и расставлены с учетом приоритетов, а в функцию качества занесены пять из них:
• ограничить количество страниц в документе методологии;
• проводить интервью с менеджерами проектов и управляющими для анализа их работы и просмотра проектной документации;
• использовать корпоративную терминологию при написании документа;
• писать в четком и понятном стиле;
• рассматривать этапы методологии через этапы жизненного цикла проекта.
КОШМАР 2500-Й ЯЧЕЙКИКрыша дома качества связывает соответствующие пары требований проекта. Для обозначения связи могут использоваться разные символы: так, для показа положительной связи мы применяем ●, а для показа отрицательной – ○.
Пат: Что произошло с вашей функцией качества? Такое впечатление, что ей еще далеко до завершения.
Джим: Моя команда ушла, а я отказался от роли менеджера проекта. Потому она и не завершена.
Пат: Но ведь все члены твоей команды пользовались функцией качества раньше? А потом ушли? В чем дело?
Джим: Они перестали приходить на собрание по разработке функции качества. Было множество разнообразных извинений, но я-то знаю: они просто были уверены, что работают впустую.
Пат: Много работы приходится делать впустую.
Джим: Мы уже потратили 16 часов. Возможно, потребуется еще 24. Команда говорит, что наша функция качества слишком большая и на ее составление уходит очень много времени.
Пат: Джим, у тебя матрица 50 × 50. Откровенно говоря, работать с ней действительно обременительно и невыгодно. Твои подчиненные – занятые люди и не могут потратить целую неделю на построение функции качества. Почему бы вам не уменьшить матрицу?
Джим: Я хотел. Я им говорил. Но они не желают больше обсуждать функцию качества. Вот почему я отказываюсь от роли менеджера.
Это типичный пример ситуации, когда неверное применение функции качества настраивает людей против менеджера проекта. Мораль здесь такова: функция качества является отличным инструментом только в случае ее правильного использования.
Рассмотрим пример. Через проведение интервью и обследований мы изучаем корпоративный язык, который помогает при написании методологии. Вероятно, данная связь является положительной. С другой стороны, при поэтапном описании методологии неизбежны повторения, в частности на каждом этапе потребуется анализ развития. Это увеличит объем методологии, что недопустимо. Очевидно, что два условия противоречат друг другу.
Почему мы анализируем взаимосвязи и строим крышу? Потому что эти отношения показывают столкновение требований и возможность нахождения компромисса между ними. Мы видели это на примере связи требования ограничения объема страниц и проведения интервью. Построение крыши дома качества позволяет увидеть условия проекта в совокупности, а не по отдельности [12].
Связь условий заказчика и требований проекта. Основа дома качества – матрица отношений. Она использует подход, похожий на применяемый при построении крыши, для обозначения связи требований проекта и условий заказчика. При нехватке времени и необходимости упрощения процесса будем ставить крестик для обозначения сильной связи между требованиями (см. рис. 4.7). Например, использование корпоративного языка способствует как отражению корпоративной культуры, так и прозрачности методологии.
Отсутствие сильной связи указывает на то, что условия заказчика не перекрываются требованиями проекта – иными словами, при его выполнении могут возникнуть проблемы. С другой стороны, если проектное требование не поддерживает ни одного требования заказчика, оно считается избыточным. Большая часть функций качества, применяемых в сложных проектах, имеет тенденцию к усложнению видов отношений. Вместо крестика допустимо использовать другие символы, показывающие степень влияния. Их можно измерить и после умножения на степень важности задействовать для оценки значимости каждого требования проекта [1].
Сравнение. На этом этапе решаются две проблемы: каждому требованию заказчика присваивается степень важности и проект сравнивается с другими. В нашем примере мы не оценивали требования заказчика, считая их одинаково важными, – это правомерно в случае мелких проектов с ограниченными ресурсами. Крупные проекты выиграют от введения рангов, помогающих сосредоточиться на наиболее значимых для заказчика требованиях.
Сравнение выявляет сильные и слабые стороны проекта по отношению к другим. Так как наш проект является внутренним для подразделения, он противостоит аналогичным проектам. Менеджер вправе спросить, каким образом наша методология соотносится с методологией подразделения А, которое в компании считается наиболее подготовленным к управлению проектами. Сравнение показывает, что наша методология короче; более того, она лучше отражает корпоративную культуру. В технологической компании высоко ценятся краткая документация и собственная культура – это и станет основным направлением работы по улучшению методологии подразделения А. В чем тогда суть сравнения? В определении возможностей для улучшения. Это, в частности, очень важно при сравнении нового продукта компании с продуктами конкурентов.
Разработка целей. Мы уже говорили о важности измерения требований проекта. Обычно для этого внутри компании проводятся дискуссии, и условия проекта формулируются как конечные цели. В нашем примере (см. рис. 4.7) конечные цели ограничены десятью страницами методологии: мы убеждены в том, что при большем объеме наши занятые менеджеры ею не воспользуются. Кроме того, мы считаем, что опроса семи менеджеров достаточно для получения необходимой информации в сжатые сроки. В случае проведения проекта для внешнего заказчика данный подход позволяет оценить требования конкурирующих проектов и скорректировать конечные цели.
Остановка или продолжение. Многие проекты используют только функции качества: это позволяет встроить требования заказчика в процесс планирования. Забегая вперед, скажем, что в крупных проектах приветствуется уточнение нужд заказчика на протяжении всей работы над проектом. С этой целью стоятся еще три дома качества (рис. 4.8). Здесь требования проекта (как сделать) из первого дома перемещаются на место требований заказчика (что сделать) во втором и т. д. Основная цель данной процедуры – соотнести требования заказчика с последовательными низкоуровневыми сокращениями проектных работ, полностью переведя их на операционный уровень. Логика тут похожа на иерархическую структуру (WBS): нужно дойти до уровня совокупности работ – уровня, на котором работа выполнена. Такой подход гарантирует, что требования заказчика будут встроены в самое основание блоков, образующих проект. По мере построения четырех домов качества их необходимо анализировать и корректировать.
Использование функции качества
Когда использовать. Не будет преувеличением сказать, что любой проект – мелкий или крупный – выиграет от разработки функции качества на начальном этапе при формировании границ и планировании. Данный подход наиболее удобен при построении домов качества, если выполняются следующие условия. Во-первых, рекомендуется использовать небольшие одноуровневые дома качества, так как они являются более эффективными. Во-вторых, к построению домов качества необходимо привлекать всю команду. В-третьих, следует удостовериться, что требования действительно исходят от заказчика. И наконец, придется потратить время на обучение людей методам построения домов качества, чтобы в дальнейшем приобщать их к этому процессу в других проектах. Только таким образом вы сможе– те создать ориентированную на заказчика культуру, использующую функции качества как образ жизни.
Время использования. Время, необходимое для построения дома качества, зависит от его размеров и числа людей, вовлеченных в этот процесс. Небольшой дом (см. рис. 4.7) могут создать три человека в течение 45 минут. Для построения большого (10 × 10) дома качества потребуются усилия пяти-шести членов команды и пять-шесть часов работы.
Выгоды. Применение домов качества в проекте имеет как стратегическое, так и тактическое значение. В стратегическом плане функции качества позволяют преодолеть традиционное убеждение, что результаты можно оценить только после завершения проекта. Новый подход с домом качества гарантирует, что проектом управляют требования заказчика, а не желания менеджера. С тактической точки зрения функции качества помогают отойти от процесса планирования проекта, когда команда уверена, что знает нужды заказчика, временные рамки превышаются, а цели проекта меняются, чтобы соответствовать действительным потребностям пользователя. Дом качества требует определения желаний заказчика на первом этапе, что и служит точкой старта проекта.
Преимущества и недостатки. Преимущества дома качества таковы:
• концептуальная простота. Функция качества представляет собой легкий для понимания инструмент, так как его постулаты просты, логичны и не выходят за пределы здравого смысла;
• возможности визуализации. С первого взгляда вы можете оценить миссию дома качества, что делает его удобным инструментом для команды проекта.
Основные недостатки дома качества связаны с его неоправданным усложнением, что провоцирует:
• громоздкость. Если у заказчика больше десяти требований, функции качества становятся тяжелыми для восприятия;
• затраты времени. Некоторые члены команды воспринимают работу по созданию дома качества как интерфейсную (Frontend) для проекта.
Вариации. Существует великое множество матриц, предназначенных для встраивания требований заказчика в рамки проекта. Меняются и их названия: от матрицы заказчика до матрицы принятия решений.
Адаптация дома качества. При описании функции качества мы стремились объяснить, как построить и в дальнейшем использовать ее для получения максимальной отдачи от любых проектов. Ниже мы рассмотрим некоторые идеи по возможной настройке инструмента для конкретного проекта.
Время использования. Время, необходимое для построения дома качества, зависит от его размеров и числа людей, вовлеченных в этот процесс. Небольшой дом (см. рис. 4.7) могут создать три человека в течение 45 минут. Для построения большого (10 × 10) дома качества потребуются усилия пяти-шести членов команды и пять-шесть часов работы.
Выгоды. Применение домов качества в проекте имеет как стратегическое, так и тактическое значение. В стратегическом плане функции качества позволяют преодолеть традиционное убеждение, что результаты можно оценить только после завершения проекта. Новый подход с домом качества гарантирует, что проектом управляют требования заказчика, а не желания менеджера. С тактической точки зрения функции качества помогают отойти от процесса планирования проекта, когда команда уверена, что знает нужды заказчика, временные рамки превышаются, а цели проекта меняются, чтобы соответствовать действительным потребностям пользователя. Дом качества требует определения желаний заказчика на первом этапе, что и служит точкой старта проекта.
Преимущества и недостатки. Преимущества дома качества таковы:
• концептуальная простота. Функция качества представляет собой легкий для понимания инструмент, так как его постулаты просты, логичны и не выходят за пределы здравого смысла;
• возможности визуализации. С первого взгляда вы можете оценить миссию дома качества, что делает его удобным инструментом для команды проекта.
Основные недостатки дома качества связаны с его неоправданным усложнением, что провоцирует:
• громоздкость. Если у заказчика больше десяти требований, функции качества становятся тяжелыми для восприятия;
• затраты времени. Некоторые члены команды воспринимают работу по созданию дома качества как интерфейсную (Frontend) для проекта.
Вариации. Существует великое множество матриц, предназначенных для встраивания требований заказчика в рамки проекта. Меняются и их названия: от матрицы заказчика до матрицы принятия решений.
Адаптация дома качества. При описании функции качества мы стремились объяснить, как построить и в дальнейшем использовать ее для получения максимальной отдачи от любых проектов. Ниже мы рассмотрим некоторые идеи по возможной настройке инструмента для конкретного проекта.
ПРОВЕРКА ФУНКЦИИ КАЧЕСТВА
Проверьте правильность структуры функций качества. В нее должны входить:
• требования заказчика (что нужно сделать);
• требования проекта (как это нужно сделать);
• крыша дома качества (матрица взаимосвязей);
• матрица соотношений;
• сравнительный анализ проектов конкурентов;
• конечные цели.
Резюме
В данном разделе был представлен инструмент функции качества, который помогает встроить требования заказчика в рамки проекта. Любой проект, мелкий или крупный, выигрывает от перевода условий заказчика в функции качества, что служит стартовой точкой при планировании работ. Этот инструмент также помогает взаимодействию функциональных групп, вовлеченных в проект. При адаптации функции качества для конкретного проекта требуется дальнейшее уточнение целей.
Заключительные заметки
В этой главе описаны пять инструментов: сетевой график заказчика, целевой план, выборка, рекомендации для обсуждения и функция качества – набор взаимодополняющих инструментов для досконального изучения требований заказчика. Все вместе они позволяют выяснить условия заказчика и затем встроить их в проектный продукт и процесс (см. таблицу). Хотя использовать их в наборе удобнее, никто не запрещает задействовать каждый инструмент по отдельности.
При раздельном применении каждый инструмент имеет свое назначение. Сетевой график предлагает систематический подход к планированию и организации процесса по выявлению требований заказчика. Причины для встреч с заказчиками и описание необходимых данных сосредоточены в целевом плане. Выборка определяет конкретных представителей, от которых можно получить верную информацию. Рекомендации для обсуждения позволяют задокументировать сценарий встреч. А когда все требования заказчика выяснены, функция качества позволяет включить их в проект. Использование этих инструментов является формальным в крупных проектах и неформальным в мелких.
При раздельном применении каждый инструмент имеет свое назначение. Сетевой график предлагает систематический подход к планированию и организации процесса по выявлению требований заказчика. Причины для встреч с заказчиками и описание необходимых данных сосредоточены в целевом плане. Выборка определяет конкретных представителей, от которых можно получить верную информацию. Рекомендации для обсуждения позволяют задокументировать сценарий встреч. А когда все требования заказчика выяснены, функция качества позволяет включить их в проект. Использование этих инструментов является формальным в крупных проектах и неформальным в мелких.
Литература
1. Shillito, M. L. 2001 “Voice of the Customer” Boca Raton, Fla.: St. Lucie Press.
2. McQuarrie, E. R. 1998 “CustomerVhits” Vol. 2. Thousand Oaks, Ca.: Sage Publications.
3. Goetsch, D. L. and S. B. Davis 2000 “Introduction to Total Quaitiy” 3d ed. Upper Saddle River, NJ: Prentice Hall.
4. Hammer, M. and J. Champy 1993 “Reengineering the Corporation” JewYork: Harper Business.
5. McKenna, R. 1995 “Real – Time Marketing” Harvard Business Review 73(4): 87 – 95.
6. Scholtes, P. R. 1996 “The Team Handbook” 2d ed. Madison, Wis.: Joiner Associates.
7. University of Michigan Business School and American Society for Quality 1998 “American Customer Satisfaction Index: 1994 – 1998” Ann Arbor: University of Michigan Press.
8. Thompson, A. T. and A. J. Strickland 1995 “Crafting and Implementing Strategy” Boston: Irwin.
9. Hoch, D. J., ?. R. Roeding, G. Purkert, and K. S. Lindner 2000 “The Secrets of Software Success” Boston, Harvard Business School Press.
10. Norman, D. A. 1998 “The Invisible Computer” Cambridge, Mass.: The MIT Press.
11. Shillito, M. L. 1994 “Advanced QFD” New York: John Wiley & Sons.
12. Evans, R. J. and M. W. Lindsay 1999 “The Management and Control of Quality” St. Paul, Minn.: South – Wesiern College Publishing.
2. McQuarrie, E. R. 1998 “CustomerVhits” Vol. 2. Thousand Oaks, Ca.: Sage Publications.
3. Goetsch, D. L. and S. B. Davis 2000 “Introduction to Total Quaitiy” 3d ed. Upper Saddle River, NJ: Prentice Hall.
4. Hammer, M. and J. Champy 1993 “Reengineering the Corporation” JewYork: Harper Business.
5. McKenna, R. 1995 “Real – Time Marketing” Harvard Business Review 73(4): 87 – 95.
6. Scholtes, P. R. 1996 “The Team Handbook” 2d ed. Madison, Wis.: Joiner Associates.
7. University of Michigan Business School and American Society for Quality 1998 “American Customer Satisfaction Index: 1994 – 1998” Ann Arbor: University of Michigan Press.
8. Thompson, A. T. and A. J. Strickland 1995 “Crafting and Implementing Strategy” Boston: Irwin.
9. Hoch, D. J., ?. R. Roeding, G. Purkert, and K. S. Lindner 2000 “The Secrets of Software Success” Boston, Harvard Business School Press.
10. Norman, D. A. 1998 “The Invisible Computer” Cambridge, Mass.: The MIT Press.
11. Shillito, M. L. 1994 “Advanced QFD” New York: John Wiley & Sons.
12. Evans, R. J. and M. W. Lindsay 1999 “The Management and Control of Quality” St. Paul, Minn.: South – Wesiern College Publishing.
Глава 5
Планирование содержания
Гневайся, когда ты желаешь этого, и твой гнев будет иметь границы.
Вильям Шекспир
Основные темы настоящей главы – это инструменты планирования содержания:
• устав проекта;
• SWOT-анализ[12] проекта;
• описание содержания;
• иерархическая структура работ.
Цель названных инструментов – определить, какие процессы необходимо выполнить в рамках проекта для того, чтобы успешно его завершить (рис. 5.1). В частности, они формируют базовый план для последующей разработки расписания и планирования стоимости. Их применение в сочетании с инструментами организационного планирования, а также планирования качества и риска в конечном итоге приводит к разработке плана проекта. Позднее, на стадии выполнения, базовый план содержания становится основой для упорядоченного контроля содержания и внесения изменений в него, создавая тем самым надежный барьер на пути «расползания» границ содержания.
Данная глава призвана помочь менеджерам проектов:
• познакомиться с различными инструментами планирования содержания;
• выбрать те инструменты, которые отвечают проектным потребностям;
• адаптировать выбранные инструменты в соответствии со своими нуждами.
Перечисленные навыки являются необходимой основой для успешного планирования проектов и разработки процесса стандартизованного управления ими.
Устав проекта
Что такое устав проекта?
Устав проекта – это инструмент, который формально авторизует проект (рис. 5.2). Данный документ обычно выпускается руководителем, внешним по отношению к проекту, и наделяет менеджера полномочиями на использование в проекте ресурсов организации. Это особенно важно в среде, где менеджеры не имеют непосредственной власти над членами проектной команды и другими ресурсами, но несут ответственность за выполнение проекта. Чтобы устав имел силу в подобной ситуации, издающий его руководитель должен находиться на том уровне, который имеет контроль над ресурсами.
Составление устава проекта
При сравнении информации, содержащейся в уставе и в описании содержания проекта, можно отметить много общего. И устав, и описание включают одни и те же элементы, например бизнес-цель, задачи проекта и контрольные события. Отличие заключается в степени детализации данных элементов. Если быть точным, то, поскольку устав проекта представляет собой инструмент авторизации, он, как правило, содержит меньшее количество деталей, ибо как раз и дает проектной команде разрешение на выполнение цикла детального планирования, частью которого является описание содержания. Закономерно, что описание содержания включает в себя больше деталей проекта, чем устав (см. раздел «Описание содержания»).