Текст книги "Набор инструментов для управления проектами"

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

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

1. Harrison, J. S. and C. St. John 1998 “Strategic Management of Organizations and Stakeholders” 2d ed. Cincinnati: South – Western College Publishing.

2. Brenner, M. S. 1994 “Practical R&D Project Prioritization” Research Technology management 37(5): 38 – 42.

3. Buss, M. D. J. 1983 “How to Rank Computer Project” Harvard Business Review 1(71): 145.

4. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1998 “Best Practices for Managing R&D Portfolios: Lessons from the leaders – Part II” Research Technology Management 41(4): 20 – 33.

5. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1997 “Portfolio Management in New Product Development: Lessons from the leaders – Part I” Research Technology Management 41(4): 20 – 33.

6. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1997 “Portfolio Management in New Product Development: Lessons from the leaders – Part II” Research Technology Management 40(6): 43 – 52.

7. Archer, N. P. and F. Ghazemzaden 1999 “An Integrated Framework for project Portfolio Selection” International Journal of Project Management 17(4): 207 – 216.

8. Marheson, D., J. E. Matheson and M. M. Menke 1995 “Making Excellent R&D Decisions” Research Technology Management 37(6) 21 – 24.

9. Marheson, D., J. E. Matheson and M. M. Menke 1994 “Using Decision Quality Principles to Balansce Your R&D Portfolio” Research Technology Management 37(3) 38 – 43.

Часть 2
Инструменты планирования проекта

Глава 4
Требования заказчика проекта

Глава написана при участии Джоза Кампоса (Jose Campos).

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

• сетевой график заказчика;

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

• выборка;

• рекомендации для переговоров;

• использование функции качества (Quality Function Deployment – QFD).

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

В этой главе менеджеры проектов научатся:

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

• выбирать методы, которые соответствуют реальной проектной ситуации;

• адаптировать выбранные методы к собственным нуждам.

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

Рис. 4.1. Роль метода определения требований заказчика в процессе управления проектом

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

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

Разработка и применение сетевого графика заказчика – достаточно новое явление в проектных организациях. Отсутствие опыта повышает риск ошибки. Чтобы не допустить оплошности, следует обратить внимание на методическую разработку и построение сетевого графика с четко определенной последовательностью этапов (см. рис. 4.2).

Рис. 4.2. Сетевой график заказчика

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

• план проекта;

• список членов команды.

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

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

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

• Почему необходимо сотрудничество с заказчиками проекта?

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

• Каким образом использовать полученную в ходе взаимодействия информацию?

ОСНОВНОЕ ТРЕБОВАНИЕ ЗАКАЗЧИКА – ЭФФЕКТИВНЫЕ ВЛОЖЕНИЯ

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

Рассмотрим пример. Сервисная служба компании Apple Computers обзванивает клиентов и каждую неделю публикует список, включающий 10 наиболее часто возникающих проблем. На основе этого списка разработчики улучшают процессы производства продуктов или начинают выпуск новых с учетом имеющихся пожеланий клиентов. Довольные клиенты нужны для поддержания стабильного экономического положения компании. Так, в 1997 году фирмы, преуспевшие в удовлетворении своих клиентов, удвоили акционерный капитал. Не секрет, что наиболее успешные мировые производители программного обеспечения считают вовлеченность заказчиков в производственный процесс одним из наиболее важных факторов выполнения проекта в целом: удовлетворение клиентов начинается с их участия в проекте. Таким образом, игнорирование требований заказчика – плохое решение для бизнеса.

Подготовка выборки[9]9
  Обычно под этим в управлении проектами подразумевается часть работ, относящихся к формированию так называемого профиля заказчика, где среди прочего определяются ключевые фигуры заказчика, его миссия, декларированная и истинная мотивации участия в проекте и прочее. – Прим. ред.


[Закрыть]. После определения цели взаимодействия с заказчиком нужно выявить представителя заказчика, с которым предстоит общаться (см. врезку «У каждого проекта есть заказчик»). Это обычно происходит на собрании команды или всех участников фактического взаимодействия по проекту. Для создания профиля необходимо ответить на следующие вопросы:

• С кем общаться для получения достоверной информации?

• Где находятся эти доверенные лица?

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

Данная информация описывает представителей заказчика, с которыми нужно взаимодействовать.

Разработка рекомендаций для обсуждения. На следующем этапе члены команды должны составить вопросы или выбрать темы для обсуждения с заказчиком проекта. Здесь основными будут вопросы:

• Какая информация действительно нужна?

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

• Является ли ответ на вопрос значимой информацией для проекта?

У КАЖДОГО ПРОЕКТА ЕСТЬ ЗАКАЗЧИК

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

Внешние и внутренние заказчики демонстрируют схожие модели поведения. Например, их определение выгоды складывается на основе собственных нужд, наборов целей или выдвигаемых на данный момент требований. Ошибочным является предположение о том, что все работают на одну организацию и стремления каждого понятны. Иными словами, внутренние заказчики проявляют все свойства внешних. Менеджер проекта должен учитывать мнение заказчика проекта, к какой бы категории тот ни принадлежал[10]10
  Термины участник (stakeholder) и заказчик (customer) проекта часто являются взаимозаменяемыми. – Примечание авт.


[Закрыть].

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

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

Основными здесь являются следующие вопросы:

• Кто из команды наиболее подготовлен для ведения переговоров?

• Хватит ли выбранным сотрудникам времени для общения и обработки информации?

• Запланировано ли обучение сотрудников для более эффективного общения?

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

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

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

• Продумана ли логистика проекта для обеспечения успеха контакта?

• Был ли заказчик уведомлен о предстоящих контактах?

• Был ли определен и согласован способ фиксации информации?

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

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

• Была ли собрана воедино вся информация по всем контактам?

• Будет ли конечный отчет написан и разослан членам команды проекта?

• Зафиксирован ли накопленный опыт для улучшения работы на следующих этапах взаимодействия с заказчиком?

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

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

• Определены ли факторы ценности для заказчика?

• Усвоила ли команда проекта эти факторы?

• Были ли факторы ценности интегрированы в процессы и проектные продукты?

Один из структурных подходов к интерпретации требований заказчика в границах проекта реализуется при помощи функции качества, подробно описанной в конце этой главы. Если работа начинается с факторов ценности для заказчика (Чего хотелось бы заказчику и в каком порядке?), то функции качества служат ее продолжением («Как в проекте учитываются пожелания заказчика?»), что выражается в переносе требований в рамки проекта и даже изменении деталей проекта.

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

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

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

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

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

Преимущества и недостатки. Ниже приведены два основных преимущества сетевого графика заказчика:

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

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

Практика указывает и на недостатки сетевой модели:

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

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

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