На фазе планирования проектов в области информационных технологий часто появляется проблема – как увязать между собой множество требований заинтересованных сторон. При этом, как правило, нужно учитывать два обстоятельства: во-первых, заинтересованных сторон довольно много; во-вторых, требования сторон часто противоречат друг другу. С позиции профессионального подхода Международного института управления проектами (PMI) в данных процессах рекомендуется составлять матрицу отслеживания требований. Однако ее вид и содержание не регламентируются общепризнанными стандартами по управлению проектами.

В поисках вариантов механизма отслеживания требований на помощь приходит японская методология QFD (Quality Function Deployment – технология развертывания функций качества).

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

С точки зрения использования методологии QFD в информационных технологиях в Интернете не найдено большого количества примеров. Тем не менее алгоритм управления требованиями остается неизменным и в данном случае.

В общем, алгоритм внедрения методологии QFD состоит из ряда последовательных шагов.

    Шаг 1. Определение требований потребителей.
    Шаг 2. Понимание требований потребителей.
    Шаг 3. Анализ текущих возможностей.
    Шаг 4. Оценка возможностей конкурентов.
    Шаг 5. Определение разрывов.
    Шаг 6. Определение способов достижения стратегического превосходства.
    Шаг 7. Анализ компромиссов.
    Шаг 8. Выбор главных показателей качества.
    Шаг 9. Структурирование программы качества.

В данной статье предпринята попытка применения методологии QFD в ИТ-проекте по разработке системы дистанционного банковского обслуживания для коммерческого банка. Для структуризации информации был применен шаблон таблицы QFD в формате MS Excel (см. рис.). Основные действия таковы.

Шаг 1: С помощью стандартных методов обследования был составлен список требований заинтересованных сторон к новому продукту (система ДБО). Был сделан акцент на том, чтобы в список попали не только явные, но и подразумеваемые требования. Список требований занимает собой левый столбик таблицы QFD. Для простоты отображения информации ограничимся демонстрацией только 10 требований (рис. 1), хотя ограничений по количеству требований в данном методе нет. Примеры требований: масштабируемость, возможность интеграции с системой «1С» и т. п.

Шаг 2: Проводится ранжирование требований. Им составляют субъективную характеристику – вес, имеющую числовое значение от 0 до 10. Естественно, этот процесс согласуется с заказчиком и, возможно, с другими заинтересованными сторонами проекта. Теперь у требований появляется числовая характеристика – вес или важность.

Шаг 3: Составляем список функциональных и прочих характеристик новой системы ДБО на основании списка требований и принимая во внимания ограничения и допущения, которые на данном этапе уже должны быть сформулированы в уставе проекта. Список занимает горизонтальную строку (перекрытие таблицы QFD). Для простоты ограничимся списком из 15 характеристик нового продукта, среди которых наличие встроенного механизма получения выписок, использование СУБД и прочее. Теперь у нашей таблицы QFD, или, как еще ее называют, «домика» качества, есть стены и перекрытия (см. рис.).

Шаг 4: В пространстве «домика» заполняем таблицу зависимостей между всеми требованиями характеристиками, используя следующую легенду:

Отметим, что пиктограмма связи имеет еще и числовое значение – вес, который будет использоваться при расчете. Для простановки связей используем команду проекта и приглашенных экспертов, включая экспертов от заказчика. Уже на данном шаге команда проекта начинает осознанно чувствовать, как различные «пожелания» заказчика влияют на характеристики нового продукта.

Шаг 5: Вычисление веса каждого требования согласно поставленным зависимостям от характеристик продукта. В нашей матрице это левый ряд с наименованием Relative Weight.

Шаг 6: Монтируем крышу «домика» качества. Крыша предназначена для простановки взаимосвязей между характеристиками продукта для понимания влияния их друг на друга.

На данном шаге мы выясняем зависимость между характеристиками будущего продукта. Эту зависимость мы будем использовать на протяжении всего проекта до сдачи продукта заказчику.

Шаг 7: На данном шаге в таблице по каждой характеристике продукта уже появилось значение веса Weight. Заполняем «подвал» матрицы установкой в строке Target or Limit Value целевых характеристик будущего продукта с учетом рейтинга важности потребительских требований. Здесь для формулировки целевых характеристик нам на помощь приходит, например, методология SMART.

Шаг 8: В нижней части матрицы проставляем также коэффициенты трудности реализации каждого требования от 0 (легко выполнить) до 10 (чрезвычайно сложно выполнить), используя экспертную оценку технической реализуемости. Теперь у нас появилась модель нового продукта с ранжированием характеристик, учитывающих важность с точки зрения потребителя, ограничения по реализуемости и эффекты от влияния характеристик продукта между собой. Соответственно можно составлять описание содержания продукта, учитывая имеющиеся ограничения по сроку и бюджету и концентрируясь на самых важных потребительских характеристиках нового продукта.

Шаг 9: Более того, на последнем шаге мы достраиваем нашу матрицу, заполняя столбец по конкурентам. В правом вертикальном блоке мы проставляем условные веса того, как данные перечисленные потребительские требования и ожидания реализованы у наших ближайших конкурентов.

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

  1. ограничения по реализуемости;
  2. конкурентную среду;
  3. взаимосвязь характеристик продукта;
  4. «забытые» требования и требования, которые будут противоречить друг другу.

Нелишним будет отметить, что данным методом удобно пользоваться, когда вы используете гибкие (agile) методологии управления ИТ-проектом и на постоянной основе отслеживаете внутренние и внешние изменения в содержании проекта. В какой-то степени эта матрица может стать «священной коровой» вашего проекта.