Что не так с качеством?

Я не очень понимаю, в какой момент произошел слом в массовом сознании, но я его наблюдаю регулярно и систематически.
Но то что слом произошел, причем совсем недавно, и не только в России, это факт. Как вам вот такие два определения качества:
1. ИСО 8402—86: Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя.
2. ГОСТ Р ИСО 9000-2015: Качество — степень соответствия совокупности присущих характеристик объекта требованиям.
Видите разницу, под катом мои мысли на эту тему.

Ключевая разница этих определений в том, что в 86 году под качеством понимали удовлетворение потребностей потребителя, в 2015 соответствие требованиям.
И вот уже в голове голосом Райкина звучит:
-У вас к пуговицам претензии есть?
- Нет, к пуговицам претензий нет, пришиты намертво.
Аналитик отвечает только за то, чтобы в TFS (или какая у вас там система управления требованиями) появились пользовательские истории для Scrum или требования для остальных методологий. Ой, простите, Скрам это не методология, это всего лишь фреймворк, который, кстати, тоже не про удовлетворение потребностей потребителя, а про ритуальные действия, которые должны выполняться строго в соответствии с требованиями. Но не суть, аналитики написали некий текст, разработчик в соответствии с этим текстом написал функционал, инженер по тестированию проверил, все работает так, как написано в требовании. Пришиты намертво, не оторвешь. Вот только пользоваться этим нельзя. Например, по тому, что никто не подумал о реальной ситуации где это будет работать. Об обрывах связи, о больших наборах данных, о том, что пользователя выбесит вводить одно и то же значение 100 раз подряд. А это ведь я рассказываю про идеальный сценарий, с выделенной аналитикой, разработкой и тестированием.
Мы все забываем про потребителя. Причем даже не обязательно вешнего. Рассмотрим самый ужасающий пример такой забывчивости: программиста. Кто является потребителем продукта за качество которого отвечает программист? Остановитесь, подумайте. Кто? Пользователь? Отлично, если программист когда пишет код думает о пользователе, о том как будут пользоваться системой, в каком окружении она будет работать, что можно сделать, чтобы если уж не облегчить жизнь пользователю, то хотя бы не усложнить. Но в большинстве случаев нет даже этого. Ну вот в требовании написано реализовать А. Ну и что, что то что написано не удобно, ломает логику системы, да и использоваться не будет пока не сделают Б, которого даже в планах пока нет. Надо сделать А, вот и сделаю как понял, а там хоть трав.. Ну в смысле а там коммит, ревью, пуш, закрыть задачу и пойти налить кофе.
А ведь кроме несчастного пользователя потребителями труда программиста являются: инженеры по тестированию, специалисты по внедрению, специалисты технической поддержки и ПРОГРАММИСТЫ!!! И ладно, тестировщиков не жаль, админы пусть мудохаются с развертыванием как хотят, тех. поддержка? А это вообще кто такие? Но блин, как можно не думать про себя любимого? Как можно писать методы на сотни строк кода? Ты что, завтра увольняешь и больше не будешь пытаться разобраться в этом спагетти? Как можно в сложной лямбде, находящейся внутри другой лямбды, которая находится по соседству с третей лямбдой использовать имя переменной параметра i (при этом тип сущностей в итерируемой коллекции пусть будет Персона)? Ну а писать catch внутри которого ничего нет, это вообще как? Это что, желание подольше искать неуловимую ошибку?
В Кайдзен есть очень правильный постулат: "Следующий процесс – это потребитель. Вся работа представляет собой ряд процессов, и в каждом процессе имеется свой потребитель и свой поставщик. Большинство работающих в организациях людей имеют дело с внутренним потребителем. Никогда не передавайте бракованные запасные части или неверную информацию людям, участвующим в следующем процессе.".  У каждого кто занимается разработкой программного обеспечения должна постоянно в голове быть мысль: не передавать брак или неверную информацию дальше. Ведь следующий по цепочке это и ты в том числе. Сделал плохо сегодня, придется переделывать завтра. Не предусмотрел сегодня, придется переделывать завтра. Как и с любым принципом, не надо перегибать палку. Не надо доводить мысль до абсолюта, вот пока не доведу до хрустального совершенства, на следующий этап не пущу. Но надо делать максимально хорошо, уверяю вас, плохо оно само получится.
P.s. Сорри за такую сумбурную портянку текста, наболело что-то...