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

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

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

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

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

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

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

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

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

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