Стоимость ошибки: почему раньше — дешевле

Считаем, во что обходится баг на разных стадиях и почему «починим потом» — самая дорогая стратегия.

Стоимость дефекта растёт тем сильнее, чем позже его находят: исправить ошибку в требованиях почти бесплатно, а тот же дефект в продакшене обходится в десятки раз дороже.

Кривая стоимости

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

Конкретные цифры зависят от проекта, но порядок неизменен: чем позже — тем дороже. Причина проста: на поздних этапах дефект уже «оброс» зависимым кодом, документацией, данными пользователей, и его исправление задевает больше частей системы.

Почему позже дороже

• Контекст забыт. Через три месяца автор уже не помнит, почему написал так. Разобраться заново — время.
• Дефект распространился. На багованный модуль уже завязались другие части. Правка одного места ломает другое.
• Ущерб уже нанесён. В продакшене баг успевает испортить данные, оттолкнуть клиентов, сорвать оплату.

Маленькая иллюстрация

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

BASE = 1  # условная стоимость правки в требованиях
stage_multiplier = {
    "требования": 1,
    "код": 5,
    "тестирование": 10,
    "продакшен": 30,
}

for stage, mult in stage_multiplier.items():
    cost = BASE * mult
    print(f"{stage:13} -> стоимость {cost}")

# «Тест» на саму идею: продакшен дороже требований минимум в 30 раз
assert stage_multiplier["продакшен"] >= stage_multiplier["требования"] * 30
print("Подтверждено: позже найден — дороже исправить")

Вывод:

требования    -> стоимость 1
код           -> стоимость 5
тестирование  -> стоимость 10
продакшен     -> стоимость 30
Подтверждено: позже найден — дороже исправить

Практический вывод

Отсюда вся современная культура «сдвига влево» (shift-left): тестировать как можно раньше, проверять требования, писать unit-тесты вместе с кодом, ловить ошибки до того, как они доберутся до пользователя. Это не перестраховка, а экономия.

Итог

• Стоимость дефекта растёт с каждым этапом — порядок роста неизменен.
• Поздний баг дорог из-за забытого контекста, распространения и нанесённого ущерба.
• Ранняя проверка — это экономия, а не лишняя бюрократия.