Здравствуйте, 4058, Вы писали:

I>>В сумме такое называют "низкое качество". Удивительно, да?

4> т.е. низкое качество, это когда продукт делает, то что нужно, доставляет минимум проблем потребителю и целом хорошо эксплуатируется?

Низкое качество, это когда требования к качеству мутные, непроверяемые — ровно как в твоей формулировке.
Хорошесть никак не валидируется, это чистая субъективщина.
Один разраб считает, что надо вот так, другой — что надо вот этад.

I>>Что бы качество стало высоким, нужно гораздо больше требований, чем эти три строчики.

4>Пожалуйста меньше пафоса. Много раз видел изящные архитектуры, божественный код, вылизанные до блеска тесты, хорошая документация, и прочие артефакты сопровождающие цикл разработки. При этом в эксплуатации оказывалась дрянь.

Все что ты перечислил к качеству никак не относится, нисколечко.

Качество это степень соответствия требованиям. Нет требований — нет качества.

Что бы остудить особо хитрых, есть качество требований, т.е. степень соответствия требований некоему стандарту индустрии.

Поскольку всё подряд проверить просто невозможно, накладываются доп. требования, косвенные
1. на процесс разработки — степень соответствия требованиям к процессу, например, если нет возможности вкомитать прямо в прод, это повышает качество
2. на процесс тестирования — степень соответствия требованиям индустрии
3. на команду — принятие решений и тд. Вместо "я так хачю, у тебя говно, иди переписывай" спользуется понятная схема взаимодействия, понятно кто за что отвечает
4. на специалистов — требования к квалификации
5. итд

Мы можем говорить, что качество высокое, когда степень соответствия на всех уровнях проверяемая и управляемая, и есть определенные метрики.

Например, количество багов само по себе нисколько не говорит о качестве. Количество пофикшеных тоже. Парадокс, да? Нам нужны определенные испытания и проверяемое условие "успешно"
Соответсвенно, если есть испытания, есть динамика выявления багов, динамика исправления, нету шарахания вида "тут тестим, тут не тестим", все это может говорить о качестве.

Здравствуйте, 4058, Вы писали:

I>>В сумме такое называют "низкое качество". Удивительно, да?

4> т.е. низкое качество, это когда продукт делает, то что нужно, доставляет минимум проблем потребителю и целом хорошо эксплуатируется?

Низкое качество, это когда требования к качеству мутные, непроверяемые — ровно как в твоей формулировке.
Хорошесть никак не валидируется, это чистая субъективщина.
Один разраб считает, что надо вот так, другой — что надо вот эдак. Отсюда и конфликт — у обоих могут быть противоположные мнения каждое из которых отстаивается до хрипа ибо каждый уверен, что "я добросовестный, а другие спустя рукава работают"

I>>Что бы качество стало высоким, нужно гораздо больше требований, чем эти три строчики.

4>Пожалуйста меньше пафоса. Много раз видел изящные архитектуры, божественный код, вылизанные до блеска тесты, хорошая документация, и прочие артефакты сопровождающие цикл разработки. При этом в эксплуатации оказывалась дрянь.

Все что ты перечислил к качеству никак не относится, нисколечко.

Качество это степень соответствия требованиям. Нет требований — нет качества.

Что бы остудить особо хитрых, есть качество требований, т.е. степень соответствия требований некоему стандарту индустрии.

Поскольку всё подряд проверить просто невозможно, накладываются доп. требования, косвенные
1. на процесс разработки — степень соответствия требованиям к процессу, например, если нет возможности вкомитать прямо в прод, это повышает качество
2. на процесс тестирования — степень соответствия требованиям индустрии
3. на команду — принятие решений и тд. Вместо "я так хачю, у тебя говно, иди переписывай" спользуется понятная схема взаимодействия, понятно кто за что отвечает
4. на специалистов — требования к квалификации
5. итд

Мы можем говорить, что качество высокое, когда степень соответствия на всех уровнях проверяемая и управляемая, и есть определенные метрики.

Например, количество багов само по себе нисколько не говорит о качестве. Количество пофикшеных тоже. Парадокс, да? Нам нужны определенные испытания и проверяемое условие "успешно"
Соответсвенно, если есть испытания, есть динамика выявления багов, динамика исправления, нету шарахания вида "тут тестим, тут не тестим", все это может говорить о качестве.