What Happens When Technical Debt Vanishes? (Рубрика #Management)

Представим, что появилась волшебная палочка, которая навсегда убирает целый класс технического долга. Миграции выполняются сами, а устаревшие feature flags исчезают, как только становятся не нужны. На это больше не требуется время инженеров. Что произойдёт с продуктивностью команды? А с метриками, которыми мы её измеряем?

Так начинается «What Happens When Technical Debt Vanishes?» Сьеры Джаспан и Коллина Грина из Google. Прочитал эту работу из серии Developer Productivity for Humans, другие исследования которой уже собирал в двух постах 1 и 2. Здесь авторы сразу предлагают мысленный эксперимент: способ устранения долга может быть любым, хоть AI, хоть статический анализ. Принимаем, что проблема решена, и разбираем последствия. Графики в статье иллюстрируют гипотезы, а не результаты замеров.

Постановка напомнила мне «No Silver Bullet» Брукса. Там есть похожий ход: допустим, мы обнулили затраты на случайную сложность разработки, привнесённую инструментами и способом реализации. Если она занимала меньше 90% усилий, даже полное её устранение не даст десятикратного ускорения. Понимание задачи и проектирование сложной системы всё ещё требуют работы. У Джаспан и Грина другой вопрос: допустим, улучшение получилось — смогут ли наши показатели его заметить?

Дальше аргумент развивается в несколько шагов

1️⃣ Освободившееся время меняет набор задач
Авторы предполагают, что компания направит его на новые функции или улучшение существующих продуктов. Там возникнут другие виды долга. Со временем организация может вернуться к привычному уровню допустимого риска, уже решая больше задач. Поэтому общая жалоба «нам мешает техдолг» может вернуться, хотя конкретную проблему действительно устранили.

2️⃣ Меняются и ожидания людей
После очистки кода удовлетворённость его качеством может вырасти, а затем снизиться: инженеры привыкнут и начнут оценивать систему относительно нового стандарта. Здесь причина возврата показателя — уже в точке отсчёта. При этом вопросы про конкретный устранённый вид долга должны сохранять улучшение.

3️⃣ Часть показателей может вообще не изменится
Число PR или строк кода не обязано вырасти, если инженеры переключились с устранения долга на другую работу. Эти счётчики плохо отражают изменение её содержания. Это хорошо продолжает их статью «All Models Are Wrong But Some Are Useful» (которую я уже разбирал): полезный эффект может оказаться за пределами выбранной модели.

Авторы даже рассматривают метрику Revenue per Engineer (выручку на инженера), как способ связать инженерную эффективность с бизнес-результатом. Но сами же оговаривают: на неё влияют рынок, продуктовая стратегия и другие части компании. Для оценки отдельной команды или человека она не подходит.

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

Поэтому я бы смотрел на три вещи:
1) Стала ли дешевле работа с конкретным видом долга
2) Куда ушло освободившееся время
3) Какой результат это позволило получить

Возвращение метрики к прежнему уровню вполне совместимо с успехом. Но само по себе успеха не доказывает — иначе любое отсутствие эффекта можно объяснить тем, что мы просто привыкли к хорошему:)

#Management #Engineering #Software #Productivity #Research #Metrics