Згоден, коли якість не закладається як управлінське рішення, технічний борг накопичується швидше, ніж команда встигає його усвідомити. Обмеження тестування happy path, відсутність реальних рев’ю і чітких критеріїв якості дають передбачуваний результат.
Про роль QA також влучно підмічено. Коли QA зводять лише до «тестера», система втрачає механізм раннього вирівнювання очікувань між бізнесом і розробкою. Я спробував системніше розкласти цю тему в окремій статті і показати, де саме приймаються ці рішення і чому наслідки з’являються значно пізніше: dou.ua/forums/topic/57741

Так, у сервісній моделі це часто свідомий вибір: демпінг, авантюрні контракти і тиск на виконавців заради короткого горизонту. У такій логіці першими ріжуть саме ті етапи SDLC, де формується якість, передусім аналіз і узгодження, і це описано ще з 70-х років. Перехід у «блакитний океан» справді єдиний сталий вихід, але він вимагає інвестицій, ризику і зміни бізнес-моделі. І до цього готові далеко не всі.

Дякую, приємно чути. Формат серії з прикладами дійсно виглядає логічним, обов’язково подумаю над цим. Якщо є теми, які особливо цікаві — із задоволенням врахую.

Судячи з коментарів, тема болить
Я спробував розкласти це спокійніше й системніше в окремій статті.
Буду радий критиці, контраргументам і незгоді: dou.ua/forums/topic/57741

Дякую за коментар, я почув вас, поки ви не втратили інтерес до цієї теми, будь ласка ознайомтеся із цією статею dou.ua/forums/topic/57741
Сподіваюсь, вона буде більше відповідати вашим очікуванням

Так, це якраз приклад працюючого механізму, а не декларації про якість. Ключове тут навіть не сама «група якості», а регулярність, підготовленість та фіксація рішень. Коли айтеми не просто знаходяться, а проходять спільне рев’ю, рішення приймаються свідомо, включно з рішенням нічого не робити, і вся відповідальність та обґрунтування зафіксовані, якість перестає бути абстракцією і стає керованим процесом. За моїм досвідом, саме прозорість прийнятих рішень, а не кількість знайдених дефектів, і є тим, що реально тримає систему під контролем.

Якість не заробляє грошей напряму, вона керує вартістю майбутнього: підтримки, змін, масштабування, репутації.
Проблема в тому, що цей горизонт часто довший за контракт, квартал або бонусну схему, тому він випадає з рішень.
Ринок дійсно «покарає», але зазвичай із затримкою.
І коли це стається, платити доводиться вже не галері й не окремим інженерам, а бізнесу в цілому. Тому питання не в тому, чи «люблять» якість. Питання в тому, хто і на якому горизонті приймає рішення. Там, де горизонт короткий якість завжди програє.
Там, де він довший вона стає економічно раціональною. Це не ідеалізм, просто різні моделі відповідальності.

Погоджуюсь: якість має бути вимірюваною. Але вимірюваність не дорівнює керованості.
Time to market є атрибутом якості, доки він не домінує над іншими без явного управління trade-off’ами.
Відповідальність QA за нечіткі вимоги коректна лише там, де QA має ownership і право блокувати реліз.
А героїзм QA — симптом відсутності управлінських рішень, а не проблема професії.
Наша практика: фіксований баланс delivery / стабілізації
У команді частина capacity зарезервована завжди: 70–80% нові фічі і 20–30% техборг, рефакторинг, стабілізація
Цей відсоток не «вибивається» дедлайном і
не зникає перед релізом.
QA тут не «ловить баги в кінці»,
а підтверджує, що ризики або закриті, або свідомо прийняті.

Так, це типовий технічний борг.
Коли пріоритет лише нові фічі, система втрачає підтримуваність, зростає складність змін і швидкість розробки падає, а не зростає.
Без виділеного часу на рефакторинг і фікс дефектів time-to-market погіршується в середньостроковій перспективі.