[Почему падает скорость поставки, и что показывает системная практика]

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

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

За три года работы с дюжиной продуктовых команд этот паттерн проявлялся достаточно последовательно, чтобы я стал принимать его как базовое допущение. Меняется не то, случается ли это, а то, как это начинается и как долго остается незамеченным. Эта статья о том, как деградация скорости поставки выглядит на практике, что ее провоцирует и что я научился замечать до того, как это замечает клиент.

Если построить график стори пойнтов за спринт на протяжении типичного жизненного цикла проекта, вы не увидите прямую линию или равномерный рост. Вы увидите кривую с характерной формой – узнаваемой, если знать, что искать.

Месяцы 1-3: скорость растет. Команда набирает темп, инструменты стабилизируются, первые фичи архитектурно несложные. Оценки здесь наиболее точные – команда работает над четко определенным скоупом в относительно чистой среде.

Месяцы 3-6: скорость выходит на плато, которое выглядит устойчивым. Стейкхолдеры довольны. Ретроспективы тихие. Цифры достаточно чистые, чтобы не было давления заглянуть под них.

С седьмого месяца кривая начинает загибаться. Не обваливаться, загибаться. Падение стори пойнтов на 10% в спринте не бьет тревогу. 15% – тоже. Но если смотреть на те же данные через другую призму – точность оценок, вариативность времени цикла, частоту переработок – сигнал там присутствует и накапливается уже несколько недель.

Ключевая проблема с использованием скорости как основной метрики состоит в том, что она измеряет выпуск без измерения сопротивления. Команда, поставляющая 30 стори пойнтов в третьем месяце и 24 в девятом, может работать с одинаковой отдачей. Разница в том, через что она работает. Я нашла более полезным другой показатель: соотношение фактического времени к оценочному в динамике по спринтам. Когда команда системно тратит значительно больше времени, чем оценивала, вне зависимости от конкретного порога, что-то структурное меняется, даже если график скорости выглядит приемлемо.

Деградация скорости редко вызвана одной причиной. На практике это почти всегда комбинация факторов, которые усиливают друг друга. Пять причин проявляются достаточно регулярно, чтобы я сегодня воспринимала их как стандартный диагностический чеклист.

1. Накопленный технический долг в высоконагруженных модулях. Части кодовой базы, которых касаются чаще всего, накапливают трение быстрее всего. Модуль, поверх которого построено пять разных фич, каждая из которых шла на небольшие компромиссы, становится всё дороже в работе. Это проявляется в вариативности времени цикла: тикеты, затрагивающие такие модули, занимают значительно больше времени, чем тикеты сопоставимой сложности в более чистых областях.
2. Изменение скоупа, поглощенное без пересчета оценок. Изменения скоупа в середине спринта – норма. Проблема – когда они поглощаются без обновления оценки, то есть стоимость изменения никогда не отражается в данных. Со временем это порождает систематическое занижение оценок, из-за чего команда выглядит медленнее – хотя на деле делает больше, чем показывает трекер.
3. Изменение состава команды без передачи знаний. Когда старший инженер уходит или переходит на другой проект, пробел в знаниях редко сразу отражается на скорости. Он проявляется через два-три спринта, когда оставшаяся команда сталкивается с системами, которые глубоко понимал только ушедший. Время цикла в затронутых областях растёт, точность оценок падает, частота переработок увеличивается.
4. Сжатие процесса ревью под давлением объема. По мере взросления проектов и роста давления на выпуск ревью кода ускоряется так, что это не отражает реальной тщательности. Ревью, занимавшие два дня, укладываются в четыре часа. Архитектурные проблемы, которые вдумчивое ревью бы поймало, начинают проскальзывать. Стоимость проявляется позже: больше переработок, больше багов, больше переоткрытых тикетов.
5. Нагрузка от переключения контекста при нескольких параллельных приоритетах. Это сложнее увидеть напрямую в данных, но проявляется в точности оценок и в разрыве между залогированными часами и завершённой работой. Когда инженеры переключаются между тремя проектами или между разработкой фич и поддержкой продакшна, их реальная пропускная способность по каждому отдельному элементу ниже, чем предполагают залогированные часы.

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

"Команда стала медленнее" – это редко ошибочное наблюдение, и неизменно неточный диагноз. К тому моменту, когда это становится ощущением, данные обычно показывают это уже несколько недель. Задача метрик – точно определить, где и почему.

1. Точность оценок по модулям, а не по спринтам. Точность на уровне спринта усредняет шум, который важен на уровне модуля. Если модуль payments стабильно требует 150% от оценочного времени – это конкретная находка, с которой можно работать.
2. Распределение , а не среднее значение. Среднее может оставаться стабильным, пока дисперсия растет: одни задачи выполняются быстрее, другие – значительно медленнее. Расширение этого распределения – структурный сигнал. Я смотрю прежде всего на верхний хвост: что занимает значительно больше всего остального и что у этих тикетов общего.
3. Частота переработок по спринтам. Какой процент тикетов, закрытых в данном спринте, был переоткрыт в течение следующих двух? Кластеризованные переработки подсказывают, где фиксы не закрепляются, – а это обычно означает, что корневая причина не устраняется, потому что её устранение потребовало бы трогать код, рефакторинг которого слишком дорог в текущих условиях.
4. Тренд соотношения багов к фичам. Медленный, но надежный индикатор. По мере того, как поддерживающая работа начинает вытеснять разработку, доля тикетов на исправление багов относительно фичей растет. Устойчивый восходящий тренд означает, что команда тратит все большую долю мощности на поддержание работоспособности существующего функционала, а не на разработку нового.
5. Время ревью PR и распределение комментариев. Рост времени ревью в сочетании со сдвигом в сторону поверхностных комментариев – стилистические замечания, минорные нейминг-конвенции – сигнализирует либо о том, что ревьюеры слишком заняты для глубокого участия, либо о том, что они избегают сложных архитектурных разговоров, потому что нет полосы пропускания их решать.

Эти пять метрик вместе обычно складываются в связную картину. Они редко все одновременно движутся в одном направлении, поэтому смотреть на них в совокупности полезнее, чем на любой отдельный индикатор.

Данные и восприятие команды расходятся чаще, чем принято думать, и направление расхождения показательно.

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

Менее распространенный, но более важный случай: данные выглядят приемлемо, а команда говорит, что что-то не так. Это требует наибольшего внимания, потому что приемлемо выглядящие данные могут маскировать реальные проблемы, если отслеживаемые метрики неправильные или данные неполные. Типичные объяснения: работа, создающая трение, не логируется должным образом; процесс оценки был неформально скорректирован с учетом более медленной среды; трение сконцентрировано в части кодовой базы, которую текущие метрики не освещают.

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

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

После третьего месяца я теперь последовательно провожу четыре проверки.

Запускаю ревью точности оценок на уровне модулей по всем тикетам, закрытым с начала проекта. Модуль, уже требующий 140% от оценочного времени на третьем месяце, весьма вероятно станет источником проблем со скоростью позже.

Проверяю, пересчитываются ли изменения скоупа или поглощаются молча. Если команда стабильно поставляет в рамках исходных оценок, одновременно поглощая изменения скоупа, фактические данные занижены относительно реальных усилий, что влияет как на прогнозирование бюджета, так и на точность будущих оценок.

Смотрю на распределение комментариев в ревью – архитектурные против поверхностных. Дрейф в сторону поверхностной обратной связи при росте объема – предупреждение о том, что глубина ревью торгуется на скорость.

Провожу явный разговор с тимлидом о факторе автобуса (bus factor). Какие части кодовой базы глубоко понимает только один человек? Этот разговор легче на третьем месяце, чем позже, когда концентрация знаний обычно становится более выраженной, а варианты ее устранения – более ограниченными.

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

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

Растущий возраст PR без роста его размера. Когда пул реквесты задерживаются в ревью дольше, но не становятся крупнее, что-то другое вызывает задержку: доступность ревьюеров, уверенность в проверяемом коде или когнитивная нагрузка, необходимая для понимания контекста.

Постепенный рост продолжительности стендапов. Это не в данных – требует внимания к динамике встреч. Когда стендапы, занимавшие пятнадцать минут, стабильно растягиваются до тридцати, причина обычно – сбой процесса, а не технический: люди приходят неподготовленными, дебаггинг в реальном времени начинается в момент, когда кто-то упоминает блокер, или команды просто вырастают настолько, что время увеличивается механически. Стоит решать напрямую, а не списывать на кодовую базу.

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

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

Ни один из этих сигналов в отдельности не достаточен для вывода о том, что скорость вот-вот деградирует. В совокупности, в динамике за два-три спринта, они формируют картину, на которую стоит реагировать – в идеале до того, как клиент спросит, почему всё ощущается медленнее.