Когда я впервые столкнулся с тем, что команда вроде бы работает, но фичи выходят месяцами, я почти поверил в миф о ленивых разработчиках. Потом мы начали измерять процесс, и картина стала честнее: люди не медленные, медленной была система. Метрики не нужны для наказаний. Они нужны, чтобы увидеть, где именно застревает поток. Ниже семь показателей, которые в моей практике объяснили почти каждую задержку.
Первая метрика — cycle time, время от начала работы над задачей до её попадания в прод. Вторая — WIP, количество задач, которые команда одновременно тащит. У нас был период, когда каждый разработчик вёл по три-четыре ветки, и все гордились многозадачностью. А cycle time рос, потому что переключение съедало фокус. Как только мы ограничили WIP и разрешили доводить до конца сначала одно, скорость выросла без героических вечеров.
Третья метрика — время до первого ревью и общее время ревью пул-реквестов. Часто команда не пишет медленно, а ждёт, пока старший разработчик освободится. Четвёртая — code churn, доля кода, который переписывают вскоре после написания. Если она высокая, проблема не в скорости набора текста, а в неясных требованиях, слабых тестах или отсутствии договорённостей. Я видел, как одна и та же логика переделывалась трижды, и это стоило недель.
Пятая метрика — blocked time, время, когда задача стоит из-за отсутствия доступа, ответа, окружения или решения архитектора. Шестая — частота деплоев и размер релиза. Редкие крупные релизы создают иллюзию занятости, но потом всё встаёт на отладку и ручные проверки. Когда мы перешли на мелкие частые поставки, предсказуемость выросла, а страх перед пятничным деплоем исчез.
Седьмая метрика — context switching и доля времени на встречи. Если у разработчика день разбит на куски по двадцать минут, он не пишет код, а постоянно восстанавливает контекст. Я сам одно время удивлялся, почему после четырёх созвонов не могу сделать простую задачу. Метрика показала: продуктивных окон почти не осталось. Мы сдвинули встречи в определённые часы и получили больше сделанного без изменения численности.
Мой главный вывод: измеряйте систему, а не людей. Соберите эти семь метрик в одну простую панель, смотрите на тренды, а не на отдельные значения. Обсуждайте их на ретро без поиска виноватых. Если cycle time падает, WIP ограничен, ревью быстрое, блокировки видны, релизы мелкие, а календарь не рвёт день на части, команда почти всегда начинает писать и выпускать быстрее. И да, это не про микроменеджмент, а про уважение к времени инженеров.
А какие метрики вы считаете самыми честными для оценки скорости команды? Было бы интересно сравнить опыт: что у вас реально помогло найти узкое место, а что оказалось красивой цифрой без пользы?
Первая метрика — cycle time, время от начала работы над задачей до её попадания в прод. Вторая — WIP, количество задач, которые команда одновременно тащит. У нас был период, когда каждый разработчик вёл по три-четыре ветки, и все гордились многозадачностью. А cycle time рос, потому что переключение съедало фокус. Как только мы ограничили WIP и разрешили доводить до конца сначала одно, скорость выросла без героических вечеров.
Третья метрика — время до первого ревью и общее время ревью пул-реквестов. Часто команда не пишет медленно, а ждёт, пока старший разработчик освободится. Четвёртая — code churn, доля кода, который переписывают вскоре после написания. Если она высокая, проблема не в скорости набора текста, а в неясных требованиях, слабых тестах или отсутствии договорённостей. Я видел, как одна и та же логика переделывалась трижды, и это стоило недель.
Пятая метрика — blocked time, время, когда задача стоит из-за отсутствия доступа, ответа, окружения или решения архитектора. Шестая — частота деплоев и размер релиза. Редкие крупные релизы создают иллюзию занятости, но потом всё встаёт на отладку и ручные проверки. Когда мы перешли на мелкие частые поставки, предсказуемость выросла, а страх перед пятничным деплоем исчез.
Седьмая метрика — context switching и доля времени на встречи. Если у разработчика день разбит на куски по двадцать минут, он не пишет код, а постоянно восстанавливает контекст. Я сам одно время удивлялся, почему после четырёх созвонов не могу сделать простую задачу. Метрика показала: продуктивных окон почти не осталось. Мы сдвинули встречи в определённые часы и получили больше сделанного без изменения численности.
Мой главный вывод: измеряйте систему, а не людей. Соберите эти семь метрик в одну простую панель, смотрите на тренды, а не на отдельные значения. Обсуждайте их на ретро без поиска виноватых. Если cycle time падает, WIP ограничен, ревью быстрое, блокировки видны, релизы мелкие, а календарь не рвёт день на части, команда почти всегда начинает писать и выпускать быстрее. И да, это не про микроменеджмент, а про уважение к времени инженеров.
А какие метрики вы считаете самыми честными для оценки скорости команды? Было бы интересно сравнить опыт: что у вас реально помогло найти узкое место, а что оказалось красивой цифрой без пользы?