Состав изделия, Здравый смысл против обстоятельств Опции

[Pavia]

Не первый раз у нас возникает вопрос. Интересует как вы поступаете?

Есть ТЗ к примеру на телевизор.
Эскизного проектирования не было. Тех. проект сверстали за неделю.
В ТЗ прописан раздел "состав изделия"
1. корпус;
2. плата;
3. матрица.

В ходе конструирования выясняется, что на телевизоре нет кнопок и нужен пуль-ДУ.
ТЗ править никто не хочет, так как его согласовывали весь год. Последнюю подпись поставили вчера, а сегодня уже сдавать изделие. Корпус и матрица покупные в его состав пульт-ДУ не входит и включить нельзя.
А в плату включить пуль-ДУ по здравому смыслу не стоит.

Я считаю, что достаточно поправить схему деления, так как в ТЗ включаются по ГОСТу "основные составные части". А состав определяет КД. Но мои коллеги считают, что раз ТЗ является не неотъемлемой частью договора. Приемка, заказчик и нормоконтроль будут проверять состав по ТЗ. Поэтому состав должно соответствовать один в один. А вот в подуровнях схемы деления можно скрыть дополнительные части. Соответственно предлагают включить пульт-ДУ в состав платы или в состав функции платы.

[@Ark]

Не первый раз у нас возникает вопрос...
...
В ТЗ прописан раздел "состав изделия"...
...

В идеале (к которому нужно стремиться) техническое задание (ТЗ) должно содержать в себе только технические требования к изделию (ТТ) и конечные технические характеристики изделия (ТХ). Нужно всячески избегать включения состав ТЗ конкретных технических решений - иначе, они становятся обязательными, а вы становитесь их невольными "заложниками". Со всеми вытекающими проблемами.
Технические решения - это конечный результат процесса разработки, а не исходные данные, и в ТЗ им не место. Но это в теории, а в жизни... Заказчик в первый день хочет знать как все будет, норовит дать вам свои "ценные указания", поучаствовать в процессе вместе с вами. И требует внести все это в ТЗ, не понимая, что конечное решение может быть совсем не таким, как его первоначально представляет заказчик, и даже разработчик.
Компромиссное решение - все-таки вписывать все это в ТЗ, но с обязательными оговорками, что, мол, это только проект решения, концепт, первоначальное видение решения, его "отправная точка" - и не более. И разработчик имеет право вносить в него изменения по своему усмотрению. Единственное, что не может делать разработчик - это изменять ТТ и ТХ изделия без согласования с заказчиком. Если сумеете придерживаться этого принципа - проблем будет гораздо меньше...