Measuring the effectiveness of software development tools and practices (Рубрика Productivity)
Я часто рассказываю про тему продуктивности инженеров, а также подходов к этому крупных компаний (смотри статьи от Google, или статьи запрещенной в России Meta), а также про то, как мы внутри Т-Банка подходим к этому. Но сегодня я хотел рассказать про подход Amazon к этому непростому снаряду - авторы предлагают метод измерения экономического эффекта от инструментов и практик разработки. Они предлагают смотреть на единую метрику CTS-SW (cost-to-serve software) - по сути, сколько ресурсов уходит на доставку единицы ПО до клиента. Эта метрика должна связать привычные engineering-метрики в духе DORA/SPACE с понятным бизнес-результатом: сэкономленной инженерной емкостью или деньгами.
Интересно, что у нас внутри Т-Банка тоже есть похожие подходы к расчетам, которые основаны на унификации процессов разработки и выделении уровня задач в командах, что приносят понятный бизнес-результат. Но давайте вернемся к оригинальной статье и посмотрим как работает подход авторов
1️⃣ Они берут "стоимость доставки ПО" как итоговую метрику, а не пытаются детально оценить каждый шаг разработки Авторы говорят, что классический activity-based costing для софта слишком хрупок и поэтому они упрощают задачу до "входные затраты → единица результата", а затем уже ищут драйверы этой стоимости по всему жизненному циклу: coding, CI/CD, planning, incident management, maintenance, search for information и т.д. Единица результата тоже подбирается под архитектуру
- Микросервисы - деплои
- Монолит - зашипленный в мастер код
- Библиотеки - коммиты
2️⃣Дальше они строят панельные данные (микс факторов + время) и используют линейные смешанные модели У них есть телеметрия по тысячам "two-pizza teams" за пять лет, и они моделируют CTS-SW через время разработчиков на деплой. Линейные смешанные модели нужны им потому, что они одновременно ловят общий эффект факторов и различия между командами. Так они нашли основные кандидаты-драйверы CTS-SW:
- Team velocity (сколько отревьювернного кода команда мерджит в неделю на инженера) - самый сильный предиктор
- Здоровье деливери (например, рейт ролбеков)
- Пейджи на on-call инженера
3️⃣ Переходят от корреляции к причинности через causal inference После нахождения эффектов авторы ищут возможность для эксперимента. Таким естественным экспериментом для них стало внедрение genAI-инструментов, в частности Amazon Q Developer. Для оценки они строят панельную регрессию с dynamic two-way fixed effects: учитывают постоянные различия между командами, общие временные эффекты, лаг прошлой скорости и time-varying covariates вроде доли команды, использующей Q Developer, rollback rate и manual interventions. Цель - не просто увидеть корреляцию, а изолировать именно причинный вклад инструмента в CR velocity и deployment velocity.
4️⃣ Добавляют "страховку" от переоценки эффекта AI Авторы отдельно признают, что если просто складывать эффекты разных экспериментов, можно завысить реальное влияние. Поэтому они разрабатывают baseline model, чтобы нормализовать оценки влияния AI-инструментов.
В общем, это явно интересный подход, который позволяет
- Решать, какие dev tools и AI tools масштабировать, исходя из измеримого эффекта
- Приоритизировать CI/CD автоматизации и практики надежности, потому что они свзяаны с лучшим CTS-SW.
- Создавать через онбординг условия для высокой team velocity, но использовать это именно как командную, а не индивидуальную метрику.
- Осторожно интерпретировать "полезные" сигналы
В будущем авторы хотят расширить модель, чтобы сравнивать архитектурные решения и давать рекомендации.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Software #Agents #Economics