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

Редактор 

Согласование параметров при выполнении проекта

Лебедев Ю.В.

Согласование – это выбор величины одного параметра с учетом величины другого/других.

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

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

Как определить параметры, требующие согласования?

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

Возьмем в качестве примера нарезанный хлеб в упаковке:

Для того, чтобы гарантированно зафиксировать все несогласованные параметры, можно использовать матрицу согласования:

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

В этом примере показано, что конфликтуют пять пар параметров. Далее нужно просто описать эти конфликты. Просто в столбик:

1. Свежесть конфликтует с полезностью. Пресловутый горячий хлеб прямо из печи свеж под самое не могу, но вреден (мало кто об этом знает, потому что на прилавок он в таком виде не попадает). Несвежий хлеб может уже содержать плесень, даже если ее еще не видно.
2. Свежесть конфликтует с сохранностью. Хлеб в упаковке дольше остается мягким. Но уже не таким свежим.
3. Свежесть конфликтует с простотой применения. Нарезанный хлеб быстрее черствеет. Если же уже вскрытый храним в упаковке, то быстрее плесневеет.
4. Полезность конфликтует с питательностью. Ну, об этом знают все, кто когда-нибудь пытался худеть, ограничивая себя в потреблении белого хлеба. Черный, кстати, в этом отношении не сильно полезнее J.
5. Сохранность конфликтует с простотой применения. Нарезанный хлеб быстрее портится (или сохнет).

Важные нюансы:

1. Матрица сама по себе не определяет параметры, требующие согласования, а только позволяет зафиксировать рассогласованности.
2. Можно, конечно, вспомнить, что ничто не идеально и проставить такие рассогласованности для каждой пары (заполнить все клетки матрицы). Но это имеет смысл только в тех крайне редких случаях, когда нужны бескомпромиссные решения и, соответственно, очень долгосрочный прогноз.
3. Здесь рассматриваем только ключевые параметры. Разумеется, эти параметры могут быть не полностью согласованы с другими, менее важными. Но на то они и менее важны! Если же вдруг оказывается, что согласовать какой-то из КПТ нужно с другим параметром, это будет значить только то, что этот «другой параметр» в данном проекте оказался именно КПТ[1].
4. В матрице зашита возможность проверки (не полной, но все же). Для чего и рассматриваем этап развития и тип предела. Например, конфликт 3 (Свежесть конфликтует с простотой применения). По обоим параметрам мы маркировали систему на 3 этапе с потребительским пределом. То есть, потребителю просто дана возможность выбора – конфликта нет…

С точки зрения прогнозного проекта мы фактически записали тот факт, что по мере развития системы такие-то ее параметры будут позже согласованы с другими.

Но разумеется, такой вывод сам по себе никому не интересен. Гораздо важнее то, что мы фактически сразу ставим задачи на устранение существующих недостатков.

И более того, ставим задачи фактически в формате противоречий (другое дело, совершенно необязательно все задачи будут решены с применением методики ТРИЗ – очень часто после аккуратного формулирования таких недостатков ответ почти очевиден).

Разумеется, выделить все такие рассогласованности может быть достаточно сложно и потребовать серьезной работы. Но в большинстве случаев основные конфликты параметров (противоречия) хорошо видны специалистам в теме уже на этих этапах. Насколько глубоко прорабатывать построение такой матрицы – вопрос требуемой глубины и точности прогноза и других требований к проекту.

[1] Уже в который раз напомнить: мы всегда анализируем не ТС саму по себе, но ТС здесь, сейчас и в рамках решаемой задачи.