Набор инструментов для управления проектами
Шрифт:
Основными здесь являются следующие вопросы:
• Кто из команды наиболее подготовлен для ведения переговоров?
• Хватит ли выбранным сотрудникам времени для общения и обработки информации?
• Запланировано ли обучение сотрудников для более эффективного общения?
На практике в состав команды обычно входят два человека. Например, для общения с восемью заказчиками создаются две команды по два человека, и каждая команда проводит по четыре встречи. Присутствие на встрече более двух человек способно испортить дискуссию. Кроме того, если участников двое, они могут разделить функции: один задает вопросы, а другой делает заметки. Необходимое условие при зачислении в команду –
И наконец, в бюджете следует предусмотреть статью для покрытия транспортных расходов интервьюеров. Это особенно важно при необходимости поездок в другие города или страны.
Общение с заказчиком. На основе подготовленных рекомендаций для обсуждения избранные члены команды проводят встречу с заказчиком проекта. Подготовка к интервью должна включать ответы на следующие вопросы:
• Продумана ли логистика проекта для обеспечения успеха контакта?
• Был ли заказчик уведомлен о предстоящих контактах?
• Был ли определен и согласован способ фиксации информации?
Организовать встречу следует так, чтобы ничто не помешало проведению интервью. Время и место встречи, присутствие заказчика и т. п. заслуживают пристального внимания. К тому же безусловным требованием является ведение записей, поскольку это единственный способ сохранить полезную информацию. Представьте себе, например, обсуждение восьми интервью, записи на которых не делались, особенно если они прошли несколько недель назад.
Обработка информации. После завершения всех встреч нужно собрать полученную информацию в единый отчет, который будет полезен проекту. Обычно это реализуется при тесном взаимодействии всех участников интервью. Цель такого взаимодействия – убедиться в том, что ответы на нижеследующие вопросы являются утвердительными:
• Была ли собрана воедино вся информация по всем контактам?
• Будет ли конечный отчет написан и разослан членам команды проекта?
• Зафиксирован ли накопленный опыт для улучшения работы на следующих этапах взаимодействия с заказчиком?
Типичный сценарий встречи может выглядеть следующим образом. Принимая во внимание общие рекомендации для обсуждения, начните с наиболее важных вопросов. Каждый участник изложит полученные данные, сделает необходимые заявления, расспросит о потребностях заказчика и систематизирует информацию по определенным категориям – к примеру, нужды заказчика и его разочарования. Используйте целевой план для выявления критериев оценки потребностей заказчика. Требования заказчика, ранжированные с учетом приоритетов, становятся так называемыми факторами ценности. В конце встречи нужно вычленить от трех до пяти категорий с потребностями, расставленными в порядке убывания их приоритетов. Последним шагом должно стать принятие на себя ответственности за применение информации, а затем составление письменного отчета.
«Встраивание» информации в границы проекта. Именно на этом этапе можно получить отдачу от учета требований заказчика. Помните, что вся собранная информация бесполезна до тех пор, пока она не включена в границы проекта. К примеру, один из вариантов – встреча членов команды для анализа итогового отчета, определенных последствий или действий, необходимых как результат обсуждения. Также целесообразно рассмотреть отчет с менеджерами. Проверьте, что требования заказчика непосредственно встроены
в границы проекта. Следующие вопросы помогут вам понять, завершен ли данный этап:• Определены ли факторы ценности для заказчика?
• Усвоила ли команда проекта эти факторы?
• Были ли факторы ценности интегрированы в процессы и проектные продукты?
Один из структурных подходов к интерпретации требований заказчика в границах проекта реализуется при помощи функции качества, подробно описанной в конце этой главы. Если работа начинается с факторов ценности для заказчика (Чего хотелось бы заказчику и в каком порядке?), то функции качества служат ее продолжением («Как в проекте учитываются пожелания заказчика?»), что выражается в переносе требований в рамки проекта и даже изменении деталей проекта.
Использование сетевого графика заказчика
Когда использовать. Сетевой график заказчика требуется в больших проектах, обычно на этапе определения границ. Многие команды начинают его формирование еще на этапе подготовки предложения и в процессе выбора проекта: это дает возможность оценить проект и включить необходимые ресурсы в план. В некоторых случаях именно на этом этапе начинается общение с заказчиками. У каждого заказчика должен быть собственный сетевой график.
В случае разработки сетевого графика для небольшого проекта процедура может быть более неформальной и гибкой ввиду ограниченного бюджета. Распространенной практикой формирования сетевых графиков становятся разработка корпоративного шаблона и его адаптация для конкретного проекта. Вне зависимости от размера и сложности проекта построение сетевого графика или его заимствование из шаблона служит для обеспечения прозрачности.
Время использования. Размер проекта определяет временные рамки сетевого графика. Обычно на составление такого графика для маленького проекта уходит около часа работы команды, в то время как для большого может потребоваться от трех до четырех часов. Много ресурсов задействовано и в процессе получения необходимой информации от заказчика, что также занимает значительное время, особенно в больших проектах. Например, на посещение командой проекта заказчика может уйти от двух дней до шести-восьми недель (хотя в маленьких проектах затраченное время сокращается до часа).
Выгода. Сетевой график позволяет уточнить требования заказчика проекта. Почти все члены команды сходятся во мнении, что необходимо понять требования заказчика, и знакомы с формальной процедурой получения нужной информации. Сетевой график помогает убедиться в том, что команда предприняла правильные шаги в нужной последовательности. Он также гарантирует, что к процессу получения качественной входной информации от заказчика отнеслись с должным вниманием.
Другая выгода становится очевидной, если вспомнить, что в начале проекта пожелания заказчика обычно неясны. Как показывает опыт, во многих проектах, связанных с производством программного обеспечения, половина времени уходит на внесение изменений в соответствии с нуждами заказчика [9]. С помощью сетевого графика можно в сжатые сроки создать поддающуюся интерпретации область проекта, уменьшить количество необходимых изменений и ускорить завершение работ.
Преимущества и недостатки. Ниже приведены два основных преимущества сетевого графика заказчика:
• наглядность. Визуальное представление процесса получения информации от заказчика делает сам процесс ясным и простым;
• образование. Так как сетевой график является относительно новым инструментом в управлении проектами, он полезен при обучении членов команды новым методам получения информации от заказчиков.