Автор: Itamar Gilad | Оригинальная статья https://itamargilad.com/velocity-vs-impact/
Сегодня в индустрии разработки продуктов наблюдается одержимость «производительностью»: команды заставляют быстрее сжигать сторипойнты, стабильно укладываться в спринты и релизные циклы, увеличивать объём поставки фич. Руководители всё чаще говорят про development velocity — скорость разработки. На деле они хотят одного: больше релизов за меньшее время. Это кажется логичным: чем быстрее делаем, тем успешнее станем?
Но я хочу показать, что скорость и объём релизов — вовсе не те метрики, на которые стоит ориентироваться. Более того, зацикленность на них может навредить.
Большая часть того, что мы создаём — впустую
Вряд ли вас удивит, что далеко не каждое наше нововведение оказывается успешным. Но по-настоящему тревожит то, насколько плохо у нас получается создавать реальную ценность.
Исследования A/B-тестов, проведённые разными компаниями независимо друг от друга, показывают: в лучшем случае лишь 1 из 3 идей даёт хоть какой-то измеримый результат. А средний показатель по индустрии — 1 из 7 (то есть примерно 14%).
Всё остальное — либо не даёт никакого эффекта, либо даже ухудшает ситуацию (пользователи реже возвращаются, клиенты меньше покупают и т. д.).
В это трудно поверить — ведь кажется, что мы делаем важные и полезные вещи. Но стоит оглянуться на прошедшие проекты, и становится ясно: ноль или отрицательный результат — это совсем не редкость.
Можно предположить (неофициально, поскольку компании неохотно собирают или делятся такими данными), что распределение «эффекта на один релиз» выглядит примерно так:…
Эксперимент: три команды продуктов
Представим три продуктовые команды — А, B и C. Все три на старте выпускают одинаковое количество изменений — по 40 релизов в год (фичи, редизайны, изменения цен, маркетинговые эксперименты и т.п. — багфиксы и технический долг не считаются).
- Команда A — контрольная группа. Она работает как обычно.
- Команда B — фокусируется на скорости. Её цель — выпускать больше.
- Команда C — делает ставку на влияние. Её цель — улучшить долю успешных изменений.
В нашем эксперименте все три команды начинают с одинаковой «успешности»:
- 25% изменений — положительный эффект (+0.5% к ключевой метрике),
- 55% — не дают результата,
- 20% — вредят (-0.5%).
Год 1
Команда A (контрольная группа)
- Релизы: 40
- Позитивные: 10
- Без эффекта: 22
- Негативные: 8
- Итог: +1% к метрике (10×0.5% – 8×0.5%)
Команда B (скорость)
Вложила ресурсы в «ускорение»: консультанты, тренеры, KPI, "повышение вовлечённости и ответственности". Допустим, получилось: +20% к релизам (48 штук).
- Позитивные: 12
- Без эффекта: 26
- Негативные: 10
- Итог: +1.2% к метрике
Вроде бы больше, но разница с A минимальна. Ресурсы потрачены — ценность почти та же.
Команда C (влияние)
Фокус — не на скорости, а на выборе и проверке идей. Команда:
- проводит исследования,
- ставит измеримые цели,
- генерирует и тестирует альтернативы,
- отбрасывает неподходящее.
Итог: успешность выше. Но за счёт этого — меньше релизов (32). Новое распределение:
- 40% — положительный эффект
- 50% — без эффекта
- 10% — негативный
- Релизы: 32
- Позитивные: 13
- Негативные: 3
- Итог: +4.8% к метрике
То есть в 4 раза лучше, чем команда скорости. И в 4.8 раза лучше, чем контрольная.
Цитата, которая отлично подытоживает:
«Одна из самых распространённых ошибок в разработке — думать, что наша задача — просто делать больше и быстрее. Но если правильно понять правила игры, станет ясно: цель не в том, чтобы строить больше. Цель — строить меньше, но так, чтобы это давало больше результата.»
— Джефф Паттон, User Story Mapping
Год 2
Команда A
Продукт разрастается, становится сложнее. Скорость падает. Релизов — 36. Всё пропорционально снижается.
Итог: +0.9% к метрике. Всё медленно деградирует.
Команда B
Тоже замедляется (45 релизов). Вложения в скорость приносят всё меньше пользы.
Итог: +1.1% — почти на месте.
Команда C
Становится ещё лучше в тестировании и запуске. Новая статистика:
- 55% — положительный эффект
- 40% — без эффекта
- 5% — негативный
- Команда запускает уже 39 изменений. Время до релиза падает, решений меньше, они быстрее, меньше людей задействовано.
- Итог: +9.8% к метрике! В 10 раз выше, чем у команды A.
Выводы: скорость ≠ успех
Увеличение скорости без роста успешности — просто ускоренное производство мусора.
Оптимизация под влияние — даёт реальную ценность.
Компании, ориентированные на результат (например, Google, Netflix, Airbnb), не зацикливаются на velocity. Они строят процессы, в которых правильные решения и правильные эксперименты — главная единица ценности.
Что делать
- Меньше фокусироваться на скорости.
- Больше — на соотношении успешных изменений.
- Измерять эффект после запуска.
- Учиться тестировать идеи быстро, дёшево и регулярно.
- Не бояться «выкидывать» идеи, даже если в них уже вложено усилий.