Составление сетевого графика заказчика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данный текст является ознакомительным фрагментом.