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

Ниже, текст доклада 2012 года.

В проектах в области информационных технологий на фазе планирования часто появляется проблема – как увязать большое количество требований заинтересованных сторон между собой. При этом, как правило, нужно учитывать два обстоятельства: во-первых, заинтересованных сторон довольно много; во-вторых, требования сторон часто противоречат друг другу. С позиции профессионального подхода Международного института управления проектами (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: Более того, на последнем шаге мы достраиваем нашу матрицу, заполняя столбец по конкурентам. В правом вертикальном блоке мы проставляем условные веса того, как данные перечисленные потребительские требования и ожидания реализованы у наших ближайших конкурентов.

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

• Ограничения по реализуемости
• Конкурентную среду
• Взаимосвязь характеристик продукта
• «Забытые» требования и требования, которые будут противоречить друг другу.

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