Прослеживаемость требований: откуда взялся этот допуск?

Ситуация: зазор двери 4 ± 0,5 мм

Дверь автомобиля — классический учебный пример QFD: на ней метод объясняли Хаузер и Клаузинг в статье «The House of Quality» (Harvard Business Review, 1988). Возьмём её и мы.

На сборке двери навешивают так, чтобы зазор между дверью и проёмом кузова был 4 ± 0,5 мм. Подгонка занимает время. Технолог предлагает ±1 мм: брака меньше, такт быстрее. Звучит разумно. Кто может возразить и почему?

Без прослеживаемости разговор сводится к «так было в чертеже» против «а давайте попробуем». С ней — к цифрам. Идём по цепочке домов качества в обратную сторону:

Зазор отвечает за то, насколько равномерно по контуру сжимается уплотнитель. Уплотнитель держит три характеристики первого этапа: шум, протечки и усилие закрывания. А за ними — три пожелания клиента. Слишком туго — дверь приходится захлопывать с размаху. Слишком слабо в одном месте — там свистит на трассе и течёт на мойке.

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

Прослеживаемость и вклад — в чём разница

В разработке программ прослеживаемость обычно ведут матрицей трассировки: требование связано с функцией, функция — с тестом. Она отвечает на вопрос «связано или нет». QFD отвечает на вопрос «насколько».

Связи в каждом доме качества взвешены (9, 3, 1), у требований есть важность. Поэтому вклад можно посчитать в процентах — в обе стороны:

• Вперёд: на какие параметры последнего этапа сильнее всего работает требование «тихо на трассе»? Это нужно, когда требование меняется и надо понять, что пересматривать.
• Назад: из чего складывается приоритет допуска на зазор и какая доля приходится на каждое пожелание клиента? Это нужно, когда хочется что-то упростить или удешевить.

Как это считает программа

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

Расчёт идёт от конца к началу. Приоритеты последнего этапа раздаются назад через каждую матрицу пропорционально связям и важности, на каждом этапе нормируются до 100%. На выходе — доля каждого требования первого этапа в итоговых параметрах.

По этим долям работает анализ доминирования. Если одно требование даёт больше 50% итога, риск высокий, больше 30% — средний. Это не ошибка, но сигнал: продукт заточен под одно пожелание. Если его важность оценили неверно — например, опросили не ту аудиторию, — съедет вся цепочка. Значит, исходные данные по этому требованию стоит перепроверить первыми.

Сводный отчёт собирает всё на одной странице: самые влиятельные требования клиента, главные характеристики последнего этапа и самые острые технические конфликты. Граф и отчёт выгружаются в PDF вместе с матрицами, граф — ещё и отдельно в SVG.

Где прослеживаемость окупается

• Изменения в конструкции и процессе. Сменить поставщика, материал, допуск — и заранее увидеть, какие пожелания клиента это заденет.
• Споры «почему так дорого». Дорогой параметр с большим вкладом защищается цифрой. Дорогой параметр с маленьким вкладом — кандидат на упрощение.
• Передача проекта. Новый инженер через год видит не только «что», но и «почему».
• Разговор с заказчиком и аудитором. Обоснование требований — частый вопрос на проверках систем качества. PDF с графом и отчётом прикладывается к документации как есть.
• Программные продукты. Откуда требование «ответ сервера за 200 мс»? Граф покажет, какие ожидания пользователей за ним стоят и какую долю они дают.

Что нужно, чтобы прослеживаемость работала

• Все этапы — в одном документе. Если продукт, детали и процесс лежат в трёх разных файлах, нить рвётся на стыках. Как связать этапы, чтобы веса переходили сами, — в статье«Многоэтапный QFD».
• Требования — из реальных источников. Прослеживаемость к выдуманному требованию ничего не доказывает. Откуда брать требования и как их формулировать, показано в статье«Дом качества: пример построения».
• Честные связи. Девятка везде размывает вклад: граф становится густым, и важные нити теряются среди случайных.
• Актуальность. Цепочка полезна, пока её обновляют вместе с проектом. В редакторе это дёшево: правка на первом этапе сразу пересчитывает все следующие и граф.