Cost of delay: сколько на самом деле стоит каждая неделя задержки фичи
Фича опаздывает на две недели. Продакт-менеджер пожимает плечами: «Всё равно тот же квартал». Tech lead кивает. CFO не узнаёт. Две недели превращаются в шесть. К этому моменту enterprise-клиент, которому фича была нужна под цикл закупок, подписывает с конкурентом. Реальная цена этой задержки для бизнеса — около $192 000, и ни один из этих долларов не появится в инженерных отчётах.
Cost of Delay (CoD) — самая обсуждаемая и самая неподсчитываемая концепция в современной разработке продукта. Дон Райнертсен заложил математику в The Principles of Product Development Flow (2009, глава 2), а SAFe оформил её в WSJF (Weighted Shortest Job First). Исследование McKinsey Developer Velocity 2023 показало, что лидеры B2B SaaS выпускают фичи в 4–5 раз быстрее аутсайдеров и непропорционально больше pipeline ARR на инженера. Но спросите у 10 PM сколько им стоила последняя задержанная фича — 9 ответят «не знаю». Математика достижима. Просто никто её не считает.
{/* truncate */}
Почему Cost of Delay редко считают
Три причины, в порядке убывания сложности:
1. Данные живут в трёх разных командах. Lost ARR — у sales. Cost разработки — у инженерного финотдела. Opportunity cost — в продуктовой роадмапе. Никто один не владеет джойном.
2. Инженеры не считают cost per feature. Без честной цифры «эта фича уже стоила нам $42K» dev-cost-компонент CoD — это пальцем в небо. Метод SQL-уровня мы разбирали в Cost per Feature: SQL-формула, которая реально сходится. Пока эта задача не решена, CoD структурно размытый.
3. Привязать выручку к конкретной фиче — сложно. Sales редко согласится, что сделка закрылась из-за фичи X. Они предпочитают «отношения» или «спонсорство руководителя». Это самый большой блокер.
Команды, которые это преодолевают, обычно имеют сильный product marketing плюс инженерно-финансовую дисциплину. PanDev Metrics закрывает второй пункт (per-feature cost из IDE-телеметрии), но не может решить за вас первый и третий.
Формула Cost of Delay
Каноническая разбивка Райнертсена, переформулированная под B2B SaaS:
CoD за неделю = (потерянная выручка/нед) + (продолжающаяся стоимость разработки/нед) + (opportunity cost/нед)
Три компонента, у каждого свой способ измерения:
Потерянная выручка/нед. Какой ARR или pipeline разблокирует эта фича и в каком окне? Если фича разблокирует $480K ARR, но клиент подпишет когда угодно — компонент потерянной выручки маленький (вы не теряете ARR, а откладываете на месяц). Если есть жёсткое окно (Q2-цикл закупок enterprise, дедлайн регулятора, RFP конкурента) — каждая неделя задержки рискует всей сделкой.
Продолжающаяся стоимость разработки/нед. Сколько команда сжигает пока фича в работе? Это ваш fully loaded еженедельный cost. Не голый оклад разработчика, а ставка с overhead-коэффициентом, покрывающим менеджмент, DevOps и общие сервисы. Два инженера по $46/час loaded × 40 часов × 2 недели = $7 360 чистого burn, даже если фича ничего не выкатывает.
Opportunity cost/нед. Сколько стоит следующая фича в бэклоге, и сколько ей стоит каждая неделя задержки? Здесь большинство команд останавливается, потому что математика рекурсивная. Шорткат: оцените CoD следующей фичи и поделите на половину (мы используем 0.5 — половинный кредит за фичу в очереди).
Полная картина — стек из трёх слоёв. Иллюстрация ниже показывает, как три компонента складываются на четырёх типичных архетипах фич.
Стек CoD за неделю. Компонент dev-cost практически постоянный; на сумму больше всего влияют lost revenue и opportunity cost.
Три рабочих сценария, где CoD меняет решение
Сценарий 1 — B2B SaaS-фича блокирует enterprise-сделку
Сделка реальная, ARR закоммичен в письме под условие выпуска фичи, окно закупок Q2 (закрывается через 6 недель).
| Компонент | За неделю | Откуда взяли |
|---|---|---|
| Lost ARR (сделка под угрозой) | $12 000 | $480K ARR × ~2.5% вероятности потери в неделю |
| Продолжающийся dev cost | $8 000 | 2 инженера × $46/час loaded × 40 часов + ~30% PM/QA |
| Opportunity cost | $12 000 | CoD следующей фичи ≈ $24K/нед × 0.5 |
| Итого CoD/неделя | $32 000 |
Проскальзывание на 4 недели стоит бизнесу около $128 000. Слип на 6 недель за окно закупок рискует всем $480K ARR плюс ещё $48K opportunity cost — разлёт больше полумиллиона долларов. В этом сценарии у каждого standup, потерянного на context switching, есть реальный, считаемый ценник.
Сценарий 2 — Внутренний tooling
Новый внутренний дашборд для customer-success команды. Прямой выручки нет. Питч: «экономит CS-команде 4 часа в неделю».
| Компонент | За неделю | Откуда взяли |
|---|---|---|
| Потерянная выручка | $0 | Нет revenue-attribution |
| Продолжающийся dev cost | $14 000 | 3 инженера × $46/час × 40 часов + DevOps + PM |
| Opportunity cost | $4 000 | У следующей фичи слабый CoD |
| Итого CoD/неделя | $18 000 |
Математика говорит: эта фича должна экономить CS-команде больше $18 000/неделю в труде — то есть свыше 200 CS-часов/неделю при $80/час loaded — иначе её надо депрайоритить и сначала выпустить следующую revenue-привязанную. Питч про 4 часа в неделю даёт максимум $2K/неделю сэкономленного времени. Фича перевёрнута на порядок. Может быть, её всё ещё стоит делать ради морали или стратегических причин, но финансово кейс отрицательный.
Это именно тот сценарий, где CoD меняет решение. Без математики «небольшой внутренний инструмент» звучит дёшево. С математикой — это самая дорогая позиция в бэклоге.
Сценарий 3 — Compliance-фича с регуляторным дедлайном
Audit trail для SOC 2. Аудиторы приедут 15 июня. Без фичи компания провалит аудит и потеряет три enterprise-сделки, привязанных к SOC 2.
| Компонент | За неделю | Откуда взяли |
|---|---|---|
| Lost revenue (до дедлайна) | $0 | Пока есть время выпустить — выручки не теряем |
| Продолжающийся dev cost | $6 000 | 1 инженер + part-time security review |
| Opportunity cost | $3 000 | Очередь с низким приоритетом |
| Итого CoD/нед (до дедлайна) | $9 000 | |
| Итого CoD (после дедлайна) | бесконечность | Провал аудита, потеря сделок, репутация |
CoD здесь нелинейный. Выглядит обманчиво дёшево до дедлайна — потом становится катастрофой. Правильное прочтение: эта фича P0 с первого дня, хотя per-week CoD у неё самый низкий из трёх сценариев. Фреймворк CoD корректно обрабатывает работу под дедлайн через флаг разрыва, а не через ранжирование по равномерному per-week числу.
Как CoD меняет приоритизацию по WSJF
Самое полезное применение CoD — ранжирование бэклога. Формула WSJF из SAFe:
WSJF = Cost of Delay / Job Size
Чем выше WSJF — тем раньше выпускать. Контраргумент: ранжирование по value/effort и по CoD/effort часто расходятся, и CoD прав.
Рабочий пример: 5 фич в бэклоге Q2, отранжированных двумя способами.
| Фича | Effort (нед) | Value ($K) | CoD/нед ($K) | Naive value/effort | WSJF (CoD/effort) |
|---|---|---|---|---|---|
| A — Enterprise integration | 6 | 200 | 32 | 33.3 | 5.33 |
| B — Эксперимент с pricing-страницей | 1 | 40 | 20 | 40.0 | 20.0 |
| C — Внутренний CS-дашборд | 4 | 60 | 18 | 15.0 | 4.50 |
| D — SOC 2 audit trail | 3 | "infinite" | 9 (потом ∞) | n/a | ∞ к дедлайну |
| E — Mobile push-уведомления | 5 | 80 | 12 | 16.0 | 2.40 |
Naive value/effort ставит B (pricing-эксперимент) первым, потом A. WSJF ставит D (compliance) первым из-за обрыва на дедлайне, потом B (дёшево, быстро, нормальный CoD), потом A. C (внутренний tooling) уезжает вниз — ровно та инверсия, под которую CoD и придумали. Большинство команд всё равно делают C, потому что CS-команда громче всех ныла на прошлом standup. Математика говорит: сначала E или A.
В бенчмаркинге продакт-менеджмента Bain & Company 2024 года команды B2B SaaS, использующие формальный CoD или WSJF, выпускают на 28% больше revenue-привязанных фич за квартал, чем команды с «stack-rank по мнению руководителя». Механизм — именно такие инверсии: регулярная депрайоритизация фич со скрыто слабым бизнес-кейсом.
Отслеживание траектории CoD в реальном времени
CoD полезнее всего как текущая метрика, а не одноразовая оценка на грумминге. Два вопроса важны каждый день:
- Сжигаем ли мы dev-cost-компонент быстрее плана? Если двухнедельная фича в третьей неделе — компонент продолжающейся разработки удвоился, а lost-revenue-компонент тикает.
- Растёт ли opportunity cost из-за того, что следующая фича становится критичной по времени? Это тихий убийца. Та фича, которую вы выпускаете, нормальная; та, которую не выпускаете, теряет деньги.
PanDev Metrics показывает первый вопрос через Task Costs Dynamic Widget: он рисует траекторию стоимости фичи в работе по дням на основе IDE-времени. Эндпоинт GET /departments/{id}/finance/employees/{userId}/task-costs возвращает историю изменения стоимости задачи, чтобы финансовая команда могла соединить её с sales pipeline и считать CoD вживую, не пересобирая джойн в Excel. Фильтры периода (last30Days, last60Days, last90Days, last180Days, allTime) позволяют смотреть фичи, которые идут месяцами и где CoD копится. Особенно полезно в связке с учётом по задачам в issue tracker, который мы разбирали отдельно.
Виджет траектории также подсвечивает разрыв burn vs progress — когда накопительная стоимость на 80% от оценки, а готовность на 50%. Этот разрыв — ведущий индикатор слипа, а не статус на ежедневном standup.
Чего наши данные не скажут
Cost of Delay требует достоверной revenue-attribution. Если ваш финотдел не может сказать «эта фича разблокирует $X pipeline ARR» — вы будете гадать в самой большой переменной формулы. PanDev Metrics даёт dev-cost-компонент с точностью до нескольких процентов: время инженера × loaded rate измеримо. На lost-revenue-стороне мы не даём ничего. Это число должно прийти из работающего sales-finance pipeline, желательно с тегом каждой возможности на конкретную фичу-зависимость.
Прагматичный путь внедрения: начните с внутренних tooling-фич, где dev cost и сэкономленное время оба измеримы, даже если revenue-attribution = 0. Математика CoD для них честная и самодостаточная. Когда команда привыкнет к формуле — переходите к revenue-привязанным фичам, договариваясь с sales о тегировании зависимостей сделок. Не пытайтесь делать оба сразу — один разговор про revenue-attribution занимает квартал.
Типичные ошибки при внедрении CoD
- Считать CoD одноразовой оценкой на планировании. Реальный CoD — текущее число. Пересчитывайте еженедельно для in-flight фич.
- Раздувать lost-revenue-компонент. Sales скажут, что под угрозой каждая сделка. Используйте per-week вероятность, а не бинарное «потеряем».
- Игнорировать opportunity cost. Этот компонент чаще всего пропускают. Из-за него внутренний tooling выглядит дешевле, чем есть.
- Применять WSJF без поправки на compliance/дедлайны. Формула работает для steady-state фич. Под дедлайн нужна отдельная P0-полоса.
- Отдавать формулу инженерам. CoD — это математика finance + sales + product + engineering. Если ей владеет одна команда — три остальных компонента будут неверны.
Как стартовать за 30 дней
Неделя 1: возьмите следующие 5 фич в бэклоге. Для каждой оцените effort в неделях и черновой dev cost через loaded hourly rate.
Неделя 2: пройдитесь по каждой с sales/CS. Для revenue-привязанных получите per-week вероятность потери сделки при задержке. Для внутренних — оцените еженедельную экономию × loaded rate сэкономленной команды.
Неделя 3: посчитайте CoD/неделя и WSJF для каждой фичи. Отранжируйте. Сравните с текущим порядком. Зафиксируйте инверсии.
Неделя 4: переставьте бэклог. Выпустите фичу с самым высоким WSJF первой. Меряйте фактическое время vs план. Пересчитывайте CoD еженедельно.
Цель не в том, чтобы каждое планирование превращалось в Excel. Цель — наработать рефлекс ловить случаи, когда очевидный приоритет — это дорогой приоритет.
Связанное чтение
- Cost per Feature: SQL-формула, которая реально сходится — per-feature cost, на котором стоит CoD
- Cost per Task: интеграция с issue tracker, которая реально сходится — отслеживание стоимости по задачам
- Lead Time for Changes: разбивка по 4 стадиям — измерить ту самую задержку, за которую платите
- Loaded Hourly Rate: почему ваш инженер стоит на 50% дороже своего оклада — входной dev-cost для CoD
- Engineering ROI: R&D как инвестиция, не как расход — фреймворк, в который CoD встаёт
Команды, которые относятся к CoD всерьёз, — не те, у кого самые красивые таблицы. Это те, кто, когда фича уезжает на неделю, могут вслух назвать долларовое число — и решить, что с ним делать.