Национальный исследовательский университет "Высшая Школа Экономики"
Опубликован: 25.01.2011 | Доступ: свободный | Студентов: 7769 / 2570 | Оценка: 4.32 / 4.06 | Длительность: 14:47:00
ISBN: 978-5-9963-0466-0
Лекция 2:

Инициация проекта

< Лекция 1 || Лекция 2: 1234 || Лекция 3 >

Формирование требований проекта

Данный процесс направлен на изучение требований заказчика, которые должны быть уже отражены в уставе проекта, и перенос их в более конкретные термины требований проекта, на основе которых уже формируется список проектных работ и программа качества проекта. Для получения корректной информации необходимо в самом начале правильно организовать ее сбор, который на ИТ-проектах чаще всего реализуется в форме интервью с заказчиком (см. рис. 1.5).

Организация и проведение результативного интервью

  1. Подготовка

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

    Основная рекомендация для проведения интервью для формирования функциональных требований к системе - использовать подход, применяемый в структурном моделировании, то есть постараться задать вопросы и получить информацию в разрезе, как показано на рис. 1.4.

    • "Большая картинка"
      • Место (под)процесса в сквозном процессе
      • Интерфейс с предшествующим процессом
      • Интерфейс с последующим процессом
    • Описание процесса
      • Что? (типовой результат и его потребитель)
      • Как? (последовательность шагов и показатели эффективности)
      • Кто? (роли и присущая им квалификация)
      • Чем? (используемые средства, инструменты, расходуемые ресурсы)
    • Документы
      • Входящие документы
      • Исходящие документы
      • Регламентирующие документы
  2. Проведение

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

    Принцип структурирования информации о бизнес-процессе

    увеличить изображение
    Рис. 1.4. Принцип структурирования информации о бизнес-процессе

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

  3. Дальнейшие действия

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

    В качестве отчета по интервью готовится сводный протокол, который затем отправляется на согласование. Пример шаблона протокола представлен в табл. 1.8.

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

    • Определены ли факторы ценности для заказчика?
    • Усвоила ли команда проекта эти факторы?
    • Были ли факторы ценности интегрированы в процессы и проектные продукты?

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

Таблица 1.8. Шаблон протокола интервью
УПРАВЛЕНИЕ ДОКУМЕНТОМ
Автор
Дата создания
ИНФОРМАЦИЯ О ВСТРЕЧЕ
Время и дата
Порядковый номер
Адрес/ место
УЧАСТНИКИ ВСТРЕЧИ
Со стороны заказчика [ФИО, должность]
Со стороны исполнителя [ФИО, должность]
РЕЗУЛЬТАТЫ ОБСУЖДЕНИЯ
Пункт повестки/ вопрос Результаты обсуждения Ответственный Сроки выполнения
.
.
.
СТАТУС ПРОТОКОЛА
Согласовано [ФИО, должность]
Утверждено [ФИО, должность]
ИНФОРМАЦИЯ О СЛЕДУЮЩЕЙ ВСТРЕЧЕ
Время/ Дата
Место

Использование функции качества

Функция качества - это инструмент для работы с заказчиком, который позволяет встроить его требования в проект. Цель этого инструмента - убедиться, что требования заказчика интегрированы в каждую часть проекта, от определения (1) требований проекта и (2) установления характеристик решения до формирования (3) проектных работ и выстраивания (4) программы обеспечения качества.

Процесс построения "дома качества" - предельно сложная процедура, особенно в случае крупных проектов. Тем не менее, этот инструмент довольно удобен в использовании и значительно повышает качество процесса управления требованиями проекта.

На рис. 1.6 отражена типовая структура "дома качества". Его заполнение производится в несколько этапов.

  1. Подготовка требований заказчика
    Схема и рекомендации по проведению интервью

    увеличить изображение
    Рис. 1.5. Схема и рекомендации по проведению интервью

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

  2. Определение требований проекта
    Функция качества проекта ("домик" качества)

    Рис. 1.6. Функция качества проекта ("домик" качества)

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

  3. Формирование матрицы взаимосвязей

    На этом этапе происходит проверка отсутствия взаимных противоречий между сформулированными требованиями проекта, иными словами, происходит их попарное сравнение. Для обозначения связи могут использоваться разные символы: так, для показа положительной связи часто используют o, а для показа отрицательной - o. Идентифицированные отношения демонстрируют столкновение требований и возможность нахождения компромисса между ними, что позволяет увидеть условия проекта в совокупности, а не по отдельности.

  4. Формирование матрицы отношений

    Заполнение матрицы отношений есть ключевой шаг построения "дома качества". Смысл ее заполнения состоит в том, чтобы убедиться, что все требования заказчика будут удовлетворены предложенными требованиями проекта. На пересечении соответствующего требования заказчика и требования проекта при наличии положительной связи ставится отметка, например, крестик. Если требование заказчика не поддерживается ни одним требованием проекта, значит, удовлетворение первого может вызвать ряд проблем. В обратной ситуации, когда проектное требование не соотносится ни с одним требованием заказчика, говорят об избыточности данного проектного требования. На крупных проектах иногда усложняют отношения между требованиями заказчика и проекта и вместо крестика используют числовые значения, характеризующие степень влияния требований проекта на реализацию заданного требования заказчика [5].

  5. Субъективная оценка через сравнительный анализ

    На данном этапе происходит присвоение степени важности каждому требованию заказчика и проект сравнивается с другими проектами и/или текущим status quo. Сравнение выявляет сильные и слабые стороны проекта по отношению к аналогичным инициативам, определяет возможности для улучшения.

  6. Объективная оценка через установку конечных целей

    Для обеспечения измерения и последующего контроля реализации требований проекта (а через них - и обеспечения требований заказчика) необходимо задать измеримые конечные цели по каждому требованию проекта, тем самым обеспечив объективную основу для управления ими.

< Лекция 1 || Лекция 2: 1234 || Лекция 3 >
Анна Яковлева
Анна Яковлева
Надежда Артюх
Надежда Артюх
Курс Методологии проектирования и внедрения корпоративных информационных систем