3.3 Метрики результативности и представители результата
Обзор и мотивация
Результативность, P в SPACE (тема 3.1), это измерение, чаще всего путаемое с активностью, и именно эта путаница существует для того, чтобы предотвратить эта тема. Результативность спрашивает, действительно ли работа инженера или команды произвела хороший результат: функцию, которая была отгружена и работала, систему, остававшуюся надёжной, изменение, сдвинувшее бизнес- или пользовательскую метрику в правильном направлении. Активность (тема 3.4) спрашивает только о том, сколько движения произошло. Команда может быть высоко активной и низкорезультативной, отгружая постоянные мелкие изменения, никогда не двигающие результат, и обратное равно возможно: команда, редко отгружающая, но чьи изменения надёжно попадают именно туда, куда нужно.
Трудность с этим измерением в том, что результат часто не приписывается единственному человеку или даже единственной команде; результаты программного обеспечения возникают из сотрудничества, из решений, принятых месяцами ранее людьми, с тех пор перешедшими на другие проекты, из рыночных условий, которые не контролирует ни один инженер. Исследователи SPACE были явны на этот счёт: результативность следует измерять на уровне системы или команды, используя множественные сходящиеся сигналы, не сводя её к единственному числу и уж точно не приписывая её отдельному инженеру изолированно. Эта тема серьёзно относится к этому указанию и относится к индивидуальному приписыванию результативности как к ловушке, которой нужно активно избегать, а не как к короткому пути, который можно принять, когда удобно.
Для крупных команд правильное измерение результативности это то, что отличает программу метрик, действительно улучшающую результаты, от той, что лишь вознаграждает видимую занятость. Корпоративным организациям, сравнивающим результативность по многим командам, нужны сигналы, сопротивляющиеся манипулированию через сырой объём выпуска; государственным организациям, обосновывающим технологическую инвестицию перед надзорными органами, нужно продемонстрировать, что инженерные усилия произвели реальные результаты, а не просто доставили артефакты, что именно принцип результаты важнее выпуска из темы 1.3, применённый к этому конкретному измерению.
Ключевые принципы
- Результативность измеряет, произвела ли работа хороший результат, а не сколько работы произошло. Это основное различие с измерением активности.
- Используйте множественные сходящиеся сигналы, никогда единственное число результативности. Ни один отдельный представитель не достаточно надёжен, чтобы стоять в одиночестве.
- Измеряйте на командном или системном уровне. Индивидуальное приписывание результата обычно ненадёжно и приглашает именно то манипулирование, против которого предупреждает эта книга на протяжении всего текста.
- Качество часть результативности, а не отдельная забота. Работа, которая отгружается, но ломает что-то ещё, на самом деле не сработала хорошо.
- Сигнал результативности без привязанного решения это украшение, точно по общему принципу темы 1.1, применённому к этому измерению.
Рекомендации
Сочетайте несколько сходящихся сигналов вместо единственной оценки результативности
Черпайте доказательство результативности из множественных источников: доля неудачных изменений (тема 2.10) и доля вырвавшихся дефектов (тема 5.1) для качества, результаты развёртывания, связанные с фактическим принятием функции (тема 5.2), для того, имела ли работа значение, и качественная оценка коллег или менеджера вклада команды в стратегические цели для контекста, который чистая метрика не может захватить. Ни один из них сам по себе не надёжен; вместе, когда они сходятся на одном выводе, они гораздо более заслуживают доверия, чем могло бы быть любое единственное число.
Измеряйте на командном уровне, сопротивляйтесь индивидуальному приписыванию
Результаты программного обеспечения редко являются продуктом работы одного человека в одиночку; они возникают из проектных решений, обратной связи ревью, предыдущей работы людей, возможно, с тех пор покинувших команду, и сотрудничества через границы. Приписывание результата единственному инженеру обычно ложная точность, игнорирующая эту реальность и создающая сильный стимул для отдельных людей защищать заслугу, а не свободно сотрудничать, именно тот вид искажения стимула, против которого предупреждает тема 1.2.
Включите качество прямо в определение результативности
Функция, отгруженная вовремя, но вызвавшая волну производственных инцидентов, не сработала хорошо, даже несмотря на то что наивный взгляд только на выпуск засчитал бы её как доставленную. Встройте долю неудачных изменений, долю вырвавшихся дефектов и данные инцидентов после релиза прямо в то, как вы оцениваете результативность, вместо того чтобы относиться к качеству как к отдельной несвязанной заботе, измеряемой только в частях 4 и 6 этой книги.
Используйте данные результативности, чтобы информировать решения об инвестициях и процессе, а не индивидуальные рейтинги
Продуктивное использование данных результативности это решение о том, куда инвестировать дальше (команда, стабильно доставляющая сильные результаты, заслуживает больше ресурсов и автономии) и куда исследовать (команда, чья работа стабильно не попадает в цель, заслуживает помощи, а не обвинения, согласно диагностическому формулированию темы 1.1). Ранжирование отдельных людей или команд в конкуренции друг с другом по данным результативности приглашает именно то манипулирование и ущерб морали, против которого предупреждает эта книга, и редко производит лучшие результаты, чем это делает диагностическое использование.
Будьте честны об ограничениях приписывания, особенно для платформенных и обеспечивающих команд
Команды, строящие общую инфраструктуру, внутренние инструменты или платформенные возможности (тема родственной книги software-engineering-guide о платформенной инженерии покрывает это напрямую), часто имеют свой вклад в результаты на несколько шагов удалённым от какой-либо единственной обращённой к клиенту метрики. Измеряйте результативность этих команд через их влияние на команды, которые они обеспечивают, принятие их платформы, сокращение трения, о котором сообщают потребляющие команды, вместо того чтобы навязывать неподходящую метрику прямого результата работе, по своей сути косвенной.
Компромиссы: плюсы и минусы
| Подход | Плюсы | Минусы |
|---|---|---|
| Единственная оценка результативности на команду | Просто представить и сравнить | Ложная точность; скрывает, какой лежащий в основе сигнал на самом деле двигал оценку |
| Множественные сходящиеся сигналы | Более заслуживает доверия, сопротивляется манипулированию единственной метрикой | Труднее резюмировать в одном числе; требует больше контекста для интерпретации |
| Измерение результативности на командном уровне | Соответствует тому, как на самом деле возникают результаты программного обеспечения | Не может напрямую ответить на вопросы об индивидуальном вкладе |
| Индивидуальное приписывание результативности | Ощущается более напрямую действенным для обзоров | Обычно ложная точность; сильный риск манипулирования и защиты заслуги |
Центральное напряжение: точность против честности. Единственное число результативности на команду, или хуже, на отдельного человека, легко сравнивать и ранжировать, но эта точность обычно ложна, скрывая реальную неопределённость о приписывании и качестве за чисто выглядящей цифрой. Разрешайте это напряжение, принимая менее аккуратную многосигнальную картину как честную, и сопротивляясь давлению от руководства или процессов обзора эффективности свернуть её обратно в единственную ложно точную оценку.
Вопросы для обсуждения в команде
Сочетает ли наше текущее измерение результативности множественные сходящиеся сигналы, или полагается на единственное число, ощущающееся более точным, чем оно есть на самом деле? Проверьте то, что вы сейчас называете «метрикой результативности», и посмотрите, сколько независимых сходящихся сигналов в неё на самом деле поступает.
Приписывали ли мы когда-либо результативность команды или отдельного человека, не учитывая совместную межкомандную природу того, как на самом деле произошёл результат? Выберите недавнюю историю успеха и проследите, сколько из неё зависело от людей, решений или предыдущей работы вне команды или человека, получивших заслугу.
Включает ли наше измерение результативности качество, или только скорость доставки и объём выпуска? Отгруженная функция, позже вызвавшая значительные производственные инциденты, не должна оцениваться как высокая результативность; проверьте, действительно ли ваше текущее измерение поймало бы этот случай.
Как мы измеряем результативность платформенной или обеспечивающей команды, чей вклад в результаты косвенен? Если честный ответ «мы не измеряем, ну», этот пробел стоит назвать и адресовать напрямую, а не оставлять эти команды фактически неизмеренными или несправедливо измеренными против обращённых к клиенту метрик результата, не подходящих их работе.
Использовались ли данные результативности когда-либо для конкурентного ранжирования отдельных людей друг против друга, формально или неформально? Этот дрейф, схожий с риском данных удовлетворённости в теме 3.2, вредит и честности данных, и готовности команды открыто сотрудничать.
Когда наши сходящиеся сигналы расходятся, например высокая скорость доставки, но растущая частота дефектов, что мы заключаем, и хорошо ли наш процесс справляется с этим расхождением? Расхождение между сигналами само по себе ценная информация; обсудите, относится ли ваша команда к нему сейчас как к шуму, который нужно игнорировать, или как к подлинной находке, достойной исследования.
Отраслевой взгляд
Стартап. Результативность обычно видна напрямую: работала ли функция, приняли ли её клиенты, сдвинулась ли метрика. Формальное многосигнальное измерение часто не нужно в этом масштабе; риск скорее в том, что успех или неудача слишком быстро приписывается одному человеку в быстро движущейся сильно совместной маленькой команде, где заслуга и вина редко принадлежат только одному человеку.
Малый бизнес. Сочетайте любые данные доставки и качества, которые у вас уже есть (тема 2.10, тема 5.1), с прямым честным разговором о том, действительно ли недавняя работа помогла бизнесу, вместо построения формального многосигнального инструментирования, которое у вас нет возможности поддерживать.
Корпорация. Именно здесь дисциплина измерения на командном уровне с множественными сигналами оправдывает свою инвестицию, поскольку давление свести результативность к единственному сравнимому числу по десяткам команд здесь сильнее всего, а ущерб от ложной точности усугубляется по всем решениям о ресурсах организации. Явно сопротивляйтесь этому давлению и стройте многосигнальное обоснование того, почему это важно.
Государство. Демонстрация того, что инженерная инвестиция произвела реальные результаты, а не просто доставила артефакты, часто центральный вопрос, который задаёт надзорный орган. Многосигнальное измерение результативности, явно привязанное к метрикам результата (тема 5.3), а не к представителям только доставки, даёт гораздо более сильный более защитимый ответ, чем один подсчёт активности или доставки.
Примеры
Корпорация. Руководство компании розничных технологий неформально ранжировало инженерные команды по стори-пойнтам, завершённым за спринт, относясь к этому как к представителю результативности. После принятия многосигнального подхода, сочетающего данные доставки, долю неудачных изменений и принятие функции после релиза, руководство обнаружило, что команда с наивысшей скоростью завершения стори-пойнтов имела самую низкую скорость принятия функций в компании: они отгружали быстро, но строили то, что клиенты не использовали. Перераспределение приоритетов дорожной карты этой команды на основе более полной картины результативности, а не вводящего в заблуждение рейтинга по единственному числу, перенаправило значительную инженерную мощность на работу с более высоким воздействием в течение одного квартала.
Государство. Инженерной программе национального налогового агентства нужно было продемонстрировать надзорному комитету, что крупная инвестиция в системы улучшила результативность, а не просто доставила законтрактованный объём. Вместо того чтобы сообщать только о завершении стори-пойнтов или вех, программа представила сходящийся набор сигналов: сниженную частоту ошибок обработки, сниженное медианное время обработки и увеличенную успешную скорость завершения самообслуживания, все привязанные к конкретным доставленным компонентам системы. Многосигнальная привязанная к результату презентация удовлетворила проверку комитета способом, которым не смог годом ранее простой отчёт «доставлено по графику» от предыдущей программы.
Бизнес-кейс: мотивация, ROI и TCO
Отдача от измерения результативности через сходящиеся привязанные к результату сигналы, а не через единственное ложно точное число: лучшие решения о ресурсах: организация, способная видеть, чья работа команд подлинно двигает результаты, может инвестировать дальше там, где это важно, и исследовать там, где нет, вместо того чтобы вознаграждать ту команду, которая оказывается самой занятой на вид. Пример розничной торговли выше типичен: вводящий в заблуждение рейтинг по единственному числу направлял внимание инвестиций прочь от того места, где оно на самом деле помогло бы.
Полная стоимость владения выше, чем у подхода с единственной метрикой, потому что это требует сочетания данных из множественных источников (доставка, качество, результат) и сопротивления организационному давлению свернуть картину обратно в одно сравнимое число. Эта стоимость стоит того, чтобы её платить, потому что альтернатива, ложно точная единственная оценка, активно вводит в заблуждение решения о ресурсах, которые данные результативности призваны информировать.
Антипаттерны и ловушки
- Путаница активности с результативностью: самая распространённая ошибка, которую специально призвано предотвратить это измерение.
- Индивидуальное приписывание результативности для совместных межкомандных результатов: обычно ложная точность, препятствующая сотрудничеству.
- Исключение качества из определения результативности: вознаграждает работу, которая отгружается, но ломает что-то ещё.
- Навязывание метрики прямого результата платформенным или обеспечивающим командам: измеряет не то для работы, по своей сути косвенной.
- Сворачивание множественных сходящихся сигналов обратно в одно ложно точное число под организационным давлением: теряет честность, которую был призван обеспечить многосигнальный подход.
- Использование данных результативности для конкурентного ранжирования отдельных людей: вредит и честности данных, и командному сотрудничеству.
Модель зрелости
- Уровень 1, Инициация: Результативность путается с активностью или объёмом выпуска, измеряется единственным неисследованным числом.
- Уровень 2, Развитие: Некоторые сигналы качества рассматриваются наряду с выпуском, но нет последовательного многосигнального подхода, и индивидуальное приписывание всё ещё происходит неформально.
- Уровень 3, Стандартизация: Результативность измеряется на командном уровне, используя множественные сходящиеся сигналы, включая качество, последовательно по всей организации.
- Уровень 4, Управление: Расхождение между сходящимися сигналами активно исследуется; платформенные и обеспечивающие команды имеют подходяще косвенные меры результативности, соответствующие их фактической работе.
- Уровень 5, Оркестрация: Данные результативности напрямую информируют решения о ресурсах и инвестициях, и организация может указать на конкретные решения о перераспределении, которые позволил многосигнальный взгляд и которые упустил бы взгляд с единственным числом.
Идеи для обсуждения
- Какое единственное число мы сейчас используем как представителя результативности, которое следует вывести из эксплуатации в пользу сходящегося набора?
- Приписывали ли мы когда-либо результат не той команде или человеку, потому что приписывание было неясным?
- Как мы сейчас измеряем результативность платформенной или обеспечивающей команды?
- Как бы это выглядело, если бы наши сходящиеся сигналы разошлись друг с другом в следующем квартале?
- Где рейтинг по стори-пойнтам или подсчёту доставки неправильно направил внимание наших инвестиций?
Основные выводы
- Результативность измеряет, произвела ли работа хороший результат, а не сколько движения произошло; не путайте её с активностью (тема 3.4).
- Используйте множественные сходящиеся сигналы, никогда единственное число результативности, и подозревайте ложную точность.
- Измеряйте на командном или системном уровне; индивидуальное приписывание результата обычно ненадёжно и вредит сотрудничеству.
- Качество часть результативности, а не отдельная несвязанная забота.
- Давайте платформенным и обеспечивающим командам подходяще косвенные меры результативности, а не навязывайте неподходящую метрику прямого результата их работе.
Источники и дальнейшее чтение
- Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity,” ACM Queue (2021).
- Accelerate: The Science of Lean Software and DevOps, Николь Форсгрен, Джез Хамбл и Джин Ким.
- Team Topologies, Мэттью Скелтон и Мануэль Пайс.
- Measuring and Managing Performance in Organizations, Роберт Д. Остин.