Ну, как бы. Есть человек, которого Арсений назвал бы ЛПР.
Его работа заключается в том, что бы принимать решенее о том, когда профит от релиза перевешивает риски.
Если он считает, что фича, которая катится в релизе оправдывает риски, которые эти ваши критикал баги несут - то да, надо катить.

Потому что если вы выкатите баг на прод - ответственность за этот баг нести будет он.
И если вы не выкатите релиз по плану - за это тоже будет нести ответственность он.

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

А если репорт был прочитан и понят? И все равно баг выкачен в прод?

Вся эта история с "мы последний рубеж между говнокодом и пользователем" это какой-то комплекс бога.

Если человек, несущий ответственность за продукт, считает что надо катить в релиз кусок говна - значит надо катить в релиз кусок говна.
Потому что с точки зрения продукта это вполне может быть выигрышной стратегией.

Ок, сейчас мы упёрлись в то, что по-разному понимаем что такое "дать фидбек". И есть у меня предположение, что в целом мы реализуем в работе идентичные подходы, но сейчас описываем их кардинально непривычно для нас обоих.

Ну и славненько. Значит профит от релиза перевешивает риски от этого бага.

Как бы, мой поинт простой:
Есть очень большая разница между "не пускать баги в прод" и "давать понятный фидбэк коллегам".
В первом случае ты бьешь кулаком в грудь и говоришь, что такое нельзя катить.
Во втором случае ты говоришь "посоны, если мы это выкатим - будут вот такие последствия, подумайте ещё раз".

И это очень разные подходы.

И кстати этот подход очень распространен с точки зрения бизнеса - прям классика, за минимальное кол-во вложений покрыть максимальную аудиторию. Остальные по боку. Это редко говорят прямо, но это есть на рынке сплошником.... И баги живут годами на проде и никто их не будет править, если финасовая отдача от их исправления меньша затрат на их исправление.

А вот тут начинаются нюансы. Понятное дело, что бесконечно чинить баги нельзя. Всё сильно зависит от ситуации: от того насколько вы задержали релиз, от наличия других багов, от степени важности этого бага и т.д.

И да, если я считаю, что мой баг положит прод и мир наполнится болью, а ответственные люди этого не видят и не понимают, то я буду тратить силы на то, чтобы подобное объяснить.

Банальный пример: выкат новой плохоработающей фичи, для которой потом выкатят позже патчи с фиксами принесёт больше профита, чем её откладывание и приведение продукта к состоянию близкого к идеальному. (как какая-то из последних игр)

И это вполне логично, и ничего плохого в этом нет, кроме того, что ранит душу нежных максималистов.

Ну, тебе сказали что всё ясно, всё понятно, но мы приняли решение выкатывать несмотря ни на что. Каким образом ты будешь их останавливать?

А вот теперь банальная история из жизни.
У тебя есть в релизе баг, который будет ронять продакшен каждые два часа.
Ну, память переполняется и всё схлопывается.
Плохо, ужасно, наполняет жизнь болью?

У нас там перед налоговой отчетностью было.... Работать было сложнее, но уже сейчас и сдали в срок или сделано без ошибок, но опоздали с отчетностью ))

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

А продакшен поставим на автоперезапуск, и окей, раз в 2 часа у чуваков будут слетать сессии.

Повторю ещё раз. Я не пропагандирую идею "нужно починить всё". Если мы придём в какой-то момент к согласию и примем решение пофиксить баг позже, то продукт пойдёт в релиз с этим багом.

Based on true story, если что.

я других знаю кучу примеров. Когда все знают про баг, бизнес смотрит, что он есть только у 1% процента клиентов, причем эти клиенты приносят очень мало прибыли и есть более срочные задачи. Тогда просто забивают на этот процент клиентов ))

или никогда не пофиксить, так как не целесообразно тратить ресурсы отдела на это, так как на прибыль не повлияет...

Мне нравится идея "придём к согласию".
Но тогда и ответственность за продуктовые решения - тоже вместе надо нести.
Типа, упала конверсия на проде - сорян, оставили тестировщика без бонуса за квартал.