Инициация проекта
Формирование требований проекта
Данный процесс направлен на изучение требований заказчика, которые должны быть уже отражены в уставе проекта, и перенос их в более конкретные термины требований проекта, на основе которых уже формируется список проектных работ и программа качества проекта. Для получения корректной информации необходимо в самом начале правильно организовать ее сбор, который на ИТ-проектах чаще всего реализуется в форме интервью с заказчиком (см. рис. 1.5).
Организация и проведение результативного интервью
- Подготовка
Изначально необходимо точно сформулировать основные идеи, которые определяют цель визита к заказчику. Участники команды проекта должны очень ясно представлять себе, какого рода информация нужна и каким образом она будет использована, с тем чтобы точно определить целевую аудиторию. Только после этого необходимо переходить к разработке списка вопросов, которые будут заданы заказчику.
Основная рекомендация для проведения интервью для формирования функциональных требований к системе - использовать подход, применяемый в структурном моделировании, то есть постараться задать вопросы и получить информацию в разрезе, как показано на рис. 1.4.
- "Большая картинка"
- Место (под)процесса в сквозном процессе
- Интерфейс с предшествующим процессом
- Интерфейс с последующим процессом
- Описание процесса
- Что? (типовой результат и его потребитель)
- Как? (последовательность шагов и показатели эффективности)
- Кто? (роли и присущая им квалификация)
- Чем? (используемые средства, инструменты, расходуемые ресурсы)
- Документы
- Входящие документы
- Исходящие документы
- Регламентирующие документы
- "Большая картинка"
- Проведение
Рекомендуется планировать интервью исходя из максимальной продолжительности в 1,5 часа. Учитывая весьма ограниченное время, необходимо всегда приходить в указанный час, заранее продумать маршруты пути к месту встречи. Каждый участвующий в процессе общения с заказчиком должен оперировать одним и тем же набором вопросов в одинаковой последовательности, чтобы обеспечить порядок проведения переговоров и удобство при дальнейшем формировании протокола интервью.
На практике для проведения интервью часто составляют команды по два человека, это удобно с той точки зрения, что один задает вопросы, а другой делает пометки. В то же время присутствие на встрече более двух интервьюеров способно значительно повредить общению.
- Дальнейшие действия
После завершения всех встреч нужно собрать полученную информацию в единый отчет, который будет полезен проекту. Обычно это реализуется при тесном взаимодействии всех участников интервью, в том числе и интервьюированных представителей заказчика, которые согласуют подготовленный сводный протокол интервью.
В качестве отчета по интервью готовится сводный протокол, который затем отправляется на согласование. Пример шаблона протокола представлен в табл. 1.8.
Крайне важным моментом является "встраивание" информации, полученной на интервью от заказчика, в проектную документацию - иначе вся собранная информация не имеет никакого значения для проекта. Для того чтобы проверить, были ли учтены требования заказчика в проектных спецификациях, рекомендуется ответить на следующие вопросы:
- Определены ли факторы ценности для заказчика?
- Усвоила ли команда проекта эти факторы?
- Были ли факторы ценности интегрированы в процессы и проектные продукты?
Инструментом, который позволяет обеспечить положительные ответы на эти вопросы, является функция качества или "дом качества", речь о котором пойдет ниже, в разделе, посвященном формированию требований проекта.
УПРАВЛЕНИЕ ДОКУМЕНТОМ | |||
---|---|---|---|
Автор | |||
Дата создания | |||
ИНФОРМАЦИЯ О ВСТРЕЧЕ | |||
Время и дата | |||
Порядковый номер | |||
Адрес/ место | |||
УЧАСТНИКИ ВСТРЕЧИ | |||
Со стороны заказчика | [ФИО, должность] | ||
Со стороны исполнителя | [ФИО, должность] | ||
РЕЗУЛЬТАТЫ ОБСУЖДЕНИЯ | |||
Пункт повестки/ вопрос | Результаты обсуждения | Ответственный | Сроки выполнения |
. | |||
. | |||
. | |||
СТАТУС ПРОТОКОЛА | |||
Согласовано | [ФИО, должность] | ||
Утверждено | [ФИО, должность] | ||
ИНФОРМАЦИЯ О СЛЕДУЮЩЕЙ ВСТРЕЧЕ | |||
Время/ Дата | |||
Место |
Использование функции качества
Функция качества - это инструмент для работы с заказчиком, который позволяет встроить его требования в проект. Цель этого инструмента - убедиться, что требования заказчика интегрированы в каждую часть проекта, от определения (1) требований проекта и (2) установления характеристик решения до формирования (3) проектных работ и выстраивания (4) программы обеспечения качества.
Процесс построения "дома качества" - предельно сложная процедура, особенно в случае крупных проектов. Тем не менее, этот инструмент довольно удобен в использовании и значительно повышает качество процесса управления требованиями проекта.
На рис. 1.6 отражена типовая структура "дома качества". Его заполнение производится в несколько этапов.
- Подготовка требований заказчика
Требования заказчика - важнейшая информация при построении "дома качества". Как правило, это самый сложный этап, поскольку необходимо выяснить наиболее значимые условия заказчика. Основной объем информации о его потребностях был выявлен в процессе интервьюирования и на этапе подготовке ТЭО и устава проекта. При разработке функции качества рекомендуется ограничивать функцию качества 10-ю требованиями заказчика, в противном случае использование инструмента становится громоздким.
- Определение требований проекта
В отличие от требований заказчика, требования проекта сформулированы в терминах конкретных действий, при помощи которых команда планирует и реализует проект. Сформулированные таким образом требования проекта должны быть доступны для выполнения измерения и контроля достижения по завершению проекта. Следует различать два вида требований проекта: условия заказчика и предложения команды для их выполнения, как правило, содержащиеся в соответствующей методологии.
- Формирование матрицы взаимосвязей
На этом этапе происходит проверка отсутствия взаимных противоречий между сформулированными требованиями проекта, иными словами, происходит их попарное сравнение. Для обозначения связи могут использоваться разные символы: так, для показа положительной связи часто используют o, а для показа отрицательной - o. Идентифицированные отношения демонстрируют столкновение требований и возможность нахождения компромисса между ними, что позволяет увидеть условия проекта в совокупности, а не по отдельности.
- Формирование матрицы отношений
Заполнение матрицы отношений есть ключевой шаг построения "дома качества". Смысл ее заполнения состоит в том, чтобы убедиться, что все требования заказчика будут удовлетворены предложенными требованиями проекта. На пересечении соответствующего требования заказчика и требования проекта при наличии положительной связи ставится отметка, например, крестик. Если требование заказчика не поддерживается ни одним требованием проекта, значит, удовлетворение первого может вызвать ряд проблем. В обратной ситуации, когда проектное требование не соотносится ни с одним требованием заказчика, говорят об избыточности данного проектного требования. На крупных проектах иногда усложняют отношения между требованиями заказчика и проекта и вместо крестика используют числовые значения, характеризующие степень влияния требований проекта на реализацию заданного требования заказчика [5].
- Субъективная оценка через сравнительный анализ
На данном этапе происходит присвоение степени важности каждому требованию заказчика и проект сравнивается с другими проектами и/или текущим status quo. Сравнение выявляет сильные и слабые стороны проекта по отношению к аналогичным инициативам, определяет возможности для улучшения.
- Объективная оценка через установку конечных целей
Для обеспечения измерения и последующего контроля реализации требований проекта (а через них - и обеспечения требований заказчика) необходимо задать измеримые конечные цели по каждому требованию проекта, тем самым обеспечив объективную основу для управления ими.