В крупной команде руководитель хочет цифр, и цифры появляются: закрытые тикеты, строки кода, коммиты, стори-поинты. Дашборды рисуются быстрее, чем растёт продуктивность, и через полгода выясняется, что числа двигаются, а релизы быстрее не становятся. Проблема не в желании измерять, а в выборе объектов измерения. Настоящая скорость большой команды складывается из потока изменений, качества обратных связей, среды и климата, и почти всё это ломается при попытке свести работу к личным счётчикам. Разберём, какие факторы работают на самом деле и как их измерять, не разрушая команду.
Почему счётчики строк и закрытых задач врут о работе инженера
У строк кода как меры труда репутация плохая была всегда. Билл Гейтс когда-то заметил, что оценивать прогресс в программировании по числу строк всё равно что оценивать сборку самолёта по весу: у хорошей конструкции и того и другого меньше. Награда за объём наказывает за удаление кода, хотя лучшая неделя инженера иногда состоит из минуса двух тысяч строк. Счёт закрытых тикетов учит дроблению: одна задача превращается в пять, часть закрывается формально, потому что горит срок. Число коммитов наказывает тех, кто думает до клавиатуры, и поощряет тех, кто жмёт сохранение чаще.
Механизм порчи описан давно и носит имя закона Гудхарта: когда мера становится целью, она перестаёт быть хорошей мерой. Многолетнее исследование метрик доставки ПО прямо предостерегает от целей вида "каждая команда должна разворачиваться раз в день к концу года": люди начинают подгонять цифру вместо продукта. Метрика без контекста это не измерение, а негласный договор о том, что именно показывать наверх.
Были попытки нормировать труд честнее, например метод функциональных точек, который оценивает объём функциональности, а не объём текста. Метод полезен для договоров и оценки сроков, но и он меряет объём, а не ценность: пять однотипных экранов и одно архитектурное решение, сэкономившее год работы, в функциональных точках выглядят несопоставимо. Счётные метрики годятся для инвентаризации, а не для понимания.
Пять метрик доставки ПО из многолетнего отраслевого исследования
То же исследование, на которое ориентируются зрелые инженерные организации, выделило пять метрик, предсказывающих и результаты бизнеса, и самочувствие людей. Описать их можно одним списком:
- время прохождения изменения, от коммита до работающей версии в продакшене;
- частота развёртываний за выбранный период;
- время восстановления после неудачного развёртывания;
- доля развёртываний, потребовавших вмешательства, отката или срочной правки;
- доля незапланированных переделок, вызванных инцидентами в продакшене.
История самих метрик показательна. Исследование начиналось с четырёх ключевых цифр, потом модель выросла до пяти, а привычное среднее время восстановления переформулировали во время восстановления после неудачного развёртывания, чтобы отделить аварии от рутины. Отдельно подчёркивается универсальность: метрики работают и для приложений с языковыми моделями, и для банковских систем, и для мейнреймов, вопрос только в контексте применения.
Метрики первой группы показывают, сколько изменений проходит через систему, метрики второй, насколько безопасно это происходит. Выводы исследования стоит выучить наизусть. Скорость и стабильность не торгуются: лучшие команды сильны по всем пяти цифрам одновременно, слабые слабы по всем. Сравнивать метрики имеет смысл для одного приложения или сервиса: смешивать в одну корзину мобильное приложение и мейнрейм нельзя, контексты несопоставимы. И главный тон: метрики работают как тема для разговора внутри команды, а не как приговор, исследование прямо советует не строить дорогие интеграционные конвейеры ради точных цифр и начинать с обсуждений.
Незримые факторы продуктивности в большой команде
Помимо потоковых цифр существует пласт, который дашборды не показывают вообще. Исследователи инженерной продуктивности собрали его в рамку из пяти измерений, известную как SPACE: удовлетворённость и самочувствие, результативность, активность, коммуникация и сотрудничество, эффективность и поток. Сила рамки в балансе: счётчики активности, те же коммиты и тикеты, занимают одно измерение из пяти, а корпоративные разговоры о продуктивности обычно сводятся именно к ним.
Осязаемые примеры незримого. Известное многолетнее исследование эффективности команд, полторы сотни коллективов крупной технологической компании, первым фактором назвало психологическую безопасность: возможность задать простой вопрос, признаться в ошибке и не опасаться, что это используют против тебя. Коллективы с высоким доверием выпускали больше и ломали реже, чем команды с более сильными на бумаге резюме. Прерывания: замеры возобновления работы показывают, что возврат в код после отвлечения занимает порядка десяти-пятнадцати минут, поэтому пять коротких вопросов за день съедают больше часа глубокой работы, если считать не разговор, а восстановление контекста. Время ревью: изменение лежит без просмотра два дня, формально работа идёт, фактически она стоит. Время онбординга: сколько новому человеку нужно до первого полезного мержа, в запущенных репозиториях это месяцы, в аккуратных с шаблонами и документацией неделя.
К незримому относится и когнитивная нагрузка. Команда, в чьих головах не помещается собственный домен, не может быть быстрой ни при каких метриках: люди тратят время на восстановление понимания, а не на работу. Практика распределения команд по доменам прямо исходит из этого ограничения, размер группы подбирают не под бюджет, а под объём предметной области. Рядом стоит фактор автобуса: если знания о критичном модуле держит один человек, любой его отпуск замедляет всю линию. Эти вещи не видны в коммитах, зато мгновенно видны в календаре.
Поток изменений и незавершённая работа вместо гонки за тикетами
Для инженерного менеджмента полезнее закона Литтла мало что есть: время цикла равно объёму незавершённой работы, делённому на скорость её завершения. Пример на пальцах: у команды в работе сорок задач, закрывает она десять в неделю, значит средняя задача идёт от старта до релиза четыре недели. Не потому, что люди медленные, а потому что очередь длинная. Сократить время цикла можно двумя способами: поднять скорость или укоротить очередь, и второй дешевле. Ограничение незавершённой работы до двадцати задач без единой лишней минуты работы сокращает путь до продакшена вдвое.
В этой же логике живёт размер партии. Десять изменений, собранных в один большой релиз, проходят через систему дольше и просматриваются хуже, чем десять отдельных, при том же суммарном объёме работы. Незавершённая работа не прогресс, а замороженные деньги и занятые головы, поэтому зрелые команды режут партии не ради эстетики, а ради скорости обратной связи и дешёвого отката. Один релиз из двадцати правок откатывается целиком, двадцать мелких откатываются по одной.
Короткие изменения это не эстетика, а экономика: маленькие пул-реквесты просматривают внимательнее и быстрее, большие лежат без внимания, потому что никто не находит двух свободных часов подряд. Частоту мержей видно прямо из истории репозитория, без единого ручного тикета:
git log --merges --since="30 days ago" --pretty=format:"%ad" --date=short | sort | uniq -cДальше остаётся честно ответить, что мешает числу расти: очередь на ревью, долгие сборки, ожидание тестовых сред или решения по архитектуре. Каждая из этих очередей чинится своими средствами, и ни одно из них не требует спрашивать с людей больше.
Быстрые обратные связи как настоящий множитель скорости
Скорость обучения команды определяется длиной самой короткой петли обратной связи. Петли устроены иерархически: компилятор отвечает за секунды, юнит-тесты за минуты, конвейер за десятки минут, ревью за часы или дни, продакшен за недели. Инженер, который узнаёт о собственной ошибке через восемь часов, к моменту ответа уже забыл половину контекста; тот же инженер с петлёй в пять минут исправляет мелочь до обеда. Каждое сокращение петли умножает число экспериментов в день, а команда движется именно экспериментами, а не героическими ночами.
Отдельный враг петли, тесты, падающие без причины. Такой тест приучает перезапускать красное, и первое настоящее падение проходит незамеченным на фоне привычного шума. Шум уведомлений работает так же: сотня алертов в день читается как спам, и важный тонет. Зрелая среда отличается не количеством мониторинга, а доверием к нему: зелёный цвет означает исправную систему, красный требует действий, серой зоны почти нет.
Почему индивидуальные метрики ломают команду изнутри
Как только метрика становится личной, меняется сама команда. Люди перестают помогать друг другу, потому что час помощи это минус в личном отчёте. Знания перестают быть общими, потому что делиться ими невыгодно. Совместный разбор инцидентов вырождается в поиск виноватого, и первой исчезает честность, на которой держится быстрая обратная связь. Крупные корпорации в своё время отказались от принудительных рейтингов внутри команд именно поэтому: рейтинг разрушал сотрудничество быстрее, чем поднимал индивидуальные результаты.
Сравнивать людей по счётчикам бессмысленно ещё и потому, что задачи несопоставимы: один тянет исследование с неясным исходом, второй переписал пять однотипных методов. Цифры выйдут похожими, ценность отличается в разы. Официальный свод правил скрама не предписывает ни стори-поинты, ни сравнение скоростей команд, и сообщество давно зафиксировало: скорость это инструмент планирования самой команды, единицы у каждой свои. Правильный уровень измерения это команда или сервис, не человек. Человек же оценивается качеством решений и взаимодействием, это субъективно, зато не ломает общее дело.
К тому же выводу приходит и исследование метрик доставки в списке типовых ошибок: метрики не должны становиться предметом соревнования между командами. Смысл замеров в сравнении команды сегодняшней с ней же вчерашней, а не с соседями по офису. Команды охотно радуются чужим успехам там, где знают, что собственные цифры нужны для поиска узких мест, а не для рейтинга. Разница тонкая, а культуру меняет радикально.
Практичные способы оценить и поднять продуктивность команды
Начинать стоит с дешёвого: короткий регулярный опрос из трёх-четырёх вопросов с полем для свободного ответа. Что тебя больше всего тормозит? Что мешало на прошлой неделе? Если убрать одну вещь, какую? Ответы дают список работ, который важно выполнять и спрашивать снова, иначе люди перестанут отвечать. Дальше идут измеримые атрибуты среды: время сборки, время ревью, время до первого мержа новичка, скорость выдачи тестовых сред.
Арифметика среды убедительнее философии. Если сборка проекта занимает сорок минут, двадцать инженеров запускают её по пять раз в день, а её сокращают до пяти минут, экономия составит почти шестьдесят рабочих часов в сутки только на ожидании. Никакая мотивация не сэкономит столько. Инструментальные команды, шаблоны проектов, документация и быстрые тестовые среды это не роскошь, а прямой вклад в скорость всей организации.
Хороший рабочий цикл выглядит скромно: короткий опрос, из ответов выбираются одна-две самые громкие проблемы, две недели на их устранение, повторный опрос с публикацией изменений. Примеры целей: снизить медианное время ревью с двух дней до четырёх часов, убрать самые медленные шаги конвейера, сократить выдачу тестовой среды с недели до часа. Каждая победа фиксируется цифрой до и после, и через полгода накапливается история, которую невозможно подделать.
И финальный принцип: измеряй поток, спрашивай людей, улучшай среду. Метрика нужна, чтобы заметить проблему и проверить, что стало лучше, а не чтобы ранжировать. В здоровых организациях цифры рождают вопросы и эксперименты, в нездоровых оправдания и рейтинги.
Продуктивность крупной команды это свойство системы, а не сумма личных показателей, и она растёт вместе с потоком, средой и доверием. Счётчики строк и закрытых задач этого не видят, а порой и портят: метрика, которая стала целью, перестаёт мерить. Пять метрик доставки дают объективную опору, рамка SPACE напоминает про самочувствие и сотрудничество, закон Литтла объясняет, почему короче очередь лучше быстрее людей. Практичный итог для руководителя звучит скромно: измеряй систему на уровне команд, разговаривай с людьми об их препятствиях и вкладывайся в среду. Скорость тогда растёт сама, потому что ей перестают мешать.