1.1 Зачем измерять программную инженерию

Обзор и мотивация

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

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

Для крупных команд это перестаёт быть приятным дополнением и становится структурной необходимостью. Команда из шести человек может разделять общую ментальную модель происходящего через ежедневное общение. Отдел из шестисот человек, разбросанный по часовым поясам и бизнес-подразделениям, не может. В таком масштабе общий, заслуживающий доверия набор чисел является единственной практической заменой того неформального понимания, которое маленькая команда получает бесплатно. Руководству корпорации нужны метрики, чтобы распределять инвестиции между десятками команд, конкурирующих за один и тот же бюджет. Государственным инженерным организациям нужны метрики, чтобы продемонстрировать законодательным органам и обществу, что выделенные средства дали реальную мощность, а не просто активность. В обоих случаях «мы много работали» не является доказательством, а защитимое число является.

Ключевые принципы

Измеряйте, чтобы учиться, а не чтобы судить. Основная цель инженерной метрики: информировать решение, а не оценивать человека или команду.
Число без привязанного решения это украшение. Если никакое значение метрики не изменило бы ваши дальнейшие действия, ей не место на дашборде.
Измерение это средство, а не цель. Цель: лучшее программное обеспечение, доставляемое более надёжно устойчивой командой. Метрики существуют только для того, чтобы служить этой цели.
У каждой метрики есть своя цена. Инструментирование, время на анализ и риск поведенческого искажения, рассмотренный в теме 1.2, все они чего-то стоят. Метрика должна отработать эту цену.
Молчание тоже решение. Выбор не измерять что-либо это выбор с последствиями, а не нейтральное положение по умолчанию.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Интенсивное инструментирование, много метрик	Широкая видимость, меньше слепых зон	Усталость от дашборда, большая площадь для манипулирования, более высокая стоимость обслуживания
Минимальные, управляемые решениями метрики	Фокус, низкие накладные расходы, каждая метрика защитима	Риск пропустить возникающую проблему за пределами выбранного набора
Метрики только для диагностики	Поощряет честную отчётность и исследование	Руководство всё равно может неформально использовать их оценочно
Метрики, привязанные к индивидуальной оценке	Ощущается подотчётным, легко объяснить руководителям	Сильный стимул к манипулированию; подрывает доверие; обычно измеряет не то

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

Вопросы для обсуждения в команде

Для каждой метрики на нашем текущем дашборде: какое решение вызвало бы хорошее значение и какое плохое? Если оба значения ведут к одному и тому же действию или вообще ни к какому, метрика украшение. Пройдите дашборд плитка за плиткой и заставьте себя честно ответить на каждую. Это упражнение регулярно сокращает раздутый дашборд вдвое за один присест, потому что большая часть разрастания накапливается из метрик, которые никто никогда не убирает, а не из метрик, которые кто-то намеренно добавил по причине, которая всё ещё действительна.
Какие из наших метрик используются диагностически, а какие незаметно стали оценочными? Метрика, созданная для понимания системного ограничения, может соскользнуть в использование для ранжирования команд или отдельных людей без чьего-либо сознательного решения, часто через случайный комментарий на совещании по ревью, который становится привычкой. Как только этот дрейф происходит, число перестаёт заслуживать доверия, потому что теперь у людей есть причина заставить его выглядеть хорошо, а не делать его точным. Назовите назначение каждой метрики в письменном виде и сверьте с текущей практикой.
Что мы не измеряем, потому что это трудно инструментировать, и во что обходится нам этот пробел? Самые опасные слепые зоны те, что никогда не попадают на дашборд именно потому, что сопротивляются лёгкому измерению: трение межкомандных зависимостей, эрозия институциональных знаний или тихое накопление хрупких обходных решений. Принесите список того, о чём все тайно беспокоятся, но никто не отслеживает, и будьте честны о причинах.
Если бы мы удалили эту метрику завтра, кто бы заметил и что бы они потеряли? Метрика, по которой никто не стал бы скучать, это метрика, не информирующая никакое решение. Этот вопрос выявляет плитки тщеславия, выживающие исключительно по инерции. Для крупной организации с десятками командных дашбордов эта дисциплина прополки важна не менее, чем дисциплина добавления новых метрик.
Сколько на самом деле стоит производство и обслуживание каждой метрики на нашем дашборде, включая инженерное время, стоящее за инструментированием? Метрики не бесплатны. Конвейеры, дашборды и время на ревью, потраченное на обсуждение числа, все они несут повторяющуюся стоимость, которую легко недооценить, потому что она распределена по множеству мелких задач, а не является одной видимой строкой бюджета. Принесите ваши реальные затраты на инструментирование и обслуживание и сопоставьте их с ценностью решения из вопроса 1.
Где измерение стало заменой суждению, а где суждение стало заменой измерению? Оба отказа реальны. Команда, которая передаёт каждое решение дашборду, теряет контекстное суждение, улавливающее то, что упускает число; команда, игнорирующая доступные данные в пользу самого громкого голоса в комнате, повторяет ту самую проблему, с которой начинается эта тема. Цель: метрики, информирующие суждение, а не метрики, заменяющие его.

Отраслевой взгляд

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

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

Корпорация. Основной риск: метрики, которые незаметно дрейфуют от диагностического к оценочному использованию по мере прохождения через управленческие слои, и дашборды, которые растут за счёт накопления, потому что никто не владеет задачей их прополки. Управление (тема 1.4) не является опциональным в таком масштабе. Стандартизируйте определения между бизнес-подразделениями и встройте регулярный обзор для выведения метрик из эксплуатации в саму программу метрик.

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

Примеры

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

Государство. Команду цифровых услуг национального налогового агентства надзорный комитет попросил продемонстрировать отдачу от многолетней программы модернизации. Существующие метрики команды были полностью внутренними и основанными на активности: завершённые стори-пойнты, закрытые спринты. Ничто из этого не отвечало на реальный вопрос комитета. Вместо этого команда построила небольшой набор метрик результата: медианное время решения проблемы гражданина с подачей документов, уровень принятия цифрового канала и частоту вырвавшихся дефектов в новой системе, и отчитывалась по ним ежеквартально с документированной методологией. Вопросы комитета сместились с «докажите, что вы работаете» на «как нам воспроизвести это в следующем агентстве», что и является тем результатом, который должен производить хорошо выбранный набор метрик.

Бизнес-кейс: мотивация, ROI и TCO

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

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

Антипаттерны и ловушки

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

Модель зрелости

Уровень 1, Инициация: Метрики, если они вообще существуют, носят случайный характер, личные для того, кто их создал, и никто не может сказать, какое решение они информируют.
Уровень 2, Развитие: Базовый набор метрик существует для некоторых команд, в основном скопированный из фреймворка или настроек инструмента по умолчанию, без явной связи с решением.
Уровень 3, Стандартизация: У каждой отслеживаемой метрики есть документированное назначение и явная классификация диагностическая или оценочная, последовательно применяемая по всей организации.
Уровень 4, Управление: Метрики пересматриваются с фиксированной периодичностью относительно решений, которые они информируют; метрики, переставшие отрабатывать свою цену, выводятся из эксплуатации, и весь набор оценивается по стоимости наравне с ценностью.
Уровень 5, Оркестрация: Измерение это живая способность: организация регулярно выявляет собственные слепые зоны, проверяет, по-прежнему ли её представители отслеживают реальность, и относится к самой программе метрик как к тому, что нужно улучшать, а не просто поддерживать.

Идеи для обсуждения

Какую метрику на нашем дашборде нам было бы труднее всего оправдать сохранение, если бы нас спросили сегодня?
Какое решение мы приняли в прошлом квартале, используя метрику, а не мнение?
Где в нашей организации диагностическая метрика незаметно стала оценочной?
Что мы боимся измерять и почему?
Если бы наша программа метрик исчезла завтра, какие решения стали бы хуже?

Основные выводы

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

Источники и дальнейшее чтение

Accelerate: The Science of Lean Software and DevOps, Николь Форсгрен, Джез Хамбл и Джин Ким.
How to Measure Anything, Дуглас У. Хаббард.
Measuring and Managing Performance in Organizations, Роберт Д. Остин.
Thinking, Fast and Slow, Дэниел Канеман.
Программа Google DevOps Research and Assessment (DORA), dora.dev.