Введение

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

Для кого эта книга

Основные читатели это те, кто выбирает, что измеряет организация: инженерные руководители, staff- и principal-инженеры, платформенные команды и команды DevOps, а также программные и продуктовые менеджеры. Второстепенные читатели это все инженеры, которые хотят понять логику дашборда, который им велят двигать, или оспорить метрику, переставшую служить своей цели. Читать от корки до корки не обязательно. Каждая тема самодостаточна, сначала излагает принцип и заканчивается практическими выводами, моделью зрелости и источниками.

Как устроена книга

Книга разделена на части (целые числа) и темы (десятичные дроби). Тема N.0 представляет каждую часть и объясняет, как связаны её темы; темы N.1, N.2, … подробно разбирают отдельные вопросы.

• Часть 1, Основы измерения: зачем вообще измерять, закон Гудхарта и психология манипулирования, выбор результатов вместо выпуска, управление и владение, источники данных и статистическая грамотность, нужная любой программе метрик.
• Часть 2, Метрики потока: Flow Framework, элементы потока и пять метрик потока, время цикла, теория очередей, классические метрики потока создания ценности (lean), метрики pull request и код-ревью, а также модель DORA как справочная тема.
• Часть 3, Опыт разработчика и модель SPACE: модель SPACE и её пять измерений, а также как проводить опросы об опыте разработчика, не превращая их в конкурс популярности.
• Часть 4, Метрики кода и качества: сложность, покрытие и эффективность тестов, churn и горячие точки, статический анализ, технический долг и документация.
• Часть 5, Продуктовые и бизнес-метрики: пропущенные дефекты, принятие функций, результаты для клиентов и бизнеса, юнит-экономика и возврат инвестиций.
• Часть 6, Метрики надёжности, эксплуатации и безопасности: SLI, SLO и бюджеты ошибок, метрики инцидентов, дежурства и ёмкость, метрики безопасности и уязвимостей.
• Часть 7, Метрики в эпоху ИИ: сдвиг парадигмы, вызванный генеративным ИИ, как измерять разработку с ИИ-поддержкой, риск инфляции метрик и почему телеметрия результатов становится путеводной звездой, когда выпуск дешевеет.
• Часть 8, Построение программы метрик: проектирование дашбордов, строить или покупать, внедрение метрик без создания страха, модели зрелости и поэтапная дорожная карта внедрения.
• Часть 9, Приложения: глоссарий, справочник определений и формул метрик, чек-листы, шаблоны, самооценка зрелости, источники и предметный указатель.

Руководящие принципы

Восемь принципов составляют хребет книги:

1. Мера, ставшая целью, перестаёт быть хорошей мерой. Проектируйте против закона Гудхарта с самого начала, а не после того, как возникло искажение.
2. Результаты выше выпуска, выпуск выше активности. Взвешивайте каждый набор метрик в сторону того, что изменилось для клиента или бизнеса, а не того, что произвела команда или насколько она была занята.
3. Каждой метрике со стимулом нужна страховочная метрика. Сочетайте скорость с качеством, а пропускную способность со стабильностью, и никогда не гонитесь за одним числом в отрыве от остальных.
4. Измеряйте системы, а не людей. Метрики, персонализирующие вину, подтачивают доверие и приглашают к манипулированию; метрики, показывающие ограничения системы, приглашают к улучшению.
5. Предпочитайте инструментирование самоотчёту там, где можно, и самоотчёт там, где нельзя. Число развёртываний берётся из конвейера; удовлетворённость из вопросов.
6. Метрика зарабатывает своё место или уходит на покой. Каждая плитка дашборда расходует внимание. Обрезайте осознанно.
7. Определения важнее дашбордов. Две команды, считающие «время выполнения» по-разному, тратят больше времени на споры о числе, чем на действия на его основе.
8. Генеративный ИИ повод пересмотреть, а не только пересчитать базовую линию. Когда выпуск дешевеет, метрикам, построенным вокруг объёма выпуска, нужны не просто новые цели, а новые страховочные метрики.

Сквозные темы

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

Как использовать

Внедряйте поэтапно; не обрушивайте дашборд разом на команду, у которой его никогда не было. Начните там, где боль сильнее всего, используйте модель зрелости каждой темы, чтобы честно определить своё место, и пусть дорожная карта внедрения (тема 8.5) задаёт порядок работ. Цель не стена графиков. Цель организация, которая может сказать, с доказательствами, работает ли то, что она делает, и которая достаточно доверяет собственным числам, чтобы действовать на их основе.