Ответ
Решение о выпуске релиза с известным багом принимается на основе оценки рисков и должно быть задокументировано. Критерии для такого решения:
-
Некритичность бага: Баг не является блокирующим (P0/P1). Он не:
- Приводит к потере данных.
- Нарушает основные бизнес-сценарии (core flow).
- Создает угрозу безопасности.
-
Ограниченное воздействие:
- Баг проявляется в редких или edge-кейсах.
- Есть простой workaround для пользователя.
- Баг не ухудшает пользовательский опыт для большинства.
-
Прозрачность и план:
- Баг заведен в трекере (например, Jira) с четким описанием.
- Есть утвержденный план и сроки его исправления.
- Информация о баге включена в релизные заметки.
-
Одобрение заинтересованных сторон: Решение согласовано с продукт-менеджером, командой разработки и тестирования.
Пример: В релизе калькулятора есть баг: функция округления иногда дает погрешность в 0.01 для очень больших чисел. Это edge-кейс, workaround — использовать меньше знаков после запятой. Баг заведен, запланирован на следующий спринт, информация есть в релизных нотах.
Ответ 18+ 🔞
А, слушай, вот это реально больная тема, про которую все молчат, а потом получается пиздец! Решение выпустить релиз с багом — это как идти на свидание, зная, что у тебя из носа торсёт сопля. Но иногда — и только иногда! — это можно сделать, не прослыв конченым мудаком. Вот как это работает, без этих ваших заумных слов, а по-человечьи.
Во-первых, этот баг должен быть не пиздец какой. То есть:
- Он не блокирует всё нахуй. Пользователь не теряет свои фотки котиков, деньги не улетают вникуда, и система безопасности не превращается в решето.
- Основной сценарий, за который платят бабки, должен работать. Если это калькулятор — он должен складывать. А если он при этом иногда на экране рисует хуй вместо равно — это, конечно, прикольно, но это уже P0, и иди, чини, долбоёб.
Во-вторых, баг должен быть редким, как честный политик. Проявляется у одного юзера из миллиона, который использует левой ногой в полнолуние. Или для него есть простой обходняк: «Не нажимайте, блядь, эту красную кнопку, пока мы не починили». Если баг плюёт всем в тарелку — забудь, не выкатываем.
Теперь, самое главное — не делать из этого секрета. Это не «ой, пронесёт». Это:
- Баг задокументирован в тикете. Не на салфетке, а в Jira/Ютреке, с описанием, как его воспроизвести, чтобы не получилось «ой, а мы забыли, че там было».
- На него есть план. «Чиним в следующем спринте, Вася». Без плана — это не решение, а надежда, а надежда, как известно, ебать — не стратегия.
- Он указан в релизных нотах. Прямым текстом: «Версия 2.0. Знайте: если вы сделаете Х, то получите Y. Мы уже в теме, чиним». Честность спасает от гнева пользователей и разборок с начальством.
И финальный аккорд — все главные в курсе и кивают. Продакт, который отвечает за фишки, тимлид, который знает, сколько это починить, и тестировщик, который матерился, находя этот баг — все должны сказать: «Да, хуй с ним, выпускаем так». Если хоть один молча курит в сторонке — это повод задуматься, не просрать ли вы сейчас полимеры.
Пример, чтобы было понятно, как это выглядит в жизни: Выпускаем обнову для калькулятора. В нём есть баг: когда пытаешься округлить число размером с бюджет России, иногда вылазит погрешность в копейку. Ну, ёпта, кому это надо? Workaround есть — не вводи, сука, столько цифр. Баг висит в Jira, назначен Васе, он его починит через неделю. В релизных нотах строчка об этом есть. Все в офисе в курсе. Вот это — контролируемый риск. А не «выпустили и молимся».