Баги на проде — это нормально

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

Если поехала верстка на кнопке или цвет баннера не тот — очень странно видеть суетные телодвижения по экстренной доставке исправлений: быстрый сбор веточек, оперативное получение апрувов и тест, влитие и разворачивание. Целая команда отвлеклась от своих задач (даже если это 15 минут) только ради такой ерунды. Возгласы по типу «это репутация» или «мы теряем клиентов» являются псевдоаргументацией. Будьте уверены, что ни одна метрика не покажет, что показатели пошли вниз именно из-за этого. Такое можно оценить только АБ-тестом. Иначе всё это можно списать на случайное совпадение.

Меня важно правильно понять. Есть действительно важные и критические баги, которые нужно устранить здесь и сейчас. Например, если в том же интернет-магазине оплаты не проходят — ну что ж, печаль, надо исправлять как можно скорее. И чтобы различать важные (здесь и сейчас) дефекты от неважных (могут подождать следующего релиза) — вводится приоритизация. Звучит просто, но на деле — нет.

Если приоритеты выставляются из головы менеджера продукта или тимлида — то плохие новости: высока вероятность необъективности и растраты ресурсов впустую. Самое правильное — сформировать критерии качества системы. И формируют их ЛПР (например, CPO и CTO, в крайнем случае) с привлечением команды. Тогда срочность/приоритет выставляется органически — всем понятно, что, почему и зачем. Сори, что пишу такую базу 🙈.

Но самый кек не в этом. Тренд «прод без багов» в компании эволюционно порождает бесполезные метрики. Ты допустил 5 багов в регрессе? Хорошо, тогда премию получишь на 20% меньше. Вот и бедные запуганные разработчики и тестировщики сильно стараются не допустить никаких дефектов: потеют и вылизывают всё досконально. Тратят время, потому что «спешка» и нет времени на спокойную реализацию (ну, конечно, мы же теряем клиентов!). А могли бы за то же время доставить другую функциональность. Когда команда сильно устаёт от этого, то быстро догадывается сломать эту метрику: можно же просто договориться завести баг не в регрессе, а после. Win-win.

Здесь довольно простая отрицательная ковариация: хочешь быстрее доставку? — увеличится число багов. Хочешь меньше багов? — увеличится время доставки. Крути как хочешь эти ползунки, и твоя риск-стратегия готова. Идеальной суперпозиции (всё и сразу) не существует.

Да, можно все покрыть фича-флагами и тогда вливай на прод хоть каждые 5 минут. Но наличие флагов не гарантирует отсутствие багов, а также неизбежно влечет к цепочке условий и исключений (что тоже стоит времени). Идеального TBD я еще ни у кого не видел.

Проявление фанатизма для достижения идеальности — бред. Идеала не существует, мир состоит из смешанных стратегий.

В общем, не бойтесь ломать прод, это естественно. Но без вредительства. За такое можно и нужно журить. ✌️